Optimizer of D

[Don Clugston]

Dave wrote:
> 
> Also, from your code in the OP, the result of process() is never used, 
> so the GCC optimizer might be optimizing some of that away also.
> 
> Regardless, floating point optimizations are currently not a strong 
> point of the DMC/DMD optimizer. If those were on par with GCC, then DMD 
> would probably take top honors here in the Language Shootout:
> 
> http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all
> 
> There are other frequent visitors to this NG (i.e.: Don Clugston) with a 
> lot of experience with writing non-trivial FP code and libraries with D...
> 
> Hope you don't mind me mentioning your name Don - If you see this, could 
> you chime in here with some common code-level optimizations, etc., that 
> you've found useful?

The DMD optimiser does not do much floating-point optimisation at all; 
it generates very simple x87 code. This forces you to make sure that 
your algorithms are optimal. Interestingly, I've found that with many 
types of problems, where you converge towards a solution, the bit of 
extra precision you get from 80-bit numbers gives you slightly faster 
convergence -- which can be more significant than low-level optimisation.

The usual rules apply --
(1) make sure you're using the right algorithm
(2) make sure your code is cache-efficient.
(3) speed only matters inside the innermost loops that are executed 
millions of times.

I think that the just-added compile-time function evaluation is going to 
be extremely significant; once all the bugs are out of it, we'll be able 
to add rule (4): make sure that everything in your innermost loops are 
evaluated at compile-time, if possible.

Note that if you're talking about graphics or games programming, the 
considerations are quite different to scientific programming; I don't 
know much about the former, others here are far more qualified than I am.

-Don.