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

111–120 of 170 posts

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

#111

Post by germandiago »

fg137 wrote: post #106
zombot wrote: post #53

The article's point in a nutshell: > The problem is that std::simd in 2026 is the 2012 solution arriving after the world moved on. The committee spent a decade polishing a library-based approach while compilers solved the easy cases automatically and ISPC solved the hard cases with language-level support. I find it interesting that the C++ committee would make that kind of mistake. Shouldn't they know better?

(having no first hand experience with WG21) Many people think there are a lot of problems with C++ committee and the standards process. Some would claim that the ISO governance model doesn't work at all. There is a lot of drama that the outside world has no idea about, because much of the discussion is behind closed doors. You can look it up (e.g. on blogs and /r/cpp), but I am not linking to anything because lots of…

The best witness to the committee (I do not think it is that bad) is to check C++ pre 11 and C++26.

There will always be things people want or comolaints. But the list of useful features and fixes is very long.

But you always see the contentious topics at the top, shadowing a lot (most) of the work that is delivered.

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

#112

Post by DannyBee »

Sharlin wrote: post #70

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

Compiler guy here - yes, the optimizer claim is,in fact, just totally wrong. The claim is it can't be constant folded, scheduled, etc because it doesn't turn into simd instructions. At the bottom, as you say, it will turn into code. That code is almost certainly builtins or uses the vector extensions or whatever , not raw asm statements. compilers can and do turn these into ir level simd instructions.

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

#113

Post by astrobe_ »

janwas wrote: post #80
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…

In such discussions, whenever you mention abstractions are universally "pretty poor", to the extent anyone is listening, I think this hyperbole can do real damage. Maybe it prevents people from getting relevant performance gains, even if not 100% of the optimum, which is anyway unattainable. And what is the alternative? Not many projects can afford to hand write intrinsics for all platforms. And are you aware that Hi…

Besides Spolsky's law of leaky abstractions, "abstractions" can also result in "lowest common denominator" situations, which are the opposite of performance optimization. Talking negatively about abstractions is not what deals damage; you are shooting the messenger here. It's the abstractions themselves that deal damage when misplaced. "Zero-cost abstractions" is the true hyperbole.

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

#114

Post by sgerenser »

SkiFire13 wrote: post #99
camel-cdr wrote: post #90

Earlier quoted context omitted.

> This will take decades because you cannot change existing architectures/processors. I think once, AVX-512, SVE and RVV are wide spread enough, you'll have a rather powerfull baselevel you can target. But this will take a lot of time.

> AVX-512 Which subset though? Some of them are not supported by some recent CPUs (e.g. 2024). Not to mention Alder Lake not supporting AVX512.

Yeah AVX-512 is basically dead as a universal target for x86, the future is now AVX-10. But I believe there is a reasonable subset that will work on both.

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

#115

Post by StilesCrisis »

> When Google needed portable SIMD for production image and video codecs, they built Highway — not std::simd.

Sure, they left the committee years ago. I am not trying to claim any sort of direct causality, but it sure seems like this is a case where Google's presence on the committee might have prevented shipping boondoggles like this. Modules is another case where I think Google's feedback might have been able to steer the ship in a better direction.

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

#116

Post by raverbashing »

StilesCrisis wrote: post #115

> When Google needed portable SIMD for production image and video codecs, they built Highway — not std::simd. Sure, they left the committee years ago. I am not trying to claim any sort of direct causality, but it sure seems like this is a case where Google's presence on the committee might have prevented shipping boondoggles like this. Modules is another case where I think Google's feedback might have been able to st…

They probably left the committee because it keeps going in circles rather than solving the issues of the language

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

#117

Post by adrian17 »

Sharlin wrote: post #70

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

I agree with you, but just a small nit:

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

That's not strictly true, you can have an implementation hidden in a separate TU, as long as that TU instantiates the template for all template arguments that the users are going to use.

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

#118

Post by StilesCrisis »

"The Default Width Problem" -- this section seems confused and definitely reeks of LLM authorship. It's comparing -march=native against std::simd and complaining that std::simd breaks portability with pre-Haswell. This is a real issue, but -march=native is no better! It bakes in the SIMD width at compile-time as well, so that binary also won't run on a pre-Haswell machine. It's a real issue but neither side solves it. You need runtime dispatch (a la Google Highway) to solve this.

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

#119

Post by jcranmer »

Sharlin wrote: post #70

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

As a compiler guy, the complaint about "opaque templates and function calls" to me raises serious doubts that the author has any idea what they're talking about. std::simd is designed to be akin to taking vector operations as intrinsics on and similar types and wrapping them in a more C++ dialect than bare compiler intrinsics (and then a second layer on top of that to make things somewhat more portable).

So the implementation of all of the std::simd at the bottom should be tiny functions that map to essentially a single instruction, specified via a header file in a mechanism that guarantees you always have the body. This makes the functions trivially obvious candidates for inlining. Since it's a C++26 addition, the dispatching logic through the layers can largely be done via if constexpr, which means most of the code is discarded by the frontend.

Given that the complaint seems to be about not vectorizing a call to a sin function, it's possible that it's implemented in libstdc++ in such a way that the library doesn't know about the compiler's -fveclib implementation. But then again, the complaint is based on the libstdc++ v14 implementation of C++ Parallelism std::simd, not the v16.1 implementation of C++26 std::simd, which is completely different (and landed circa 2 months ago).

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

#120

Post by sucrosesucrose »

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.

No such case.
Post reply on HN