6 ms·

Very neat, i hope this will get easier to do in the future once languages start including these SIMD semantics in the language itself like rust tries to do: ht

Very neat, i hope this will get easier to do in the future once languages start including these SIMD semantics in the language itself like rust tries to do: https://doc.rust-lang.org/std/simd/struct.Simd.html https://doc.rust-lang.org/std/simd/struct.Simd.html Libraries implemented in languages without these semantics will greatly benefit from this.

geertj 3y ago
And C++: https://en.cppreference.com/w/cpp/experimental/simd https://en.cppreference.com/w/cpp/experimental/simd This proposal has been around for a while a but it recently got some new momentum and seems to be on track for c++26. Gcc ships a version today for those wanting to try it.
- janwas 3y ago
  I'm curious what is the new momentum? It's difficult to understand the value proposition of std::experimental::simd. Standardization has taken many years, lost the "load/store" function naming which just about everyone everywhere(?) is using, and only resulted in ~30 ops [1] that are also mostly achievable with compiler builtins or perhaps even autovectorization. Four years ago, we stepped in with Highway to fill the gap; it now has about 250 ops [2] and an active community. I have not wanted to step on any toes, but wonder whether the ship has by now sailed on this? [1]: https://en.cppreference.com/w/cpp/header/experimental/simd https://en.cppreference.com/w/cpp/header/experimental/simd [2]: https://github.com/google/highway/blob/master/g3doc/quick_reference.md#operations https://github.com/google/highway/blob/master/g3doc/quick_re...
  - geertj 3y ago
    Late comment, just saw this. Not sure where the momentum is coming from. The proposal has a new maintainer now, new drafts have been released, and there's a stated goal to get this included in C++26. For me, the appeal for experimental/simd would be it being part of the stdlib. Have you considered proposing Highway for stdlib inclusion? From your description it appears to be a more complete implementation. I realize it's a long and arduous process, but I think it's the only way to make something truly the default implementation. (And thanks for the link. I was not aware that Highway existed.)
    - janwas 3y ago
      Interesting, thanks for sharing :) At the time we open-sourced Highway, the standardization process had already started and there were some discussions. I'm curious why stdlib is the only path you see to default? Compare the activity level of https://github.com/VcDevel/std-simd https://github.com/VcDevel/std-simd vs https://github.com/google/highway https://github.com/google/highway. As to open-source usage, after years of std::experimental, I see <200 search hits [1], vs >400 for Highway [2], even after excluding several library users. But that aside, I'm not convinced standardization is the best path for a SIMD library. We and external users extend Highway on a weekly basis as new use cases arise. What if we deferred those changes to 3-monthly meetings, or had to wait for one meeting per WD, CD, (FCD), DIS, (FDIS) stage before it's standardized? Standardization seems more useful for rarely-changing things. 1: https://sourcegraph.com/search?q=context:global+std::experimental::simd+-path:clang-tidy+count:10000+-path:sycl+-path:highway/+-repo:highway+-path:man/+-path:md%24+-path:rst%24+-path:sh%24+-path:txt%24+-path:testsuite/+-path:tests/+-path:svn-base%24&patternType=standard&sm=1&groupBy=repo https://sourcegraph.com/search?q=context:global+std::experim... 2: https://sourcegraph.com/search?q=context:global+HWY_NAMESPACE+-path:clang-tidy+count:10000+-path:sycl+-path:highway/+-repo:highway+-path:man/+-path:md%24+-path:rst%24+-path:sh%24+-path:txt%24+-path:testsuite/+-path:tests/+-path:svn-base%24+-path:libjxl+-path:jpeg-xl+-path:jxl+-path:jpegli&patternType=standard&sm=1&groupBy=repo https://sourcegraph.com/search?q=context:global+HWY_NAMESPAC...
  - anonymoushn 3y ago
    Highway does seem like the obvious choice for a C++ SIMD abstraction layer!
dzaima 3y ago
A problem is that most such things (the rust thing, C++'s experimental/simd, Zig's SIMD types) have the vector size as a compile-time property, while ARM's SVE and RISC-V's RVV are designed such that it's possible to write portable code that can work for a range of implementation widths. Thus such a fixed-width SIMD library would be forced to target the minimum (128-bit) even if the hardware supports 256-bit, 512-bit, or more. (SVE supports up to 1024-bit, RVV - up to 65536-bit) There is Highway (https://github.com/google/highway https://github.com/google/highway) however, that does support dynamically-sized SIMD.
- almatabata 3y ago
  If you compile the code by specifying the target as native you could get around that limitation no?
  - cozzyd 3y ago
    yes, but then if distributing binaries, you need a different binary for each SIMD width.
    - vkazanov 3y ago
      You can actually autogenerate all reasonable variants of the code if necessary, there aren't that many architectures these days. Simd imstructions are usually very local, this shouldn't blow up the binary. The point is to not have to write repetitive source code many times.
    - Pet_Ant 3y ago
      What is the real cost to just have those few methods be compiled in and then a branch? You don't need to ship a separate binary for each target, you can have dead code in it. I mean fat binaries take this idea to the extreme to support multiple architectures. https://en.wikipedia.org/wiki/Fat_binary https://en.wikipedia.org/wiki/Fat_binary
      - dzaima 3y ago

