On 12/6/2013 3:02 PM, Maxim Fomin wrote:
What surprises me most is claim that D can 'hypothetically' generate more
efficient code comparing with C, especially taking into account current
situation with code generation and optimization.
The claim about inherent advantages implies that code generation is not good
now. If it can be so efficient, why it is not the case? And if in practice it is
worse, than who cares that 'in theory' code can be better?
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.
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."
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.
- 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.
- phobos snowball - one invocation of some function in standard library leads to
dozens template instantiations and invocations of pretty much stuff
True enough, but does that lead to non-performant code? 2.064 cuts that down
quite a bit anyway, and I think we can make more improvements in this regard.
