Yes all three compilers shared same frontend (different version generaly)

Dne 18.2.2016 v 09:57 Luis via Digitalmars-d napsal(a):
> On Thursday, 18 February 2016 at 00:35:01 UTC, Chris Wright wrote:
>> On Wed, 17 Feb 2016 22:57:20 +0000, Márcio Martins wrote:
>>
>>> I was reading the other thread "Speed kills" and was wondering if there is any practical reason why DMD is the official compiler?
>>
>> Walter Bright is the lead developer, and for legal reasons he will never touch source code from a compiler he didn't write. And since DMD is something like twice as fast as LDC, there's at least some argument in favor of keeping it around.
>>
>> Should Walter retire, there's a reasonable chance that LDC will become the primary compiler. However, compilation speed is important.
>>
>> I'm not sure how different LDC and DMD are, but perhaps you could use DMD for development and LDC for production builds?
>
> Correct me, but If I understand correctly what I read on other threads, LDC & GDC uses the same frontend that DMD, but a few versions more older because they need to update the glue layer the front end with lvm/gnu backend ?

On Thursday, 18 February 2016 at 00:35:01 UTC, Chris Wright wrote:
> On Wed, 17 Feb 2016 22:57:20 +0000, Márcio Martins wrote:
>
>> I was reading the other thread "Speed kills" and was wondering if there is any practical reason why DMD is the official compiler?
>
> Walter Bright is the lead developer, and for legal reasons he will never touch source code from a compiler he didn't write. And since DMD is something like twice as fast as LDC, there's at least some argument in favor of keeping it around.
>
> Should Walter retire, there's a reasonable chance that LDC will become the primary compiler. However, compilation speed is important.
>
> I'm not sure how different LDC and DMD are, but perhaps you could use DMD for development and LDC for production builds?

Walter should not need to ever work on D compiler back-ends, there are *a lot* of issues to be dealt with in the language implementation that are front-end only or at least not backend related. There are others that can work/already work with the LLVM backend and they seam to know what they are doing.

There warts and issues in the language/runtime/phobos are well know, spending time fixing them is more valuable for the community rather than having Walter (maybe others) working on any dmd backend stuff.

As rsw0x suggested, a push to get LDC on sync with mainline, and switching to it after it would make more sense in the long run. Probably focusing on LDC and investing more man power will also help fix any perf issues re. compile time, there should bot be much to loose here at least for debug compile times.

All this of course depends on Walter's willing to give up working on DMD, whatever this means for him.

On Thursday, 18 February 2016 at 10:16:40 UTC, Radu wrote:
> On Thursday, 18 February 2016 at 00:35:01 UTC, Chris Wright wrote:
>> On Wed, 17 Feb 2016 22:57:20 +0000, Márcio Martins wrote:
>>
>>> I was reading the other thread "Speed kills" and was wondering if there is any practical reason why DMD is the official compiler?
>>
>> Walter Bright is the lead developer, and for legal reasons he will never touch source code from a compiler he didn't write. And since DMD is something like twice as fast as LDC, there's at least some argument in favor of keeping it around.
>>
>> Should Walter retire, there's a reasonable chance that LDC will become the primary compiler. However, compilation speed is important.
>>
>> I'm not sure how different LDC and DMD are, but perhaps you could use DMD for development and LDC for production builds?
>
> Walter should not need to ever work on D compiler back-ends, there are *a lot* of issues to be dealt with in the language implementation that are front-end only or at least not backend related. There are others that can work/already work with the LLVM backend and they seam to know what they are doing.
>
> There warts and issues in the language/runtime/phobos are well know, spending time fixing them is more valuable for the community rather than having Walter (maybe others) working on any dmd backend stuff.
>
> As rsw0x suggested, a push to get LDC on sync with mainline, and switching to it after it would make more sense in the long run. Probably focusing on LDC and investing more man power will also help fix any perf issues re. compile time, there should bot be much to loose here at least for debug compile times.
>
> All this of course depends on Walter's willing to give up working on DMD, whatever this means for him.

