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

101–110 of 170 posts

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

#101

Post by exceptione »

hansvm wrote: post #97
exceptione wrote: post #89

Earlier quoted context omitted.

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.

I'm not the person you're asking, but I share that opinion for both compiled languages and JIT solutions, including .net core specifically. All but the most trivial use cases can't be autovectorized, by JIT or otherwise. One of the recent things I worked on (reed-solomon decoding) offers basically zero opportunities for autovectorization unless the compiler reinterprets certain scalar loops as dedicated galois instru…

Thanks, your are talking about using plain loops with regular arrays, or do you mean the specific types like here https://learn.microsoft.com/en-us/dotnet/standard/simd>?

EDIT: A bit more background @https://medium.com/@meriffa/net-core-concepts-simd-avx-intri...>

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

#102

Post by cogman10 »

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…

I think what a SIMD library does, above all else, is get the programmer to write code in a way that can be directly translated into SIMD instructions. A big issue that compilers have to contend with is that they aren't allowed (unless you enable ffast_math) to rearrange floating point operations. Putting an add or a multiply in the wrong place can spoil SIMD optimizations that the compiler could otherwise pull off.

But the problem is as you state. For people that really care about that sort of thing, they are likely going to have the exact SIMD sequence they want to execute in mind anyways. That leaves you with a definition that is doomed to be both not low level enough and too low level.

I think what this is useful for is a fallback description of the desired SIMD operations. It won't be ideal on non-targeted platforms, but it will be something.

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

#103

Post by tialaramex »

secondcoming wrote: post #86
tialaramex wrote: post #78

Earlier quoted context omitted.

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.

> I'm not sure what the argument is here?

That std::hive will fit right in. Another container type you probably shouldn't use, draining precious maintenance resource from groups who have better things they could be doing.

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

As with std::hive. Indeed the "unordered" containers, just like std::hive were repeatedly knocked back and eventually got in decades after they were obsolete. Persistence really does pay off in C++

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

Sure, doubtless std::hive is fine for that same majority of people.

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

#105

Post by drysine »

pwdisswordfishq wrote: post #56
jcranmer wrote: post #38

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…

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…

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

That's a mean interpretation, mean both towards the committee and towards the author.

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

#106

Post by fg137 »

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 content is very biased and hard to verify.

Something that is not controversial and worth a read is https://thephd.dev/embed-the-details and you can see the point.

I do feel the TC39 (the group behind the ECMAScript/JavaScript standard) seems more practical and effective. There are disagreements and dramas but not nearly as bad as with C++.

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

#107

Post by germandiago »

CoastalCoder wrote: post #82
janwas wrote: post #80

Earlier quoted context omitted.

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.

Not who you asked but I think the meaning is that since intrinsics for simd are different in each platform, being able to have something that is portable and sometimes works faster is something, while writing for Intel, ARM and a zoo of instruction sets is not an option for some.

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

#108

Post by feelamee »

> The pattern is clear: every major project that actually needs portable SIMD in production chose a third-party library or a different language

of course they chose third-party library, because C++26 is just only published and don't have wide support/adoption experience.

> And the most damning data point might be EVE itself — a committee member looked at std::simd, decided it wasn’t good enough, and built his own library.

It's just a manipulation. First commit in eve[1] was published in 2018. There was no any std::simd in standard at that time.

> Nobody waited for std::simd. By the time it ships in C++26, these libraries will have a decade of production battle-testing, real user feedback, and cross-platform coverage that std::simd can’t match on day one.

Manipulation 2. No library have decade "of production battle-testing, real user feedback, and cross-platform coverage" on day one. So, why their authors created them?

> Including pulls in deeply nested template machinery — simd.h, simd_x86.h, simd_builtin.h, and friends. A trivial function computing sin on a SIMD vector takes about 2.2 seconds to compile. The equivalent scalar for-loop? 0.2 seconds.

Would be more interesting if you compare this with precompiled headers and C++20 modules.

> The std::simd version? It emits actual vsqrtps + vmulps because the optimizer can’t perform algebraic simplification through opaque template function calls:

opaque template function calls? What is this?

Of course there is 1000 examples when compiler can do better job with scalar loop. And there is 1000 examples when it can't. But, for some reason people do write simd manually. Probably because they want predictable code generation - no massive slowdown on another compiler/another compiler version/another cpu/another one line of loop changed.

> sqrt(x) * sqrt(x)

what compiler would generate with manual simd intrinsincs? I doubt the same as scalar mul.

> The frustrating part is that the problems are well-understood. SIMD programmers have been asking for the same things for years, and none of them are in std::simd.

Show me your proposal with critique of std::simd, if you asking for them. Or at least someone other proposal. How you can understand that someone asking?

Too many emotional statements in, too little technical details.

[1] https://github.com/jfalcou/eve

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

#109

Post by feelamee »

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…

> People that don’t use SIMD today are unlikely to use std::simd tomorrow.

why? at least I see that I will start with std::simd in my pets. If this would not enough, I would go forward to intrinsics. But, I think, starting with std::simd would be much simpler for beginner.

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

#110

Post by vrighter »

imtringued wrote: post #68
portly wrote: post #54

Earlier quoted context omitted.

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

what you effectively said is "there should be only one isa".

Because if that was all it took, why wouldn't it also apply to every other instruction set too?

Post reply on HN