Inherent code performance advantages of D over C?

[H. S. Teoh]

On Tue, Dec 10, 2013 at 08:28:14AM +0100, Joseph Rushton Wakeling wrote:
> On 09/12/13 20:45, Araq wrote:
> >That language X is faster than C in "practice" because X is much more
> >developer friendly and thus you can tweak your code much easier etc.
> >is an argument of every language out there.
> 
> Yes, but most languages (certainly most "friendly" ones) do not
> allow you to drill down into the details in the way that D does.
> 
> The claim that's made for most languages in my experience is that,
> sure, the language is ultimately slower, but the developer time
> saved is worth more than the performance hit, and if you ever
> _really_ need to gain that extra performance, you can always drop
> down into C.  Of course, that assumption doesn't hold for some
> domains (e.g. intensive scientific simulation, games...) which is
> why C/C++ still has a significant presence there.
> 
> By contrast with D you get all that friendliness of refactoring and
> redesigning and extra time to experiment with alternatives, but in a
> language which is speed-wise on a par with C anyway; and if its
> higher-level constructs cause any problems, you can drill down to
> micro-management of your program _while still writing in D_.  That's
> why D is very useful for heavy-duty scientific simulation and why
> unlike most other friendly languages it's a genuine contender for
> games programming.

Recently I rewrote one of my personal pet projects in D. It turned out a
lot better than the original C version -- D's high-level features made
it easier to implement complex functionality with relatively simple (and
readable!) code.

Then I came to a CPU-intensive bit, and initially things didn't look
very good: a particular medium-sized problem that I was using as a
real-life test case ran in seconds in the C version, but took a very
long time with the D version (about 40 *minutes*, if I remember). I was
a bit disappointed, but remembered that the D version was still not yet
refined. It turned out that I had overlooked a simple but very
significant optimization present in the C version that hadn't been
implemented in the D version yet. (Basically, it's a brute-force
combinatorial algorithm, so the complexity is exponential, and every
little problem reduction can make a big difference. In this case, it was
a matter of recognizing the equivalence of certain problem combinations
that allowed the reduction of the search space by a factor of about n
factorial.) In the original C code, it took quite a while to implement
this optimization because ...  well, in C, you had to spell out every
last thing, otherwise it just won't work. In D, I kicked a crude version
of it out in under a day.

Result? The D version now runs faster than the C version -- perhaps up
to an order of magnitude. I was suitably impressed.  It's not all roses
and flowers yet, of course -- the D version has some memory usage issues
that I need to work on, but the fact that an almost optimal-performing
version of the code could be done so smoothly in such a short time
speaks good things about D.

Plus, D's ease of expression made it so easy to implement new algorithms
without incurring runtime costs -- I easily implemented an A* search
algorithm instead of the original plain BFS, and now, for certain
problems, the D version flat out beats the C version in terms of
performance. Could I have implemented an A* search in the C version?
Sure, after weeks or months of careful reworking of the C code to make
sure I didn't break anything or introduce any segfaults. Arguably, the
result would perform better than D. But the fact of the matter is, with
D, I achieved extremely good performance for just a few days' work. And
I think that's the crux of the issue here: sure in C you can code in a
way that will beat every other language out there. But it requires a lot
of careful effort to get you there (not to mention dealing with all the
associated pitfalls). D may not get you all the way to absolute
every-last-drop-from-the-CPU performance, but it gets you 90% of the way
there, with far, far less effort. Most of the time, this is a far better
ROI than in C.


T

-- 
Three out of two people have difficulties with fractions. -- Dirk Eddelbuettel