DMD is slow for matrix maths?

[H. S. Teoh via Digitalmars-d]

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

-- 
Creativity is not an excuse for sloppiness.