aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-05-06add export_hasher and import_hasher to the guts moduleexportJack O'Connor
This was requested in https://github.com/BLAKE3-team/BLAKE3/issues/84.
2020-05-04lower our required version of `cc`Jack O'Connor
I've tested manually and found that 1.0.4 is the oldest version of `cc` that builds successfully for us. (Version 1.0.3 is missing the `is_flag_supported` method.) This change might help with https://github.com/BLAKE3-team/BLAKE3/issues/83. That said, the underlying issue there is related to "minimum supported Rust versions", and `blake3` does not yet have an MSRV other than latest stable.
2020-04-28version 0.3.30.3.3Jack O'Connor
Changes since 0.3.2: - `b3sum` binaries are built in CI and attached to new GitHub tags.
2020-04-28build b3sum binaries in CI for new tagsJack O'Connor
These configs and code are adapted from the CI workflow in https://github.com/oconnor663/blake3-py, especially the upload_github_release_asset.py script, which is copied verbatim.
2020-04-14version 0.3.20.3.2Jack O'Connor
Changes since 0.3.1: - Fixed a compiler error on older versions of Clang, https://github.com/BLAKE3-team/BLAKE3/issues/79.
2020-04-13refactor build.rsJack O'Connor
Two main changes: - In https://github.com/BLAKE3-team/BLAKE3/issues/79 we learned that older versions of Clang require AVX-512 flags even to compile AVX-512 assembly. - If the C compiler doesn't support AVX-512, we'd still prefer to build the SSE4.1 and AVX2 assembly implementations, on x86_64.
2020-04-12Do not require AVX512DQSamuel Neves
Whereas vinserti64x4 is present on AVX512F, vinserti32x8 requires AVX512DQ, which we do not test for. At this point there is not much risk of incompatibility, since Skylake-X chips have all the requires instruction sets, but let's be precise about this.
2020-04-11print the compiler version in CI, for help with debuggingJack O'Connor
2020-04-10unbreak neon benchmarksJack O'Connor
A helper function was incorrectly restricted to x86-only. CI doesn't currently cover this, because benchmarks are nightly-only, and it's kind of inconvenient to set RUSTC_BOOTSTRAP=1 through `cross` (which normally doesn't propagate env vars). But maybe we should start...
2020-04-02only run CI on branches and PRs, not tagsJack O'Connor
2020-04-02version 0.3.10.3.1Jack O'Connor
Changes since 0.3.0: - The x86 build now automatically falls back to "pure" Rust intrinsics, under either of two possible conditions: 1. The `cc` crate fails to invoke a C compiler at all, indicating that nothing of the right name (e.g. "cc" or "$CC" on Unix) is installed. 2. The `cc` crate detects that the compiler doesn't support AVX-512 flags, usually because it's too old. The end result should be that most callers successfully build the assembly implementations, and that callers who can't build those see a warning but not an error. (And note that Cargo suppresses warnings for non-path depencies.)
2020-04-01automatically fall back to the pure Rust buildJack O'Connor
There are two scenarios where compiling AVX-512 C or assembly code might not work: 1. There might not be a C compiler installed at all. Most commonly this is either in cross-compiling situations, or with the Windows GNU target. 2. The installed C compiler might not support e.g. -mavx512f, because it's too old. In both of these cases, print a relevant warning, and then automatically fall back to using the pure Rust intrinsics build. Note that this only affects x86 targets. Other targets always use pure Rust, unless the "neon" feature is enabled.
2020-03-31move prototypes to shared header file, and make all local functions static.Samuel Neves
2020-03-31turn all compiler warnings into errors in CIJack O'Connor
2020-03-30put the CI badge back down in the READMEJack O'Connor
2020-03-30version 0.3.00.3.0Jack O'Connor
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.
2020-03-29add testing-only flags to disable individual instruction setsJack O'Connor
This lets CI test a wider range of possible SIMD support settings.
2020-03-29refactor the Cargo feature setJack O'Connor
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.)
2020-03-29version 0.2.30.2.3Jack O'Connor
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.
2020-03-29add a Windows GNU AVX-512 build break workaroundJack O'Connor
The break in question only repros under --release, and we didn't start testing a release build of the prefer-intrinsics mode until just now.
2020-03-29add more --release mode testingJack O'Connor
2020-03-29save missing clobbered registers on WindowsSamuel Neves
2020-03-28print instruction set support quietlyJack O'Connor
2020-03-28print out instruction set support in CIJack O'Connor
2020-03-28add release assembly testsJack O'Connor
2020-03-25C files -> C and assembly filesJack O'Connor
2020-03-25c/README.md changesJack O'Connor
The C implementation now supports output seeking. Also expand the API section a bit, and reorganize things to put the example on top.
2020-03-25add blake3_hasher_finalize_seek to the C APIJack O'Connor
2020-03-24disable fail-fast for cross tests tooJack O'Connor
2020-03-17correct a commentJack O'Connor
2020-03-16add links to other implementations in the readmeJack O'Connor
2020-03-16update b3sum/README.mdJack O'Connor
2020-03-16add the --num-threads flagJack O'Connor
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.
2020-03-15wrap --help output to 80 columnsJack O'Connor
2020-03-05add an example of parsing a Hash from a hex stringJack O'Connor
Suggested by @zaynetro: https://github.com/BLAKE3-team/BLAKE3/pull/24#issuecomment-594369061
2020-03-01clean up the C example a bitJack O'Connor
2020-02-27some comment typosJack O'Connor
2020-02-25version 0.2.20.2.2Jack O'Connor
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.)
2020-02-25remove a mis-optimization that hurt performance for uneven updatesJack O'Connor
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.
2020-02-21update the red bar chart with the figure from the asm implementationJack O'Connor
2020-02-19add examples to the b3sum readmeJack O'Connor
2020-02-14check for AVX-512 compiler support even when using assemblyJack O'Connor
2020-02-14version 0.2.10.2.1Jack O'Connor
Changes since 0.2.0: - Workarounds in the assembly implementations (enabled by the "c" feature), to build with older compilers.
2020-02-13tag the first release of the C implementation, c-0.2.0Jack O'Connor
This release is motivated by a fix for a potential security vulnerability. 421a21abd8a8be9fc7be4eb9c62b7004dc9ec93c fixes a bug introduced in a1c4c4efb58aa57596f4c92e0a01914a584c8613. 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.
2020-02-13Fix bug inadvertently introduced in a1c4c4efb58aa57596f4c92e0a01914a584c8613Samuel Neves
2020-02-13Work around GCC bug 85328 by forcing trivially masked stores.Samuel Neves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85328 Fixes #58.
2020-02-13Work around clang bug 36144 by replacing anonymous label numbers.Samuel Neves
https://bugs.llvm.org/show_bug.cgi?id=36144 Fixes #60.
2020-02-12more file renaming, use underscores more consistentlyJack O'Connor
2020-02-12Rename assembly files (blake3-* -> blake3_*)Erik Johansson
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.
2020-02-12version 0.2.00.2.0Jack O'Connor
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.
generated by cgit v1.2.3 (git 2.46.0) at 2026-01-26 23:41:36 +0000