4 ms·
I 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
by oconnor663 3y ago
I 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.