Code should at all points be easy to reason about. Is SIMD easy to reason about? No.
That's why I suggested making macros
I refuse macros for the same reason. Sure they can be handy, but usually they make code harder to read too.
Everyone should know SIMD
241–250 of 263 posts
Re: Everyone should know SIMD
#242[deleted]
Re: Everyone should know SIMD
#243Earlier quoted context omitted.
I'm no fan of closed-source languages, and lord knows MATLAB has its warts. But I can't deny that it was pretty seamless to write efficient vectorised code for numerical simulations at uni. I don't have much experience with it, but my understanding is that Julia is the closest thing to a more modern and expressive language that has similar vectorisation capabilities.
R and Numpy are also pretty good at this (and Julia was inspired by both of these and Matlab). In fact, I'm reasonably certain that R (known as S in the 70's) was the first real language designed around this concept.
I learned R for statistical programming at uni, where there was less emphasis on vectorised computation, so it didn't jump to mind, but yes! I've never quite felt like numpy 'clicked' for me in the same way, though. It always felt a bit bolted on, which I suppose it is, as a library (though @ operator overloading etc makes things somewhat nicer now).
Re: Everyone should know SIMD
#244Earlier quoted context omitted.
You know, it's always funny to read takes like "A broken compiler forcing you to write explicit SIMD instead of trusting auto-vectorization and coming out 20-30% faster is the best argument I've seen for reading your own generated assembly occasionally instead of assuming the compiler has you covered" because you can quite easily imagine an alternative one like "A broken compiler revealing that the auto-vectorization…
Is there some way to write unit tests for cases where you know vectorisation should have been applied? I guess micro benchmarks should cover the performance part. We have ArchUnit to cover code structures, it would be nice if something similar exists for generated assembly.
The gcc torture test suite has for most vect/ tests ast checks to see such regressions. LLVM missed it.
Re: Everyone should know SIMD
#245Good article! I just wouldn't start off with bold sentences as > SIMD can be simple to understand and > writing SIMD is just about as easy as a for loop and then the first example requires 12 lines to replace one line of scalar code. Be honest and say SIMD is hard but the results are worth it! (Another nitpick: if this article is for newbies, don't use SIMD-only words and concpts before explaining them. Step 5 is goo…
What he's getting at is, the concept can be simple if you're open to understand it, and it actually is!
Re: Everyone should know SIMD
#246Is SIMD in rust still pretty bad?
In some cases the ergonomics are worse than C, which is a feat in 2026. Portable SIMD is (perma?) nightly. Requires 'unsafe' everywhere. To skip bounds-checking, you typically need to switch your writing style from loops to iterators. No JIT, so you need multiversioning and/or target-cpu=native. Since Rust doesn't bring a compiler, you need to predict all your target architectures in advance. Cannot inspect @code_llv…
Yes seems like too much work or hassle. I'm kinda looking at Java as a Rust replacement, and Zig as a C replacement. This might just be the ultimate combo.
Re: Everyone should know SIMD
#247Earlier quoted context omitted.
> You really should see if you can get the compiler to auto-vectorize first (possibly padding data structures and loops) before you write anything by hand. Counterpoint: https://pharr.org/matt/blog/2018/04/18/ispc-origins > I think that the fatal flaw with the approach the compiler team was trying to make work was best diagnosed by T. Foley, who’s full of great insights about this stuff: auto-vectorization is not a p…
How is that different from any other compiler optimization? And what does the last statement in the quote mean anyway? When is performance "predictable"; do you freeze the entire toolchain? And what is the alternative? Handroll manual SIMD code for every possible architecture you may target? If you're writing C++, you're already rolling on decades of compiler optimization. You return by value because it makes code mo…
> How is that different from any other compiler optimization?
When it can be single-handedly responsible for an 8× speedup, you might not want to rely as much on the compiler as in the case of smaller, cumulative optimisations.
> And what is the alternative? Handroll manual SIMD code for every possible architecture you may target?
Use a library like Highway? https://github.com/google/highway
Re: Everyone should know SIMD
#248we make extensive use of simd at work, usually through highway: https://github.com/google/highway imo this is one of the greatest libs ever written. it handles dynamic dispatching of correct simd instructions / lane widths for various hardware with just one simd loop written (handling NEON/AVX/AVX2/AVX512/extensions) with comparable performance to handwritten native intrinsics
Why is then so slow?
Re: Everyone should know SIMD
#249Earlier quoted context omitted.
R and Numpy are also pretty good at this (and Julia was inspired by both of these and Matlab). In fact, I'm reasonably certain that R (known as S in the 70's) was the first real language designed around this concept.
I guess it depends on what real language means to you, but APL[1] existed before and it's fully array based. [1]: https://en.wikipedia.org/wiki/APL_%28programming_language%29
When I writing the comment I was like, maybe APL was first? Nah, no-one will claim that. So congratulations on nerd-sniping me ;)
Re: Everyone should know SIMD
#250Earlier quoted context omitted.
How is that different from any other compiler optimization? And what does the last statement in the quote mean anyway? When is performance "predictable"; do you freeze the entire toolchain? And what is the alternative? Handroll manual SIMD code for every possible architecture you may target? If you're writing C++, you're already rolling on decades of compiler optimization. You return by value because it makes code mo…
> How is that different from any other compiler optimization? When it can be single-handedly responsible for an 8× speedup, you might not want to rely as much on the compiler as in the case of smaller, cumulative optimisations. > And what is the alternative? Handroll manual SIMD code for every possible architecture you may target? Use a library like Highway? https://github.com/google/highway
Forgot to add: using Highway also means that you can detect and take advantage of e.g. AVX2 or AVX-512 in one binary that still works on CPUs without those instruction sets, whereas relying on autovectorisation would mean having to build with `-mavx2`, `-mavx512`, etc. which means that pretty much no one who relies on prebuilt binaries would get them.