Basic benchmark

[Bill Baxter]

On Sun, Dec 14, 2008 at 3:22 PM, Walter Bright
<newshound1 at 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