DMD backend quality (Was: Re: DIP 1031--Deprecate Brace-Style Struct Initializers--Community Review Round 1 Discussion)

[H. S. Teoh]

On Mon, Feb 17, 2020 at 09:14:31PM +0000, Guillaume Piolat via Digitalmars-d wrote:
> On Sunday, 16 February 2020 at 00:16:24 UTC, H. S. Teoh wrote:
> > Of course, DMD is still very fast at compiling and useful for
> > smaller utilities and script-like programs where performance isn't
> > critical, or for running unittests for isolated modules during
> > development due to fast turnaround times. But codegen quality is
> > definitely not among the reasons I still use DMD.
> 
> I still happily use DMD for most development because it still builds
> faster.  (On Windows, try `dub -a x86 --compiler dmd` and see)

I don't use dub because it increases my build times by like 2X or more.
I do still use DMD for when I'm working on unittesting a single module
and don't need the entire program linked (`dmd -unittest -i -main -run
mymodule.d` is amazing).  But for my main program I prefer LDC, because
I'm frightened of discrepancies between compilers coming back to bite me
in the behind, plus for small utilities I sometimes just use debug
builds for "production" use, and LDC gives me basically a free 20%
performance boost for no extra effort.  Plus, it's annoying to have to
switch between different compiler options syntax just so I can use both
dmd and ldc2 for my builds.


> But yes adding -O -inline frightens me.

I've encountered quite a few obscure codegen bugs related to -O -inline.
It's great that they are fixed now, but from a user's POV it's a rather
unpleasant experience to have to deal with compiler bugs that only show
up with -O -inline.  It exarcerbates the problem of dmd producing slow
code, because now I'm forced to live with *not* using -O -inline.  It's
yet another reason to use LDC instead.


> I think DMD should play its strength of generating code very quickly
> :) even at the expense of output performance.

The thing is, for all the effort Walter put into making dmd as fast as
possible, when you're writing template-heavy code it's *still* slow.
Well, you say, then just write less templates.  But the problem is,
sometimes these compiler performance problems aren't obvious until your
project grows larger, and by then the templated code is already heavily
ingrained in your codebase and would be too onerous to rewrite.

So if I'm going to have to wait several seconds for my template-heavy
code to compile anyway, why not use a compiler that gives me better
codegen in return?


T

-- 
It is impossible to make anything foolproof because fools are so ingenious. -- Sammy