Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Everyone should know SIMD

mitchellh.com

Post reply on HN
Print view View original

181–190 of 263 posts

Re: Everyone should know SIMD

#181

Post by MarceColl »

disgruntledphd2 wrote: post #176
subset wrote: post #175

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

Re: Everyone should know SIMD

#182

Post by Someone »

teo_zero wrote: post #113

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…

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

I think SIMD, and certainly that first example is way more tedious than it is hard.

What makes it tedious are

- you have to figure out how many things your hardware can do in parallel

- you have to chop up the work in packets of that size

- once you have your results, you have to ‘unchop’ them

- if there is a chance ‘chopping up’ leaves you with remaining items, you have to handle that case separately

- if the code you want to apply SIMD to uses constants, you have to create vectors containing copies of them

Neither of those is particularly hard, but each adds work, making things tedious.

Re: Everyone should know SIMD

#183

Post by nananana9 »

spockz wrote: post #157
Joker_vD wrote: post #115

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

I've been begging for years for a a [[must_vectorize]] annotation that I can place before a loop I care about, and turn it into a compile error if the compiler can't figure it out.

Re: Everyone should know SIMD

#184

Post by mitchellh »

inigyou wrote: post #144
mitchellh wrote: post #16

Earlier quoted context omitted.

> mitchell, i know you hang around some of these comments sometimes hi im here > i noticed that in ghostty you bring in some c++ libs to do the simd heavy lifting for you. any plans to port that to zig? anything missing from the language or libs that's preventing it? No plans to port it. For others, this is referencing highway: https://github.com/google/highway The major limitation of Zig's vectors is that they're co…

Why does your website block Tor so I can't read the article?

No idea

Re: Everyone should know SIMD

#185

Post by dupontcyborg »

nananana9 wrote: post #183
spockz wrote: post #157

Earlier quoted context omitted.

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.

I've been begging for years for a a [[must_vectorize]] annotation that I can place before a loop I care about, and turn it into a compile error if the compiler can't figure it out.

this would be amazing

Re: Everyone should know SIMD

#186

Post by dupontcyborg »

we 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

Re: Everyone should know SIMD

#187

Post by Sesse__ »

heja2009 wrote: post #168
teo_zero wrote: post #113

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…

Around 1990 I had the fortune to learn Parallel-C - a language that was designed during the Transputer hype and was essentially C extended by a few features to support easy parallel programming. My favourite feature was par( ; ; ) essentially a for loop that will be auto-parallelized by the compiler - some boundary conditions apply.

You may be interested in OpenMP.

Re: Everyone should know SIMD

#188

Post by Sesse__ »

amelius wrote: post #153
teo_zero wrote: post #113

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.

GF2P8AFFINE has entered the chat.

(I've both played bridge actively and written SIMD code professionally, bridge rules are way simpler. Actually playing good bridge is probably harder.)

Re: Everyone should know SIMD

#189

Post by Sesse__ »

dupontcyborg wrote: post #186

we 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

No, not really. Highway generates rather bad code as soon as you step outside a pretty narrow vertically-oriented scope, in my experience.

Re: Everyone should know SIMD

#190

Post by tmtvl »

Jtarii wrote: post #70
gblargg wrote: post #42

My compiler knows SIMD. However, knowing the limitations of SIMD might help avoid a calculation that can't be optimized to use it.

Your compiler can vectorise trivial things, once your code gets complicated it will no longer vectorise.

Once the code is complicated you don't need to make it more complicated lest it becomes unmaintainable.
Post reply on HN