3 ms·
Recently I started using a new golang library that generated random IDs for different components of a complex data structure. My own use case had tens of thous
by gwd 2y ago
Recently I started using a new golang library that generated random IDs for different components of a complex data structure. My own use case had tens of thousands of components, and profiling revealed that a significant chunk of the time initializing the data structure was in crypto/rand's Read(), which on my Macbook was executing system calls. Patching the library to use math/rand's Read() instead increased performance significantly.
In addition to math/rand being faster, I was worried about exhausting the system's entropy pool for no good reason: in this case, the only possible reason to have the ID's be random would be to serialize and de-serialize the data structure, then add more components later; which I had no intention of doing.
Not sure exactly how the timing of the changes mentioned in this blog compare to my experience -- possibly I was using an older version of the library, and this would make crypto/rand basically indistinguishable from math/rand, in which case, sure, why not. :-)
- agwa 2y agoDo note that "exhausting the system's entropy pool" is a myth - entropy can't run out. In the bad old days, Linux kernel developers believed the myth and /dev/random would block if the kernel thought that entropy was low, but most applications (including crypto/rand) read from the non-blocking /dev/urandom instead. See https://www.2uo.de/myths-about-urandom/ https://www.2uo.de/myths-about-urandom/ for details. So don't let that stop you from using crypto/rand.Read!
- Asmod4n 2y agoonce you somehow got 256 bit of entropy it will be enough for the lifespan of our universe.
- masklinn 2y ago> this would make crypto/rand basically indistinguishable from math/rand, in which case, sure, why not. :-) It's closer to the other way around. crypto/rand was not modified in any way, its purpose is to expose the OS's randomness source, and it does that just fine. math/rand was modified to be harder to confuse with crypto/rand (and thus used inappropriately), as well as to provide a stronger, safer randomness source by default (the default RNG source has much larger state and should be practically impossible to predict from a sample in adversarial contexts). > I was worried about exhausting the system's entropy pool for no good reason No good reason indeed: there's no such thing as "exhausting the system's entropy pool", it's a linux myth which even the linux kernel developers have finally abandoned.
- jrpelkonen 2y agoOthers have already addressed the impossibility of exhausting the system entropy pool, however, I would add that you can buffer Read() to amortize the cost of the syscall. Also, make sure that your patch does not introduce a secure vulnerability as math/rand output is not suitable for anything security related.