Comment by tomsmeding | Hacker News Reader

Comment by tomsmeding | Hacker News Reader

Parent Full thread

To properly auto-vectorise this, you need to transform your ArrayOfStructures (AoS) representation to a StructureOfArrays (SoA) form, i.e. put all the r's next to each other, all the g's, etc. Then your operations are nicely in groups of four adjacent elements and the compiler will almost surely vectorise it.

I'm no black magician, but I think the fact that the operations you want to do in parallel (the r's of four adjacent pixels) do not access adjacent memory cells, requiring a gather instruction or somesuch, which I hear is either slow or unsupported. Alternatively, it could vectorise the pixels themselves, but that's three elements, not four. Does it auto-vectorise it if you also do the operation on the a's?

> Does it auto-vectorise it if you also do the operation on the a's?

Good point. Combined with fixing my loop increment (that jcranmer made me realize was wrong), I now get some vectory goodness: https://godbolt.org/z/yTJzKH

No idea what it all means. It'll be interesting to benchmark.

The code is not optimal, because there are implicit conversions to int (32-bit values) which are quite expansive. There should be explicit casts to uint16_t, like this: dest.r = uint16_t(uint16_t(dest.r * invAlpha) + uint16_t(c.r * c.a)) >> 8;

Adding a single uint16_t cast like this:

  dest.r = uint16_t(dest.r * invAlpha + c.r * c.a) >> 8;

Seems to get all of the benefit. The result is 34 instructions in the loop. (Was 38).

Amazingly, switching from gcc 8.2 to gcc trunk, reduces the instructions in the loop to 18. See https://godbolt.org/z/sEvz2w

Reply on news.ycombinator.com