DMD is slow for matrix maths?

[Laeeth Isharc via Digitalmars-d]

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?