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

161–170 of 170 posts

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

#161

Post by Pannoniae »

msla wrote: post #149
Pannoniae wrote: post #74

Earlier quoted context omitted.

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.

Sure, if you're willing to write a large enough chunk that you can eat the cost of not inlining it. If you just write a small leaf function or two, it will probably be a wash or perform worse.

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

#162

Post by janwas »

teo_zero wrote: post #154
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…

> If I want good results, I have to write intrinsics. Any good book / article / tutorial to begin learning it? Most docs I've tried assume you already know what you can do and focus on how to express it in assembly or with intrinsics. However, I'm not even aware of what operations are commonly implemented in hardware. For example, FMA is not normally tought, is not expressed in higher-level languages... how am I supp…

Working on one together with fastcode.org :)

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

#163

Post by fulafel »

secondcoming wrote: post #83
fulafel wrote: post #66

Earlier quoted context omitted.

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.

The problem is more in language (or SIMD architecturally, depending on your POV). C semantics block too many of the necessary transformations that autovectorization would need to do.

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

#164

Post by plasticeagle »

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 don't use AI at work either. Never will.

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

#165

Post by janwas »

nnevatie wrote: post #159
janwas wrote: post #75

Earlier quoted context omitted.

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.

Runtime dispatch is still a PITA in Highway, especially compared to ISPC. A simple algorithm or kernel becomes a multi-file macro-hell, basically.

Any suggestions for improvement? We went through >5 iterations of the dispatching and I am fairly confident this is about as good as it gets in current C++. I suppose "macro hell" is a matter of taste. Objectively, we have six dispatch related macros in the example: https://gcc.godbolt.org/z/KM3ben7E The ~two dozen lines of boilerplate are generally copied from an example. But why multi-file?

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

#166

Post by fweimer »

janwas wrote: post #137
fweimer wrote: post #122

Earlier quoted context omitted.

People reported challenges building V8 (whether upstream or the Node.js variant) on s390x with z13 support. I don't know if it was discussed on the porters mailing list because it's not public: https://groups.google.com/g/v8-s390-ports Elsewhere, some people interpreted https://github.com/google/highway/issues/1895 as meaning that Highway code does not work on z13 at all.

Thanks for sharing. The first link seems non public indeed. I can imagine there is some compile issue we could reasonably fix, with the help of someone who has Z13 access. Please encourage them to raise an issue. I will be back on May 26. After that, it should at least be able to use the scalar fallback. The issue with Z14 is that it lacks fp32 support. Would their usage be integer only?

I'll bring it up with some folks. It probably won't change much because the z13 transition has finished by now. It's still good to know because RISC-V is in the same boat regarding Highway support today: we need scalar fallback in Highway until we get RVA23 hardware deployed.

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

#167

Post by nnevatie »

janwas wrote: post #165
nnevatie wrote: post #159

Earlier quoted context omitted.

Runtime dispatch is still a PITA in Highway, especially compared to ISPC. A simple algorithm or kernel becomes a multi-file macro-hell, basically.

Any suggestions for improvement? We went through >5 iterations of the dispatching and I am fairly confident this is about as good as it gets in current C++. I suppose "macro hell" is a matter of taste. Objectively, we have six dispatch related macros in the example: https://gcc.godbolt.org/z/KM3ben7E The ~two dozen lines of boilerplate are generally copied from an example. But why multi-file?

The link doesn't work - could you link it again? I might be basing my above comment on and older version of Highway.

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

#168

Post by aphillips801 »

meling wrote: post #67

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…

I did a lot of experimentation with the Go1.26 experiment. It's easy to use and produces good code but only supports x86 ATM. (See https://andrewwphillips.github.io/blog/go1p26.html#simd-expe...)

I think there will be a "portable" wrapper that will also support other architectures (arm, riscv, even wasm) in the future based on the Highway C++ library.

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

#169

Post by aphillips801 »

meling wrote: post #67

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…

Also here is an example of some Go and the Asm code generated:

https://godbolt.org/z/n8hKhc7rY

(click the recompile button if you don't see the Asm code)

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

#170

Post by janwas »

nnevatie wrote: post #167
janwas wrote: post #165

Earlier quoted context omitted.

Any suggestions for improvement? We went through >5 iterations of the dispatching and I am fairly confident this is about as good as it gets in current C++. I suppose "macro hell" is a matter of taste. Objectively, we have six dispatch related macros in the example: https://gcc.godbolt.org/z/KM3ben7E The ~two dozen lines of boilerplate are generally copied from an example. But why multi-file?

The link doesn't work - could you link it again? I might be basing my above comment on and older version of Highway.

Oops, the final T got cut off somehow, sorry about that.

https://gcc.godbolt.org/z/KM3ben7ET

Post reply on HN