On Sunday, 30 June 2013 at 19:48:45 UTC, Gabi wrote:
Hi D community,
I am new to D and got impressed with the language so much that
I was thinking on introducing D it my workplace as an
alternative to C++ which is heavily used on our projects.
The first question that came up was how it stands up with C++
performance wise ?
I didn't find D on the shootout site (why?) and didn't find
almost any benchmarks comparisons.
Are there any good comparisons out there ?
Gabi
D used to be in the shootout, and was doing very good, right on
par with g++. That was before Isaac Gouy, the maintainer of the
shootout/benchmark game, decided to remove a number of languages,
among which D. Don't ask us what his criteria are, noone knows
for sure.
Overall, the performance of D can be extremely good. It is most
often largely superior to Java, and it can even be better than
C++ in non trivial programs, if one cares about not allocating
too much on the heap. It seems indeed that the automatic memory
management is a major performance killer, and it's not always
easy to know in advance what the overall performance of D code
will be. But the less work for the GC, the better.
To illustrate this, in one recent thread, one guy did a direct
translation of his C++ raytracer to D. His first attempt wasn't
very good, as the D version was almost 10x slower than the C++
version (with the same gcc backend), which is abnormal. A few
simple optimizations later (without changing the algorithm), the
D version was 40% faster than the g++ -O2 version. Another
example of high performance is the std.regex library, which is
known to be faster than all other implementations that we've
heard of, in any language. So yes, one can get stellar
performance out of D, but I would say right out of the box, it's
not automatic, it does require some work where high performance
is needed. However, out of all the existing languages, it's
probably second only to C++.
Up until fairly recently, memory allocation was not considered a
primary concern, so that some parts of the Phobos standard
library do allocate memory behind the scene. But today, a lot of
attention is being paid not to allocate when it's not absolutely
necessary, and the standard library is slowly being expurged of
unnecessary allocations. This is largely a manual process,
though. In a not too distant future (say before 2014), some
tooling will help detecting spurious memory allocations, so that
there is good hope that the Phobos library will be essentially
clean in that regard. Also, there is some work going on for a
concurrent GC.
