4 ms·
Hi Jack! I'm the author of the post :) The blake3-py library uses PyO3 to bind the official Rust implementation, so I wonder perhaps if PyO3 is adding some ove
by jszymborski 3y ago
Hi Jack! I'm the author of the post :)
The blake3-py library uses PyO3 to bind the official Rust implementation, so I wonder perhaps if PyO3 is adding some overhead.
Sounds like I have some more testing to do.
- oconnor663 3y agoI just took another quick look at my Rust code and Python's C code. It looks like they try to avoid allocating/acquiring a Mutex in the short case. I wonder if that could be part of the problem. Allocating a Rust Mutex should be ~free on Linux, but acquiring it will be a SeqCst compare-exchange... Edit: My code avoids acquiring the Mutex in the initial constructor and only takes it in update(). Are you using update() in your benchmark? If you tweak it to avoid update, does it affect the numbers?
- jszymborski 3y agoI use def blake3_hash(data): return blake3(data).digest()
- oconnor663 3y agoInteresting, I'm able to repro this locally: https://gist.github.com/oconnor663/57ece045df23fe977228aae0cd3ae189 https://gist.github.com/oconnor663/57ece045df23fe977228aae0c... input bytes: b'hello world' average SHA-256 iteration time: 284 ns average SHA-512 iteration time: 470 ns average BLAKE2s iteration time: 231 ns average BLAKE3 iteration time: 355 ns For comparison, in short-input Rust benchmarks on the same machine, one block of BLAKE2s (SSE41) is 77 ns and one block of BLAKE3 (AVX512VL) is 43 ns. So whatever's happening here, I think it's dominated by Python overhead.