On Wednesday, December 21, 2016 22:05:32 Yuxuan Shui via Digitalmars-d wrote:
> On Wednesday, 21 December 2016 at 21:12:07 UTC, Jerry wrote:
> > On Wednesday, 21 December 2016 at 16:41:58 UTC, Jesse Phillips
> >
> > wrote:
> >> On Wednesday, 21 December 2016 at 16:30:15 UTC, bachmeier
> >>
> >> wrote:
> >>> [...]
> >>
> >> People that want to use D, want to use the latest and greatest. The reference compiler moves the fastest so they want the reference compiler to be switched to a different backend. Why a FOSS back end is required to use D depends on the person, usually it is political.
> >
> > Any other backend would be better. DMD with -O takes over an hour for my project to compile. In comparison LDC with -O3 takes less than a minute and produces a faster binary. It doesn't really make sense to increase the workload maintaining 2-3 different compilers when D is already lacking manpower.
>
> That sounds like a bug in the DMD backend...

Definitely. It is almost always the case that building a program with dmd is much faster than building with gdc or ldc. The tradeoff is that gdc and ldc do a much better job optimizing the resultant binary. So, with dmd, you get fast compilation but a somewhat slower binary, whereas with gdc and ldc, you get slow compilation but a faster binary.

If anyone is seeing dmd compile anything significantly more slowly than gdc or ldc, then dmd has a bug, and it should be reported (though reducing the code to something reportable can be entertaining; fortunately, dustmite can be a big help with that).

- Jonathan M Davis

On Wednesday, December 21, 2016 18:49:43 Johannes Pfau via Digitalmars-d wrote:
> Am Wed, 21 Dec 2016 08:18:48 -0500
>
> schrieb Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>:
> > On 12/20/16 6:08 PM, Andrei Alexandrescu wrote:
> > > Hello, a few engineers at Red Hat are taking a look at using the D language on the desktop and have reached out to us. They have created a list of issues. We are on the top-level ones, and of course would appreciate any community help as well.
> > >
> > > https://gist.github.com/ximion/77dda83a9926f892c9a4fa0074d6bf2b
> >
> > An engineer from Debian wrote down what's needed on the distribution side to give a green light to the D language:
> >
> > https://gist.github.com/ximion/fe6264481319dd94c8308b1ea4e8207a
> >
> >
> > Andrei
>
> "GDC does not support creating shared libraries at time, which is a big deal for distros which need it to reduce duplicate code and make security fixes easier."
>
> You can cross that one off the list.
>
> "GDC only supports an ancient version of the D standard library, which has many nice classes and also bugfixes missing."
>
> We're at 2.068.2 now. Still old, but good enough to run the latest vibe.D release.

Well, that's quite old at this point, and many programs will not build with it. vibe.d is a bit abnormal in that it tries to compile with several releases, whereas most projects tend to just use the latest. So, I think that the complaint that "GDC only supports an ancient version of the D standard library" is completely justified. At this point, if you want to compile with GDC, you pretty much need to target it and/or version portions of your code for different compilers or different compiler/library versions (which is what the vibe.d guys go to the extra effort of doing but very few D developers do). I fully expect that GDC will eventually catch up, but unfortunately, until it does, for many projects, it's useless. And I'd honestly recommend to people to avoid it until it does catch up, since otherwise, they're just going to run into compatability problems, and when they ask questions on SO or in the forums about what does or doesn't work, they're going to have problems due to differences in what does and doesn't work with GDC vs dmd and ldc.

- Jonathan M Davis

On Wednesday, December 21, 2016 15:46:19 Gerald via Digitalmars-d wrote:
> Given that DMD is a non-starter for Linux packages, how feasible is it to simply deprecate GDC and declare LDC as the reference/production compiler for D? DMD could become the experimental/future facing compiler used to evolve D as a language but not meant to be used for production code. This would resolve the non-free aspect of DMD as well as the ABI issue between compilers.

Anyone who wants to use ldc can use ldc. It doesn't need to be the reference compiler for that. And unlike gdc, it's actually pretty close to dmd. So, there should be no problem with folks using ldc for production right now if they want to.

- Jonathan M Davis

On Wednesday, 21 December 2016 at 21:27:57 UTC, Jack Stouffer wrote:
> On Wednesday, 21 December 2016 at 21:12:07 UTC, Jerry wrote:
>> Any other backend would be better. DMD with -O takes over an hour for my project to compile. In comparison LDC with -O3 takes less than a minute and produces a faster binary. It doesn't really make sense to increase the workload maintaining 2-3 different compilers when D is already lacking manpower.
>
> A 60:1 speedup? I've never heard of that big of a difference before. Especially since LDC is typically slower to compile, even on massive code bases like Weka's.
>
> Could you please file a bug with some details?

I ran it again, was a bit over a minute. But still 1 min 30 seconds compared to an hour.

1:07:40.162314 -- dmd with -O
0:01:28.632916 -- ldc2 with -O

0:00:23.802639 -- dmd without -O
0:00:33.818080 -- ldc2 without -O

It'd be quite a bit of work to narrow down what it is and if it has something to do with how many structures I use or otherwise. I'd have to try and emulate that with test code as I can't use my code. Then the issue would just sit there for who knows how long. It's not that big of an issue, as I just use ldc2 instead anyways.

