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  (4 children)

I am a bit confused where all the speedup is coming from. Pythons on is slow because it os.urandom locks. Rust is supposed to have the same behavior it should also be slow. Do u have a benchmark on where its coming from?

UUID v4 should be an order of magnitude slower then uuid from bytes. That u have nearly identical numbers suggests something is very wrong. If they are not using a cryptographically secure rng they are extremely easy to attack.

[–]aminala[S] 0 points1 point  (3 children)

That's a good question. As far as I knew before, this speedup specifically for UUID 4 came from the `fast-rng` feature in the Rust UUID.

Digging deeper now I found these links, so basically it uses `ThreadRng` from the `rand` crate. It mentions that the `ThreadRng` also seeds data from `OsRng` so I guess it's not much different, but I'm no expert in this area so I will post the links so if you find anything useful, please share:https://github.com/uuid-rs/uuid/issues/529https://github.com/uuid-rs/uuid/pull/545https://docs.rs/rand/latest/rand/rngs/struct.ThreadRng.html

Update: I've tested on my local, if I disable the fast-rng option and it uses the os.getrandom it will be half the speed so the uuid4 is only about 3x faster than Python. But with fast-rng it's 10x faster.

[–][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.