Changes since version 0.2.3:
- The optimized assembly implementations are now built by default. They
perform better than the intrinsics implementations, and they compile
much more quickly. Bringing the default behavior in line with reported
benchmark figures should also simplify things for people running their
own benchmarks. Previously this crate only built Rust intrinsics
implementations by default, and the assembly implementations were
gated by the (slightly confusingly named) "c" feature. Now the "c"
feature is gone, and applications that need the old behavior can use
the new "pure" feature. Mainly this will be applications that don't
want to require a C compiler. Note that the `b3sum` crate previously
activated the "c" feature by default, so its behavior hasn't changed.
The biggest change here is that assembly implementations are enabled by
default.
Added features:
- "pure" (Pure Rust, with no C or assembly implementations.)
Removed features:
- "c" (Now basically the default.)
Renamed features;
- "c_prefer_intrinsics" -> "prefer_intrinsics"
- "c_neon" -> "neon"
Unchanged:
- "rayon"
- "std" (Still the only feature on by default.)
Changes since version 0.2.2:
- Bug fix: Commit 13556be fixes a crash on Windows when using the SSE4.1
assembly implementation (--features=c, set by default for b3sum). This
is undefined behavior and therefore a potential security issue.
- b3sum now supports the --num-threads flag.
- The C API now includes a blake3_hasher_finalize_seek() function, which
returns output from any position in the extended output stream.
- Build fix: Commit 5fad419 fixes a compiler error in the AVX-512 C
intrinsics implementation targeting the Windows GNU ABI.
As part of this change, make the rayon and memmap dependencies
mandatory. This simplifies the code a lot, and I'm not aware of any
callers who build b3sum without the default dependencies.
If --num-threads is not given, or if its value is 0, b3sum will still
respect the RAYON_NUM_THREADS environment variable.
Changes since 0.2.1 (and since c-0.2.0):
- Fix a performance issue when the caller makes multiple calls to
update() with uneven lengths. (#69, reported by @willbryant.)
If the total number of chunks hashed so far is e.g. 1, and update() is
called with e.g. 8 more chunks, we can't compress all 8 together. We
have to break the input up, to make sure that that 1 lone chunk CV gets
merged with its proper sibling, and that in general the correct layout
of the tree is preserved. What we should do is hash 1-2-4-1 chunks of
input, using increasing powers of 2 (with some cleanup at the end). What
we were doing was 2-2-2-2 chunks. This was the result of a mistaken
optimization that got us stuck with an always-odd number of chunks so
far.
Fixes https://github.com/BLAKE3-team/BLAKE3/issues/69.
This release is motivated by a fix for a potential security
vulnerability. 421a21abd8 fixes a bug
introduced in a1c4c4efb5. A truncated
pointer register led to a segfault on x86-64 under Clang 7 and 8.
Clang 9 happens to be unaffected, but the behavior is undefined in
general. See also:
https://github.com/BLAKE3-team/BLAKE3/issues/60#issuecomment-585838317
The C implementation of BLAKE3 hasn't been formally packaged anywhere,
and most callers vendor code from master. This release tag is intended
to make the fix above more visible, to encourage callers to update their
vendored copies. We will continue to publish tags like this whenever
bugs in the C implementation are fixed, or if there are any incompatible
API changes.
Note that the issue above does not impact callers of the Rust `blake3`
crate. The affected file, `blake3_dispatch.c`, is not compiled by that
crate in any configuration. It does impact callers of the internal
`blake3_c_rust_bindings` crate, but that crate is not published on
crates.io and not intended for production use.
This gives the assembly files the same prefix as the intrinsics files which
simplifies building when the build system should pick between the assembly and
the intrinsics files.
Changes since 0.1.5:
- The `c_avx512` feature has been replaced by the `c` feature. In
addition to providing AVX-512 support, `c` also provides optimized
assembly implementations. These assembly implementations perform
better, perform more consistently across compilers, and compile more
quickly. As before, `c` is off by default, but the `b3sum` binary
crate activates it by default.
- The `rayon` feature no longer affects the entire API. Instead, it
provides the `join::RayonJoin` type for use with
`Hasher::update_with_join`, so that the caller can control when
multi-threading happens. Standalone API functions like `hash` are
always single-threaded now.
We use a counter value that's very close to wrapping the lower word,
when we're testing the hash_many chunks case. It turns out that this is
a useful thing to do with parents too, even though parents 1) are
teeechnically supposed to always use a counter of 0, and 2) aren't going
to increment the counter at all. We caught a bug in the assembly
implementations this way (where we accidentally did increment the
counter, but only the higher word), because the equivalent test in
rust_c_bindings uses this eccentric parents counter value.
Changes since 0.1.4:
- Remove all AVX-512 code from builds with the default feature set. This
works around https://github.com/rust-lang/rust/issues/68905 and fixes
the nightly build as long as the "c_avx512" feature is not activated.
This release is a backport of a single commit, e43a7d6. The master
branch contains backwards-incompatible changes (fc219f4), and the next
release of master will be version 0.2.0.
Note that the `b3sum` crate activates the "c_avx512" feature by default,
and it will continue to fail to build on nightly until the upstream bug
is fixed.
https://github.com/rust-lang/rust/issues/68905 is currently causing
nightly builds to fail, unless `--no-default-features` is used. This
change means that the default build will succeed, and the failure will
only happen when the "c_avx512" is enabled. The `b3sum` crate will still
fail to build on nightly, because it enables that feature, but most
callers should start succeeding on nightly.
https://github.com/rust-lang/rust/issues/68905 is currently causing
nightly builds to fail, unless `--no-default-features` is used. This
change means that the default build will succeed, and the failure will
only happen when the "c_avx512" is enabled. The `b3sum` crate will still
fail to build on nightly, because it enables that feature, but most
callers should start succeeding on nightly.
Jack O'Connor
Samuel Neves
Erik Johansson