On 2/17/2020 11:57 PM, Basile B. wrote:
> No I say that some are not counted because they left github. For example me, I'm not in the list, despite of 80+ commits in DMD.

Oh, I see. So it's an undercount, the actual number of contributors is higher.

Anyhow, I can see becoming an inactive github user, but why leave, especially since github contributions can be a great asset for your resume? A number of significant D contributors have been able to leverage that into getting well compensated positions, a result I'm pretty proud of. I like to see you guys being successful.

On Monday, 17 February 2020 at 18:45:25 UTC, jxel wrote:
> On Monday, 17 February 2020 at 05:11:14 UTC, Walter Bright wrote:
>> On 2/16/2020 7:02 PM, Adam D. Ruppe wrote:
>>> (my personal experience btw is that bugzilla is where issues go to be ignored, lost, or forgotten for years.)
>>
>> Anyone can submit PRs to fix bugzilla issues, including you.
>
> That doesn't mean they will get merged. There's lots of PR open that have been open for years without any sort of feedback. Why would anybody waste their free time to simply have their work ignored?

This is not true. If a lot of PR are opened it's not because they are ignored. There are plenty of valid reasons and none matches to what your reductive POV.

- additional changes are requested but the author does not make these changes ;
- the changes cannot be merged because they need to be rebased ;
- the changes cannot be merged until other another PR get merged (label BLOCKED) ;
- the changes cannot be merged because they doesn't pass the test suite ;
- the changes are not accepted, they don't follow the language direction ;
- the PR is a draft or a WIP, so it get a bit ignored because the author ask for it ;
- the changes are too big, hard to understand ;
- the author doesn't care anymore ;
- the changes were not approved explicitly but the author doesn't close the PR ;
etc.

see https://github.com/dlang/dmd/pulls?q=is%3Apr+is%3Aopen+sort%3Acomments-asc

There is always at least one comment (excluding the one auto generated by the bot)

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 do not know about others, but I personally do not expect DMD to be as performant as people would like it to be. As a REFERENCE COMPILER I expect it to be as close to the current language specification as possible. DMD does that beautifully, and on top of that does a pretty good job at compiling code quite fast. I can't ask for more! - If they optimize the codegen to generate better code, that is fine, but not essential, as I use GCC (others may prefer LDC) for release builds.

On Tuesday, 18 February 2020 at 04:11:51 UTC, jxel wrote:
> On Monday, 17 February 2020 at 22:25:17 UTC, Walter Bright wrote:
>> On 2/17/2020 1:14 PM, Guillaume Piolat wrote:
>>> I still happily use DMD for most development because it still builds faster.
>>> (On Windows, try `dub -a x86 --compiler dmd` and see)
>>> 
>>> But yes adding -O -inline frightens me.
>>> I think DMD should play its strength of generating code very quickly :) even at the expense of output performance.
>>
>> No worries, there are no plans to change the fast path through the backend.
>
> If DMD used LDC to build itself, it'd run even faster. There's a PR open for that iirc.

Yes please !

On Tuesday, 18 February 2020 at 13:04:36 UTC, Dejan Lekic 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 do not know about others, but I personally do not expect DMD to be as performant as people would like it to be. As a REFERENCE COMPILER I expect it to be as close to the current language specification as possible. DMD does that beautifully, and on top of that does a pretty good job at compiling code quite fast. I can't ask for more! - If they optimize the codegen to generate better code, that is fine, but not essential, as I use GCC (others may prefer LDC) for release builds.

The problem is that efforts are divided as a result. Work still has to be maintained on the backend. As someone showed there's multiple PR that have stagnated because no one is willing to look at them that modify the backend to comply with the C ABI. Bugs that have been open for years. Bugs that don't exist in LDC, even though that's basically being maintained by one person. If people want a fast backend, you can build a custom backend for performance in LLVM, a few projects have done this already. But honestly that's a waste of time. The slowest part of D is the frontend and CTFE not the backend in LDC. 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.

On Tuesday, 18 February 2020 at 15:30:57 UTC, jxel wrote:
> On Tuesday, 18 February 2020 at 13:04:36 UTC, Dejan Lekic 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 do not know about others, but I personally do not expect DMD to be as performant as people would like it to be. As a REFERENCE COMPILER I expect it to be as close to the current language specification as possible. DMD does that beautifully, and on top of that does a pretty good job at compiling code quite fast. I can't ask for more! - If they optimize the codegen to generate better code, that is fine, but not essential, as I use GCC (others may prefer LDC) for release builds.
>
> The problem is that efforts are divided as a result. Work still has to be maintained on the backend. As someone showed there's multiple PR that have stagnated because no one is willing to look at them that modify the backend to comply with the C ABI. Bugs that have been open for years. Bugs that don't exist in LDC, even though that's basically being maintained by one person. If people want a fast backend, you can build a custom backend for performance in LLVM, a few projects have done this already. But honestly that's a waste of time. The slowest part of D is the frontend and CTFE not the backend in LDC. 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.

DMD already exists, nobody's forced to use it, and I doubt it's sucking any resources away from LDC.

On Tuesday, 18 February 2020 at 15:41:36 UTC, bachmeier wrote:
>
> DMD already exists, nobody's forced to use it, and I doubt it's sucking any resources away from LDC.

Is there one thing DMD does better, that is being able to debug with Visual Studio. With DMD you get full debugging information including locals, almost as you were debugging a C++ program. When I compile with LDC I just get basic debugging information. I presume that this is because LDC emits a different debugging format.

On 2/18/20 6:30 PM, jxel wrote:
> 
> The problem is that efforts are divided as a result. Work still has to be maintained on the backend. As someone showed there's multiple PR that have stagnated because no one is willing to look at them that modify the backend to comply with the C ABI. Bugs that have been open for years. Bugs that don't exist in LDC, even though that's basically being maintained by one person. If people want a fast backend, you can build a custom backend for performance in LLVM, a few projects have done this already. But honestly that's a waste of time. The slowest part of D is the frontend and CTFE not the backend in LDC. 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.
> 

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.

On Tuesday, 18 February 2020 at 15:00:47 UTC, Guillaume Piolat wrote:
>
> Yes please !

https://github.com/dlang/installer/pull/425

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