Live data from Hacker News

Everyone should know SIMD

mitchellh.com

191–200 of 263 posts

Re: Everyone should know SIMD

#191

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

I'm not fully sure what this means but perhaps you're right about Python given its use by data engineers, academics, SREs (though they're mainly Go these days ... which also lacks fully stable native SIMD support). Otherwise though I'd say the rest are used almost exclusively by software engineers. Unless I'm misunderstanding you.

Re: Everyone should know SIMD

#192

Earlier quoted context omitted.

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.

I'm not fully sure what this means but perhaps you're right about Python given its use by data engineers, academics, SREs (though they're mainly Go these days ... which also lacks fully stable native SIMD support). Otherwise though I'd say the rest are used almost exclusively by software engineers. Unless I'm misunderstanding you.

Still hidden behind an experimental flag but SIMD is fully functional in Go: https://pkg.go.dev/simd/archsimd

Re: Everyone should know SIMD

#193
post #161
post #119

Earlier quoted context omitted.

It was an early AVX-512 unit that resulted in down lock when you used more than a few instructions in short time, as well as resulted in a Linus rant. Later CPUs (updated skylake xeons and later, AMD Zen 4 and newer) don't have the issue

Historically, it was a bit more complex than that, and applies to more than just AVX-512: https://gist.github.com/rygorous/32bc3ea8301dba09358fd2c64e0... .

Fun! in Dwarf Fortress way :)

Thanks for the deeper dive

Re: Everyone should know SIMD

#194
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…

Yep, I avoid saying the word simple almost entirely - its straight forward to get to the top of a mountain, it might still be incredibly arduous.

Simple Network Management Protocol

Simple Mail Transfer Protocol

Lightweight Directory Access Protocol

Sometimes I think the RFC editors are trolling us.

Re: Everyone should know SIMD

#196
post #114

Remember that bug with Intel Skylakes [0]? When an application used AVX, it slowed down everything else on that node. It was by far not easy to debug why some applications randomly suffered perf hits on a new hardware being rolled out in Azure. [0] https://arxiv.org/abs/1901.04982?utm_source=chatgpt.com

The Intel server CPUs Skylake Server, Cascade Lake and Cooper Lake, which had bad frequency/voltage management are now ancient history and very few of them have been used as workstation CPUs by individual users. AMD Zen 4 and Zen 5, and also those Intel CPUs with AVX-512 support starting with Ice Lake, behave much better and there is no reason to avoid AVX-512, which has much better energy efficiency than the alterna…

"Those who cannot remember the past are condemned to repeat it."

Re: Everyone should know SIMD

#197

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.

> Learning to check the compliers optimization reports is arguably more valuable.

More valuable than learning to write SIMD code? When writing SIMD code is itself the remedy to lousy autovectorisation?

If you can only identify the problem, you’re left with “well, that sucks”.

Re: Everyone should know SIMD

#198

The vast majority of developers have 0 need for learning SIMD. Why mislead them, and make them feel like to be a "real" developer they have to know it?

It seems like its useful to be aware of at the very least. Surely every developer has written a hot loop that adds or compares simple terms. Knowing that a compiler COULD in theory optimize this for the target CPU architecture is useful in many cases.

Re: Everyone should know SIMD

#199

I think an even better advice is that everyone should know array programming, because you generally need that mindset for SIMD optimizations as (packed) SIMD-specific techniques are surprisingly rare. And array programming gives you a generally performant code even without SIMD because it is much easier to auto-vectorize.

Array programming where we compare first and look for the first failure later will not help much here if runs are short because by itself it doesn't give you early termination and you may spend a lot of time on wasted comparisons.

Re: Everyone should know SIMD

#200
post #174

Earlier quoted context omitted.

The 2015 people didn't take into account the high stress levels in 2026. We're all struggling to pay for groceries and rent.

I think I am missing the joke here. Who exactly is worse off than 11 years ago?

Eggs 11 years ago cost $0.89 (hell, TWO years ago!). Today they cost $5+.
Post reply on HN