Status of AVX 512 ?

[ManuelCostanzo]

Hello !

I want to ask if this crate supports AVX 512 instructions. If not, Is it in the plans to be able to support it ? This would be the definitive rate for simd in Rust ? Because I understand that the one that is in the official documentation does not have more support.

Thanks

[Lokathor]

Hello.

We will support 512-bit vectors. However, you'll need to turn up the enabled features during compilation because by default Rust binaries are not compiled with avx-512 enabled.

[ManuelCostanzo]

Thank you for reply ! And what features I have to enable ?

[Lokathor]

You'd usually use a target-feature list in the RUSTFLAGS value during build.

The allowed features are the same as for the target_feature attribute

It appears that you can't enable avx-512 on stable yet.

Perhaps @Amanieu knows more? I've seen them merging work in stdarch lately.

[ManuelCostanzo]

I made a N-Body algorithm implementation, and on my server, compiling with target-cpu=knl works much better than with target-cpu=native.

It's like it vectorizes better, but without adding any target-feature.

Although I am not in a KNL, it is true that the server has similar instructions and for some reason it works better (i mean, the algorithm takes less time to finish)

[Amanieu]

Currrently we tie the stabilization of target_feature features with the implementation of the relevant intrinsics in stdarch (The AVX512 intrinsics are still incomplete). However I think we should separate these now that we have stdsimd.

[workingjubilee]

Knight's Landing chips lack the narrower-width SSE instructions so it is likely that some things that are lowering to SSE instructions while using -Ctarget-cpu=native are lowering to AVX instructions with -Ctarget-cpu=knl.

[workingjubilee]

I just pestered everyone by mentioning this in the Zulip so I should mention it here: I should note that "AVX-512" is by no means a singular unitary feature, there is avx512f ("F" for "Foundation", perhaps?) and also extension features for AVX-512 that build on top of avx512f, so that's something to be aware of. Our main attention will be on supporting the concepts of 512-bit vectors abstractly in our API and in a manner that is vendor-neutral so that the compiler can do the best job it can with a desired intention without the programmer having to get into the nitty-gritty specifics of Intel's API.

[jedbrown]

@ManuelCostanzo Note that gcc/clang/icc generally avoid 512-bit registers even when compiled for skylake-avx512 due to license-based downclocking, which includes stalls at frequency transitions. You have to specifically request them by something like -mprefer-vector-width=512. Ice Lake has a big improvement in downclocking so we might see compilers using 512-bit registers by default. rustc --print target-features suggests that there is no way to encourage the compiler to actually use 512-bit registers (which is what you want if you spend lots of time in sustained avx512 code).

[calebzulawski]

Unfortunately I believe that will also be entirely out of our hands unless LLVM provides a mechanism for encouraging it. Using target-cpu=native may help in some cases?

[jedbrown]

Aha! rustc -Ctarget-cpu=skylake-avx512 -Ctarget-feature=-prefer-256-bit. It's confusing because +prefer-256-bit is the default and one specifies that they want 512 by disabling it -- I'd been looking for +prefer-512-bit, which doesn't exist.

https://godbolt.org/z/nEMWz9

[workingjubilee]

At first I was considering to myself, "shouldn't this issue be closed?" since it's not something the Portable SIMD API can help with per se. However, past and future Jubilees, please consider: These specific instructions on targeting AVX512-enabled architectures should probably go somewhere, and from that "guide-level" perspective, this is within the scope of our mandate.

[tarcieri]

AVX512 would certainly be nice for cryptography. For example, curve25519-dalek has a backend leveraging AVX512-IFMA.

GHASH (used by AES-GCM) also benefits from VPCLMULQDQ, but it's already possible to leverage from Rust just by using target-cpu=skylake

The Keccak sponge function (used by the SHA3 family and the KangarooTwelve XOF) is another example of an algorithm that could benefit: https://github.com/XKCP/K12/blob/master/lib/Optimized64/KeccakP-1600-AVX512-plainC.c

[workingjubilee]

@tarcieri When I said "specific instructions" I meant for human usage.

Conversely, guaranteeing specific machine instructions, including for specific SIMD architectures, are compiled into the binary is not actually in-scope for the SIMD API project, as much of a paradox as that may seem, so usages like those will likely continue to depend on core::arch::x86_64, etc.

[tarcieri]

If I understand what you're saying, there are specific logical operations the above AVX512 use cases map to, but there may not be corresponding Rust traits for those operations.

The curve25519-dalek use case requires a multiply-accumulate operation, namely fused multiply–add.

The GHASH use case is carryless multiplication. I'm not sure what a good API is for distinguishing that from a more traditional multiply-with-carry.

Keccak is simple bitwise ops like XOR and shuffles.

[calebzulawski]

FMA will likely be supported at some point (regardless of AVX-512). Unfortunately llvm doesn't expose carry-less multiply (https://groups.google.com/g/llvm-dev/c/5cpOboKOBg4/m/kJ9z_xkVAQAJ) so you'd probably need to use std::arch for that.