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.