geertj 3y ago

And C++: https://en.cppreference.com/w/cpp/experimental/simd https://en.cppreference.com/w/cpp/experimental/simd This proposal has been around for a while a but it recently got some new momentum and seems to be on track for c++26. Gcc ships a version today for those wanting to try it.

janwas 3y ago
I'm curious what is the new momentum? It's difficult to understand the value proposition of std::experimental::simd. Standardization has taken many years, lost the "load/store" function naming which just about everyone everywhere(?) is using, and only resulted in ~30 ops [1] that are also mostly achievable with compiler builtins or perhaps even autovectorization. Four years ago, we stepped in with Highway to fill the gap; it now has about 250 ops [2] and an active community. I have not wanted to step on any toes, but wonder whether the ship has by now sailed on this? [1]: https://en.cppreference.com/w/cpp/header/experimental/simd https://en.cppreference.com/w/cpp/header/experimental/simd [2]: https://github.com/google/highway/blob/master/g3doc/quick_reference.md#operations https://github.com/google/highway/blob/master/g3doc/quick_re...
- geertj 3y ago
  Late comment, just saw this. Not sure where the momentum is coming from. The proposal has a new maintainer now, new drafts have been released, and there's a stated goal to get this included in C++26. For me, the appeal for experimental/simd would be it being part of the stdlib. Have you considered proposing Highway for stdlib inclusion? From your description it appears to be a more complete implementation. I realize it's a long and arduous process, but I think it's the only way to make something truly the default implementation. (And thanks for the link. I was not aware that Highway existed.)
  - janwas 3y ago
    Interesting, thanks for sharing :) At the time we open-sourced Highway, the standardization process had already started and there were some discussions. I'm curious why stdlib is the only path you see to default? Compare the activity level of https://github.com/VcDevel/std-simd https://github.com/VcDevel/std-simd vs https://github.com/google/highway https://github.com/google/highway. As to open-source usage, after years of std::experimental, I see <200 search hits [1], vs >400 for Highway [2], even after excluding several library users. But that aside, I'm not convinced standardization is the best path for a SIMD library. We and external users extend Highway on a weekly basis as new use cases arise. What if we deferred those changes to 3-monthly meetings, or had to wait for one meeting per WD, CD, (FCD), DIS, (FDIS) stage before it's standardized? Standardization seems more useful for rarely-changing things. 1: https://sourcegraph.com/search?q=context:global+std::experimental::simd+-path:clang-tidy+count:10000+-path:sycl+-path:highway/+-repo:highway+-path:man/+-path:md%24+-path:rst%24+-path:sh%24+-path:txt%24+-path:testsuite/+-path:tests/+-path:svn-base%24&patternType=standard&sm=1&groupBy=repo https://sourcegraph.com/search?q=context:global+std::experim... 2: https://sourcegraph.com/search?q=context:global+HWY_NAMESPACE+-path:clang-tidy+count:10000+-path:sycl+-path:highway/+-repo:highway+-path:man/+-path:md%24+-path:rst%24+-path:sh%24+-path:txt%24+-path:testsuite/+-path:tests/+-path:svn-base%24+-path:libjxl+-path:jpeg-xl+-path:jxl+-path:jpegli&patternType=standard&sm=1&groupBy=repo https://sourcegraph.com/search?q=context:global+HWY_NAMESPAC...
- anonymoushn 3y ago
  Highway does seem like the obvious choice for a C++ SIMD abstraction layer!

dzaima 3y ago

A problem is that most such things (the rust thing, C++'s experimental/simd, Zig's SIMD types) have the vector size as a compile-time property, while ARM's SVE and RISC-V's RVV are designed such that it's possible to write portable code that can work for a range of implementation widths. Thus such a fixed-width SIMD library would be forced to target the minimum (128-bit) even if the hardware supports 256-bit, 512-bit, or more. (SVE supports up to 1024-bit, RVV - up to 65536-bit) There is Highway (https://github.com/google/highway https://github.com/google/highway) however, that does support dynamically-sized SIMD.

almatabata 3y ago
If you compile the code by specifying the target as native you could get around that limitation no?
- cozzyd 3y ago
  yes, but then if distributing binaries, you need a different binary for each SIMD width.
  - vkazanov 3y ago
    You can actually autogenerate all reasonable variants of the code if necessary, there aren't that many architectures these days. Simd imstructions are usually very local, this shouldn't blow up the binary. The point is to not have to write repetitive source code many times.
  - Pet_Ant 3y ago
    What is the real cost to just have those few methods be compiled in and then a branch? You don't need to ship a separate binary for each target, you can have dead code in it. I mean fat binaries take this idea to the extreme to support multiple architectures. https://en.wikipedia.org/wiki/Fat_binary https://en.wikipedia.org/wiki/Fat_binary
    - dzaima 3y ago