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

141–150 of 170 posts

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

#141

Post by janwas »

astrobe_ wrote: post #113
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…

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.

Is this a good faith reply? The particular abstraction we built, and is being discussed, is manifestly and obviously not a lowest common denominator. Looks like you are deploying a second straw man, that of zero cost. In other comments here I acknowledge a cost to intrinsics.

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

#142

Post by mgaunard »

pixelesque wrote: post #71
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…

Yep, same here and agree. Compilers have definitely got better though: another issue in the past (maybe still is to a degree? although compilers have got a lot better at this in the past 15 years, but it used to be one of the things only Intel's ICC actually got right), that if you wrapped the base-level '__m128' or 'float32x4_t' in a struct/union in order to provide some abstraction, the compiler would often lose tr…

That's an ABI constraint of the x86 32-bit API.

People invented x32 to fix this. Or just use amd64.

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

#143

Post by duped »

janwas wrote: post #138
duped wrote: post #129

Earlier quoted context omitted.

A manual is not a tutorial, and having AI anywhere near this task is actively harmful. Please do not build this.

?? Where did you see mention of AI?

I searched the name "fastcode" and the only results were AI

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

#144

Post by pixelesque »

mgaunard wrote: post #142
pixelesque wrote: post #71

Earlier quoted context omitted.

Yep, same here and agree. Compilers have definitely got better though: another issue in the past (maybe still is to a degree? although compilers have got a lot better at this in the past 15 years, but it used to be one of the things only Intel's ICC actually got right), that if you wrapped the base-level '__m128' or 'float32x4_t' in a struct/union in order to provide some abstraction, the compiler would often lose tr…

That's an ABI constraint of the x86 32-bit API. People invented x32 to fix this. Or just use amd64.

This was with amd64.

ICC was at the time the only compiler that would not do that.

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

#145

Post by Remnant44 »

sgerenser wrote: post #114
SkiFire13 wrote: post #99

Earlier quoted context omitted.

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

It's a little dramatic to say avx512 is dead versus 10 - rather, I would say that avx10 finalizes a universally available set of avx512 extensions. For AVX 10.1, there's essentially, no difference after Intel backed out of reducing the vector length.

For at least the next decade AVX 512 will be the high performance target, reaching all of the zen4/5/6 CPUs as well as whatever avx-10 enabled CPUs Intel producers.

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

#146

Post by jcranmer »

feelamee wrote: post #140
jcranmer wrote: post #124

Earlier quoted context omitted.

Have you read the entire paper, and not just skimmed the front matter? The interface is a generic template approach, which can work on any element type T, not just float/double/complex /complex , but custom types like bigint or rational or random_custom_finite_field. Or integration with units libraries (there's another dumpster fire coming down the line...). Your BLAS library will provide you just the four basic elem…

> Your BLAS library will provide you just the four basic element types, ..., and you still need fallback logic anyways to handle the other types. so, your problem with it is that it does all you want (e.g. LAPACK bindings) AND give extra features?? > so it takes a decent amount of dispatch logic to convert the template interface to the actual library calls I can't estimate how much this degrades performance. But, it…

> so, your problem with it is that it does all you want (e.g. LAPACK bindings) AND give extra features??

You've completely misunderstood the point: the point is that the "extra features" means you won't get the main feature (BLAS bindings).

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

#147

Post by adev_ »

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 a legitimate criticism is that it is unclear who std::simd is for. People that don’t use SIMD today are unlikely to use std::simd tomorrow. At the same time, this does nothing for people that use SIMD for serious work. Who is expected to use this?

There is plenty of vectorization that are simple enough to be done with std::simd today and that will still bring any autovectorizer begging on its knees for various reasons.

As an anecdote, I currently got a 8x speedup with std::simd (AVX2 & SVE2) on a rather trivial parser of mine recently that autovectorizer failed miserably to do properly.

Would I have get better result using intrinsics ? Likely, yes.

Did I want to suffer the maintainability and portability pain associated with it for a simple parser ? Certainly not.

For these use case, std.simd does the job. And will probably do a better and wider job with time when it get enriched by the committee.

The blog brings some valid criticism but really looks like a flame war trying to destroy an already opened door.

(1) Is there more performant solutions that std::simd for vectorization ?

Yes, of course. The STL evolves slow, its main goal is to provide a generic and portable implementations of a set of algorithms. Not to provide the best implementation in existence.

The best implementation of most algorithms (including SIMD patterns) evolves every 6 month, you can not expect a standard library with 3 different implementation to keep up with that.

(2) Is the future of vectorization ISPC ?

Nope. ISPC has been around for > 10y and is still niche. There is very good reasons to that: Yes it can generate better code but in most use case, adding a massive dependency of a compiler + an arbitrary LLVM version + a DSL on your project is not worth it.

Specially considering that it is an Intel project and that Intel (almost) abandonned the project multiple time (In pure Intel fashion).

So yes, criticism is easy, and yes std::simd is full of problems.

But I am glad it exists, and thanks to the people that made it happen... Because it is useful, even in the current state.

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

#149

Post by msla »

Pannoniae wrote: post #74
fithisux wrote: post #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

sadly inline assembly is still at the ergonomics of "one compiler doesn't support it in x64 mode" and "you can choose between the readable syntax (which is a black box to the compiler) and the unreadable syntax (which can specify I/O/clobber regs)"

OK, is there a horrible speed penalty for writing your SIMD in pure assembly functions and then calling those functions? If you're writing assembly anyway, just drop the "inline" part.

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

#150

Post by Rendello »

magicalhippo wrote: post #2

The linked[1] "six reasons to use std::simd" was just what I needed after a long week. Hilarious! [1]: https://github.com/NoNaeAbC/std_simd

This is the first time I've seen a classic for loop called a "boomer loop", but apparently this isn't even the first instance (not the first definition):

http://boomer-loop.urbanup.com/18229646

Post reply on HN