Walter doesn't have to give up working on DMD, right? Everyone could continue working on DMD, perhaps a few people could help on all three, I don't know... It's important if more people work on DMD and focus on polishing the frontend and language features, being the reference compiler, and used by all three compilers as well. What could potentially be important would be to backport key fixes/features from current frontend to LDC/GDC as well.

On Thursday, 18 February 2016 at 06:57:01 UTC, Kai Nacke wrote:
> On Wednesday, 17 February 2016 at 22:57:20 UTC, Márcio Martins wrote:
>> I was reading the other thread "Speed kills" and was wondering if there is any practical reason why DMD is the official compiler?
>>
>> Currently, newcomers come expecting their algorithm from rosetta code to run faster in D than their current language, but then it seems like it's actually slower. What gives?
>>
>> Very often the typical answer from this community is generally "did you use LDC/GDC?".
>>
>> Wouldn't it be a better newcomer experience if the official compiler was either LDC or GDC?
>> For us current users it really doesn't matter what is labelled official, we pick what serves us best, but for a newcomer, the word official surely carries a lot of weight, doesn't it?
>>
>> From a marketing point of view, is it better for D as a language that first-timers try the bleeding-edge, latest language features with DMD, or that their expectations of efficient native code are not broken?
>>
>> Apologies if this has been discussed before...
>
> Hi,
>
> even if DMD is the official reference compiler, the download page http://dlang.org/download.html already mentions "strong optimization" as pro of GDC/LDC vs. "very fast compilation speeds" as pro of DMD.
>
> If we would make GDC or LDC the official compiler then the next question which pops up is about compilation speed....
>
> Regards,
> Kai

I agree that there is potential for compilation speed to become the new question, but I don't think it's very likely for newcomers to have larger codebases to compile for compilation speed to matter.

I suppose it's a lot easier to address the compilation speed issue in LDC/GDC, than to improve and maintain DMD's backend to the expected levels, right?

On 18 February 2016 at 11:42, Márcio Martins via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On Thursday, 18 February 2016 at 10:16:40 UTC, Radu wrote:
>
>> On Thursday, 18 February 2016 at 00:35:01 UTC, Chris Wright wrote:
>>
>>> On Wed, 17 Feb 2016 22:57:20 +0000, Márcio Martins wrote:
>>>
>>> I was reading the other thread "Speed kills" and was wondering if there
>>>> is any practical reason why DMD is the official compiler?
>>>>
>>>
>>> Walter Bright is the lead developer, and for legal reasons he will never touch source code from a compiler he didn't write. And since DMD is something like twice as fast as LDC, there's at least some argument in favor of keeping it around.
>>>
>>> Should Walter retire, there's a reasonable chance that LDC will become the primary compiler. However, compilation speed is important.
>>>
>>> I'm not sure how different LDC and DMD are, but perhaps you could use DMD for development and LDC for production builds?
>>>
>>
>> Walter should not need to ever work on D compiler back-ends, there are *a lot* of issues to be dealt with in the language implementation that are front-end only or at least not backend related. There are others that can work/already work with the LLVM backend and they seam to know what they are doing.
>>
>> There warts and issues in the language/runtime/phobos are well know, spending time fixing them is more valuable for the community rather than having Walter (maybe others) working on any dmd backend stuff.
>>
>> As rsw0x suggested, a push to get LDC on sync with mainline, and switching to it after it would make more sense in the long run. Probably focusing on LDC and investing more man power will also help fix any perf issues re. compile time, there should bot be much to loose here at least for debug compile times.
>>
>> All this of course depends on Walter's willing to give up working on DMD, whatever this means for him.
>>
>
> Walter doesn't have to give up working on DMD, right? Everyone could continue working on DMD, perhaps a few people could help on all three, I don't know... It's important if more people work on DMD and focus on polishing the frontend and language features, being the reference compiler, and used by all three compilers as well. What could potentially be important would be to backport key fixes/features from current frontend to LDC/GDC as well.
>

