Updated D Benchmarks

[Robert Clipsham]

bearophile wrote:
> Robert Clipsham, the pages are indeed improved a lot. Thank you for your work.

Thanks, I'm glad you approve!

>> with all benchmarks limited to 256mb memory usage<
> - Some benchmarks of the Shootout site will probably need more than 256 mb of RAM.

None of the ones that I'm currently using are. This is just an arbitrary 
limit I have put in place so my server doesn't run out of memory.

>> The only request I believe I've missed (correct me if I'm wrong!) is a C 
>> or C++ reference. This was planned for inclusion, but I couldn't come to 
>> a conclusion on which compiler to include and whether to use C or C++.
>> Before you suggest having multiple references, I would rather only have 
>> one reference otherwise it becomes more general language benchmarks 
>> rather than D.
> 
> The purpose of the reference is to see how far are the D implementations from "a good enough" compilation. In most cases this means that you can time a C or C++ version (in some benchmarks other languages are faster than C/C++, but for the moment we can ignore this).
> So my suggest is just to take a look at the Shootout site, where you take your code from (D implementations aren't present anymore, but there are kept elsewhere if you need them), and use the C version every time it's the faster between the C and C++ ones, and use the C++ version in the other cases (I give preference to the C version because they are generally simpler).

So you suggest I choose whichever performs best out of C or C++? What 
compiler would you recommend? Before I was leaning towards C++ (not sure 
on a compiler), purely because it has a more similar feature set to D/

> Few notes:
> - I may also offer you few more benchmarks not present in the Shootout site.

Thanks! I'd love to add more benchmarks, 6 doesn't give a great 
overview. Someone has already sent me a few which I plan to include, 
most of them seem to be x86-32 specific though so I've asked they're 
updated before I include them.

> - Now I suggest you to add more benchmarks.

My thoughts exactly!

> - Did you strip the executable produced by ldc and gdc? (If you do it, or you don't do it, then add a note that says it).

No, I did not strip them. I think I might add another page, one with 
executable sizes, another with stripped executable sizes.

> - What is the trouble of nbody with gdc?

I can't remember off the top of my head, I seem to recall it was a 
linking error though. I did try to debug it when they were originally 
run I didn't manage to get anywhere with it though.

> - when you give an URL into an email or post I suggest you to not put a full stop "." at the end, otherwise the person that reads the post may have to delete it manually later from the URL. If you really want to add a full stop or a closing parentheses, put a space before it, like this: (http://www.digitalmars.com/webnews/ ).

I generally do, it was 4am when I posted though ;P

> - The compilation times are too much small, so such values are probably noisy. So you may add another value: you can compile all the programs and take the total time required (this isn't the sum of the single compilation times). Otherwise you may need a different benchmark, a much longer D program, that you can compile with all three compilers.

I don't see a problem with this. Even if the values are noisy it still 
shows that the compilation times are tiny! I quite like your idea of 
summing the total compile time, I believe this will probably confuse 
some people and lead them to think D takes a long time to compile. I 
should note that compile times are unlikely to be accurate in any case 
as they are only compiled once.

> - From your results it seems ldc needs more memory to run the programs. The LDC team may take a look at this.

There doesn't seem to be that much difference, but I'm sure they'd be 
happy to look into it. One of the ideas of the benchmarks is to add a 
bit of competition and see if we can get D compilers even faster! :D
I think once we have a reference from a C or C++ compiler this will 
become even more true (providing D isn't faster already).