You are all missing the point of my benchmark, which was to get at the speed the raw ALGORITHM goes. It is SIMPLY one AES encrypt per 16 bytes of output.
My approach was a back-of-the-napkin to show what my crappy machine does when there's very little overhead EXCEPT the encryption operation. But on any desktop or better architecture, the hardware support has long enabled rates north of a gigabit per second, and generally, FAR better. For isntance, AMD's Ryzen can top 15 gigabits per second. <https://www.vortez.net/articles_pages/amd_ryzen_7_1700x_review,7.html> You can ALWAYS do a lot to slow ANY PRNG down, like make a ton of unnecessary system calls. Still, it would be relatively easy to provide secure random numbers by default. It can be done... you all are measuring a ton of overhead from other things, which can all be controlled. Also, the reason some of you see a performance difference between /dev/urandom and /dev/random, and some of you don't: Linux used to have a pretty old school approach to things, and /dev/urandom was different and slower than /dev/random. There was pretty much never a good reason to call /dev/random on a box with the old implementation. The whole subsystem was rebuilt, and they do the same thing now, but both devices remain. And, the whole subsystem is far more sane and efficient than it used to be, as well.
