Live data from Hacker News

C++26 Shipped a SIMD Library Nobody Asked For

lucisqr.substack.com

41–50 of 170 posts

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

#41

Earlier quoted context omitted.

The full scope of what SIMD is used for is much larger than parallelizing evaluation of numeric types and algorithms. For example, it is used for parallel evaluation of complex constraints on unrelated types simultaneously while packed into a single vector. Think a WHERE clause on an arbitrary SQL schema evaluated in full parallel in a handful of clock cycles. SIMD turns out to be brilliant for this but it looks noth…

I don't quite get how something like highway doesn't cover this, while intrinsics do. Can you explain the usecase more concretely?

Almost literally what I stated. Consider a row in Postgres table or similar. Convert the entire WHERE clause across all columns in that table into a very short sequence of SIMD instructions against the same memory. All of the columns, regardless of type, are evaluated simultaneously using SIMD. For many complex constraints you can match rows in single digit clock cycles even across many unrelated types. This is much faster than using secondary indexes in many cases.

It isn’t hypothetical, I’ve shipped systems that worked this way. You can match search patterns across a random dozen columns across a schema of hundreds of columns at essentially full memory bandwidth.

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

#42
post #37

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.

Who says these are the same people?

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

#43

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…

> Trying to abstract over SVE with a SIMD library is a bit of a fool's errand It reallt isn't. You just make the default SIMD-width agnostic and anything less portable opt-in. You can still specialize for a specific width pn scalabe vector ISAs. > The intended programming model is just too different from traditional ISAs, and there are algorithms that are nearly impossible to write efficiently for it. Such as? > All…

    Such as?
I have a database that has big columns that get functions applied to them to compute the result set. This is a perfect case for length agnostic instructions, except out ends up horribly memory bound. A nice optimization is to only compute those lanes containing rows that might actually be in the result set by keeping track of a sparse record that depends on the lane size. But the cnt instructions are optional, and this also inhibits compiler optimizations in that lookup.

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

#45

Earlier quoted context omitted.

I don't quite get how something like highway doesn't cover this, while intrinsics do. Can you explain the usecase more concretely?

Almost literally what I stated. Consider a row in Postgres table or similar. Convert the entire WHERE clause across all columns in that table into a very short sequence of SIMD instructions against the same memory. All of the columns, regardless of type, are evaluated simultaneously using SIMD. For many complex constraints you can match rows in single digit clock cycles even across many unrelated types. This is much…

OK, I thought it couldn't be that, because that should be doable with std::simd or a SIMD abstraction. Well, unless you JIT it, in which case intrinsics wouldn't help either.

> You can match search patterns across a random dozen columns across a schema of hundreds of columns at essentially full memory bandwidth

Do I underatand it correctly, that this would only work, if you have multiple of the same comparisons (e.g. equality check with same sized data) in the WHERE clause and the relevant collumns are within one multiple of the SIMD width of each other?

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

#46
post #37

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.

Glad to see the classic goomba fallacy in action even here on HN.

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

#47
Why not just writing inline assembly is not enough?

You optimize for a specific target.

The problem is that you cannot be cross-platform. Sure.

But that is why software is incremental.

I write for my HW, not yours. You can write for yours.

Make folders with implemntations

x86_v1 x86_v2 arm64 riscv64 ... ... ...

and include

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

#48
post #46
post #37

Earlier quoted context omitted.

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

Glad to see the classic goomba fallacy in action even here on HN.

I praise Claude and hate AI articles because I could've asked Claude to dumb down the debate if I wanted.

Articles should be high information density and summarizable with Claude.

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

#50

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.

Those type attributes are also used for the x86 intrinsics API, and they override default C behaviors like promotions and presumptions around aliasing (ironically they make type punning easier, though maybe it was just the few use cases I explored, and this isn't an area where I have alot of experience). C23 also gained the _BitInt type, which discards all the old promotion rules, which should help autovectorization.

I think ISPC is still the proper way to go. But these days everybody wants One Language to Rule Them All along with standard libraries for doing everything out-of-the-box. And while in principle ISPC's approach could be stitched into C or C++ in a fairly clean manner (perhaps with well-defined and enforced segregation of constructs to minimize complexity), it's just not gonna happen: C++ is too enamored with constructing libraries through deeply complex templated types (hammer, nail, yada yada), and C is just too conservative (though if GCC or clang went the distance with a full implementation, there's a good chance the C committee would adopt it).

Post reply on HN