Java does thread protect, but it is synchronized. Also java.math and
java.util's random number generator aren't pluggable with alternate
implementations. For that I would need SecureRandom.
For my simple example I think I will use a per-thread
java.util.Random, note the issues, and point interested readers to the
literature.
This has me wondering: should Clojure's rand and rand-int default to
use a thread-bound instance of java.util.Random?
Stuart
> On Oct 27, 7:06 pm, Stuart Halloway <[EMAIL PROTECTED]> wrote:
>> ; take samples, tracking number that land
>> ; :in circle and :total number
>> (defn sample-for-pi [count]
>> (reduce (fn [{in :in total :total} point]
>> {:in (if (in-circle? point) (inc in) in)
>> :total (inc total)})
>> {:in 0 :total 0}
>> (take count (repeatedly random-point))))
>
> You'll need to use a different pseudorandom number generator /
> pseudorandom stream for each thread. Otherwise adding more threads
> won't help performance much, because they will serialize on the PRNG.
> (Hopefully Java thread-protects the PRNG's state -- the C library
> doesn't, which makes for interesting errors ;-) .) Using Pthread
> mutexes to protect the thread state, in a C implementation of a Monte
> Carlo method on an 8-core 2-socket recent Intel box, I was only able
> to get 2x speedup. (For game tree search I can get 8x speedup on the
> same machine.)
>
> Check out the following parallel PRNG tutorial for more info:
>
> http://www.cs.berkeley.edu/~mhoemmen/cs194/Tutorials/prng.pdf
>
> mfh
> >
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~----------~----~----~----~------~----~------~--~---
