Hi Thomas, Personally, I would love to see that happen. It seems like the best way to make split acceptable.
Is Brian Gladman's C implementation still best in class? In my tests even without AESNI it could exceed the traditional System.Random in performance ( https://github.com/rrnewton/intel-aes/wiki), while providing much better randomness and splitability. Re: AESNI, my attempt at using the Intel provided asm for this introduced build fragility. What would be the more portable way to do it? Rewrite it using GCC intrinsics? http://tab.snarc.org/posts/technical/2012-04-12-aes-intrinsics.html -Ryan On Thu, May 3, 2012 at 7:43 PM, Thomas DuBuisson <thomas.dubuis...@gmail.com > wrote: > Ryan, > I've grown annoyed at System.Random enough (specifically, StdGen). > How much, if any, pushback would there be if I put together a FFI > binding to a C AES-CTR based RNG. There are many advantages: > > 0) The API wouldn't have to change (though some parts should, and some > change is already planned) > 1) It can be fast (maybe not MT fast, but really quite good) > 2) It's secure and the splitting properties can be related to > cryptographic problems. > 3) It could use Intel NI instructions when available. > 4) It's NIST standardized, so there exist known answer tests. > 5) We could expose a method to fill an arbitrary buffer :: Storable a > => Ptr a -> Int -> IO () > 6) The rest of the community doesn't have to do any of the work. > > I'd be tempted to pull in the 'entropy' package for seeding, but will > make that a separate proposal. > > Cheers, > Thomas >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe