Thanks Carl and Robby for the explanations. I'm learning a great deal.
I'm working with Tim Brown to learn how to use places.
-Joe
On Thu, Jul 25, 2013 at 11:36 PM, Carl Eastlund wrote:
> Joe,
>
> There are multiple concurrency and parallelism tools in Racket. If you
> want concurrency but
Yes, that's the point: parallelism (for speed) and concurrency (for ease of
programming) are completely different things and a progress meter needs
only the latter, which is very well supported in Racket via events and
threads and friends.
Continuing what Carl wrote: in addition to the GC issues,
Joe,
There are multiple concurrency and parallelism tools in Racket. If you
want concurrency but aren't concerned about parallelism, there are software
threads in Racket that will all run in the same OS thread (
http://docs.racket-lang.org/reference/threads.html). If you want a tool
that support
Hi Robby,
Please pardon my ignorance, but is there an easy to use thread library with
Racket? I've used threads in other environments and I don't recall so many
restrictions.
For example, how would you do something like a %-done meter if you have
very limited ability to instrument the code you a
hashes are definitely not future-safe, unfortunately.
Robby
On Thu, Jul 25, 2013 at 6:50 PM, Joe Gilray wrote:
> Here is an update:
>
> I rewrote gcd and used a hash-table for the squares check. The hash-table
> change sped up the sequential code about 10x! Then I tried using future /
> touc
Here is an update:
I rewrote gcd and used a hash-table for the squares check. The hash-table
change sped up the sequential code about 10x! Then I tried using future /
touch and it seems to improve the performance a little, but there is quite
a bit of blocking (on >= and hash-ref) still.
New cod
Thanks for your help James. Let me know what you learn. I will try to
rewrite those routines. As indicated for (square? ) I will need to make a
table which will slow things down further :-(
About typed racket: my goal is to learn, so I have played with typed racket
but didn't get very far (mayb
Unfortunately, it is still rather easy to stumble upon a primitive which
unexpectedly blocks futures.
Are you familiar with Typed Racket? Switching to typed can give you
performance improvements even in sequential programs. In futures programs,
TR can help you avoid blocks because it uses its ex
I created a "place farm" for just those occasions when I had more
processors than mathematical insight on Project Euler.
I submitted a bug (long since fixed) a while back, using the place farm
code; where sync failed under stress. And I stopped using it a while ago.
It's rough... old... and poor
You might try places. Writing your own gcd seems straightforward. I'm not
sure about integer-sqrt?, tho. Maybe you could make a table or something if
you know there are not that many numbers.
Or maybe someone will adjust the runtime to make those future safe!
Robby
On Wed, Jul 24, 2013 at 11:34
So I should write my own (gcd ) and (square? ) functions?
I can try that, but isn't there a simple way to use threads?
Thanks,
-Joe
On Wed, Jul 24, 2013 at 7:47 PM, Robby Findler
wrote:
> When I run this, the future visualizer shows that gcd and square-number?
> block the futures. square
When I run this, the future visualizer shows that gcd and square-number?
block the futures. square-number? is implemented in TR and if you take it,
you find that integer-sqrt also blocks the futures. I'm not sure if those
functions can be made to run safely in futures or not.
Robby
On Wed, Jul 2
I have a ProjectEuler problem that I wanted to speed up so I thought I
would try to speed it up with future / touch.
I tried the following:
; function that searches for progressive numbers for a given range of b
values
(define (find-progressive-num b-start b-end b-incr lim)
(for/sum ([b (in-ran
13 matches
Mail list logo
