It’s actually an interesting breakdown of ways NEON differs from SSE, and how a “direct” translation may well be sub optimal. Their first example is really illustrative of this. SSE has an instruction that pulls the top(I think?) but of each register and creates an 8bit mask from those. You can do similar in NEON but the perf is apparently terrible. But NEON has an instruction that packs some bits from each register into a 64bit value, and you can go from that to the masking behaviour you were presumably trying for originally, but much faster.
The other examples and case studies are similarly interesting.
I started studying the SSE code. This ended up not being useful and even counter productive. I only began to make good progress when I let myself forget what I knew about the SSE implementation and instead used the C code as a starting point. By letting myself back up and think about what the code was actually doing at a high level, and then thinking about how best to write that in NEON, I was able to come up with quite different approaches compared to the SSE code, and in the end the NEON version was much faster.
From the article also, 10-20% improvement (I guess in Instructions Per Cycle) on some str methods in glibc https://sourceware.org/git/?p=glibc.git;a=commit;h=3c9980698...
We could use some further optimisation in the emulated screen rendering code in VICE, particularly on ARM.
