Some of the comments from the users

"MT19937B with my optimizations takes 83% less time than ran2() from Numerical
Recipies, which we had been using. Random number generation was a significant
component of our DSMC application. Switching RNG's therefore reduced
execution time for a 17% reduction in runtime for our full application on a
typical problem. Since we usually run jobs for weeks on supercomputers, this
translates directly into real time and money savings."
(From Hawk: Direct Simulation Monte Carlo application for plasma simulation.
Scalable Concurrent Programming Laboratory, Syracuse University.)

"I am a student interested in RNGs for crypto applications. I stumbled upon
your mt19937b PRNG on the web and I am testing it to check whether it's
suitable or not to key generation. Previously I tried other PRNGs but
unfortunately they weren't good enough, mainly because (I guess) of short
cycles. The problems arise when you try to periodically reseed the PRNG:
even if you start the keygeneration process with a different seed every
time, sooner or later you'll have the PRNG falling into an alreadypassed
state eventually obtaining the same key as before... Are the short cycles
to blame?.
Anyway this didn't happen so far with your mt19937b generator and I would
be glad to know the reason of this improvement, namely: are you sure that
reseeding your PRNG with *different* seeds (32 bit) I'll get a totally
different output stream every time?"
Answer: the probability to get an overlapping sequences
is very very very small, negligiblly small.

"I've been seeing good results from your mt19937b RNG in the simulation
of a small multiagent system for which many other generators have
been giving poor to marginal results. The RNG is being used to help
verify probabilistic calculations for this multiagent system which
give an accurate reference for comparison. Some initially worrying
discrepancies disappeared when using mt19937b, so I'm quite grateful
for you contribution.
My work uses the CMU Common Lisp language and your algorithm has been
implemented in lisp. A small change was made to the implementation of
the tempering calculations to avoid overflowing 32bit numbers (the
algorithm is unchanged). To further enhance performance an Intel x86
specific version has also been written, which runs about 33% faster
than optimised C.
...
I'm currently helping to maintain CMUCL and since mt19937b seems to be
performing well (and is faster) I was wondering if you would recommend
and give permission to use mt19937b as the basis of a revised RNG for
CMUCL which is distributed as public domain code?"