On 7/20/2015 11:34 PM, Martin Nowak wrote:
> I got this number from Daniel, he didn't found a reason.
> Chances are it's uniformly slower because of dmd's backend, but of course
> profiling might help.

Consider that the Win32 version of dmd is built with with the same backend as dmd. If there's a slowdown with that version, it isn't due to the backend.

Am Tue, 21 Jul 2015 01:54:44 -0700
schrieb Walter Bright <newshound2@digitalmars.com>:

> On 7/20/2015 11:34 PM, Martin Nowak wrote:
> > I got this number from Daniel, he didn't found a reason.
> > Chances are it's uniformly slower because of dmd's backend, but of
> > course profiling might help.
> 
> Consider that the Win32 version of dmd is built with with the same backend as dmd. If there's a slowdown with that version, it isn't due to the backend.

"On Win32 the performance difference is much smaller, because it's going from compiling with dmc to compiling with dmd"

https://youtu.be/5daHGXSetXk?t=2438

On 21 July 2015 at 11:04, Johannes Pfau via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> Am Tue, 21 Jul 2015 01:54:44 -0700
> schrieb Walter Bright <newshound2@digitalmars.com>:
>
>> On 7/20/2015 11:34 PM, Martin Nowak wrote:
>> > I got this number from Daniel, he didn't found a reason.
>> > Chances are it's uniformly slower because of dmd's backend, but of
>> > course profiling might help.
>>
>> Consider that the Win32 version of dmd is built with with the same backend as dmd. If there's a slowdown with that version, it isn't due to the backend.
>
> "On Win32 the performance difference is much smaller, because it's going from compiling with dmc to compiling with dmd"
>

You beat me to it....

On Tuesday, 21 July 2015 at 08:54:43 UTC, Walter Bright wrote:
> Consider that the Win32 version of dmd is built with with the same backend as dmd. If there's a slowdown with that version, it isn't due to the backend.

Talking about compiler speed, we can get an easy 10% speedup using PGO+LTO.
https://github.com/D-Programming-Language/dmd/pull/4651

On 07/20/2015 05:02 PM, Andrei Alexandrescu wrote:
>
> I, too, think we devote too much attention to the picayune. There's a
> lot of interesting stuff in Walter's post, yet most discussion focused
> on a side remark. -- Andrei

We worry too much about that. I don't mind bikeshedding so much as bikeshedding *about* bikeshedding.

I don't think anyone *has* anything to say about the real meat of the original post beyond just "Yes, sounds good, +1, etc." There's nothing anyone disagrees with, there's nothing anyone is uncertain or unclear about, and therefore there is nothing to say on those matters. Discussion only occurs when there *isn't* universal understanding and agreement.

On 7/20/2015 11:19 PM, Martin Nowak wrote:
> On Tuesday, 21 July 2015 at 03:47:11 UTC, Iain Buclaw wrote:
>> 1. If you want ddmd to be compilable by both gdc and ldc then you can't
>> introduce any new features to the ddmd codebase post conversion.
>
> Sticking to 2.068 will help for some time but is not a long-term solution.
> Particularly when considering some of the bigger D issues left to resolve, we'll
> likely have to deal with some incompatibilities/deprecations.
> Also consider that we might use the stable phobos parts.
>
> I made a Trello card, let's discuss the details when we're actually working on
> this.
> https://trello.com/c/4NtxWDtK/30-compatibility-implications-for-self-hosting-d-compiler
>
>

I don't see a reason to maintain 2.068 beyond the time that LDC and GDC migrate to ddmd.

On Monday, 20 July 2015 at 21:27:17 UTC, Mathias Lang wrote:
>
> We do follow a versioning style: '2.MAJOR.PATCH'  (with major being 3 digits). It's not as good as SemVer, but better than it was few years ago, and I have faith we'll end up following SemVer at some point.
>
> Following SemVer strictly wouldn't solve the real problem: We'll go from
> 2.068, 2.069. 2.070.. to 3.0.0, 4.0.0, 5.0.0 and will soon end up playing
> catch up with Chrome.
> To follow SemVer we'll have to separate breaking changes from bugfixes
> (including regressions) from new feature, and most likely work with
> separate branches.. Martin already started to work on this and we're in a
> nicer spot now, but it requires manpower.
> Since we don't have 2 consecutive releases that don't break code, I see no
> point in changing the version scheme at this point other than satisfying
> the purists.
>
> Having a focus for releases will hopefully mitigate that problem. But so far most posts have been about "BTW we need that fixed" and "our versioning scheme is broken".

+100

On 7/21/2015 4:31 AM, Martin Nowak wrote:
> Talking about compiler speed, we can get an easy 10% speedup using PGO+LTO.
> https://github.com/D-Programming-Language/dmd/pull/4651

The PR needs to be updated.

On Monday, 20 July 2015 at 21:10:57 UTC, Martin Nowak wrote:
>> 6. Convert the back end to D as well.
>
> Waste of time IMO, there is nothing to gain here.

- We already have a working C++ backend and can interface that from ddmd, the other compilers will have to work with a C++ interface anyhow.
  Just translating doesn't improve anything for D users.

- The backend generates pretty bad code, we'll never be able to catch up with good optimizers. Why should we invest in an outdated backend?

- Bugs in the backend are among the worst for users and time consuming to fix. Translating the backend risks to introduce new bugs.

On 07/21/2015 09:47 AM, Johannes Pfau wrote:
> Such gdc-specific frontend changes are fortunately rare. But with our own frontend fork we can simply commit them. With a unified frontend we'll have to spent hours convincing dmd devs that we need these changes for GDC.

I understand that it's sometimes frustrating to spend hours convincing
somebody of a seemingly obvious change. But please bear in mind that
communication is the foundation for collaboration.
The only sustainable way to raise awareness for gdc/ldc implications of
dmd changes is to explain why something needs to be done differently.
I think the Target pattern is a good example for a design decision
making gdc/ldc related differences visible in the dmd frontend.

Of course it's possible to just fork the frontend and pave your own way, but in the interest of alternative compilers I'd rather see more involvement of you in dmd development to help identify issues upfront. A good improvement would be to continously merge the dmd frontend during gdc development. Right now we only get feedback (if any) for issues long after the changes have been released.

TL;DR The reason you have to convince dmd devs is b/c we have no idea what you're doing and you don't tell us.