You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Because BLAKE3 natively supports parallelism without changing the final
hash, sharding is bypassed. This is much more useful than getting
different file hashes depending on which hashing method you used.
The BLAKE3 hashing is done by memory mapping the file, and defaults to
the max number of workers which is the number of logical CPU cores.
This is a good default and the most performant setup. It is also what
the standard BLAKE3 CLI tool (b3sum) does. It is implemented in Rust
and so will be true parallelism rather than the thread concurrency
implemented for other hashing algorithms, so the speed up should be
quite large. But it will likely be slower on HDDs than having no
parallelism. I think this is the right default, but the HDD concern
is documented.
Resolves: #530
Signed-off-by: makeworld <[email protected]>
Copy file name to clipboardExpand all lines: CHANGELOG.md
+1Lines changed: 1 addition & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -29,6 +29,7 @@ All versions prior to 1.0.0 are untracked.
29
29
- Implemented a new, minimal container image. This variant excludes optional dependencies (like OTel and PKCS#11) to reduce footprint, focusing solely on core signing and verification mechanisms.
30
30
- The library now requires at least v4.0.0 of `sigstore` due to breaking changes in that library
31
31
- Added support for signing and verifying using private Sigstore instances (`--trust_config`)
0 commit comments