On Thu, 07 Apr 2011 15:20:41 -0400, Edward Jaffe <[email protected]> wrote:
I keep attending IBM presentations that assert the code generated by the C compiler will outperform assembler. Some programmers I respect have asserted the same thing. Every time I look into this I see the wonders of the C compiler's optimizer--which understands cache effects and how to best use the System z instruction pipe line. Empirically, however, I have yet to find a program written in C or any other language that can actually outperform a well-written assembler language program. Every time I think I've finally found the example that proves these assertions, it turns out the assembler program is doing something inefficient (like this case with LOADing a service module over and over) and, once fixed the assembler language program runs faster. Is it just me??
There are always pieces of information that are extremely useful in optimizing code that are simply not present in the code itself so not possible for a compiler to use in optimization. Consider, for example, a heavily executed loop with four if blocks. Except in very rare special cases, the compiler would have no idea which blocks are likely to be executed and which not. So, it has no choice but to treat them as having more or less equal probability of being executed so equally optimized. A programmer, on the other hand, even with only a glimmer of knowledge of what the program is doing can usually guess which if block is most likely to be executed so optimize the code for that if block, for example by holding registers and pointers needed for that if block over the whole loop while requiring saving and reestablishment of context for the unlikely if blocks. Programmers make decisions like this all the time without giving it much thought at all, the cumulative effect being that a compiler can huff and puff all it wants, it's at an unfair disadvantage and doesn't stand a chance. While some C compilers have a register directive that gives a hint to the compiler to try to keep a value in a register, this is a pretty blunt instrument and only buys one so much. All this said, probably the best predictor of program speed is the skill of the Assembler/C/Java/COBOL/whatever programmer. And for 95+% of the code out there, performance just has to be adequate for the task at hand, not great. -- Cheers, Alex Kodat Sirius Software
