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

81–90 of 170 posts

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

#81

Post by himata4113 »

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…

it's just a compiler hint just like all other hints, parity with other languages.

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

#82

Post by CoastalCoder »

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…

> 100% of the optimum, which is anyway unattainable.

Can you expand on this? Sounds like an interesting discussion.

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

#83

Post by secondcoming »

fulafel wrote: post #66
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)

In my limited experience with looking at autovectorisation compiler output, gcc is quite bad unless you hold its hand, and clang tries to autovectorise everything it sees.

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

#84

Post by tialaramex »

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?

> I find it interesting that the C++ committee would make that kind of mistake. Shouldn't they know better?

The main reason why people attend WG21 meetings is to get their pet features into the C++ language or the associated standard library. To some extent you can further that goal by shooting down other people's suggestions, especially if they would conflict ‡

C++ is a vast sprawling language. There are no genuine "C++ experts" for the same reason there aren't any people who know all of mathematics. There are a lot of people who are experts on some corner of the language or its libraries, and some who know a little bit about almost everything but no overarching experts.

‡ A good way to do this work would try to have such rivals all work together to improve the language, a sort of "yes, and" collaborative approach but although this has occasionally been able to work in C++ the whole WG21 structure works against it, in particular they vote to achieve consensus, which is not what the word "consensus" means and rewards appeasing haters much more than it does finding out what the problems are and working to fix them.

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

#85

Post by fweimer »

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

Have you considered our Highway library? Runtime dispatch need not be a PITA :) It's basically portable intrinsics, and a much more complete set (>300) than the ~50 in std.

Does it have fallback paths for everything, though? Scalar if necessary?

Projects that depend on Highway drop support for CPUs not listed in the Highway documentation, saying that they can't support these CPUs because they are incompatible with Highway: https://google.github.io/highway/en/master/README.html#curre...

Are these projects somehow mistaken?

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

#86

Post by secondcoming »

tialaramex wrote: post #78
pwdisswordfishq wrote: post #56

Earlier quoted context omitted.

Just wait until you hear about std::hive. The work of one obsessive author, who never gave a good explanation for why the thing needed to be in the standard library instead of an external one. The committee was apathetic about the proposal and kept bringing up various trivial issues, in a clear attempt to stall him, but he refused to take the hint. So eventually they relented. Outside coverage I have seen so far seem…

I feel like std::hive fits right in to the C++ stdlib group of collections The least stupid is std::vector which is just the typical O(1) amortized growable array type found in most modern languages, with a mediocre API. 8/10 could do better. std::array is just the built-in array type C++ should have but doesn't. This shouldn't be a library type, that's embarrassing. std::deque looks like you're getting something lik…

I'm not sure what the argument is here?

These are in the standard library because someone proposed their inclusion.

They're fine for the majority of people who really don't want to roll their own data structures each time.

They're not compulsory to use, you're still free to roll your own.

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

#88

Post by secondcoming »

raverbashing wrote: post #58

sigh C++ sits on that weird abstraction level where it wants to be a higher level language but it keeps grinding their gears on stuff like pointer sizes, pointer arithmetic or vector sizes and at the same time wants to keep being C compatible and needs that interface with the lower level world Now compare with how numpy does things: you care about the data size but not the implementation. Still, I didn't expect less…

numpy is a python wrapper over a C library written by people who have ground those gears

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

#89

Post by exceptione »

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…

Do you say that from the perspective of compiled languages? I hear good things about .net core wrt SIMD, but that has the advantage it can decide at JIT.

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

#90

Post by camel-cdr »

SkiFire13 wrote: post #76
imtringued wrote: post #68

Earlier quoted context omitted.

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

> 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. This will work only for the most basic SIMD usages. > CPU vendors must offer a basic set of vector instructions that is supported on all architectures. This will take decades because you cannot change existing architectures/processors.

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

Post reply on HN