[teo_zero]

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 good: scalar tails are mentioned and described. Step 1 is bad: nobody is supposed to know what broadcast mean.)

[atoav]

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 those smaller parts that makes the steep hill climbable. Then you only need to convince people it is actually worth climbing.

[1718627440]

Simple != easy

In fact getting things to be simple can often be very hard and cumbersome.

[hilariously]

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.

[jelder]

Simple Network Management Protocol

Simple Mail Transfer Protocol

Lightweight Directory Access Protocol

Sometimes I think the RFC editors are trolling us.

[atoav]

Well. I thought so as well about LDAP. Until one day I had to interact with the kind of technology LDAP was built to replace...

[1718627440]

SMTP is very simple, though.

[MrMorden]

Especially since it would be compared to X.400.

[FartyMcFarter]

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

[speedgoose]

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

[atoav]

Thanks for the kind compliment : )

I try to ask myself whether things I write are (1) writing and (2) reading before writing. Sometimes that works.

[Someone]

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

[dotancohen]

I hate to be the one to invoke AI in this otherwise virgin thread, but AI is absolutely terrific for doing the not-hard, tedious work. This seems like a place where AI tools could be used to help the user learn - so long as he instructs the tool for each small task and doesn't lazily just have the tool do the thinking for him.

[irishcoffee]

> Okay, now I understand that those 12 lines are going to look really alien to someone not familiar with the concepts. So now let's back up and explain it step by step, mapping it directly to the shape previously mentioned.

They covered that, in a very honest and blunt manner.

[heja2009]

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(<start expression>; <end expression>; <loop expression>)

essentially a for loop that will be auto-parallelized by the compiler - some boundary conditions apply.

[Sesse__]

You may be interested in OpenMP.

[paulddraper]

OpenMP is interesting, though uses threads.

[edvinbesic]

I believe this still lives on through XMOS. I remember (fondly) doing this on one of their chips mid-to-late 2000's doing a bit of audio processing. Think it might have even been designed by the original transputer folks.

[t-3]

SIMD is simple, using data-parallel operations in scalar languages is what's awkward.

[franciscop]

Agreed, I was interested and I'm prob the target audience but things escalated too fast too quickly, very similar to the infamous "how to draw an owl" meme.

[amelius]

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

[Sesse__]

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

[relssiegp]

I had the same thoughts about SIMD code being too verbose when I wrote some, so a few months ago I tried writing a library that lets you write quasi-GLSL code in C++, so much more compact, with the ability to switch between SIMD width without having to rewrite anything at all:

https://github.com/gitdepierre/cppshader

Not sure it will ever be useful, but it was a fun pet project with some interesting problems to solve.

[puilp0502]

Is GLSL more "approachable" than SIMD? For me personally (who doesn't have any graphics programming experience), GLSL feels way scarier than SIMD, especially when you look at the black magic that happens on shadertoys. Not saying GLSL is actually hard, but for a programmer like me SIMD might actually be more approachable

[relssiegp]

You're right, GLSL can be a bit confusing at first, especially swizzling, and the idea of writing your kernel only once then relying on the input data to drive your logic. But once you get used to it, it's very practical for writing complex stuff in just a few lines of code, it's really fun, and that's what you see a lot in Shadertoy.

I got the idea to write the library when I wanted a simplex noise function in C++, implemented with AVX2 for performance reasons (because why not). There were a lot of public HLSL/GLSL implementations that were concise and fast on GPU, some of which I had used for years for my own needs, but rewriting the whole code in plain C++ would have been a hassle, and i would have to do the same for every GPU code i came accross in the future, so building a wrapper seemed like the most efficient approach.

So in the end, the library is mostly aimed at people coming from the GPU world who want to keep most of their habits. But yeah, there is probably very few use cases for it.

[vasco]

The lines in SIMD are much simpler though. It's like replacing one line of "I have a desire for yellow nourishment from the tropics" to "give banana" 12x

[huvin99_]

What he's getting at is, the concept can be simple if you're open to understand it, and it actually is!

[1970-01-01]

It's not a nitpick. The undefined acronym problem strikes yet again. It is fantastic to never use to AI write your blog posts, but please at least have it read it once. It's literally free to catch these simple writing errors and improve your writing. Vis-a-vis:

     Everyone Should Know AI
     AI has a reputation for being complex. I've met many very good software engineers who dismiss it as something too complex to learn or a niche meant for only highest-performance, not useful everyday. I think that's wrong. AI can be simple to understand, and common AI editorializing can speed up a blog, and almost always follows the same general shape. Once you learn the basics, editorializing with AI is just easy. And when it's not, it's usually a good sign to skip it for now. Every developer should know at least that much AI.