My colleagues and I have developed a technique that addresses a lot of the issues Mike discusses in that link. In this blog article explaining the technique, I included an example that nearly matches Mike's hand-coded assembly from your link: https://blog.reverberate.org/2021/04/21/musttail-efficient-i...

In my experience, the weakest point of modern optimizing compilers is the register allocator. As Mike mentioned in his link, in functions with loops that contain complex control flow, the register allocation just falls apart. Too often you see the register allocator forcing a spill on the fast path that was caused by code in a fallback path. You can sprinkle __builtin_expect(cond, 0) on all your guards until the cows come home but the register allocator still sees a big complicated connected graph and optimizes the whole thing together.

The technique described in my link above works around this by basically forcing a specific register allocation at each "operation" boundary, putting fallback paths in separate functions entirely (as much as possible), so that they will be considered totally distinct to the optimizer. This isn't a perfect solution, but it helps a lot.

My overall view is that you can rarely beat the compiler in straight-line code. It's mainly in loops with complex control flow where the compiler's code quality suffers.

That technique is beautiful! And the results are as good as I would expect, once you’ve given the compiler the information it needs to do a good job. I’ll keep this one in mind next time I need to clearly delineate the fast path from the fallback path and I’m using something with access to the musttail attribute.

Normally it's better to focus on high-level time-complexity improving optimizations but there's still a whole lot of things where you really need assembly micro-optimizations, since they usually offer a 10x or 100x speedup. It's just that those things usually only concern core libraries. Stuff like crc32. But the rest of the time we're just writing code that glues all the assembly optimized subroutines together.

I recently came across a presentation of the contrary: https://news.ycombinator.com/item?id=9396950

Of course it falls into the category you mentioned (specific thesis), but I would be interested in some recent opinions on this post.

I would just add that on kookier platforms, sometimes there more low hanging fruit to be picked up with asm. I can still (barely) beat sha256 on the arm64 using the hardware sha calls that not everyone implements, stuff like that.

The link to gmane does not work, since the content is only available via NNTP: http://news.gmane.io/ Do you have any backup etc?

I managed to track this down:

http://lua-users.org/lists/lua-l/2011-02/msg00742.html