6 ms·

If you're using an llvm-compiled language targeting a new avx512-enabled architecture, you're already using avx512 instructions to vastly accelerate your progra

• rat9988 3y ago
  Yes but his point still stands.
  • kolbe 3y ago
    He said "Introduced in 2017, and still totally unusable in the wild." I understand his frustrations with his own hardware, but he's using lower end consumer hardware. We could quibble about what it means to be "in the wild," but I operate in a compute heavy space where companies buy good hardware, and they all make effective use of AVX512 instruction.
• ComputerGuru 3y ago
  Hardly. Autovectorization is rarely performed as a percentage of all the cases where it’s theoretically possible, not reliably done (no guarantees - even if it AVs today, the same code may not AV tomorrow), and not something you want your actual hot path to rely on. AV is nice for “incidental” speedups to general code. No serious library touting SIMD acceleration will consider AV sufficient for the core hot loop.
  • kolbe 3y ago
    > Autovectorization is rarely performed as a percentage of all the cases where it’s theoretically possible, This is not my experience. Do you have some justification for this statement? I've found myself far more impressed by autovectorization than disappointed by it. I've found that code most people think is autovectorizable actually violates scalar contracts. But if you write clear code whose scalar implementation won't introduce UB if autovectorized, the compiler is really good. Here's my go-to example. Agner Fog's VCL is a well-respected library. It has vectorized versions of all sorts of useful mathematitical functions. For fun, I rewrote his `exp(x)` function using his exact algorithm, but in scalar code, and it autovectorized, and benchmarks the same. https://godbolt.org/z/TK637PTh7 https://godbolt.org/z/TK637PTh7
• cmrdporcupine 3y ago
  My point is you can't really distribute a binary which targets it or rely on its effects. It's not common enough yet. And autovectorization is nice, but explicit SIMD intrinsics use usually wins if done right.
  • janwas 3y ago
    Why not distribute a binary that uses AVX-512 if present, and falls back to AVX2 or SSE4 if not? It can be quite easy, see the example earlier in this thread.
    • cmrdporcupine 3y ago
      Yes, well, in my case I don't have a machine to even test AVX512 on, which sorta speaks to the problems inherent with AVX512, doesn't it -- buy a high-end laptop in 2023 and still don't have AVX512 on it. Which is what led to my original comment here. If I was getting paid $$ for this work, sure, I'd rent cloud instances or hardware to do that development. But it presents a dilemma for open source work. Anyways, it's all griping. We'll either eventually all get AVX512, or it will die and some other more common wide vector extension will take its place, or we'll all be having the same gripe about NEON or RISC-V V extensions 10 years from now. It's just frustrating some of the nice toys that are in AVX512, in particular nice support for bitmasking that would make the code I'm writing much nicer & faster.
      • kolbe 3y ago
        Godbolt will run simple programs for you. And you can choose whatever compiler you want to use very easily. Just make sure you enable 'Output... > Run the compiled output'. I think there's some randomness about what cloud instance your code gets run on, because sometimes it fails due to not having all the necessary instructions. > Anyways, it's all griping. We'll either eventually all get AVX512, or it will die and some other more common wide vector extension will take its place, or we'll all be having the same gripe about NEON or RISC-V V extensions 10 years from now. I think we'll get a unified instruction set. Part of AVX512's difficulty is that it's not just AVX512 or not. It's AVX512F and/or AVX512BW and/or AVX512VL ...x10
• IshKebab 3y ago
  Nobody distributes binaries compiled for AVX-512 for obvious reasons. The only times you'll use it are for source-based distros like Gentoo, and programs that do run time feature detection, but they are relatively rare and won't be using autovectorisation.
  • janwas 3y ago
    Runtime feature detection need not be rare nor hard, it's a few dozen lines of boilerplate. You can even write your code just once: see https://github.com/google/highway#examples https://github.com/google/highway#examples.
    • IshKebab 3y ago
      That's still hard, given the tiny benefit it would give to 99% of code. Maybe modern tooling (e.g. Cargo) will lower the barrier so that it becomes less rare, but in C++ it's definitely not worth the effort for the vast vast vast majority of projects.
      • cmrdporcupine 3y ago
        Unfortunately Rust is way behind on getting SIMD intrinsics out there. Anything AVX512 is nightly (unstable) only still.
      • janwas 3y ago
        Wow, I find "vast vast vast" hard to believe. If we don't have loops where a lot of CPU time is spent, why even write in C++? I admittedly focus more on libraries, but quite a large number of them are already vectorized. I would venture that a sizable fraction of CPU time, even in 'normal' non-HPC context, uses SIMD indirectly. Think image/video decompression, browser handshakes/rendering, image editing, etc.
        • IshKebab 3y ago
          > If we don't have loops where a lot of CPU time is spent, why even write in C++? Because it isn't just hot or autovectorisable loops that are faster in C++; everything is faster. Function calls, member accesses, arithmetic, etc. Even loops are normally not very hot and not autovectorisable. You're right that things like audio/image processing, compression etc. benefits from SIMD but that is in the 1%. Those are libraries that have already been written. The vast vast majority of people are not writing audio codecs or whatever.