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).
