D compiler benchmarks

Robert Clipsham robert at octarineparrot.com
Mon Mar 9 09:16:53 PDT 2009


bearophile wrote:
> - Having a C or C++ (or something better, where necessary) baseline reference can be very useful to know how much far is the D code from the fastest non-ASM versions.

This seems to be quite a popular request, I'll do this at some point

> - you can improve the graphs in the dbench.octarineparrot.com page so they can be read better.

How would you like them improved? I just copied and pasted some CSS to 
generate them, it can easily be tweaked to be easier to read.

> - Tune all your tests so they run for 6-15 seconds or more. If they run for less than 3 seconds there's too much measure noise.

Sounds like a good plan, I'll do that next time I run them

> - Taking the average of three runs isn't that good, but this is a tricky topic... Take the minimum for now.

Someone has already pointed this out, and I plan to do it next time. By 
minimum do you mean the fastest or slowest result?

> - With my browser the label "binarytrees2" is misplaced.

All the benchmarks on the right are slightly misplaced, I can't figure 
it out. I'll try and tweak it so it fits better one I get your input on 
how to improve the graphs.

> - what's the differece between nsievebits2 and nsievebits? And nbody and nbody2? Reading the source is good, but a small note too is good.

As you probably know, the tests are just from the shootout. The number 
is the version number of the test, I picked the tests that performed the 
best when there was more than one.

> - Both in GDC and LDC it's positive to add what backends they use (for example: ldc version: r1050 using LLVM 2.5).

I'll do that with the next update.

> - Note that currently LDC goes up only to -O3.

I thought 4/5 introduced linker optimisations? Either way it doesn't 
matter, -O5 will perform all the optimisations available with the 
current version of ldc.



More information about the Digitalmars-d mailing list