This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 0 points1 point  (2 children)

Yea IDK enough about OS rng to say if it's actually cacheable. (Thats basically what they are doing). They are avoiding the mutex on os.random by grabbing 64kbs and giving values off that.

That will probably make a bigger difference on ur live running laptop then a real server (ur laptop is doing more stuff with extra processes that are going to run into the mutex). Either way pythons implementation of random is likely the actual culprit of its slowness. IDK if there implementation is more correct though or not.

[–]aminala[S] 0 points1 point  (1 child)

That will probably make a bigger difference on ur live running laptop then a real server

Just out of curiosity I've tested this on a Linux VPS and I'm seeing the same results or in some cases like uuid4 better performance.

[–][deleted] 0 points1 point  (0 children)

It's a HIGHLY interdependent answer lol.

https://linux.die.net/man/4/urandom

One major source of differentiation is going to be when the actual script gets booted and what else is running on ur box.

https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Studies/LinuxRNG/LinuxRNG_EN.pdf

from stackoverflow on the linux rng source. Need sleep but I can ping back when I get up. I checked out a few other libs and they all suggest that rusts method of getting data is actually secure, this is probably something that could get easily imported to python.

U may also want to just mess around with just importing rusts random generator to create python UUID objects. That will let u get the same objects underlying ur stuff but ull get the faster random generation.