faster ziggurat-like methods about ng-numpy-randomstate

[bashtage]

Looks interesting. The exponential definitely should make it in.

[bashtage]

Some quick benchmarks for normal in Python. Generating 1000000

fast-prng: 70ms
randomstate (mt19937): 135ms
randomstate (dsfmt): 35ms
randomstate (xoroshiro): 23ms

The mt19937 in randomstate cannot change due to upstream compatibility. This said, the implementation in randomstate when using a good core PRNG is already 3 times faster than fast-prng.

[bashtage]

These were testes using the just released 1.11.3.

[bashtage]

I made a mistake in my previosu benchmarks -- fast PRNG is faster in normals as you say. I differed the numbers of prndoms generated by a factor of 10.

[bashtage]

fast-prng uses a very fast, inlined core PRNG. This seems to be the source of most of the gains.

Time in ns/observation when producing 10,000,000

                     Uniform           Normal
fast-prng               3.91             6.16
xoroshiro               3.95             8.89

This suggests the Ziggurat implementation is around 100((8.89-3.95)/(6.16-3.91) - 1) = 119% faster, or about double performance.

I suspect all of the apparatus in the abstraction needed to handle lots of different PRNGs is a non-trivial source of the performance difference.

[anntzer]

I think fast_prng is just using MT19937 (https://bitbucket.org/cdmcfarland/fast_prng/src/b132857f4f040b53516c1b404ade67871c7807d4/shared.h?fileviewer=file-view-default#shared.h-6), so the overhead, if any, comes from the PRNG dispatch?

[bashtage]

It looks to be using a simd aware MT19937 which is a precursor to dSFMT.
There are a lot of difference that help performance of fast prng such as
having a smaller state and having the only state global to the module. I
don't see any easy way to try and utilize these optimizations while keeping
all of the structure and backward compatibility of a numpy-esque
randomstate.

This said I can try and port over the ziggurat implementation to see how it
goes. I already have 3 or 4 different versions in the code. And the
exponential ziggurat is also a very good idea.

On Fri, Jul 15, 2016, 8:02 PM Antony Lee [email protected] wrote:

I think fast_prng is just using MT19937 (
https://bitbucket.org/cdmcfarland/fast_prng/src/b132857f4f040b53516c1b404ade67871c7807d4/shared.h?fileviewer=file-view-default#shared.h-6),
so the overhead, if any, comes from the PRNG dispatch?

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#64 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFU5RdfdHM5yacHqpyrcZdWgEjtXIa7-ks5qV9lFgaJpZM4JNCWx
.

[anntzer]

On my laptop xoroshiro seems ~26% slower than the inline fast_prng; I guess that's an acceptable cost for the additional functionailities in randomstate.

[bashtage]

I'm going to close this. I've added ziggurat for Normal and Exponential and implicitly for Gamma (which depends on normal and exponential). The fast_prng is definitely very fast and uses an improved but more complicated sampler to avoid the expensive rejection sampling. This said, the gap is now quite small (say 6.5ns/normal vs 9ns/normal, which are both much faster than NumPy's 70ns/normal). The exponential gain is even larger, with the Ziggurat about 10x faster on Linux.