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