does java.security.SecureRandom have the same problem?
I have been using it for evolutionary algorithms, but have noticed
bottlenecks (likely mostly because my fitness evaluations are
computationally expensive).
You can implement it as such:
(import '(java.security SecureRandom))
(defn srand
mac: Thanks for that -- it's a pointer to one of my own former students, who I
should be bugging about this stuff :-)
-Lee
On Mar 26, 2010, at 3:30 AM, mac wrote:
> There is a fast Java version of Mersenne Twister here, if you feel
> like compiling a java file:
> http://cs.gmu.edu/~sean/resea
Interesting blog post, Chas, which led me to doall some of my lazy sequences
(not 100% sure I caught them all) and in the process I also found another
source of contention that I removed (over a Date object).
But I'm still having contention somewhere that I can't find.
Is there a tool that wi
On Fri, Mar 26, 2010 at 9:55 AM, Chas Emerick wrote:
> 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 co
Just as long as your binding form is within the function body, you're
good to go. e.g., you need to do this (or its equivalent):
(send some-agent #(binding [random-state (Random.)] (other-fns %&)))
*not* this:
(binding [random-state (Random.)]
(send some-agent other-fns))
The latter will
Thanks all for the quick and helpful responses on the issues with rand-int/rand
and concurrency.
I probably have some other issues that are also gumming up some of my
concurrency, but following the advice on of creating per-thread
java.util.Random objects *seems* to have helped, although it's
There is a fast Java version of Mersenne Twister here, if you feel
like compiling a java file:
http://cs.gmu.edu/~sean/research/
On 26 mar, 05:43, Chas Emerick wrote:
> I was going to suggest something similar using seque in an atom, but
> in neither case (using an atom or a ref) is the conten
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)))
As for the problems debugging code that calls nextInt, call setSeed
with an arbitrary number at startup.
After setting setSeed the sequence of ints returned will be the same
every run.
You may have trouble if you don't have any synchronization between
threads.
It could still have race conditions f
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-numbe
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 genera
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 g
13 matches
Mail list logo
