Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C++26 Shipped a SIMD Library Nobody Asked For

lucisqr.substack.com

Post reply on HN
Print view View original

31–40 of 170 posts

Re: C++26 Shipped a SIMD Library Nobody Asked For

#31

Post by camel-cdr »

mgaunard wrote: post #7

I made the first proposal to the C++ standard committee to introduce SIMD in 2011, before Matthias Kretz got involved with his own version (which is what became std::simd). This was based on what eventually became Eve (mentioned in the article). Back then, it was rejected, for the same arguments that people are making today, such as not mapping to SVE well, having a separate way to express control flow etc. There was…

> There was a real alternative being considered at the time: integrating ISPC-like semantics natively in the language.

I think this is the best solution for truely portable SIMD. Sure it doesn't cover everything, but it makes autovec explicit, guaranteed and more powerfull.

One of the biggest problems with "portable" SIMD libraries, is that when it's used for simple things, often autovec is better, as it has access to the direct ISA semantics and can much easier do things like unrolling.

Re: C++26 Shipped a SIMD Library Nobody Asked For

#32

Post by usrnm »

plasticeagle wrote: post #30

Nobody should read that AI slop article. Nobody. Maybe there's an interesting story in there, it's certainly possible. But the "author" could not be bothered to write it, and so why should we waster our time reading it?

I read it and found it interesting

Re: C++26 Shipped a SIMD Library Nobody Asked For

#33

Post by camel-cdr »

jandrewrogers wrote: post #17
mpyne wrote: post #9

Earlier quoted context omitted.

> I think a legitimate criticism is that it is unclear who std::simd is for. I think it's for people like me, who recognize that depending on the dataset that a lot of performance is left on the table for some datasets when you don't take advantage of SIMD, but are not interested in becoming experts on intrinsics for a multitude of processor combinations. Having a way to be able to say "flag bytes in this buffer matc…

You raise some good points. I think a lot about how to make SIMD more accessible, and spend an inordinate amount of time experimenting with abstractions, because I’ve experienced its many inadequacies. The design of the intrinsics libraries do themselves no favors and there are many inconsistencies. Basic things could be made more accessible but are somewhat limited by a requirement for C compatibility. This is somet…

IMO what's needed is ISPC like guided autovec with a lot of hinting support to control codegen (e.g. hint for generating an unrolled version only or an unrolled and non-unrolled version).

Basically something like #pragma omp SIMD, but actually designed for the SIMD model, not parallel one, that erros when vectorization isn't possible.

Ideally it would support things like reductions, scans, reference of elements from other iterations (e.g. out[i] = in[i-1]+in[i+1]), full gather scatter, early break, conditional execution control (masking or also a fast-path, when no active elements), latency vs throughput sensitive (don't unroll or unroll to max without spilling), data dependent termination (fault-only-first load or page aligned for thigs like strlen), ...

Re: C++26 Shipped a SIMD Library Nobody Asked For

#34

Post by stephbook »

AlotOfReading wrote: post #12
mgaunard wrote: post #7

I made the first proposal to the C++ standard committee to introduce SIMD in 2011, before Matthias Kretz got involved with his own version (which is what became std::simd). This was based on what eventually became Eve (mentioned in the article). Back then, it was rejected, for the same arguments that people are making today, such as not mapping to SVE well, having a separate way to express control flow etc. There was…

Trying to abstract over SVE with a SIMD library is a bit of a fool's errand. The intended programming model is just too different from traditional ISAs, and there are algorithms that are nearly impossible to write efficiently for it. All the ones I've seen wrap it up as a bastardized fixed length ISA, and even ARM's own guidance basically recommends that approach. Frankly, the length agnostic stuff is a mistake that…

I'm no C++ dev, but as an outsider, it sure reads like the whole "int is variable length" mistake again.

Re: C++26 Shipped a SIMD Library Nobody Asked For

#36

Post by pjmlp »

stephbook wrote: post #34
AlotOfReading wrote: post #12

Earlier quoted context omitted.

Trying to abstract over SVE with a SIMD library is a bit of a fool's errand. The intended programming model is just too different from traditional ISAs, and there are algorithms that are nearly impossible to write efficiently for it. All the ones I've seen wrap it up as a bastardized fixed length ISA, and even ARM's own guidance basically recommends that approach. Frankly, the length agnostic stuff is a mistake that…

I'm no C++ dev, but as an outsider, it sure reads like the whole "int is variable length" mistake again.

That abstraction is occasionally usable in low level systems code, that is why Go, Rust, D and C# support it as well.

Also to note that is C not C++.

Re: C++26 Shipped a SIMD Library Nobody Asked For

#37

Post by pjmlp »

plasticeagle wrote: post #30

Nobody should read that AI slop article. Nobody. Maybe there's an interesting story in there, it's certainly possible. But the "author" could not be bothered to write it, and so why should we waster our time reading it?

I love people praise Claude for doing their work, every day on HN, while at the same time complaining about AI in articles.

Re: C++26 Shipped a SIMD Library Nobody Asked For

#38

Post by jcranmer »

If you thought std::simd was a library nobody asked for, just wait until you hear about . I feel like half the people looking forward to that think they're just going to get standard C++ bindings to LAPACK, when instead they're probably going to get an unoptimized, slapdash implementation of LAPACK written by people who aren't good at BLAS.

As for SIMD itself, designing a good SIMD library is difficult because there are several different SIMD approaches and some of them work poorly for certain use cases. For example, you can take an HPC-ish approach of "vectorize this loop" (à la #pragma omp simd) and have the compiler take care of a fairly mechanical transformation. Or you can take an opposite approach of treating a 128-bit SIMD vector as a fundamental data type in your language. Which approach is better depends on your use case.

Re: C++26 Shipped a SIMD Library Nobody Asked For

#39

Post by chris_wot »

plasticeagle wrote: post #30

Nobody should read that AI slop article. Nobody. Maybe there's an interesting story in there, it's certainly possible. But the "author" could not be bothered to write it, and so why should we waster our time reading it?

... because it makes some decent points?

Re: C++26 Shipped a SIMD Library Nobody Asked For

#40

Post by Someone »

countWSS wrote: post #25

GCC already solved it: https://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html The operations behave like C++ valarrays. Addition is defined as the addition of the corresponding elements of the operands. For example, in the code below, each of the 4 elements in a is added to the corresponding 4 elements in b and the resulting vector is stored in c.

And these are also available in clang. https://clang.llvm.org/docs/LanguageExtensions.html#vectors-...:

“Vectors and Extended Vectors

Supports the GCC, OpenCL, AltiVec, NEON, SVE and RVV vector extensions”

Post reply on HN