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

[H. S. Teoh]

On Tue, Feb 18, 2020 at 07:12:34PM +0300, drug via Digitalmars-d wrote:
> On 2/18/20 6:30 PM, jxel wrote:
> > 
> > The problem is that efforts are divided as a result.
[...]

That's the fallacy described in "The Mythical Man-Month".


> IMO you are wrong if you think that dropping dmd will increase man
> power in ldc/gdc land. Who wants to contribute to ldc/gdc already
> doing it. It is open source - people contribute to projects they like,
> you can not tell them what to do. Efforts are not divided - if dmd
> would be dropped people who doesn't contribute to ldc/gdc won't start
> doing that.

Yeah, this is not a commercial endeavour where people are paid to work
on stuff they didn't choose to work on.  The people currently working on
dmd do so because they *want* to work on dmd.  If we drop dmd, they may
end up going elsewhere to find something else they're interested
instead. There's no reason to expect that they will suddenly acquire a
fresh interest in ldc/gdc -- if they already had such an interest they'd
already be working on ldc/gdc.


> On 2/18/20 6:30 PM, jxel wrote:
[...]
> > The slowest part of D is the frontend and CTFE not the backend in
> > LDC.

?!  That's clearly not true.  I'm compiling the same codebase with dmd,
and it's measurably faster than ldc2.  Since it's identical source code,
and the two compilers share the same frontend, the only possible
difference in compile times must be due to the different backends.

Of course, compile speed isn't the only criterion for choosing between
compilers, and that's why I still prefer using LDC in spite of DMD being
faster at compiling.  The deciding factor is the fact that the LDC
backend, in spite of being slower, emits better code.  So I'm gaining
more runtime performance by paying with slightly longer compile times.
The increase in compile times is (currently) outweighed by the superior
performance of the resulting executable.


> > That's not even mentioning the constant out of memory problems
> > I experience and have to try to optimize the compiler for with my
> > code.

The frontend's memory issues are mainly because Walter switched to a
bump-the-pointer allocator in interest of compile speed.  Even with
-lowmem there are still fundamental problems that are unsolvable when
running a low-memory system.  I've essentially given up using dmd on
low-memory systems.  Fast compile times are worthless when the compiler
never finishes running before it runs out of memory. It's an
embarrassment.  (And this is why the whole "fast code fast" slogan makes
me cringe. It epitomizes one of the worst aspects of D in my
experience, in spite of everything else I love about D.)


T

-- 
"640K ought to be enough" -- Bill G. (allegedly), 1984. "The Internet is not a primary goal for PC usage" -- Bill G., 1995. "Linux has no impact on Microsoft's strategy" -- Bill G., 1999.