update readme to better explain rust comparison

[zeebo]

I don't want to give the impression that the Rust version is always slow with incremental updates, nor do I want to ignore that internal buffering has no downsides, but I do want to highlight the upsides of having internal buffering.

This should help balance those concerns.

Rendered

[oconnor663]

The new writeup looks good. Thanks for putting it together so quickly.

We just released version 0.2.0 of the blake3 crate earlier today. It adds the c Cargo feature, which enables assembly implementations. Any chance you could rerun the benchmarks with that feature enabled? (The blake3 crate itself doesn't enable it by default, because it requires a C compiler. But the b3sum binary crate does enable it by default.)

[zeebo]

I don't mind, but can you provide some more details on how to run it? I'm not very familiar with Rust tooling, and have just been doing cargo bench 😄

[oconnor663]

Any other week, I'd run this at the root of the BLAKE3 repo:

cargo +nightly bench --features=c

However we have some unrelated breakage on nightly at the moment (BLAKE3-team/BLAKE3#57), so what I'm running this week is this:

RUSTC_BOOTSTRAP=1 cargo +stable bench --features=c

It looks like you're defaulting to the nightly Rust channel, so that +stable above will select the stable channel (which you might need to install). RUSTC_BOOTSTRAP=1 is a hack to allow us to run benchmarks on stable (normally nightly is required). And finally --features=c turns on the "c" Cargo feature, which we define in Cargo.toml and then look for in build.rs (and throughout the Rust code) to turn on the assembly implementations.

If you want to filter the benchmarks down to something specific, you can put all or part of the name of the benchmark on the end of the command line there as an extra argument.

[zeebo]

Thanks for the information. It looks like it's ~10% faster on my machine, so great work. The charts have been updated.

Time to study the techniques used in that assembly 😄

[zeebo]

Alright, since you said it looked good earlier except for newer benchmarks, and those have been updated, I'm giving this a merge. Thanks!

[oconnor663]

Thanks for the information. It looks like it's ~10% faster on my machine, so great work.

All credit goes to @sneves.