There seems to be a deterrence against backporting ie: 2.068 fixes to 2.066 for LDC/GDC.  I have no idea why, I do it all the time. :-)

On Thursday, 18 February 2016 at 10:48:46 UTC, Iain Buclaw wrote:
> There seems to be a deterrence against backporting ie: 2.068 fixes to 2.066 for LDC/GDC.  I have no idea why, I do it all the time. :-)

Part of the problem is just that no one else knows *which* fixes have been back-ported - there doesn't seem to be a list prominently displayed anywhere on the GDC home page.

This leaves people like myself to default to the assumption that the GDC/LDC front-end basically matches the DMD one of the same version.

On Thursday, 18 February 2016 at 06:57:01 UTC, Kai Nacke wrote:
> even if DMD is the official reference compiler, the download page http://dlang.org/download.html already mentions "strong optimization" as pro of GDC/LDC vs. "very fast compilation speeds" as pro of DMD.
>
> If we would make GDC or LDC the official compiler then the next question which pops up is about compilation speed....

Yeah. dmd's compilation speed has been a huge win for us and tends to make a very good first impression. And as far as development goes, fast compilation speed matters a lot more than fast binaries. So, assuming that they're compatible enough (which ideally they are but aren't always), I would argue that the best approach would be to use dmd to develop your code and then use gdc or ldc to build the production binary. We benefit by having all of these compilers, and I seriously question that changing which one is the "official" one is going to help any. It just shifts which set of complaints we get.

Regardless, dmd's backend was written by Walter and is the one he's worked on for something like 25 years. I would be shocked if he were to switch to something else now. And actually, he'd risk legal problems if he did, because he doesn't want anyone to be able to accuse him of taking code from gcc or llvm. Yes, dmc/dmd has failed to keep up with gcc/gdc and llvm/ldc in terms of optimizations, because there are far fewer people working on it, but it compiles way faster than they do. There are advantages to each, and as long as that's clear, and we treat gdc and ldc as least semi-official, I think that we're fine. If anything, the problem is probably that the gdc and ldc folks could use more help, but dmd and Phobos suffer from that problem on some level as well, albeit probably not as acutely.

- Jonathan M Davis

On Thursday, 18 February 2016 at 10:45:54 UTC, Márcio Martins wrote:
> I suppose it's a lot easier to address the compilation speed issue in LDC/GDC, than to improve and maintain DMD's backend to the expected levels, right?

LLVM has about 2.5 million code lines. I am anything than sure if it is easy to improve compilation speed.

Regards,
Kai

On Thursday, 18 February 2016 at 11:12:57 UTC, Jonathan M Davis wrote:
> If anything, the problem is probably that the gdc and ldc folks could use more help, but dmd and Phobos suffer from that problem on some level as well, albeit probably not as acutely.
>
> - Jonathan M Davis

Yes, participation is a key issue for all compilers and the libraries.

It is easy to say that compilation speed of ldc may be fixed. But turning on the profiler and looking for potential improvements is a totally different action.
As always I welcome every contribution to ldc. :-)

Regards,
Kai

On Thursday, 18 February 2016 at 11:41:26 UTC, Kai Nacke wrote:
> On Thursday, 18 February 2016 at 10:45:54 UTC, Márcio Martins wrote:
>> I suppose it's a lot easier to address the compilation speed issue in LDC/GDC, than to improve and maintain DMD's backend to the expected levels, right?
>
> LLVM has about 2.5 million code lines. I am anything than sure if it is easy to improve compilation speed.

On some level, I would expect compilation speed and generating well-optimized binaries to be mutually exclusive. To get those extra optimizations, you usually have to do more work, and that takes more time. I'm sure that some optimizations can be added to dmd without particularly compromising compilation speed, and gdc and ldc can probably be made to compile faster without losing out on optimizations, but you can only go so far without either losing out on compilation speed or on optimizations. And obviously, it's not necessarily easy to make improvements to either, regardless of whether it comes at the cost of the other.

- Jonathan M Davis