My reading is that the first 4 are pure C, presumably using the standard practice of inclining so as to make the tightest loop possible, and to allow the compiler to make other optimizations.  The final line is what happens when you replace the existing ziggurat in NumPy with the new one. I read it this way since it has both “new” and “old” with numpy. If it isn’t this, then I’m unsure what “new” and “old” could mean in the context of this thread.

 

I suppose camel-cdr can clarify what was actually done.

 

Kevin

 

 

From: Robert Kern
Sent: Monday, February 8, 2021 3:41 PM
To: Discussion of Numerical Python
Subject: Re: [Numpy-discussion] Question about optimizing random_standard_normal

 

On Mon, Feb 8, 2021 at 3:05 AM Kevin Sheppard <kevin.k.shepp...@gmail.com> wrote:

If I understand correctly, there is no gain when applying this patch to Generator.  I'm not that surprised that this is the case since the compiler is much more limited in when it can do in Generator than what it can when filling a large array directly with functions available for inlining and unrolling. Again, if I understand correctly I think it will be difficult to justify breaking the stream for a negligible gain in performance.

 

Can you explain your understanding of the benchmark results? To me, it looks like nearly a 2x improvement with the faster BitGenerators (our default PCG64 and SFC64). That may or may not worth breaking the stream, but it's far from negligible.

But I did run the built-in benchmark: ./runtests.py --bench bench_random.RNG.time_normal_zig and the results are:

 

              new           old

PCG64      589±3μs     1.06±0.03ms

MT19937     985±4μs     1.44±0.01ms

Philox     981±30μs    1.39±0.01ms

SFC64      508±4μs       900±4μs

numpy    2.99±0.06ms   2.98±0.01ms # no change for /dev/urandom

 

--

Robert Kern

 

_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Reply via email to