Compilation error on Windows #142
Comments
|
This doesn't look like it has much to do with AVX-512 at all; the build script detects that VS2015 doesn't support it, and doesn't include it in the build. What is ultimately failing is VS2015's MASM inability to recognize |
|
Ah sorry, that wasn't obvious to me from the compiler output. I'll rename this issue to something less specific. |
nre-ableton
changed the title
|
3a8204f should have made this not fail, but I do not have a VS 2015 handy to check. |
|
@sneves Thanks for the quick fix! I will try to setup a VM to test your change. |
|
I was just bitten by this, because I'm also on VS2015 and any blake3 version >= 0.3.1 doesn't build for me. |
|
@Boscop sorry for the delay. The next release is likely to be 1.0, and I've been waiting until I have a chunk of time to go over everything and make sure the whole API is in good shape. If this is a major blocker for you, though, we could cherry-pick it onto a patch release branch as a workaround? |
|
It's fine, I just depend on the git version for now :) |
|
@oconnor663 Actually, it is a problem, because I cannot |
Changes since 0.3.7: - Fix a build break under Visual Studio 2015: #142 - Add Hash::from_hex(). - Implement PartialEq<[u8]> for Hash, using constant_time_eq. - Implement Display for Hash, equivalent to Hash::to_hex(). - Change derive_key() to return a 32-byte array. As with hash() and keyed_hash(), callers who want a non-default output length can use Hasher::finalize_xof(). - Replace Hasher::update_with_join() with Hasher::update_rayon(). The former was excessively generic, and the Join trait leaked implementation details. As part of this change, the Join trait is no longer public. - Upgraded arrayvec to 0.7.0, which uses const generics. This bumps the minimum supported Rust compiler version to 1.51. - Gate the digest and crypto-mac trait implementations behind an unstable feature, "traits-preview". As part of this change upgrade crypto-mac to 0.11.0.
|
@Boscop ok I'm going to stop dragging my feet and just release 1.0. Could you help me test that this branch (this PR) works for you? |
|
Thanks, I'll test it soon. |
|
@Boscop I think it's doable. I just put up a new branch, where I've cherry-picked just the changes from master that fix bugs in C and assembly files. (These are all build bugs, not get-the-wrong-answer bugs, as far as I know.) Could you see if this branch works for you: https://github.com/BLAKE3-team/BLAKE3/tree/release_0.3.8 |
|
@oconnor663 Thanks a lot, I just tested that branch, and it works! I tested it by building this (which didn't build with the crates-io version of blake3 0.3) with: [patch.crates-io]
blake3 = { git = "https://github.com/BLAKE3-team/BLAKE3", branch = "release_0.3.8" }on Win 8.1 with Visual Studio 2015. |
Changes since 0.3.7: - This is a backport release of bugfixes from master. The next release of master will be version 1.0. - Fix a build break under Visual Studio 2015: #142
|
@Boscop I just released 0.3.8. Please let me know if |
|
@oconnor663 Yes, it worked, thanks! Btw, I'm also using fn hash_file(path: impl AsRef<Path>) -> io::Result<Vec<u8>> {
use blake3::Hasher;
const BLOCKSIZE: usize = 16 * 1024; // 16 KiB supports all SIMD instruction sets
let mut buf = [0u8; BLOCKSIZE];
let mut file = File::open(path)?;
let mut hasher = Hasher::new();
loop {
match file.read(&mut buf)? {
0 => break,
n => {
hasher.update(&buf[.. n]);
}
}
}
Ok(hasher.finalize().as_bytes().to_vec())
}Also, is there a way to compile my exe so that it will use runtime detection of SIMD features, so that it uses AVX-512 when running on a CPU that supports that? (If I compile it with the latest VS2019) Btw, would it still run on CPUs that don't support AVX-512 if I compile it on a CPU that supports it? |
I haven't done much work with lots of small files. My instinct is that hashing speed is less likely to be your bottleneck than disk read or directory traversal speed. You might want to look into some of the strategies that ripgrep uses to read lots of small files quickly. (I think the
BLAKE3 does CPU feature detection automatically in both C and Rust. So unless you use special flags to turn it off, you'll get what you want here by default. |
|
Thanks for the detailed response! Yeah, I used to use
Even when compiling with VS2015 which doesn't support the flag for AVX-512? |
Ah good question, this slipped my mind above. If you take a look at our What that means is, if you compile BLAKE3 with a modern C compiler that supports AVX-512 flags, then the AVX-512 implementation will be available for the dispatch functions to choose, based on processor support detected at runtime. But if you compile BLAKE3 with an old C compiler that doesn't support AVX-512, then the dispatch functions won't have the AVX-512 implementation available, even if you run the binary on a CPU that could have supported it. If Rust adds support for AVX-512 in the future (either through intrinsics, like it has for SSE2/4.1 and AVX2 today, or through stable inline assembly), we'll be able to get rid of this reliance on the C compiler. And to be clear, in all of these cases, the built binary is fully compatible with any x86 CPU. It will never dispatch to an implementation that the CPU doesn't support. That only changes if you set something like |
Similar to issue #79, I'm getting compilation errors when building blake3 v0.3.7 on Windows:
I'm actually trying to build sccache 0.2.15, and blake3 is a dependency (or transient dependency?) of that, so forgive me for my unfamiliarity with this project. I've checked the open issues/PRs and didn't see this reported yet.
The text was updated successfully, but these errors were encountered: