On Tuesday, 27 October 2015 at 03:10:43 UTC, H. S. Teoh wrote:
On Tue, Oct 27, 2015 at 02:21:38AM +0000, Laeeth Isharc via
Digitalmars-d wrote: [...]
So I would suggest it isn't productive to think about whether
Dmd will catch up. Maybe, maybe not. Doesn't matter. Making
it faster will help many - this defeatist attitude of 'why
bother - just use GDC or LDC' may not be the best long-term
strategy (remember that these too are volunteer projects, and
they don't have an army, especially GDC, and you shouldn't
assume that magically they'll always manage just because they
have so far), whether or not it catches up. There's always an
opportunity cost, but so what.
One should treat dmd performance as an interesting challenge,
not something that's set in stone, and can never much change.
While I agree that improving dmd performance will at the end of
the day reap benefits for all parties involved, I'm also not
holding my breath for that to happen. I haven't measured the
performance of the latest DMD git HEAD against GDC, but the
last time I checked (which is sometime earlier this year, not
that long ago), GDC-generated code still outperforms
DMD-generated code by 20%-30%.
Judging from the assembly code, this difference mainly arises
from the DMD inliner being overly conservative, and the lack of
advanced loop optimization techniques such as aggressive code
hoisting, strength reduction, unrolling, etc.. Fixing the
inliner will probably be relatively easy; loop optimizations
will be more challenging, especially if Walter continues to
insist on compilation speed. Some of the problems that have to
be solved in advanced loop optimization require more expensive
algorithms, which may incur a penalty on compilation time.
T
Thanks for the insight.
If the optimisations are configurable by the user, you pick your
poison, and live with that tradeoff, no?
