dsimcha wrote:
== Quote from Walter Bright (newshou...@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!!!

Reply via email to