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