"Wrong: use Assembler Language."
I'd be interested to see more research on this. I would hope that modern compilers can generate better optimised code than hand assembly for most cases by now.
Does anyone have any pointers to research on this topic?
I'd be interested to see more research on this. I would hope that modern compilers can generate better optimised code than hand assembly for most cases by now.
Does anyone have any pointers to research on this topic?
A good, clever human can generally beat a compiler.
There's a reason that the core of nearly any high performance multimedia, graphics, or encryption library is written in assembly, or compiler intrinsics (which are pretty much assembly instructions written in C syntax)
Granted, it's a niche case, though an important one -- using a switch statement for bytecode dispatch leads to poor branch prediction in VMs, and better alternatives require either non-standard extensions (http://eli.thegreenplace.net/2012/07/12/computed-goto-for-ef...) or assembler.
If you're really concerned with performance when writing C, try to avoid painting yourself into a corner. Profile. Consider custom memory allocators, if much of your time is spent creating short-lived or equal-sized objects. In general, look at the tricks the really hardcore game devs do in C++.
Also, use valgrind, because you'll probably cut too many corners. ;)
That's not the real reason that assembly is often not worth it, even in situations where it once was. The real culprit is that for a long time CPUs were outpacing memory in speed gains, so a cache miss became more and more expensive relative to the clock speed.
This meant that more and more micro-optimization work has gotten focused on cache behavior. C gives you just as much control over how your data structures are stored as assembly would. Maybe you'll need to define some prefetch() macros depending on your compiler, but that's about it.
There are certainly some remaining cases where you really want to control things at a register-allocation level (encryption, codecs, fancy floating-point things) However, most projects are better off focusing on improving their memory behavior rather than trying to get to that cache miss in 80 instead of 82 cycles.
The other huge shift in performance-oriented computing is, of course, the availability of more and more CPU cores. Again, lots of work to do but assembly doesn't give you any advantage at all.
So even if you're good enough at writing assembly to beat the compiler (and most people aren't) you probably should have been spending your optimization effort on other things.
This brings to mind another reason why the statement "Wrong: use Assembler Language" is so goofy. You're never going to use assembly language. You're going to use 99.9% C or C++ and a bit of assembly language. "Use C if you want something to go as fast as possible" is still basically correct.