Hi Leigh, I need to change stance wrt MT.
On 6/16/16, 2:31 PM, "Leigh" <lei...@gmail.com> wrote: >I get your point, but most people probably use mt_rand() because "it's >better than rand". mt_rand is also incredibly slow and has a huge state >when compared to modern algorithms. I should probably note the >performance gains in the RFC. I spent some time trying to understand the weird PHP mt_rand(). I took the binary MT19937_02 generator from TestU01 and made a variant with the PHP bug. I added side-by-side diff off the results from running BigCrush on both here https://gist.github.com/tom--/a12175047578b3ae9ef8 I can't see any significant difference between. More interesting was how this work changed my appreciation of Mersenne Twister. I used to think it was a good RNG. But that dates back a long time to when George Marsaglia had the best tests for RNGs and he was challenging sci.math to factor enormous numbers to use in new generators with ever more extravagant periods. I took it on authority that MT was decent. But after spending time with the code I see you're right! Its state and period are crazy. It's one thing to be slow but on top of that it's chewing up cache lines as though nothing else needs them. My opinion on rand() is that it is historical, like the crummy old RNGs kicking around in various libcs and elsewhere. Don't use them. Now I feel the same about mt_rand() -- like MD4 and DES, it's interesting history. I think every self-respecting programming environment should provide a good deterministic RNG. And now it seems I've persuaded myself that it's time time for PHP to move on from MT. So I need to update my opinion on your RFC. I still think rand() and mt_rand() implementations can stay but I now agree with you that it's time for a new RNG. And I agree that xoroshiro128+ is a good choice. Specifically, rand() docs should say that the underlying RNGs are obsolete, not portable and have questionable quality on some platforms. mt_rand() docs should mention the poor performance and reference #71152. Tom -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
