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?
In general, compiler-generated assembly is on par with naieve hand-written assembly. It's not going to beat something that anyone put any real time into, but if time to market matters at all, you're not going to be able to put large amounts of time into hand-coding assembly.
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)
Agreed. I have used C almost every day for the last 25 years... And not only is the C more maintainable, it is more easily ported to new CPU architectures than assembly (complete rewrites in that case) -- and yes, it is a fast, low overhead language -- especially moreso when using the CPU vendors compilers over GCC since they already know the best way to optimize for their own architecture.
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. ;)
For decades people have said that compiler's code generation is at par... and it slowly has become more true. I read a lot of disassembly listings and I'm often pleasantly surprised at how clever some of the code is. However, there's also plenty of times where I see plainly wasted instructions as well.
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.
Yes, compiled C or C++ is almost always better. This is a major reason why the Microsoft compilers no longer support inline assembly code on the 64-bit architectures. (you can still link in assembled binaries of course)
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.
I thought people stopped writing Assembly a while ago but I recently interviewed at Apple and I interviewed with one group that deals with optimizations for vector mathematics using special hardware on the A4/A5 chips and he said they still write some code in Assembly because for performance reasons.
Comments
"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?
In general, compiler-generated assembly is on par with naieve hand-written assembly. It's not going to beat something that anyone put any real time into, but if time to market matters at all, you're not going to be able to put large amounts of time into hand-coding assembly.
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)
Agreed. I have used C almost every day for the last 25 years... And not only is the C more maintainable, it is more easily ported to new CPU architectures than assembly (complete rewrites in that case) -- and yes, it is a fast, low overhead language -- especially moreso when using the CPU vendors compilers over GCC since they already know the best way to optimize for their own architecture.
Here's a good example: http://article.gmane.org/gmane.comp.lang.lua.general/75426
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. ;)
For decades people have said that compiler's code generation is at par... and it slowly has become more true. I read a lot of disassembly listings and I'm often pleasantly surprised at how clever some of the code is. However, there's also plenty of times where I see plainly wasted instructions as well.
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.
Yes, compiled C or C++ is almost always better. This is a major reason why the Microsoft compilers no longer support inline assembly code on the 64-bit architectures. (you can still link in assembled binaries of course)
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.
I thought people stopped writing Assembly a while ago but I recently interviewed at Apple and I interviewed with one group that deals with optimizations for vector mathematics using special hardware on the A4/A5 chips and he said they still write some code in Assembly because for performance reasons.
You can take better advantage of SIMD instructions and keep more performance critical things in registers for example.