undefined

points

[-]

> Sorry, nobody does stochastic simulations where the number of uniform random numbers obtained per second is any sort of bottleneck. If you've spent considerable time on stochastic simulation, you already know this.

Actually, I spent a considerable amount of time in my doctorate and postdoc doing this.

Any kind of MCMC sampling of a simple model tends to be bound by the rate you can draw variates.

Examples of this include: Gillespie simulations of chemical kinetics, Ising and Potts lattice models (including their roughly bazillion variations), and anything resembling bootstrap or permutation sampling.

Just because your problems aren’t bound by the rate of drawing uniform variates doesn’t mean that these problems don’t exist. It just means that you have a narrow view.

by kbolino3 days ago|

prev|

[-]

Whether your recommendation is valid seems to be quite CPU-dependent. Cf:

  cpu: AMD Ryzen 5 5600X 6-Core Processor             
  BenchmarkAES_CBC-12             100000000               10.96 ns/op
  BenchmarkAES_CTR-12             83161234                14.36 ns/op
  BenchmarkPCG-12                 345336063                3.463 ns/op
  BenchmarkChaCha8-12             174143492                6.894 ns/op
  BenchmarkXoshiro256p-12         254343658                4.717 ns/op
  BenchmarkXoshiro256pp-12        266837442                4.496 ns/op

vs.

  cpu: Apple M4 Pro
  BenchmarkAES_CBC-14             162698020                7.370 ns/op
  BenchmarkAES_CTR-14             242501074                4.954 ns/op
  BenchmarkPCG-14                 197000988                6.083 ns/op
  BenchmarkChaCha8-14             237430095                5.050 ns/op
  BenchmarkXoshiro256p-14         252911710                4.738 ns/op
  BenchmarkXoshiro256pp-14        252656401                4.745 ns/op

Code: https://gist.github.com/kbolino/afbb86f3c9b2bd2f87272801d156...

by dgacmu4 days ago|

prev|

[-]

This is a very weird hill to die on.

I do a lot of testing and designing of things like hash tables and filters, and having a really fast, non-CS generator is incredibly useful for being able to clearly identify performance bottlenecks in designs. PCG has been spectacularly useful for that purpose for me.

by saithound4 days ago|

parent|

[-]

When was the last time a new PRNG helped you clearly identify a performance bottleneck?

As in, you were using state of the art generator X, and you couldn't see the performance bottleneck, but updating to a newer (faster, or same speed but higher quality) generator Y, and could subsequently identify the performance bottleneck?

If you're using PCG, not in the last 12 years.

(In a parallel comment I suggest trying AES-CTR for this use case)

by dgacmu4 days ago|

parent|

[-]

It's not critical but if you gave me something that behaved statistically like PCG (i.e., I didn't fret about whether it was going to cause me weird problems) but was twice as fast I'd be happy and would shift to it - it would speed up profiling and measuring and that would be nice. We still find ourselves often pre-generating a list into memory to keep the prng entirely off of the measurement path. It wouldn't be magic, but I don't need magic. I like nice things that make my life a little easier in a small corner of my research. :)

by Straw4 days ago|

parent|

[-]

Most modern RNGs should be faster than memory bandwidth (when optimized), so unless your list is small enough to fit in cache, its unclear if this is faster?

by saithound4 days ago|

parent|

prev|

[-]

dgacmu: if you're writing C on x64, try AES-128-CTR (AES-NI, 8 way) using the header wmmintrin.h which has hardware accelerated primitives for this. An LLM can implement the RNG for you based on this comment if you want to test it out quickly. It should be faster than PCG, and higher quality.

by dgacmu4 days ago|

parent|

[-]

Will do. I'm on vacation right now and losing my laptop for a few days, but seems worth trying. My recollection from the RNGs a decade ago (I'm dating myself) was that the AES approaches had higher latency but were quite decent, though slower than PCG. Curious how that's evolved.

by magicalhippo4 days ago|

parent|

prev|

[-]

> When was the last time a new PRNG helped you clearly identify a performance bottleneck?

While not a bottleneck as such, I contributed to a photorealistic path tracer using the Metropolis algorithm[1], and we got a 10-15% increase in samples/second when we switched from a decent to a much faster and better PRNG. Like you we didn't think the performance of it mattered much until we profiled it.

Granted this was a decade or so ago, would be interesting to compare the state of the art PRNGs.

Anyway, just pointing out that there can be real-world cases.

[1]: https://en.wikipedia.org/wiki/Metropolis_light_transport

by SideQuark3 hours ago|

prev|

[-]

As others here have pointed out, this is nonsense. The vast majority of PRNG calls on the planet are extremely high perf simulations, where crypto secure versions are a ludicrous cost in speed, energy, and sheer stupidity. That you and others do not understand is simply because you don’t see the places it’s required.

I’ve a PhD, have written papers on PRNGs, have worked in both cs prng and high perf prngs, have done decades of HPC projects, scientific sims. I get called in to develop precisely these high performance systems, and when you want to replace trillions to quadrillions of PRNG calls with one costing 10-1000x more, you’d get deservedly fired immediately.

You keep arguing about AES style code on a CPU. That’s not where people do high performance code. Try implementing AES and a fast prng on a GPU. You’ll soon find out how absolutely terrible cs-prngs are at performance. The measuremt isn’t how many ns per prng. It becomes how many thousands of prng generated per ns.

It’s bafflingly shortsighted for people with zero work in this area to continue to argue this. Choose the right tool for the job. Don’t project ignorance as knowledge. Both are useful advice.