upvote

points

by dgacmu4 days ago |
comments
upvoteby saithound4 days ago|
[-]
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)

reply
upvoteby dgacmu4 days ago|
parent|
next
[-]
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. :)
reply
upvoteby 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?
reply
upvoteby saithound4 days ago|
parent|
prev|
next
[-]
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.
reply
upvoteby 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.
reply
upvoteby 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

reply