Basic benchmark

Jason House jason.james.house at gmail.com
Sat Dec 13 16:15:35 PST 2008


Bill Baxter wrote:

> 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
> from.
> 
> 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.
> 
> --bb

I couldn't agree more!

I never understood why people were so anti-gdc.  I would not be surprised to hear that the gdc developer(s) stopped after hearing just how little people appreciated their hard work.  



More information about the Digitalmars-d mailing list