Trust about D programming.

[Era Scarecrow]

On Thursday, 24 January 2013 at 04:31:24 UTC, H. S. Teoh wrote:
> For one thing, modern CPUs have pipelines and caches. Modern 
> optimizing C compilers often rearrange instructions in order to 
> maximize performance by reducing (or eliminating) pipeline 
> hazards and cache misses. The resulting assembly code often 
> look nothing like the source code. (In fact, some CPUs do this 
> internally as well, and optimizing compilers often rearrange 
> the code in order to take maximum advantage of what the CPU is 
> doing.)
>
> The result of this is that many of the so-called 
> "optimizations" that C programmers like to do by hand (and I am 
> among them) actually have no real benefits, and in fact, 
> sometimes has worse performance because it obscures your intent 
> to the compiler, so the compiler is unable to produce the best 
> code for it.

  I remember doing things like that. If I was dividing something 
by 8 I would shift right instead by 3; Although it does the same 
job it hides my intent from readers (and even myself) and might 
not allow the compiler to make better optimizations because of 
it. I ended up coming to the conclusion after reading a lot on 
compilers that the compilers do a decent job of finding cases 
where it replace them with better choices and condensing code. 
Rather than doing math for a fixed set of calculations, it 
pre-calculates them and sets it into variables that are used, 
drops whole sections that don't do anything, etc.

  In today's CPU's the C compiler is somewhat obsolete. Half the 
time to make use of special hardware (say the MPU's in video 
cards) you need to do assembly code anyways for access to them. 
The compiler might make use of MMX or other instruction sets but 
that seems a bit more unlikely on it's own without some hints or 
certain code patterns that suggest heavy use where it would 
benefit heavily from (and the hardware flags know the target can 
handle said instructions).