Cool, that's much better. Can we establish that all (or all important)
Java 5+ VMs use AtomicLong in next?
> Ah, I didn't see the call to next. The java docs do say that is the
> implementation for that method, but they are lying:
>
> protected int next(int bits) {
> long oldseed, nextseed;
> AtomicLong seed = this.seed;
> do {
> oldseed = seed.get();
> nextseed = (oldseed * multiplier + addend) & mask;
> } while (!seed.compareAndSet(oldseed, nextseed));
> return (int)(nextseed >>> (48 - bits));
> }
>
> On Dec 2, 8:05 am, Stuart Halloway <[EMAIL PROTECTED]> wrote:
>> nextDouble calls next, which according to Java 5 docs is:
>>
>> synchronized protected int next(int bits) {
>> seed = (seed * 0x5DEECE66DL + 0xBL) & ((1L << 48) - 1);
>> return (int)(seed >>> (48 - bits));
>> }
>>
>> This is exactly the kind of thing I think we shouldn't have to worry
>> about in Clojure.
>>
>> Stuart
>>
>>> Looks like the only synchronization is for lazy initialization of
>>> the
>>> instance of Random used by the static method:
>>
>>> public final class Math {
>>
>>> private static Random randomNumberGenerator;
>>
>>> private static synchronized void initRNG() {
>>> if (randomNumberGenerator == null)
>>> randomNumberGenerator = new Random();
>>> }
>>
>>> public static double random() {
>>> if (randomNumberGenerator == null) initRNG();
>>> return randomNumberGenerator.nextDouble();
>>> }
>>
>>> }
>>
>>> public class Random implements java.io.Serializable {
>>> public Random() { this(++seedUniquifier + System.nanoTime()); }
>>> private static volatile long seedUniquifier = 8682522807148012L;
>>
>>> public double nextDouble() {
>>> long l = ((long)(next(26)) << 27) + next(27);
>>> return l / (double)(1L << 53);
>>> }
>>> }
>>
>>> On Dec 2, 12:04 am, Stuart Halloway <[EMAIL PROTECTED]>
>>> wrote:
>>>> Clojure's rand delegates to Java's Math.random(), which I am pretty
>>>> sure has a synchronized block in it.
>>
>>>> One problem with living on top of Java is calling into methods that
>>>> have no (conceptual) need to be synchronized. This could hurt
>>>> performance in an app carefully written in Clojure to avoid mutable
>>>> state and locking. Since unsynchronized PRNGs exist, I would
>>>> suggest
>>>> we modify rand to use one. (I am willing to take the lead on
>>>> writing
>>>> one in Clojure if needed.)
>>
>>>> Thoughts?
>>
>>>> Stuart
> >
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
