Mid-term vision review

H. S. Teoh via Digitalmars-d digitalmars-d at puremagic.com
Sat Apr 4 13:48:27 PDT 2015


On Sat, Apr 04, 2015 at 01:10:43PM -0700, Walter Bright via Digitalmars-d wrote:
> On 4/3/2015 9:41 AM, David Nadlinger wrote:
> >On Friday, 3 April 2015 at 15:07:57 UTC, Andrei Alexandrescu wrote:
> >>On 4/3/15 3:10 AM, Andrea Fontana wrote:
> >>>It would be great to have dmd on embedded platforms.
> >>
> >>I agree. We just don't have the champion for that yet. -- Andrei
> >
> >I might obviously be biased, but to be honest I don't see much value
> >in starting to port a largely obsolete backend to a whole new
> >processor architecture.
> 
> It's not obsolete at all. There's nothing fundamentally wrong with it,
> or preventing new optimizations being added to it. After all, I didn't
> have trouble upgrading it from 16 to 32 bits, from 32 to 64, to Linux,
> to OSX, to SIMD, etc.

The trouble with the dmd backend is that it currently doesn't produce
very well-optimized code. I have consistently observed a 20-30%
performance degradation with code compiled with dmd vs. code compiled
with gdc (both with all optimization switches turned to the max). From
cursory investigation of the asm output, dmd appears to be unable to
inline beyond the most trivial function calls, doesn't do loop
refactoring / unrolling as well as gdc does, and a host of other little
things that all add up to poorer performance when CPU-intensive inner
loops are concerned. A lot of this deficiency shows up especially in
range-based code, which consists of lots of calls to small functions
from inner loops, where performance really matters.

Now, obviously, there's nothing (in theory) stopping you or anybody else
from improving the backend so that it *can* perform better
optimizations, but the fact of the matter is that there is a whole group
of dedicated contributors to gdc/ldc backends who are constantly honing
their respective optimizers, some of whom specialize in improving
optimizers, whereas AFAICT you are the only one here who's truly
comfortable with dmd's backend code and who can implement these
improvements within a reasonable amount of effort. However, we need you
for other, high-level things related to D -- we can't afford you to
spend all of your time working only on the optimizer in the backend.
Besides, even if you could, you're just one person, whereas gdc/ldc have
a much larger number of contributors, some of whose specialty is
optimization.  Do you realistically think you can singlehandedly outdo
all of them? And now we're talking about adding whole new platforms to
the backend, with all that it entails (need to write more optimization
code for each new target and maintain it all, etc.).

With all due respect, I recognize that you produced superior C/C++
compilers back in the day in spite of the naysayers, but as they say,
extraordinary claims require extraordinary proof. You had extraordinary
proof back then, in the form of actual compilers that generated superior
code. Unfortunately, today, staring me in the face is the irrefutable
data that dmd-produced code consistently performs 20-30% poorer than
gdc-produced code (sometimes I've seen it as bad as 40-50%). In light of
that, I find it hard to justify investing more effort into the dmd
backend when you could instead put your efforts into improving DMDFE and
let the gdc/ldc backend guys do what they do best.


T

-- 
Give me some fresh salted fish, please.


More information about the Digitalmars-d mailing list