SoylentNews is people
SoylentNews
Dan Luu demonstrates that even when optimizing, compilers often produce very slow code as compared to very basic source that is easily accessible to every assembly code programmer: Hand coded assembly beats intrinsics in speed and simplicity:
Every once in a while, I hear how intrinsics have improved enough that it's safe to use them for high performance code. That would be nice. The promise of intrinsics is that you can write optimized code by calling out to functions (intrinsics) that correspond to particular assembly instructions. Since intrinsics act like normal functions, they can be cross platform. And since your compiler has access to more computational power than your brain, as well as a detailed model of every CPU, the compiler should be able to do a better job of micro-optimizations. Despite decade old claims that intrinsics can make your life easier, it never seems to work out.
The last time I tried intrinsics was around 2007; for more on why they were hopeless then (see this exploration by the author of VirtualDub). I gave them another shot recently, and while they've improved, they're still not worth the effort. The problem is that intrinsics are so unreliable that you have to manually check the result on every platform and every compiler you expect your code to be run on, and then tweak the intrinsics until you get a reasonable result. That's more work than just writing the assembly by hand. If you don't check the results by hand, it's easy to get bad results.
For example, as of this writing, the first two Google hits for popcnt benchmark (and 2 out of the top 3 bing hits) claim that Intel's hardware popcnt instruction is slower than a software implementation that counts the number of bits set in a buffer, via a table lookup using the SSSE3 pshufb instruction. This turns out to be untrue, but it must not be obvious, or this claim wouldn't be so persistent. Let's see why someone might have come to the conclusion that the popcnt instruction is slow if they coded up a solution using intrinsics.
In my own experience, I have yet to find an optimizing compiler that generates code as fast or as compact as I am able to with hand-optimized code.
Dan Luu's entire website is a treasure trove of education for experienced and novice coders alike. I look forward to studying the whole thing. His refreshingly simple HTML 1.0 design is obviously intended to educate, and is an example of my assertion that the true experts all have austere websites.
(Score: 3, Interesting) by TheRaven on Sunday September 11 2016, @09:42AM
A human can craft 10 lines of assembly, keeping all important aspects of CPU architecture in mind, really easily
Architecture? Maybe. Microarchitecture? No chance. A modern CPU can have around a hundred instructions in flight at a time, typically has at least half a dozen independent pipelines, and has complex dependencies between them. It also has a very complex register rename unit and some horrible interactions between that and the pipeline (for example, on a number of recent Intel microarchitectures, xor %rax, %rax provides a hint that a register is dead and so can result in a factor of 2 speedup in a tight loop).
Even if you can keep all of this in your head, these details change significantly between microarchitectures. A little while ago, a colleague of mine wrote hand-crafted assembly routines for the C standard library memcpy, strcpy, and friends using a mixture of different AVX and SSE instructions. He found that a different one gave the best performance on each of the four most recent Intel microarchitectures and in some cases different ones gave the best performance with different microcode revisions within the same microarchitecture.
It's also worth noting that a big part of the reason that a human can beat a compiler ever is that a compiler almost never tries to generate optimal code, because it takes too long. Using a superoptimiser and an SMT solver for scheduling will beat any assembly programmer, but no one does this in conventional compilers because most people don't want to burn 15 minutes on CPU time optimising a single function, for every function in their code. If that function happens to be the hottest code path in their program, however, it's probably a lot cheaper to burn even a few hours of CPU time than a couple of days of expert assembly programmer time.
sudo mod me up