
Billions of Random Numbers in a Blink of an Eye - tosh
https://dragan.rocks/articles/19/Billion-random-numbers-blink-eye-Clojure
======
dragandj
Maybe also worth checking out are two books that I'm writing right now where
this is used and explained in more detail:

[https://aiprobook.com](https://aiprobook.com)

Deep Learning for Programmers at [https://aiprobook.com/deep-learning-for-
programmers/](https://aiprobook.com/deep-learning-for-programmers/)

Numerical Linear Algebra for Programmers at [https://aiprobook.com/numerical-
linear-algebra-for-programme...](https://aiprobook.com/numerical-linear-
algebra-for-programmers)

Everything uses open source software:

[https://github.com/uncomplicate](https://github.com/uncomplicate)

~~~
cbzbc
All the best with making it work for you - but for me that pricing strategy
would seem to make for a very expensive book.

~~~
dragandj
If I could sell a million copies, I would be gladly selling them for $1 each.
However, since these are unique books for specialists, the potential audience
is more limited, which unfortunately requires that they cost a bit more.

------
tptacek
Just for what it's worth: it's not that cryptography needs difficult-to-
generate "true" random numbers, but rather that it needs a particular kind of
pseudorandomness. The best mental model to have of crypto-randomness is that
it's seeded from events unpredictable enough to be effectively secret; a
typical CSPRNG is, in fact, essentially a stream cipher that uses "entropy"
(again, those unpredictable events) as its key.

Once you've got it seeded, you can get random numbers from your system's
platform CSPRNG plenty fast, and CSPRNGs make, for most applications, a
reasonable default RNG.

~~~
FabHK
1\. Agreed that CSPRNG are fast enough for most purposes, and should be the
default PRNG basically everywhere.

2\. The magic ingredients of a CSPRNG are not only the "secret entropy" for
seeding, but also the property that given a sequence of its outputs, it's
sufficiently hard to predict the next output (this implies that it won't fail
the usual statistical tests - every CSPRNG is a PRNG, but not vice versa: for
example, with 624 outputs of the Mersenne Twister, you can predict all
subsequent ones.)

This _next-bit test_ property was sort of implied (by saying "stream cipher"),
but I wanted to spell it out, as it's good to have in one's mental model.

3\. For some purposes (such as Monte Carlo simulations), a non-CSPRNG makes
sense, as they're still faster. (But given the asymmetric payoffs of a
mistake, default should be CSPRNG.)

~~~
tgsovlerkhgsel
> a non-CSPRNG makes sense, as they're still faster

Nowadays with highly optimized and often hardware-accelerated crypto, I
honestly doubt it matters.

Using "openssl rand", I can generate randomness 2x as fast as with a naive

    
    
      while (1) { r = rand(); fwrite(&r, 4, 1, stdout); }
    

compiled with -O2. If I replace "openssl rand" with "openssl enc -aes-128-ctr
< /dev/zero", I get randomness 4 times faster again, i.e. _8 times_ as fast as
with the naive approach using rand(), hundreds of megabytes on a single core.

And I don't have to worry about the properties of the PRNG.

~~~
ahh
Fair, but rand() is kinda trashy, and the overwhelming part of that cost is
fwrite anyway.

~~~
tgsovlerkhgsel
A large part of the cost being "not random number generation" is part of the
point - speed of random number generation generally doesn't matter compared to
the speed of what you do with the numbers, and optimizing other things, e.g.
how to get the bits converted to random numbers usable by an application, are
much more important than quickly generating the random bits.

------
velosol
I was curious what PRNG was being used and it was a bit deep in the post, but
it appears to be Philox [1] or ARS5 [2].

[1]: [http://michaelbrundage.com/note/2005/01/05/random-number-
gen...](http://michaelbrundage.com/note/2005/01/05/random-number-generation/)

[2]: [https://software.intel.com/en-
us/node/590411](https://software.intel.com/en-us/node/590411)

~~~
FabHK
Yes, both part of John Salmon, D. E. Shaw et al.'s Random123 suite. I am
actually surprised that they're so fast, I'd have thought that PCG or the
xoroshiro family is faster. But then, none of them are CSPRNG.

[https://www.deshawresearch.com/resources_random123.html](https://www.deshawresearch.com/resources_random123.html)

[http://www.thesalmons.org/john/random123/releases/1.00/docs/...](http://www.thesalmons.org/john/random123/releases/1.00/docs/index.html)

[http://www.thesalmons.org/john/random123/papers/random123sc1...](http://www.thesalmons.org/john/random123/papers/random123sc11.pdf)

------
debbiedowner
I was surprised, but I guess everything is working near optimally.

1 Billion 32 bit numbers in 347 ms is 23 G Bytes/s. In 40ms is 200 G Bytes/s.
DDR4 is 26 G Bytes per second. And Nvidia GPUs do indeed have over 200 G
Bytes/s: [https://www.microway.com/knowledge-center-
articles/compariso...](https://www.microway.com/knowledge-center-
articles/comparison-of-nvidia-geforce-gpus-and-nvidia-tesla-gpus/)

------
thisguy47
Am I missing something? With numpy on my 2017 Macbook Pro, I can generate 1B
random, normally distributed numbers on a CPU in ~1.3 microseconds.

In [3]: %timeit np.random.normal(1000000000)

1.3 µs ± 26.2 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)

Edit: and 2.5e17 in ~7.95 microseconds

In [5]: %timeit np.random.normal((500000000, 500000000))

7.95 µs ± 90.7 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)

~~~
nimih
You might be misremembering the numpy.random api, since you appear to only be
generating one or two random numbers in your tests.

I get results about 100x slower those of the article's CPU benchmark when
using numpy on a 2019 MBP:

    
    
      python -m timeit -s 'import numpy as np; x = np.zeros(1000000)' -u msec 'np.random.normal(x)'
      10 loops, best of 5: 30.9 msec per loop
    

edit: I'm no python wizard myself, so I'm perfectly willing to believe that
there's a better way to generate a random array in numpy than what I'm doing.

------
bfuller
Unrelated by I'll ask anyway: Does anyone know of a way to get high bandwidth
quantum random numbers for cheap? I am using ANU's service but its not enough
to scale, and it seems quantum random numbers are sort of expensive to
produce.

~~~
tatersolid
Why, exactly do you need “quantum random numbers”?

For any conceivable application, you just need 256 bits of entropy and a good
CSPRNG.
[https://blog.cr.yp.to/20170723-random.html](https://blog.cr.yp.to/20170723-random.html)

------
johnmarcus
but can i use it to mine bitcoin?

