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 key-generation process with a different seed every time, sooner or later you'll have the PRNG falling into an already-passed 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 multi-agent 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 multi-agent 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?"