dmd codegen improvements

[Laeeth Isharc via Digitalmars-d]

On Sunday, 30 August 2015 at 16:17:49 UTC, Ola Fosheim Grøstad 
wrote:
> On Sunday, 30 August 2015 at 06:07:25 UTC, Laeeth Isharc wrote:
>> Morale is important in long term projects that don't pay off 
>> very quickly, and constant nagging and grumbling doesn't tend 
>> to help, even in the case when it is entirely well founded.
>
> Actually, it does help.

There's a big difference between saying "dmd generates code 
that's slow by the standards of modern C++ compilers.  it's an 
impressive accomplishment for a small group, but we ought to do 
better.  I know C++ and asm, and only have a little time, but I 
would like to help.  what would be most useful to look at ?"

and something else.

In my experience grumbling without action doesn't tend to lead to 
the change you want in the world.  In theory maybe it should, and 
someone will listen.  But human beings are funny creatures.

> There has been changes over time. Right now the most sensible 
> thing to do is
> to focus on stability, refactor the codebase, document the 
> codebase and track regressions. If you actually want others to 
> contribute you need to leading by example... E.g. you need to 
> get the boring stuff done first.

Well how would a dictator of D accomplish that?  Probably porting 
the compiler to D would be a pretty good start, for a variety of 
reasons.  That will help with stability, refactoring, and 
documentation I should have thought.  Not everyone knows C++, and 
of those who do, not everyone wants to write in it.

By the way, the dmd source code doesn't seem horribly obscure to 
read at first glance.

> If you actually want others to contribute you need to leading 
> by example

alors ?  as you point out, an asm.js backend would be rather nice 
to have, and you are by all accounts a low-level guy, so it 
shouldn't be hard to do, no ?

> There is absolutely no point in helping out with a project that 
> add features/optimizations faster than they are finished. Such 
> projects are never finished. Even if you got 10 more people to 
> work on it, the outcome would not be that it would be finished, 
> you would end up getting more features, not more polish.

Given that C compilers are still developing, I doubt D will ever 
be finished in my useful career.  So what ?  The facts speak 
against your claim, since D is clearly becoming more polished 
with every release - just look at the improvements to the GC 
within the past year.  (Runtime/compiler, whatever).

> For a project that is in perpetual beta leaders need to show 
> their priorities.

Andrei talked about documentation and presentation a little while 
back, and we're now in a much better state.  Allocators soon 
here.  People have got D to run on embedded systems with low 
resources.  GC is getting better - maybe not yet good enough for 
some, but I don't know that it's an easy problem and realistic to 
expect things to change in the space of a year.  etcimon has 
written something interesting - maybe a niche application or not 
yet ready for prime time - I haven't had time to see.

Walter talked about the need to get across that D is being used 
for serious business by serious people.  He made the Andy Smith 
talk happen, and that certainly increases the language 
credibility amongst a group that spends a lot of money on 
technology.  Maybe D will have another decent-sized hedge fund 
user soon.  I tried with a bank, but they had bigger problems.

> 1. Complete the language specification (define semantics).
> 2. Implement and polish semantics.
> 3. Clean up syntax.
> 4. Tooling.
> 5. Performance.

As some wit once said, what is true is not original, and what is 
original is not necessarily true.  Ie syntax/tooling/performance 
is already a focus here.  Semantics, I don't know.  I'd bet on 
good taste over excessive formalisation, but I am no computer 
science expert.  It's good enough for my modest needs.  I'd 
honestly bet that a little more effort to communicate the 
practical commercial benefits of D would make much more of a 
difference than this abstract stuff.  But who am I to say.



Laeeth.