Clojure calls out to Java's java.lang.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."
Look at java.util.Random for local RNGs. In the long term, it might make sense for core's rand to refer to a *random-number-generator* var that defaults to a shared thread-safe RNG but can be rebound per thread in cases like yours to reduce contention. In the short term, you can just write your own wrapper functions. -Per On Fri, Mar 26, 2010 at 9:35 AM, Lee Spector <[email protected]> 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. > -- 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.
