Fwd: Any GHC plans to adopt tf-random?

Michał Pałka michal.palka at chalmers.se
Fri Nov 15 16:38:39 UTC 2013


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 <rrnewton at gmail.com>
> > Subject: Re: Any GHC plans to adopt tf-random?
> > Date: 6 november 2013 22:51:02 CET
> > To: Nicolas Frisby <nicolas.frisby at gmail.com>
> > Cc: "ghc-devs at haskell.org" <ghc-devs at haskell.org>
> > Reply-To: rrnewton at 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
> > <nicolas.frisby at gmail.com> wrote:
> >         Adding Ryan Newton to the TO field, as the maintainer of
> >         random.
> >         
> >         
> >         On Wed, Nov 6, 2013 at 2:02 PM, Nicolas Frisby
> >         <nicolas.frisby at gmail.com> 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 at haskell.org
> > http://www.haskell.org/mailman/listinfo/ghc-devs
> > 
> 
> 








More information about the ghc-devs mailing list