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.
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.
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.
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.
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).
2 года назад
I love this topic, even I don't need it in my field.
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?
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 .
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.
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.
![Felix "Unfair" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/Oswujxm2Ag0/mqdefault.jpg)
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.
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.
now THAT's interesting :-) I'll have to look at them...
Thanks, I was not previously familiar with these generators and will check them out!
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 ?
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.
This should be interesting. I just implemented Complementary Multiply With Carry and some xorshift32 a while back.
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.
Does an audio engineering C++ job pay enough to afford a trichologist? One can expect people presenting good technology to also look tidy.
Page 28, there is typo in STL's name.
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).
I love this topic, even I don't need it in my field.
Or : you don't know yet you need them ? :-)
I like this topic too and it totally is my field. RNGs are in my job title.
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?
Audio, graphics, scientific computation. Neither one of these requires a crypto-secure RNG, and extra speed is always welcome.
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 .
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.
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.