Changes since 1.5.0:
- The Rust crate is now compatible with Miri.
- ~1% performance improvement on Arm NEON contributed by @divinity76 (#384).
- Various fixes and improvements in the CMake build.
- The MSRV of b3sum is now 1.74.1. (The MSRV of the library crate is
unchanged, 1.66.1.)
vld1q_u8 and vst1q_u8 has no alignment requirements.
This improves performance on Oracle Cloud's VM.Standard.A1.Flex by 1.15% on a 16*1024 input, from 13920 nanoseconds down to 13800 nanoseconds (approx)
Specify language requirement as a [compile-feature] and force compiler
extensions off ensuring portability problems are detected early on.
Note that we do not use the `C_STANDARD` property, because it doesn't
propagate to dependent targets and would prohibit users from compiling
their code base with consistent flags / language configuations if they
were to target a newer C standard. Similarly we do not configure
`C_STANDARD_REQUIRED` as [compile-features] do not interact with
it--they are enforced regardless.
[compile-feature]: https://cmake.org/cmake/help/latest/manual/cmake-compile-features.7.html#compile-feature-requirements
clang-cl is LLVM's MSVC-compatible compiler frontend for Windows ABI.
If clang-cl is in use, `CMAKE_C_COMPILER_ID` is `Clang` even though
it doesn't take Unix-like command line options but MSVC-like options.
`if(MSVC)` is the correct predicate to check if we should pass MSVC-ish
command line options.
ARMv8 CPUs are guaranteed to support NEON instructions. However, for
32bit ARMv8 triplets GCC needs to explicitly be configured to enable
NEON intrinsics.
Changes since 1.4.1:
- The Rust crate's Hasher type has gained new helper methods for common
forms of IO: update_reader, update_mmap, and update_mmap_rayon. The
latter matches the default behavior of b3sum. The mmap methods are
gated by the new "mmap" Cargo feature.
- Most of the Rust crate's public types now implement the Zeroize trait.
This is gated by the new "zeroize" Cargo feature.
- The Rust crate's Hash types now implements the serde Serialize and
Deserialize traits. This is gated by the new "serde" Cargo feature.
- The C library now uses atomics to cache detected CPU features under
most compilers other than MSVC. Previously this was a non-atomic
write, which was probably "benign" but made TSan unhappy.
- NEON support is now disabled by default on big-endian AArch64.
Previously this was a build error if the caller didn't explicitly
disable it.
If multiple threads try to compute a hash simultaneously before the library has been used for the first time,
the logic in get_cpu_features that detects CPU features will write to g_cpu_features without synchronization,
which is a race condition and flagged by ThreadSanitizer.
This change marks g_cpu_features as an atomic variable to address the race condition.
Changes since 1.4.0:
- Improved performance in the ARM NEON implementation for both C and
Rust callers. This affects AArch64 targets by default and ARMv7
targets that explicitly enable (and support) NEON. The size of the
improvement depends on the microarchitecture, but I've benchmarked
~1.3x on a Cortex-A53 and ~1.2x on an Apple M1. Contributed by
@sdlyyxy in #319.
- The MSRV is now 1.66.1 for both the `blake3` crate and `b3sum`.
Given the myriad of `-mfpu` options for ARM [1], the inability to
portably query for CPU support, and the lack of standardized ISA names
we have no other choice, but to opt out of automatically supplying NEON
compile flags. Instead we simply add the NEON optimized source file if
we detect an ISA with guaranteed NEON support (>= ARMv8) or the user
explicitly requests it (in which case he is expected to provide the
compile flags with `CMAKE_C_FLAGS` or `BLAKE3_CFLAGS_NEON` either
through a toolchain file or commandline parameters).
[1]: https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html
Changes since 1.3.3:
- The C implementation provides a `CMakeLists.txt` for callers who build
with CMake. The CMake build is not yet stable, and callers should
expect breaking changes in patch version updates. The "by hand" build
will always continue to be supported and documented.
- `b3sum` supports the `--seek` flag, to set the starting position in
the output stream.
- `b3sum --check` prints a summary of errors to stderr.
- `Hash::as_bytes` is const.
- `Hash` supports `from_bytes`, which is const.
The ISA names communicated by `CMAKE_SYSTEM_PROCESSOR` aren't as much
standardized as one would wish they were. Factor the different names
into lists allowing for simpler checks and future updates.
Add hidden options for enabling SIMD support in case ISA detection
fails. These should only be used to temporarily workarounds until the
ISA name lists has been updated/fixed.
In order for blake3 to be usable as a shared library on Windows it is
required to annotate public symbols. Use this as an opportunity to prune
the symbol table for other OSes, too.
Aggreggate source files directly in the target instead of a proxy
variable.
Install CMake package config files in order to allow the project to be
found via `find_package()` by dependents.
Replace hard coded SIMD compiler flags with configurable options. Retain
the current GCC/Clang flags as defaults for these compilers. Add default
SIMD compiler flags for MSVC.
Remove hard coded compiler flags (including -fPIC). These are not
portable and should be set by the toolchain file or on the CLI.
- Guard ASM sources with triplet compatibility checks.
- Remove the `BLAKE3_STATIC` option in favor of [`BUILD_SHARED_LIBS`].
[`BUILD_SHARED_LIBS`]: https://cmake.org/cmake/help/v3.9/variable/BUILD_SHARED_LIBS.html
SSSE3 is indicated by bit 9 of ECX, not bit 0, which indicates the
presence of SSE3.
There are very few CPUs in use affected by this bug; SSE3 was part of
the Prescott new instructions, introduced in the later Pentium 4 chips,
whereas SSSE3 was introduced in Intel's Core 2 and AMD's Bulldozer. This
leaves a few Pentium 4 and Athlon 64 models that will potentially run an
illegal pshufb or pblendw.
Changes since 1.3.2:
- Fix incorrect output from AVX-512 intrinsics under GCC 5.4 and 6.1 in
debug mode. This bug was found in unit tests and probably doesn't
affect the public API in practice. See
https://github.com/BLAKE3-team/BLAKE3/issues/271.
Fixes https://github.com/BLAKE3-team/BLAKE3/issues/271.
The `_mm512_cmp_epu32_mask` intrinsic is broken under GCC 5.4 and 6.1.
This led to incorrect output in the AVX-512 implementation when building
with intrinsics instead of assembly. This fix is a simplified version of
Samuel's proposed fix here:
f10816e857 (commitcomment-90742995)
I'm adding the i32::MAX test case here because I personally screwed it
up while I was working on
https://github.com/BLAKE3-team/BLAKE3/issues/271. The correct
implementation of the carry bit is the ANDNOT of old high bit (1) and
the new high bit (0). Using XOR instead of ANDNOT gives the correct
answer in the overflow case, but it also reports an incorrect "extra"
overflow when the high bit goes from 0 to 1.
Changes since 1.3.1:
- Dependency updates only. This includes updating Clap to v4, which
changes the format of the `b3sum --help` output. The new MSRV is
1.59.0 for `blake3` and 1.60.0 for `b3sum`. Note that this project
doesn't have any particular MSRV policy, and we don't consider MSRV
bumps to be breaking changes.
Javier Blazquez
Jack O'Connor
divinity76
divinity76
Henrik S. Gaßmann
Viacheslav H
Rui Ueyama
Havard Eidnes
sdlyyxy
1f604
Joel Rosdahl
SteveGremory
Samuel Neves
namazso
Alberto González Palomo
wargio
Fangrui Song