Basic benchmark

Bill Baxter wbaxter at
Sat Dec 13 11:25:38 PST 2008

On Sun, Dec 14, 2008 at 3:07 AM, Jarrett Billingsley
<jarrett.billingsley at> wrote:
> On Sat, Dec 13, 2008 at 12:55 PM, Jason House
> < at> wrote:
>> Jarrett Billingsley wrote:
>>> I hope bearophile will eventually understand that DMD is not good at
>>> optimizing code, and so comparing its output to GCC's is ultimately
>>> meaningless.
>> Personally, I appreciate seeing this stuff from bearophile.  I use D in ways where speed really does count.  One of my draws to D was that it was a systems language that could be faster than something like Java.  I also was sick of C++ and its problems, such as code that requires workarounds for compiler bugs or lack of compiler optimization.  It's really sad to see D requiring the same kind of stuff.  For D to become as mainstream as C++, all of this stuff that bearophile posts must be fixed.
> Walter is the only one who can make DMD faster, and I think his time
> is much better spent on designing and maintaining the language.

I think the point is not to convince Walter to spend time working on
DMD's optimizer, but to convince him that the DMD optimizer is
hopelessly obsolete and thus should be abandoned in favor of another,
like LDC.  There's also the 64-bit issue.  I don't see Walter ever
making the current toolchain 64-bit capable (at least not on Windows).
 This is going to become an increasingly ridiculous limitation for a
supposed "systems programming language" as time marches on.

At some point something has to change.

> The reference compiler is just supposed to be _correct_, not necessarily
> _fast_.

Fortunately it's not an either/or situation.  If Walter chooses to
move the reference compiler to a mainstream compiler infrastructure,
then *he* can work on making the reference compiler correct, while
many *other people* (including many who don't know anything about D)
work on making the compiler fast.

> If Walter spent all his time working on making the the DMDFE
> optimizer better and making DMD backend produce faster code, he
> wouldn't have time to work on the language anymore,

Agreed.  That would be like putting lipstick on the proverbial pig.

> and it would be
> duplicated effort since GDC and LDC already do it better.

I guess it's possible to imagine a world where Walter cranks out DMDFE
code coupled to a sub-par DMD backend that no one uses, since everyone
has moved on to LDC or something.  But why go there?  LDC is
completely open source.  There's no reason the reference D compiler
can't also be the fast D compiler.  And become more open in the
process, too.

That reference compiler / fast compiler dichotomy might have been ok
for C++ back in the old "cfront" days, but in those days people
everywhere were dying for something a little more high-level than C.
Today they aren't.  In those days the big corps took notice of C++ and
most vendors were maintaining their own cfront-based compilers for
their own platforms with their own custom back-end optimizations.
There's nothing like that happening with D today.  Today the big corps
have C++ and if that's not high-level enough then they have 32-dozen
scripting languages and VM hosted byte-compiled languages to choose

So for a niche language like D, making the default compiler be a sucky
compiler is very bad marketing in my opinion.  And talk about
duplicating efforts -- every time Walter releases a new reference
compiler, the developers on the fast compiler have to scramble to
incorporate those changes, when they could be working on bug fixes and
other useful performance improvements.  And downstream bugfixes is
another area of duplicated efforts -- already LDC developers have
fixed various bugs in the DMDFE, and these must then be posted to
bugzilla for Walter to eventually put back into his version of DMDFE.

That said, LDC isn't quite there yet, especially on Windows, but it
would be very encouraging to see Walter take at least a little
interest in it.  The transition would be a little painful for a while,
but much less painful than trying to write a new back end from
scratch, and in the end I believe it would make D a much more viable
platform going forward.


More information about the Digitalmars-d mailing list