Hi Lee,
Indeed -- from the docs for Math.random():
"This method is properly synchronized to allow correct use by more
than one thread. However, if many threads need to generate
pseudorandom numbers at a great rate, it may reduce contention for
each thread to have its own pseudorandom-number generator."
At its root, java.util.Random uses an AtomicLong to store the last
dispensed pseduorandom number, so that is the fundamental point of
contention (all of your threads are blocking on a CAS on a single atom
in the Math class' Random instance).
You can certainly have a Random instance per-thread -- when you set up
each thread of execution (in a send to an agent, at the start of the
fn that you're pmap'ing across a dataset, whatever), just bind a new
java.util.Random to a var, and have all your code pull random numbers
from there.
- Chas
On Mar 25, 2010, at 10:35 PM, Lee Spector wrote:
I'm trying to track down the reason that I sometimes see a lot of
concurrency in my system (up to 1200% CPU utilization on a dual
quadcore mac that also has some kind of hyperthreading, allegedly
allowing a maximum of 1600% CPU) while other times it gets stuck at
around 100-200%. My system (a genetic programming system) has a
*lot* of randomness in it, so it's hard to repeat runs and get a
firm handle on what's going on.
But after a bunch of testing I'm beginning to suspect that it might
be the random number generator itself (clojure-core/rand-int in this
case, which calls (. Math (random))). This seems at least somewhat
plausible to me because I guess that the underlying Java random
method must be accessing and updating a random number generator
state, and so this would be a concurrency bottleneck. So if I'm in a
condition in which lots of concurrent threads are all calling rand-
int a lot then all of the accesses to the state have to be
serialized and my concurrency suffers (a lot).
Does this sound plausible to you? If so, is there a straightforward
way to avoid it? It is not important to me that the random numbers
being generated in different threads be generated from the same
generator or coordinated/seeded in any way. I just need lots of
numbers that are "random enough." I guess I could roll my own random
number generator(s) and either have a lot of them with independent
states or maybe even make them stateless (always generating numbers
by scrambling the clock?). But I would hope there would be something
simpler.
Thanks,
-Lee
--
Lee Spector, Professor of Computer Science
School of Cognitive Science, Hampshire College
893 West Street, Amherst, MA 01002-3359
[email protected], http://hampshire.edu/lspector/
Phone: 413-559-5352, Fax: 413-559-5438
Check out Genetic Programming and Evolvable Machines:
http://www.springer.com/10710 - http://gpemjournal.blogspot.com/
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to [email protected]
Note that posts from new members are moderated - please be patient with your
first post.
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
To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or
reply to this email with the words "REMOVE ME" as the subject.
