On 18 February 2016 at 11:53, tsbockman via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> 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.
>

Typically things that you no one will ever notice, nor care to.  Anything that causes an ICE is a candidate for backporting.  Features or changes in behaviour are not in that list of approved things to backport.  For example, I typically raise (and Kai probably too) about half a dozen patches to DMD that fix bad or nonsensical frontend "lowering" in almost *every* release.

Saying that, I have in the past:
- Backported vector support from master when they first got accepted.
- Current 2.066FE uses C++ support from 2.068.

But these are, again, nothing that end users would ever be aware about.

On Thursday, 18 February 2016 at 11:47:48 UTC, Kai Nacke wrote:
> 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

As a casual user of the language I see that there is a fragmentation of resources and a waste in this regard with people developing in mainline, then some of you LDC guys catching up.

My simple assumption is that if presumably the dmd backend is not maintained anymore, a lot of the core dmd people can focus on improving whatever problems the frontend or glue layers have.

This could only mean that you core LDC guys could focus on llvm backend optimizations (both code gen and performance related). I'm going to assume that those kind of performance optimizations are also constantly done by upstream llvm, so more win here.

Users will not magically turn to contributors if their perception is that there is always going to be a catch-up game to play somewhere. Not to mention that if one want's to get something in LDC, one has to commit it in mainline, which is DMD, you just multiplied the know-how someone needs to have to do some useful work...

And finally, just pointing people to ldc/gdc (always a version or 2 behind, another grief) each time dmd performance is poor, looks awfully wrong.

On 02/17/2016 09:28 PM, rsw0x wrote:
> I'm curious where Andrei stands on this issue, IIRC he was upset at one
> point that dmd could not be redistributed properly on linux distros.

We'd love dmd's backend to have a more permissive license, and we have tried to make it so. Regardless, the dmd compiler is an important part of the D ecosystem and is here to stay. -- Andrei

On Thursday, 18 February 2016 at 12:16:49 UTC, Radu wrote:
> My simple assumption is that if presumably the dmd backend is not maintained anymore, a lot of the core dmd people can focus on improving whatever problems the frontend or glue layers have.

That's what they're already doing. Very little work is done on the backend (which is part of why it doesn't optimize as well as gcc or llvm). Occasionally, work has to be done on the backend, but by and large, the dmd devs are working on the frontend, which benefits gdc and ldc just as much as it does dmd. Now, that doesn't change the fact that the gdc and ldc guys could use more help, but and if the dmd backend were dropped, then presumably some of the work being done on the frontend would be going to the glue layer for either gdc or ldc, but that would further slow down the development of the frontend and not necessarily improve things overall.

Regardless, losing dmd's backend would be a _huge_ loss. Yes, the binaries that it generates are slower, but its faster compilation times are a huge win for developers and can significantly improve the development time of a project. It also has served us very well in impressing and attracting programmers to D. Ultimately, we want all three compilers with all three backends to be well-maintained and usable, because they each have their pros and cons.

- Jonathan M Davis

On 2016-02-18 01:35, Chris Wright wrote:

> Should Walter retire, there's a reasonable chance that LDC will become
> the primary compiler. However, compilation speed is important.

Walter working on D is his way of retiring ;)

-- 
/Jacob Carlborg

On Thursday, 18 February 2016 at 12:48:23 UTC, Jacob Carlborg wrote:
> On 2016-02-18 01:35, Chris Wright wrote:
>
>> Should Walter retire, there's a reasonable chance that LDC will become
>> the primary compiler. However, compilation speed is important.
>
> Walter working on D is his way of retiring ;)

Well said :)

On Wednesday, 17 February 2016 at 22:57:20 UTC, Márcio Martins wrote:
> 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?

Squeezing that last ounce of performance out of the processor is only one reason to use D, and to be perfectly honest, not likely to ever be a selling point, because you're not going to consistently beat C++ by 30% or 40% anyway.

D's selling point is the design of the language. DMD offers another selling point, fast compilation, and for many tasks the inefficiency is irrelevant. "If you're careful, as fast as C++" isn't by itself the most compelling sales pitch.

On Thursday, 18 February 2016 at 12:05:12 UTC, Jonathan M Davis wrote:
> 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

I agree with that. It also means that it would be considerably easier to have a setting in LDC/GDC that generates slightly worst code, and compiles slightly faster... perhaps never reaching the speed of DMD, but compilation speed is not the only factor, is it?

GCC/LLVM have many more supported platforms and architectures, produce faster code, and have large communities behind them, constantly optimizing and modernizing, backed by it giants like Google, Apple, ...

I cannot say for GCC but LDC also has considerably better tooling with the sanitizers.

LDC seems to also be the closest to support all major platforms and architectures, including iOS and Android which are huge markets. It supports Win64/Win32 (experimental) out-of-the-box.

Both LDC and GDC have no weird legal strings attached.
Both can be distributed with major Linux distros.

All that DMD has going for it is it's compilation speed.

These are all big points towards having more users experience and enjoy D as we do!

To get more contributors, more people have to use and believe in the language. DMD has a lot of clear barriers for this.

Really, not a lot has to change to start with, just fix the installers and slap the official tag in either LDC or GDC.

On Thursday, 18 February 2016 at 12:23:18 UTC, Jonathan M Davis wrote:
> On Thursday, 18 February 2016 at 12:16:49 UTC, Radu wrote:
>> My simple assumption is that if presumably the dmd backend is not maintained anymore, a lot of the core dmd people can focus on improving whatever problems the frontend or glue layers have.
>
> That's what they're already doing. Very little work is done on the backend (which is part of why it doesn't optimize as well as gcc or llvm). Occasionally, work has to be done on the backend, but by and large, the dmd devs are working on the frontend, which benefits gdc and ldc just as much as it does dmd. Now, that doesn't change the fact that the gdc and ldc guys could use more help, but and if the dmd backend were dropped, then presumably some of the work being done on the frontend would be going to the glue layer for either gdc or ldc, but that would further slow down the development of the frontend and not necessarily improve things overall.
>
> Regardless, losing dmd's backend would be a _huge_ loss. Yes, the binaries that it generates are slower, but its faster compilation times are a huge win for developers and can significantly improve the development time of a project. It also has served us very well in impressing and attracting programmers to D. Ultimately, we want all three compilers with all three backends to be well-maintained and usable, because they each have their pros and cons.
>
> - Jonathan M Davis

No to contradict what you said but there is still sensible work eating time, like Dwarf EH.

Probably making LDC part of the release process could make things better for both sides. I can see that after a while of sync releases someone will retire DMD for practical reasons.

Anecdotal evidence shows that each time D moved to a more open license or participation group things worked for the better.

On Thursday, 18 February 2016 at 12:22:20 UTC, Andrei Alexandrescu wrote:
> On 02/17/2016 09:28 PM, rsw0x wrote:
>> I'm curious where Andrei stands on this issue, IIRC he was upset at one
>> point that dmd could not be redistributed properly on linux distros.
>
> We'd love dmd's backend to have a more permissive license, and we have tried to make it so. Regardless, the dmd compiler is an important part of the D ecosystem and is here to stay. -- Andrei

Andrei, I agree with that. DMD is important and should be where most of the exploratory action happens. But does it really have to be the "face" of the D language?