Basic benchmark

Jason House jason.james.house at gmail.com
Sun Dec 14 21:01:00 PST 2008


I have already hit long division related speed issues in my D code. Sometimes simple things can dominate a benchmark, but those same simple things can dominate user code too!

Walter Bright Wrote:

> Jarrett Billingsley wrote:
> > I hope bearophile will eventually understand that DMD is not good at
> > optimizing code, and so comparing its output to GCC's is ultimately
> > meaningless.
> 
> The long arithmetic benchmark is completely (and I mean completely) 
> dominated by the time spent in the long divide helper function. The 
> timing results for it really have nothing to do with the compiler 
> optimizer or code generator. Reducing the number of instructions in the 
> loop by one or improving pairing slightly does nothing when stacked up 
> against maybe 50 instructions in the long divide helper function.
> 
> The long divide helper dmd uses (phobos\internal\llmath.d) is code I 
> basically wrote 25 years ago and have hardly looked at since except to 
> carry it forward. It uses the classic shift-and-subtract algorithm, but 
> there are better ways to do it now with the x86 instruction set.
> 
> Time to have some fun doing hand-coded assembler again!
> 
> Fixing this should bring that loop timing up to par, but it's still not 
> a good benchmark for a code generator. Coming up with good *code 
> generator* benchmarks is hard, and really can't be done without looking 
> at the assembler output to make sure that what you think is happening is 
> what is actually happening.
> 
> I've seen a lot of benchmarks over the years, and too many of them do 
> things like measure malloc() or printf() speed instead of loop 
> optimizations or other intended measurements. Caching and alignment 
> issues can also dominate the results.
> 
> I haven't looked closely at the other loop yet.




More information about the Digitalmars-d mailing list