On Thursday, 25 February 2016 at 03:05:21 UTC, Walter Bright wrote:
> On 2/18/2016 9:52 AM, Kai Nacke wrote:
>> I really like the compiler diversity.
>
> Me too. Having 3 major implementations is a great source of strength for D.

I like it too. I just think that we can't afford it at this point, and that this is a major impediment for improving the quality of the D ecosystem.

 — David

On Thursday, 25 February 2016 at 17:57:49 UTC, David Nadlinger wrote:
> I'm only playing devil's advocate because many people here make it seem as if there was no cost to supporting multiple compilers, while there most definitely is. This ranges from the blatant duplication of work over PR issues to the fact that big language/compiler features are all but impossible to implement for anybody but you, since you are the only one who knows how to implement them on DMD (and in the current situation, not having them available in DMD would be a deal-breaker).
>

It would be nice if the DMD frontend was completely uprooted from the DMD backend and put into separate git projects. The frontend should be completely agnostic from which backend it's using or else it's just more trouble the LDC/GDC developers have to deal with.

On Thursday, 18 February 2016 at 06:57:01 UTC, Kai Nacke wrote:
> If we would make GDC or LDC the official compiler then the next question which pops up is about compilation speed....
>

ldc is still significantly faster than clang, or gdc than gcc. I don't think this is that much of a valid concern, especially for smaller programs.

On Thursday, 25 February 2016 at 19:25:38 UTC, deadalnix wrote:
> On Thursday, 18 February 2016 at 06:57:01 UTC, Kai Nacke wrote:
>> If we would make GDC or LDC the official compiler then the next question which pops up is about compilation speed....
>>
>
> ldc is still significantly faster than clang, or gdc than gcc. I don't think this is that much of a valid concern, especially for smaller programs.

For larger programs, LDC with single-file compilation outdoes DMD by a large factor on any recent multi-core CPU for both debug and release builds in my tests. DMD did not scale across cores anywhere near as well as LDC.
OTOH, it does not benefit from singleobj this way when doing release builds.

On 02/25/2016 02:55 PM, rsw0x wrote:
> On Thursday, 25 February 2016 at 19:25:38 UTC, deadalnix wrote:
>> On Thursday, 18 February 2016 at 06:57:01 UTC, Kai Nacke wrote:
>>> If we would make GDC or LDC the official compiler then the next
>>> question which pops up is about compilation speed....
>>>
>>
>> ldc is still significantly faster than clang, or gdc than gcc. I don't
>> think this is that much of a valid concern, especially for smaller
>> programs.
>
> For larger programs, LDC with single-file compilation outdoes DMD by a
> large factor on any recent multi-core CPU for both debug and release
> builds in my tests. DMD did not scale across cores anywhere near as well
> as LDC.
> OTOH, it does not benefit from singleobj this way when doing release
> builds.

Good to know, thanks! -- Andrei

On 2/25/2016 1:50 PM, Andrei Alexandrescu wrote:
> Good to know, thanks! -- Andrei

DMD did slow down because it was now being compiled by DMD instead of g++. Also, dmd was doing multithreaded file I/O, but that was removed because speed didn't matter <grrrr>.

As I said, keeping the compiler speed up is a constant battle.

Currently, dmd makes zero user of multicore. I didn't know that ldc did.

On Thursday, 25 February 2016 at 19:55:20 UTC, rsw0x wrote:
> On Thursday, 25 February 2016 at 19:25:38 UTC, deadalnix wrote:
>> On Thursday, 18 February 2016 at 06:57:01 UTC, Kai Nacke wrote:
>>> If we would make GDC or LDC the official compiler then the next question which pops up is about compilation speed....
>>>
>>
>> ldc is still significantly faster than clang, or gdc than gcc. I don't think this is that much of a valid concern, especially for smaller programs.
>
> For larger programs, LDC with single-file compilation outdoes DMD by a large factor on any recent multi-core CPU for both debug and release builds in my tests. DMD did not scale across cores anywhere near as well as LDC.
> OTOH, it does not benefit from singleobj this way when doing release builds.

Would it be possible to point me in the directions of projects where you saw ldc being faster? I didn't try per-module, but on the projects I tried, dmd is still considerably faster when compiling per-package. And given that per-package is nearly always faster than per-module... (http://forum.dlang.org/post/yfykbayodugukemvoedf@forum.dlang.org)

Atila

On Thursday, 25 February 2016 at 22:38:45 UTC, Atila Neves wrote:
> On Thursday, 25 February 2016 at 19:55:20 UTC, rsw0x wrote:
>> [...]
>
> Would it be possible to point me in the directions of projects where you saw ldc being faster? I didn't try per-module, but on the projects I tried, dmd is still considerably faster when compiling per-package. And given that per-package is nearly always faster than per-module... (http://forum.dlang.org/post/yfykbayodugukemvoedf@forum.dlang.org)
>
> Atila

Forgot to say: I measured seconds ago on the most recent dmd and ldc with an 8-core CPU with hyperthreading (so 16 threads).

Atila

On Thursday, 25 February 2016 at 22:03:47 UTC, Walter Bright wrote:
> DMD did slow down because it was now being compiled by DMD instead of g++.

You can compile it using LDC just fine now. ;)

> Also, dmd was doing multithreaded file I/O, but that was removed because speed didn't matter <grrrr>.

Did we ever have any numbers showing that this in particular produced a tangible performance benefit (even a single barnacle)?

> As I said, keeping the compiler speed up is a constant battle.

And this leaves me wondering why nobody ever wrote a comprehensive compiler performance tracking tool. There is Dash, my half-finished CI-style project (that a couple of people were interested in picking up after DConf, but which never really happened), and Vladimir's quite limited TrenD adaption of Mozilla's areweslimyet, but nobody really came up with something that would be part of our day-to-day development workflow.

> Currently, dmd makes zero user of multicore. I didn't know that ldc did.

LDC doesn't do so either. I think what rsw0x referred to is doing a normal "C-style" parallel compilation of several compilation unit. I'm not sure why this couldn't also be done with DMD, though.

 — David

On Thu, Feb 25, 2016 at 02:03:47PM -0800, Walter Bright via Digitalmars-d wrote:
> On 2/25/2016 1:50 PM, Andrei Alexandrescu wrote:
> >Good to know, thanks! -- Andrei
> 
> DMD did slow down because it was now being compiled by DMD instead of g++.  Also, dmd was doing multithreaded file I/O, but that was removed because speed didn't matter <grrrr>.
[...]

I remember you did a bunch of stuff to the optimizer after the switchover to self-hosting; how much of a difference did that make? Are there any low-hanging fruit left that could make dmd faster?

On a related note, I discovered an O(n^2) algorithm in the front-end...
it's unlikely to be an actual bottleneck in practice (basically it's
quadratic in the number of fields in an aggregate), though you never
know. It actually does a full n^2 iterations, and seemed like it could
be at least pared down to n(n+1)/2, even without doing better than
O(n^2).


T

-- 
What is Matter, what is Mind? Never Mind, it doesn't Matter.