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.dubuisson@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