Fast, High-Quality Pseudo-Random Numbers for Non-Cryptographers in C++ - Roth Michaels - CppCon 2022

cppcon.org/
---
Fast, High-Quality Pseudo-Random Numbers for Non-Cryptographers in C++ - Roth Michaels - CppCon 2022
github.com/Cpp...
Many C++ developers reach for std::rand() the first time they need a pseudo-random number. Later they may learn of its downsides and include ＜random＞ to use the Mersenne Twister (std::mt19937) and various distributions from the standard library. For some the journey ends here, but for others questions arise: How should I properly seed my generators? How should I approach portability? Does std::mt19937 failing some statistical tests matter to me? Am I leaving performance on the table using std::mt19937? What quality do I need for my use-case and how can I get the best deterministic performance for that quality?
After a brief introduction to generating pseudo-random numbers with the C++ standard library this talk will look at answering these questions in digital audio applications; the same learnings could be applied elsewhere such as games, graphics, or some simulations. We will examine some benchmarks and quality analysis of standard library pseudo-random number generators and modern generators outside the standard. We will close with a demonstration of ways to make runtime-performance determinism improvements with minor quality loss over using standard library distributions.
---
Roth Michaels
Roth Michaels is a Principal Software Engineer at iZotope/Soundwide, an industry leader in real-time audio software for music production and broadcast/film post-production. In his current role on the Audio Research Team at iZotope's parent company, Soundwide, he is focused on developing new fast prototyping frameworks. When he joined iZotope, Roth was the lead library designer of a new internal cross-platform "Glass", part of which is now available as open-source. More recently in his former role as Mix/Master Software Architect, Roth helped develop the reference implementation to move iZotope's products to subscription and led the team that launched the company’s first SaaS offering for music producers. Roth studied music composition at Brandeis University and continued his studies in the Dartmouth Digital Musics program. Roth began his career in software development writing software for his own compositions, and the works of other composers and artists, and teaching MaxMSP to composers and musicians; both private instruction and designing university courses. Before joining iZotope, he was working as a consultant for small startups working on mobile applications specializing in location services and Bluetooth.
---
Videos Filmed & Edited by Bash Films: www.BashFilms.com
TH-cam Channel Managed by Digital Medium Ltd events.digital...
#cppcon #programming #cpp

[@decky1990]

Really enjoyed this chat - thank you.
The concept of “how correct is it?” vs “how correct does it actually need to be?” was definitely something that resonated with me, at least.

[@oj0024]

The fastest PRNG that doesn't fail any statistical tests I'm aware of (PractRand, TestU01) is the romu-random family of generators (RomuDuoJr for 64, and RomuTrio32 for 32 bit). RomuTrio32 is slightly faster than xoshiro128+, and doesn't have statistical flaws in the lower bits.

[@leyasep5919]

now THAT's interesting :-) I'll have to look at them...

[@rothmichaels]

Thanks, I was not previously familiar with these generators and will check them out!

[@nangld]

Does an audio engineering C++ job pay enough to afford a trichologist? One can expect people presenting good technology to also look tidy.

[@dat_21]

Hashing functions are way to go for cheap noise generation. Faster than conventional recursive RNGs. Decent properties, no dependencies and trivial vectorization.
And since when quality of distribution matters for audio? Distribution itself doesn't define spectral properties in any way. For that, you should measure autocorrelation.
For audio purposes, a tiny bias will never ever be noticeable, so using a non-biased uniform distribution is a waste of resources. If for some reason you need a normal-like distribution, you can use a low order polynomial normalizer.
Personally, I never noticed any difference in sound between uniform and normal distribution. However, you can hear some spectral artefacts in cheap PRNGs, in particular LFSRs. It has a certain "grain clanking" to it, which should show itself on autocorrelation test.

[@leyasep5919]

It's interesting but I feel it didn't go deep enough in the subject... Maybe a little presentation of the available algos would help ?

[@Acetyl53]

This should be interesting. I just implemented Complementary Multiply With Carry and some xorshift32 a while back.

[@davidjohnston4240]

Check out PCGs. I've lived the xorshift life, but PCGs are so much more fun. Neither any use for cryptography, but when it's just statistical uniformity you need, PCGs are where it's at.

I love this topic, even I don't need it in my field.

[@leyasep5919]

Or : you don't know yet you need them ? :-)

[@davidjohnston4240]

I like this topic too and it totally is my field. RNGs are in my job title.

[@MarekKnapek]

Page 28, there is typo in STL's name.

[@masondeross]

The include files are the c headers (), not the C++ ones (), so there is no std namespace for srand() and rand(). Alternatively, srand(unsigned variable) is how you seed subsequent calls to rand(), if you thought that was a typo'd call to rand(). He probably left it in the typical "c style mostly c++" still commonly used before c++11 to show that it is really old code and shouldn't be used in c++ anymore (even though the standard has versions of rand and srand for legacy reasons).

[@Feuermagier1337]

If you aren't absolutely sure that your random number generator is a bottleneck - use a cryptographically secure generator! Cryptographically secure should be your default, even if what you do is not in any way cryptographic. You can either spend lots of time checking and worrying whether your generator is good enough for your application - or you just use one that will work in every application (except if you need multiple gigabyte of random data per second on an extremely limited CPU). So the true question is: Are there really applications that benefit from using a faster (but insecure) generator?

[@dat_21]

Audio, graphics, scientific computation. Neither one of these requires a crypto-secure RNG, and extra speed is always welcome.

[@ninepoints5932]

I do not agree with this advice. Why exhaust your entropy pool to produce cryptographically secure numbers 100x slower than a prng that does the job. Don't reach for a cryptographically secure rng first. And definitely don't use or .

[@heater5979]

Hmm......"Are there really applications that benefit from using a faster (but insecure) generator?"
Conversely: Are there any non-security critical applications that benefit from using a slower (but secure) generator?
Horse for courses as usual.

[@davidjohnston4240]

The Crypto secure RNG in the faster Xeon CPUs manages above 2GBps. Software RNGs can go faster if you dedicate multiple cores to it, but then you've got little left for processing to do something with the numbers. An example where smaller, non secure, but faster RNGs are an application are the RNGs used in ML and GPU chips. You need hundreds or thousands of them per chip, injecting noise into each compute element. So size matters and often you want it to be gaussian, not uniform and floating point. 1000 Intel Crypto Secure DRNGs would take a large slice of silicon and it's uniform and not floating point. So you need to match your RNG to the application. Mr audio in the video probably would want a fixed point RNG, which I've designed, but it never hit silicon, whereas the other types I've mentioned I've designed into silicon products. I'm disappointed he rolled out to old tropes about lava lamps and radioactive sources, when in practice, almost all entropy sources are differentially stabilized metastable latches (Intel) or ring oscillators (most other people), implemented in silicon.