Basic benchmark

Walter Bright newshound1 at digitalmars.com
Sat Dec 13 22:22:15 PST 2008


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.

I haven't worked on the code generator / optimizer, other than fixing 
bugs, since about 1995. While there are obviously specific cases where 
it could do better, overall it still does a good job. In fact, for a 
while it was #1 on the Shootout aggregate benchmark results.

By "good job", I mean that overall it's within 10%.

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

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.

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.



More information about the Digitalmars-d mailing list