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 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