On Wednesday, 21 December 2016 at 18:33:52 UTC, Brad Anderson wrote:
> On Wednesday, 21 December 2016 at 16:41:56 UTC, hardreset wrote:
>> On Wednesday, 21 December 2016 at 16:30:15 UTC, bachmeier wrote:
>>> On Wednesday, 21 December 2016 at 10:15:26 UTC, hardreset wrote:
>>>> On Tuesday, 20 December 2016 at 23:08:28 UTC, Andrei Alexandrescu wrote:
>>>>> Hello, a few engineers at Red Hat are taking a look at using the D language on the desktop and have reached out to us. They have created a list of issues. We are on the top-level ones, and of course would appreciate any community help as well.
>>>>
>>>> Is moving to LLVM backend or LDC something that is on the roadmap?
>>>
>>> What does it mean to "move" to LDC? Why can't you use LDC now?
>>
>> Moving the reference compiler to LLVM as was suggested in the list.
>
> I've never been able to understand why it matters.

Cause people think LDC is better and it would be a big win if everyone focused just on that. It's not about which has "official compiler" slapped on it, it's about where the development effort is focused.

That said I dont care really, I was just curious what the solution was to the closed source back end was.

On 12/21/16 7:09 PM, Jerry wrote:
> On Wednesday, 21 December 2016 at 21:27:57 UTC, Jack Stouffer wrote:
>> On Wednesday, 21 December 2016 at 21:12:07 UTC, Jerry wrote:
>>> Any other backend would be better. DMD with -O takes over an hour for
>>> my project to compile. In comparison LDC with -O3 takes less than a
>>> minute and produces a faster binary. It doesn't really make sense to
>>> increase the workload maintaining 2-3 different compilers when D is
>>> already lacking manpower.
>>
>> A 60:1 speedup? I've never heard of that big of a difference before.
>> Especially since LDC is typically slower to compile, even on massive
>> code bases like Weka's.
>>
>> Could you please file a bug with some details?
>
> I ran it again, was a bit over a minute. But still 1 min 30 seconds
> compared to an hour.
>
> 1:07:40.162314 -- dmd with -O
> 0:01:28.632916 -- ldc2 with -O
>
> 0:00:23.802639 -- dmd without -O
> 0:00:33.818080 -- ldc2 without -O
>
> It'd be quite a bit of work to narrow down what it is and if it has
> something to do with how many structures I use or otherwise. I'd have to
> try and emulate that with test code as I can't use my code. Then the
> issue would just sit there for who knows how long. It's not that big of
> an issue, as I just use ldc2 instead anyways.

Would be great to narrow this down regardless. Shouldn't be too difficult since the penalty is so huge. Must be a pathological case we should fix anyway. -- Andrei

On Thursday, December 22, 2016 00:59:27 hardreset via Digitalmars-d wrote:
> On Wednesday, 21 December 2016 at 18:33:52 UTC, Brad Anderson
> >> Moving the reference compiler to LLVM as was suggested in the list.
> >
> > I've never been able to understand why it matters.
>
> Cause people think LDC is better and it would be a big win if everyone focused just on that. It's not about which has "official compiler" slapped on it, it's about where the development effort is focused.

Most of the focus is on the frontend, not any of the backends. So, most of the work is automatically shared across all of the compilers. It's just that the frontend isn't 100% compiler agnostic (though work has been done to get it there), so some work has to be done to get it and the glue layer updated, and dmd gets that first. LDC isn't far behind though. GDC's main problem is the hump in getting from the frontend being in C++ to it being in D, and once they've got that sorted out, I expect that they'll be _much_ faster at updating.

Regardless, most of the effort is going towards stuff that has nothing to do with the compiler backend.

- Jonathan M Davis

On Thursday, 22 December 2016 at 01:30:44 UTC, Andrei Alexandrescu wrote:
>
> Must be a pathological case we should fix anyway. -- Andrei

Likely related bug has been open 5 years minus 1 day: https://issues.dlang.org/show_bug.cgi?id=7157

On Thursday, 22 December 2016 at 01:57:55 UTC, safety0ff wrote:
> On Thursday, 22 December 2016 at 01:30:44 UTC, Andrei Alexandrescu wrote:
>>
>> Must be a pathological case we should fix anyway. -- Andrei
>
> Likely related bug has been open 5 years minus 1 day: https://issues.dlang.org/show_bug.cgi?id=7157

Yup looks like that was the cause. Removed some of the functions that did a "foreach()" over some large tuples. Down to 26 seconds with that removed.

On Thursday, 22 December 2016 at 02:32:30 UTC, Jerry wrote:
> On Thursday, 22 December 2016 at 01:57:55 UTC, safety0ff wrote:
>> On Thursday, 22 December 2016 at 01:30:44 UTC, Andrei Alexandrescu wrote:
>>>
>>> Must be a pathological case we should fix anyway. -- Andrei
>>
>> Likely related bug has been open 5 years minus 1 day: https://issues.dlang.org/show_bug.cgi?id=7157
>
> Yup looks like that was the cause. Removed some of the functions that did a "foreach()" over some large tuples. Down to 26 seconds with that removed.

tuples as in compiler tuples ?
The T... kind ?