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

61–70 of 170 posts

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

#61

Post by camel-cdr »

jandrewrogers wrote: post #57
camel-cdr wrote: post #45

Earlier quoted context omitted.

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.…

Every column has its own independent constraint: equality, order, range intersection, bit sets, etc that is evaluated concurrently in single operations. Independent per column in parallel. It does require handling the representation of columns to enable it but that isn’t onerous in practice. It isn’t intuitive but it is one of those things that is obvious in hindsight once you see how it works. The gap is that people…

Ah, so you're just doing SoA or AoSoA layout? It sounded like you where doing something more special than the standard SIMD usecase.

This does easily work with SIMD abstractions and even length-agnostic vector ISAs, unless you're doing AoSoA and your storage format has to match your memory format and it has the be the same on all machines. In which case you probably want to do something like 4K blocks anyways, in which case you can make it agnostic for all vector length anybody reasonably cares about for this type of application anyways.

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

#62

Post by camel-cdr »

IshKebab wrote: post #51
stephbook wrote: post #34

Earlier quoted context omitted.

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

In a way it's worse because at least with int you're not really expecting to run the same binary on architectures with different int lengths, and also for several decades there have only been two realistic options (32 or 64), which makes it easy to deal with. With RVV (and SVE I assume) there are a wider range of realistic options - at least 128, 256 and 512. The RVV spec allows up to 65536! Also it's totally reasona…

Here is a highway example: https://gcc.godbolt.org/z/7sdPr61W6

There is a bit of boilerplate to get dynamic dispatch working, but apart from that it's quite simple to use.

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

#63

Post by pjmlp »

jjmarr wrote: post #48
bakugo wrote: post #46

Earlier quoted context omitted.

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.

Some would argue code should be the product of craftsmanship and vibe coding has no place in it.

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

#64

Post by sph »

pjmlp wrote: post #37
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.

I hate AI in code, I hate AI in articles, I hate when AI sticks to the bottom of my shoe.

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

#65

Post by lenkite »

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?

Overly wordy and repetitive - taking 3x the amount of words if a human had written it.

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

#66

Post by fulafel »

jandrewrogers wrote: post #3

I have written a lot of SIMD for both x86 and ARM over many years and many microarchitectures. Every abstraction, including autovectorization, is universally pretty poor outside of narrow cases because they don’t (and mostly can’t) capture what is possible with intrinsics and their rather extreme variation across microarchitectures. If I want good results, I have to write intrinsics. No library can optimally generate…

Autovectorisation is the main way SIMD hardware gets put into use, whether you think it's pretty poor or not.

SIMD came to mainstream in 1995 Pentium MMX and has been proven rather difficult for compilers to target, but after 30+ years is doing a bit better despite PLT conspiring against it. (see eg CUDA, Futhark etc)

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

#67

Post by meling »

Curious if people here have looked at the upcoming SIMD support in Go: https://go.dev/doc/go1.26#simd

Currently experimental, but looks like the first Intel arch will arrive in the next release in about 3 months. They are also going to support a portable layer.

Wondering what people here think about the approach the Go team is taking; I think they would appreciate more eyeballs on their design. (I’m not competent in this space (yet))…

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

#68

Post by imtringued »

portly wrote: post #54
mgaunard wrote: post #6

Earlier quoted context omitted.

For me the main issue is that if you're serious about SIMD, you need to use a state-of-the-art library and can't rely on some standard library whose quality is variable, unreliable, and which is by design always behind.

Don't let the best be the enemy of the good. I got amazing performance for swapping for-loops with some simple SIMD patterns. Moreover. By doing this. I noticed that the codebase started to become better shaped for performance as well. By writing SIMD patterns, you get into the mindset of tight, hot loops.

The problem is that you're better off by defining SIMD friendly data structures and letting the compiler figure it out than by hand coding the actual SIMD operations.

If you wanted to explicitly opt into bundling/batching of operations, you wouldn't actually want to define a fixed register size. You'd want a data type that represents an arbitrarily sized register and exposes some across batch operations. Then the compiler can make use of this mini DSL to optimize your SIMD code to actual instructions.

The problem is solvable, but it requires cooperation from all parties. CPU vendors must offer a basic set of vector instructions that is supported on all architectures. The language committee must be willing to support function local variable size data types that are never exposed in the ABI. The compiler developers must increase the quality of their auto vectorizers.

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

#69

Post by Aardwolf »

I'd actually rather just have the compiler give some guarantees on producing SIMD code when you write regular C++ code doing sums, multiplications, etc... in a particular way. And perhaps add a few more operators/keywords to the language for modern CPU instructions (we got things like popcount, countl_zero and fma, but what about e.g. pext, pdep, aes, ...)

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

#70

Post by Sharlin »

The point about the optimizer only seeing "opaque templates and function calls" makes little sense.

First off, templates are the opposite of opaque due to the fundamental requirement that the implementation be visible to every translation unit using a template. This makes any function calls trivially inlinable.

Second, and the reason for the above requirement, templates are compiled by monomorphization – making a distinct, separately optimizable copy of each concrete instantiation of a template. By the time the compiler backend sees the intermediate representation, there’s nothing about templates left.

There are of course reasons why highly abstracted template code may be difficult to optimize, for instance if function call chains are so deep that the inliner gives up. There are also legitimate reasons why a fully language-based solution might beat a library-based one. But one of the points of adding a library to the std is that the standard library is allowed to cheat as much as it wants. It can be deeply integrated to the compiler and implemented entirely using compiler magic if necessary.

std::simd may be too little, too late for many reasons, but I doubt any of them is that the compiler can’t see through the code.

Post reply on HN