default random object?

[grauzone]

dsimcha wrote:
> == Quote from Walter Bright (newshound1 at digitalmars.com)'s article
>> Andrei Alexandrescu wrote:
>>> 2. The global random generator will be allocated per thread. Are you
>>> cool with this too?
>> That could have speed problems with a tight loop accessing thread local
>> storage.
> 
> I don't think this matters, since for apps that really need it, a RNG can be
> explicitly passed in.  This is purely a convenience feature for when you want
> random number generation to "just work" even if it's not the most efficient thing
> in the world.  Also, checking thread_needLock() is dirt cheap, in my experience
> faster than accessing TLS.  You could also have a global, non-thread local RNG
> that is used if a check to thread_needLock() returns false.

I don't understand this. If implemented right (D2.0 or gcc thread 
variables), TLS can be as fast as a normal global variable. You only 
need an additional check (a simple if()) to lazily initialize the RNG.

Regarding "just work": it seems D's philosophy, to prefer to do the 
simple and "right" thing instead of raw efficiency, seems to be 
abandoned. Like std.algorithm uses weird string mixins, and the 
predicate is a template argument instead of a normal one (that's IMHO).

>> If it's a shared global with no locking, the thread randomness
>> will increase its randomness <g>.

Huh, non-blocking random generators?

> Yay, D's getting hardware random number generators!!!