Live data from Hacker News

Everyone should know SIMD

mitchellh.com

151–160 of 263 posts

Re: Everyone should know SIMD

#151
post #85

It distresses me that we don’t have a language that can do a best effort parallelization of arbitrary loop like code across SIMD, multiple threads, multiple cores and GPU with a small directive. I don’t need it to be optimal, just … handy as an option! The last time I brought this up here, folks offered a bunch of options that don’t quite do this, and the best candidate was this 15 year old compiler project that is I…

>It distresses me that we don’t have a language that can do a best effort parallelization of arbitrary loop like code across SIMD, multiple threads, multiple cores and GPU with a small directive.

It's called ParaSail. The next closest thing to ParaSail is ...

... literally just Rust.

Why? Because ParaSail has completely eliminated pointers, thereby preventing pointer aliasing. It can't be understated that pointer aliasing and alignment are the two biggest bottlenecks preventing autovectorization.

The people talking about better compilers, etc, just don't get it. It's not a compiler problem, it's a language semantics problem.

Pointer aliasing prevents parallelism full stop. If there is a single memory region and you perform a write to it, you have to assume that the write invalidates all data loaded from the pointers. If you make pointer aliasing illegal, then you have guaranteed that each pointer points to a distinct subset of the global memory, turning each pointer into a pointer to an isolated region. This means you have multiple regions you can write to in parallel. This is crucial, if you do not understand this you don't get parallel programming at all.

I mean think about it, this is the difference between having a four toilet bathroom with a single door or four doors.

The thing about alignment is not as easy to explain, but here is my attempt at it: If you allow the array to be misaligned at the front, then you have to run scalar code at the front. Same problem if you misalign at the end.

If you have a naked pointer and a for loop (think C), then the alignment problem alone precludes autovectorization without a complex scalar preamble. Autovectorization has to assume that the loop length could be anything, meaning it could be less than 8 elements to begin with. If the loop is always a multiple of 8 and always aligned, then the loop can be autovectorized even if the loop only does a single iteration.

Of course, after these critical blockages are gone you're still stuck with the problem of having to write branchless/non-diverging code.

Re: Everyone should know SIMD

#152

> Every developer should know at least that much SIMD. > This [...] applies to any programming language. Support for SIMD instructions varies by programming language This is a very pedantic nitpick because this article is good (& getting SIMD support across more languages would also be good), but the "every programmer should know" line feels a bit odd when neither of the 2 most popular languages natively support SIMD…

I would venture as far as to say that the most popular languages might not be the most used by software engineers, as in, people this kind of article would be aimed at.

Re: Everyone should know SIMD

#153

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

It's all relative though. The rules of playing bridge (the card game) are much harder than understanding the rules around SIMD instructions.

Re: Everyone should know SIMD

#155
post #118

Earlier quoted context omitted.

This is probably one of the biggest sins in technological teaching. Sure it is crucially important to take away the fear of a topic. But you don't do so by saying it is simple, you do so by showing it is simple. And it turns out sometimes you cannot show it is simple, because it is in fact very complex. But every complex topic is made up of smaller, simpler ones. Good teachers then manage to find a good order of thos…

True on all counts. Not sure why you're getting downvoted.

It’s a bit weird because it is one of the better HN comments I read in the last days.

Re: Everyone should know SIMD

#156

Earlier quoted context omitted.

Be the change you want to see. Post a transcript on your own website.

Yes, I will do that when I have time one of these years. I did mean to caveat that in my post but forgot. I mainly wanted to make the vertical integration point.

Do it today or you'll end up never doing it.

Make sure to link back to the source, of course, and don't pass it off as your own words.

Re: Everyone should know SIMD

#157
post #99

Earlier quoted context omitted.

That’s exactly what happened: https://xcancel.com/mitchellh/status/2079672171321081908#m

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.

Re: Everyone should know SIMD

#159
Does anyone know of a good hands-on introductory and practical tutorial on SIMD? I know that SIMD doesn't imply particular instruction set but a pattern of concurrent data transformation.

I guess what I'm looking for is something that addresses the common idioms in SIMD. For example, want to do concurrent data look up? This is how you do it in SIMD; this is how you search; this is how to prepare your data in a manner conducive to SIMD operations; these are the data types you typically find in programming languages, like __mm128; so on and so forth.

Re: Everyone should know SIMD

#160
I started learning multi-platform (x86 + ARM) SIMD last year by writing an audio synthesizer:

https://github.com/seclorum/SIMDSynth

It has been a very rewarding experience, and the synth architecture - multitimbral polyphonic - provides a great stream of data for applying SIMD principles, i.e. multiple streams going through the same process.

Has been pretty hard to debug, though. I found myself wishing I had some sort of simulator to help me understand the state of things in each pipe. I suppose I should spend some time investigating SIMD tools next time I get into this - but I fear it'll require a lot more investment. If anyone has any tips, I'm all ears ..

Post reply on HN