On Friday, 6 December 2013 at 23:19:22 UTC, Walter Bright wrote:
You can write D code in "C style" and you'll get C results. To
get performance advantages from D code, you'll need to write in
a structurally different way (as Andrei pointed out).
Looking through Phobos, there is a lot of code that is not
written to take advantage of D's strengths. An apt one
discussed here recently is the std.path.buildPath, which is
written in "C style", as in allocating memory for its result.
A structural D style version would accept a range for its
output, and the range need not allocate memory. This would be
fundamentally faster than the typical C approach.
This pattern is repeated a lot in Phobos code.
I believe that most of your points are either insignificant
(like array length -
it is carried together with pointer almost everywhere in C)
I see a lot of C code that does strlen() over and over. I think
Tango's XML parser showed what can be done in D versus any
known C implementation. It took maximal advantage of D's
slicing abilities to avoid copying.
Dmitry's regex also showed huge gains over C regex
implementations.
This C code is easy to fix. Unlike in D there is no way to fix
constant gc allocations and if gc is disabled, you say good buy
to: classes, interfaces, exceptions, dynamic arrays, delegates,
lambdas, AA arrays, etc.
By the way, if you mentioned strlen(), lets compare printf() and
writeln().
or provide some marginal advantage.
Even a marginal advantage is a counter example to the claim
"there is no way proper C code can be slower than those
languages."
But summing this issues altogether makes D code cannot compete
with C code.
Such advantages are offset by:
- huge runtime library
C has a huge runtime library, too, it's just that you normally
don't notice it because it's not statically linked in. Be that
as it may, 2.064 substantially reduced the size of "hello
world" programs.
- constant runtime lib invocation and allocation stuff on heap
This is, as I mentioned, a problem with writing C style code in
Phobos.
is it a C style?
T[] data = [T, T, T];
or this:
T data;
auto dg = { return data; }
- horrible mangling (see
http://forum.dlang.org/thread/mailman.207.1369611513.13711.digitalmar...@puremagic.com
examples from hall of D mangling, mangling is so big, that
forum software goes
astray)
Long mangling is not an inherent language characteristic, as
that thread suggests improvements.
But this is flaw in implementation. Language and its advantages
are dead without implementation.
And again, notice that you are speaking about 'hypothetical
advantages' (language advantages) which implies two things:
1) current efficiency is worse when comparing with some benchmark
2) despite many years of development, community failed to realize
these advantages.
This makes me think that probably there is another reason of why
code is less efficient, for example fundamental characteristics
of the language make him hard to be quick. This is not bad per
se, but saying that language code can be faster than C, taking
into account some many problems with D, looks like advertisement,
rather then technical comparison.