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

61–70 of 263 posts

Re: Everyone should know SIMD

#61

Post by wrs »

tapirl wrote: post #58
wrs wrote: post #45

Earlier quoted context omitted.

Yes. "`@reduce(.And, ...)` combines every boolean using `and` and returns a single boolean." If it's true (the common case here) then you proceed to look at the next 8 bytes. If it's false, you apply a @bitcast (turn the booleans into bits) and @ctz (find the first 0) to get the index of where it was false.

Maybe I'm wrong, but should it be @clz instead?

No, the diagram looks like a binary literal but it's actually backwards from that. Lane 0 becomes the LSB, but that's on the left of the diagram.

Re: Everyone should know SIMD

#62

Post by kiaansaraiya »

I'd slightly rephrase the title to "everyone should know when SIMD didn't happen." Modern compliers are extremely good at vectorization until they suddenly aren't, an they'll often fall back to scalar code because if assumptions or a single-data dependent branch. Learning to check the compliers optimization reports is arguably more valuable.

Re: Everyone should know SIMD

#63

Post by Jtarii »

ivanjermakov wrote: post #49

I respect (and fear a little) those who intentionally utilize SIMD in their implementations, but I believe it's a bit too much of a semantic shift for 2-5x performance gain. Good news is that modern compilers are more than capable of emitting SIMD code even if original source is nothing but. Most software's poor performance would be fixed long before SIMD comes into play. Reduce obvious DB/server round trips, bad dat…

>Good news is that modern compilers are more than capable of emitting SIMD code even if original source is nothing but.

This is only true if you are intentionally writing code that the compiler can easily vectorise. Which is not most code.

Re: Everyone should know SIMD

#64

Post by applfanboysbgon »

ivanjermakov wrote: post #49

I respect (and fear a little) those who intentionally utilize SIMD in their implementations, but I believe it's a bit too much of a semantic shift for 2-5x performance gain. Good news is that modern compilers are more than capable of emitting SIMD code even if original source is nothing but. Most software's poor performance would be fixed long before SIMD comes into play. Reduce obvious DB/server round trips, bad dat…

There is nothing to fear or respect about using SIMD. Don't lionize learning. You can learn too, if only you allow yourself to.

Re: Everyone should know SIMD

#65

Post by tapirl »

wrs wrote: post #61
tapirl wrote: post #58

Earlier quoted context omitted.

Maybe I'm wrong, but should it be @clz instead?

No, the diagram looks like a binary literal but it's actually backwards from that. Lane 0 becomes the LSB, but that's on the left of the diagram.

Aha, you are right. Smaller indexes are for least-significant bits.

Re: Everyone should know SIMD

#66

Post by tstack »

derf_ wrote: post #29

To bolster the argument, even if you do not plan to write the SIMD yourself or will "just get AI to do it", it is important to know what can be fast in SIMD (and on what hardware). That allows you to design your algorithms and structure your code so that the SIMD is possible. Internalizing things like how data dependencies matter, how expensive it is to increase the width of your vector elements (and how to avoid the…

> what can be fast

I think this doesn't get talked about enough. If your input is a big run of data that is being checked/transformed in one shot, it works well. But, if you're likely to have to make a decision on several bytes of the input, SIMD will be the same or slower than the scalar method. It's not a magic "go fast" button.

Re: Everyone should know SIMD

#68

Post by favorited »

andix wrote: post #34

99% of developers should just ignore SIMD. Most projects have a lot of low hanging fruit to increase performance, and still nobody finds the time to solve them.

That doesn't mean you should default to a slower implementation for new code. If you do, you're just creating more low-hanging fruit that nobody will find time to solve.

Re: Everyone should know SIMD

#70

Post by Jtarii »

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.
Post reply on HN