Hello Ryan and Nicolas, I'm happy to see some interest in the tf-random package. The package has not been extensively tested. I ran it on x86-64 and x86 Linux, and on x86 Windows. It would be good to check if it gives the same results on a big-endian architecture, such as ARM, however I don't have access to such a machine. When it comes to the performance, it is good on x86-64, but significantly slower on x86, and probably on other 32-bit architectures, because the cipher's code is optimised for 64-bit arithmetic. It may be possible to use a 32-bit optimised version for the 32-bit architectures to mitigate that, but that would mean even more C code to review. Another issue is whether to change the RandomGen/Random API, which might be considered at the same time. The current Random instances are slow, suffer from the modulo bias, and work only when the range of numbers returned by the generator is (0, 2147483562). However, I am aware that the disturbance would potentially be much larger if the API is changed, so doing it may need some planning. Ideally, it would be nice if people started using the package and see how it performs in practice before any decisions are made. Best regards, Michał

Begin forwarded message:

...

From: Ryan Newton Subject: Re: Any GHC plans to adopt tf-random? Date: 6 november 2013 22:51:02 CET To: Nicolas Frisby Cc: "ghc-devs@haskell.org" Reply-To: rrnewton@gmail.com

...

Hi all,

...

It looks like since the paper has come out the code has been released to Hackage. I personally would love to replace System.Random with something like this.

...

I think the question of whether it's time comes down to some due-diligence issues outside the scope of the paper. This library has C code, have people tested it extensively on Mac/Linux/Windows? Does it have any performance divots we should know about? (Though the performance of the legacy implementation was bad in many respects -- it is a low bar.)

...

-Ryan

...

On Wed, Nov 6, 2013 at 3:12 PM, Nicolas Frisby wrote: Adding Ryan Newton to the TO field, as the maintainer of random.

On Wed, Nov 6, 2013 at 2:02 PM, Nicolas Frisby wrote: Bugs #3575 #3620 have to do with splitting StdGens yielding dependent generators.

The Haskell 2013 paper Splittable Pseudorandom Number Generators Using Cryptographic Hashing by Claessen and Pałka yielded the tf-random package on Hackage.

Are there any plans to integrate these corrections into System.Random?

...

Thanks.

...

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs