On Sun, Dec 14, 2008 at 3:22 PM, Walter Bright <newshou...@digitalmars.com> wrote: > Jarrett Billingsley wrote: >> >> 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. The >> reference compiler is just supposed to be _correct_, not necessarily >> _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, and it would be >> duplicated effort since GDC and LDC already do it better. > > But there are other reasons to keep the back end. Sometimes, I need to tweak > it to support something specific. For example, > > 1. the stuff to hook together module constructors > 2. thread local storage > 3. position independent code > 4. support for various function call sequences > 5. D symbolic debug info > 6. Generating libraries directly > 7. Breaking a module up into multiple object files > > and coming soon: > > 8. insertion of memory fences > Other possibilities are D specific optimizations, like taking advantage of > immutability and purity, that I doubt exist in a back end designed for > C/C++.
Of course that back end was also designed for C/C++ originally, right? But anyway, I agree with bearophile, that requiring too many special features out of a back end will make it hard for any alternative D compilers to keep up. > While of course all this can be added to any back end, I understand how to > do it to mine, and it would take me a lot of time to understand another well > enough to be able to know just where to put the fix in. That's understandable, but at some point it becomes worth the effort to learn something new. Many people get by just fine using C++. They may be interested in D, but it just takes too much effort. However, a little effort invested in learning D pays off (at least we all believe so or we wouldn't be here). Likewise, if there were a really solid well-maintained back end with a liberal open source license that generates great code, it would very likely be worth your time to learn it, even though it might be rough going in the short term. > Another thing I'd be very unwilling to give up on with the dmd back end is > how fast it is. DMC is *still* by far the fastest compiler out there. I'd gladly trade fast compilation for "has a future" or "supports 64-bit architectures" or "generates faster code" or "doesn't crash when there are too many fixups in main()". Have you seen the messages about how long it can take to compile DWT applications? DWT progs are already desperately in need of some smarter dependency tracking and ability to do minimal recompilations. I think implementing that (in a build system or whatever) would more than make up for the loss in raw compilation speed. Besides, I think a chunk of the the compilation speed is thanks to the module system, and avoiding the endless reparsing required for C++ #includes. So any D compiler should benefit. Anyone have the data for the time required to compile tango with DMD vs LDC? It would be interesting to see how bad the difference is. Anyway, all that said, it's not clear that we really do have that mythical "uber backend" available right now. According to my conversations on the clang mailing list, the current target is for LLVM to be able to fully support a C++ compiler by 2010. I'm not quite sure what all that involves, but apparently it includes things like making exceptions work on Windows. So it certainly does look a bit premature to move over to LLVM as the primary platform for D at this point. --bb
