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!!!