DMD is slow for matrix maths?

[Jack Stouffer via Digitalmars-d]

On Tuesday, 27 October 2015 at 02:21:40 UTC, Laeeth Isharc wrote:
> In addition, it's mildly demoralising to others to say such 
> things, no matter how good ones intent might be.

My intentions are to call things as they are. If people are 
demoralized after learning that one person working in his spare 
time can't match the productivity of several people working full 
time, then they need a reality check.

> You maybe need some increase in contributions

People are perfectly willing to contribute to the front-end of 
dmd as it's boost licensed and not esoteric. The back-end, as I 
mentioned before, is really only understood by two or three 
people. Also, the dmd back-end struggles to be classified as open 
source and is certainly in no way free software. Those two things 
don't really inspire many people to sink their teeth into dmd's 
backend, especially sense all of your work will become 
copyrighted by a private company after you submit it.

> Was Weka not using DMD, for example ?  (Maybe I misremember).  
> These things will change over time - look at the spurt of 
> hiring lately, and I am doing my small part too (beginnings are 
> often small).

Companies using dmd are unlikely to influence dmd's codegen in 
any way. The biggest thing that companies will complain about are 
compiler and Phobos bugs, as it actively stops them from doing 
any work.

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

No one is saying use gdc or ldc, people are saying use gcc or 
llvm.

> There's always an opportunity cost, but so what.

Either you don't understand the concept of opportunity cost or 
your falling into the sunken costs fallacy.

> One should treat dmd performance as an interesting challenge, 
> not something that's set in stone, and can never much change.

goto opportunity_cost;