I was going to suggest something similar using seque in an atom, but
in neither case (using an atom or a ref) is the contention going to be
minimized -- just shifted from the AtomicLong in java.util.Random to
the now-app-level atom or ref.
- Chas
On Mar 26, 2010, at 12:30 AM, Andrzej wrote:
As others have pointed out using per-thread java.util.Random objects
is probably the best way to go in this particular case. However, I'm
curious if the following code could give any speed gain on your
machine:
(defn rand-seq [] (repeatedly #(. Math (random))))
(def rand-seq-ref (ref (rand-seq)))
(nth @rand-seq-ref 100) ;; pre-cache random values; evaluate it
every some time
;;btw, how to do it automatically?
(defn next-rand-val []
(dosync (commute rand-seq-ref next) (first @rand-seq-ref)))
user=> (next-random-val)
0.5558267606843464
user=> (next-random-val)
0.32353157456467474
Cheers,
Andrzej
On Fri, Mar 26, 2010 at 11: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.
