4 ms·

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 compi

by 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

janwas 3y ago
I understand it's much more convenient to develop on the machine that has it all. Further to the Godbolt suggestion, one band-aid is that Highway fairly efficiently emulates some of the fancier AVX-512 instructions such as CompressStore. You could then develop on AVX2, then rent 1 VCPU-hour to build and verify it indeed works on AVX-512. As for the subsets of AVX-512, we defined them into groups matching Skylake and Icelake; that works pretty well. Zen4 would also support the Icelake features, but it gets its own target so that we can special-case/avoid the microcoded and super-slow CompressStore there.
- kolbe 3y ago
  What do you think the future of C++ is with vectorization? I keep thinking that the language is too far down the rabbit hole of scalar guarantees to ever allow for us to only rely on autovectorization. Maybe we can add some language features like "false path is defined behavior if statements" and bit-sized bools. But then we'd need people to totally change the way they code. Maybe we need a new, non-scalar successor language? Maybe libraries can take care of it? I've been using Highway for a couple weeks (I'm the guy who is writing the unroller feature). Highway is more limited in its breadth than raw intrinsics. I've noticed a few instances so far where you had to make a judgement call, and decided not to have Highway expose certain features (like 32 bit indexing into 64 bit type scatter/gather). And with more things that x86/ARM throw at us, the harder I think it becomes for a library to be the solution. From what I've seen of std::simd, I don't see how that possibly can be the solution. What do you think?
  - janwas 3y ago
    Oh, hi :) I like your unroller idea, it can simplify user code and is quite general. Agree about autovectorization. It is not even a true programming model, because we have only limited ability to influence results. Also agree std::simd is far too limited (something like 50 ops, mostly the straightforward ones, vs >200 for Highway), and difficult to change/extend within the ISO process. It is very difficult to get widespread traction with a new language, even given LLVM. Mojo, Carbon, Zig are also already potentially helpful. I do believe a library approach (and in particular Highway, because considerable effort is required to maintain support for so many targets/compiler versions and AFAICS nothing else properly supports RISC-V and SVE) is the way to go for the next 5 years. Major compiler update cycles are something like 1.5-2 years and I don't think there will be a fundamental shift anytime soon towards RL, for example. After those 5 years, the future remains to be written :) As to missing features: we are happy to add ops whenever there is sizable benefit for some app, and it doesn't hurt other targets. For mixed-type gather, x86 is the only platform that does this, so encouraging its use would pessimize other platforms. And I think apps can easily promote/demote their indices to match the data size. But always happy to discuss via Github issues :)
- cmrdporcupine 3y ago
  Highway looks nice. I'm in Rust these days, and SIMD support there is remarkably terrible in comparison. And I'm not nearly close enough to being an expert on the subject to contribute anything upstream to improve that. AVX512 is available only if you compile against nightly still. https://github.com/arduano/simdeez https://github.com/arduano/simdeez looks like it's trying to fit into this space, fairly promising.
  - janwas 3y ago
    :) Thanks for the pointer. Glad to see simdeez now has a maintainer again. I believe its (mostly) 'abstracting SIMD width' feature is important and helps nudge people in a good direction.
    - cmrdporcupine 3y ago
      I played with it last night and it does not seem to support many integer intrinsics (e.g. a wrapping of of _mm_set1_epi8 and _mm_cmpeq_epi8 seems not to be present), so isn't useful for my purpose. :-(
      - kolbe 3y ago
        Huh? https://gcc.godbolt.org/z/o4KjbMs8z https://gcc.godbolt.org/z/o4KjbMs8z
        cmrdporcupine 3y ago
        I was talking about simdeez, not highway -- but I did actually find tip of tree on simdeez worked for me.
        kolbe 3y ago
        Ahh. Okay. Good luck. It's a fun rabbit hole.

by kolbe 3y ago

janwas 3y ago

I understand it's much more convenient to develop on the machine that has it all. Further to the Godbolt suggestion, one band-aid is that Highway fairly efficiently emulates some of the fancier AVX-512 instructions such as CompressStore. You could then develop on AVX2, then rent 1 VCPU-hour to build and verify it indeed works on AVX-512. As for the subsets of AVX-512, we defined them into groups matching Skylake and Icelake; that works pretty well. Zen4 would also support the Icelake features, but it gets its own target so that we can special-case/avoid the microcoded and super-slow CompressStore there.

kolbe 3y ago
What do you think the future of C++ is with vectorization? I keep thinking that the language is too far down the rabbit hole of scalar guarantees to ever allow for us to only rely on autovectorization. Maybe we can add some language features like "false path is defined behavior if statements" and bit-sized bools. But then we'd need people to totally change the way they code. Maybe we need a new, non-scalar successor language? Maybe libraries can take care of it? I've been using Highway for a couple weeks (I'm the guy who is writing the unroller feature). Highway is more limited in its breadth than raw intrinsics. I've noticed a few instances so far where you had to make a judgement call, and decided not to have Highway expose certain features (like 32 bit indexing into 64 bit type scatter/gather). And with more things that x86/ARM throw at us, the harder I think it becomes for a library to be the solution. From what I've seen of std::simd, I don't see how that possibly can be the solution. What do you think?
- janwas 3y ago
  Oh, hi :) I like your unroller idea, it can simplify user code and is quite general. Agree about autovectorization. It is not even a true programming model, because we have only limited ability to influence results. Also agree std::simd is far too limited (something like 50 ops, mostly the straightforward ones, vs >200 for Highway), and difficult to change/extend within the ISO process. It is very difficult to get widespread traction with a new language, even given LLVM. Mojo, Carbon, Zig are also already potentially helpful. I do believe a library approach (and in particular Highway, because considerable effort is required to maintain support for so many targets/compiler versions and AFAICS nothing else properly supports RISC-V and SVE) is the way to go for the next 5 years. Major compiler update cycles are something like 1.5-2 years and I don't think there will be a fundamental shift anytime soon towards RL, for example. After those 5 years, the future remains to be written :) As to missing features: we are happy to add ops whenever there is sizable benefit for some app, and it doesn't hurt other targets. For mixed-type gather, x86 is the only platform that does this, so encouraging its use would pessimize other platforms. And I think apps can easily promote/demote their indices to match the data size. But always happy to discuss via Github issues :)
cmrdporcupine 3y ago
Highway looks nice. I'm in Rust these days, and SIMD support there is remarkably terrible in comparison. And I'm not nearly close enough to being an expert on the subject to contribute anything upstream to improve that. AVX512 is available only if you compile against nightly still. https://github.com/arduano/simdeez https://github.com/arduano/simdeez looks like it's trying to fit into this space, fairly promising.
- janwas 3y ago
  :) Thanks for the pointer. Glad to see simdeez now has a maintainer again. I believe its (mostly) 'abstracting SIMD width' feature is important and helps nudge people in a good direction.
  - cmrdporcupine 3y ago
    I played with it last night and it does not seem to support many integer intrinsics (e.g. a wrapping of of _mm_set1_epi8 and _mm_cmpeq_epi8 seems not to be present), so isn't useful for my purpose. :-(
    - kolbe 3y ago
      Huh? https://gcc.godbolt.org/z/o4KjbMs8z https://gcc.godbolt.org/z/o4KjbMs8z
      - cmrdporcupine 3y ago
        I was talking about simdeez, not highway -- but I did actually find tip of tree on simdeez worked for me.
        kolbe 3y ago
        Ahh. Okay. Good luck. It's a fun rabbit hole.