On Thu, Aug 13, 2015 at 12:53 AM, Iain Buclaw via dmd-internals <dmd-internals@puremagic.com> wrote:
> On 12 August 2015 at 00:59, Martin Nowak <code@dawg.eu> wrote:
>
> These are all places where class allocations occur the most it seems.
>
> I was about to propose making this change:
>
>  extern (C) Object _d_newclass(const ClassInfo ci)
>  {
>      auto p = allocmemory(ci.init.length);
> +    *(cast(void **) p) = cast(void*) ci.vtbl;
> -    p[0 .. ci.init.length] = cast(void[])ci.init[];
>      return cast(Object)p;
>  }
>
> But then I checked and found out that Daniel removes all ctors in the D conversion. =)
>
> I guess this is the reason why memcpy calls have increased!
>

We don't have support for constructing classes across the language
boundary, and without the memcpy the member variables will be
uninitialized.  D (or at least dmd's druntime) requires the init[]
blit before constructor calls anyway.
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

I left -release off so that assertions would still trigger, like they do in the C++ version of dmd.

On Wed, Aug 12, 2015 at 11:15 PM, Martin Nowak via dmd-internals <dmd-internals@puremagic.com> wrote:
> On Wednesday, 12 August 2015 at 12:44:00 UTC, Iain Buclaw wrote:
>>
>> By the way, I noticed that ddmd is always built in non-release mode, and I discovered that I can squeeze out more performance by speculatively skipping unneeded _d_invariant calls.
>
>
> I already compiled ddmd w/ -release to get my numbers.
>
>
> _______________________________________________
> dmd-internals mailing list
> dmd-internals@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

I'll say again, 2.067 dmd is the hard minimum requirement to build ddmd on all of our major platforms.  2.066 does not work.  This is why I'm suggesting we stick with 2.067 as a baseline, and ideally wait until ldc and gdc have a 2.067 release.  2.067 is the version being tested on the autotester.

On Wed, Aug 12, 2015 at 8:03 PM, Walter Bright via dmd-internals <dmd-internals@puremagic.com> wrote:
>
>
> On 8/11/2015 11:40 PM, Martin Nowak via dmd-internals wrote:
>>
>>
>> If you want to compensate the slowdown by optimizing the compiler we should first try to improve our template instantiation, then do the switch. https://trello.com/c/L0nV131G/17-investigate-fix-compiler-slowdown
>>
>> https://github.com/D-Programming-Language/dmd/pull/4780#issuecomment-124087604
>
>
> The slowdown has a solution - 4780 - which you and Kenji don't agree with. Nevertheless, that is how the compiler used to work before the slowdowns and regressions. The worst case of 4780 is the user will add the -allinst compiler switch, and their compilation will get slower. This is far better than it gets slower for every case.
>
> If we keep finding reasons not to do the switch, it will never happen.
>
> If we wait for ldc/gdc to catch up to 2.068, then we'll be in the same situation with 2.069+.
>
> _______________________________________________
> dmd-internals mailing list
> dmd-internals@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

I think that's the right thing to do while developing.

On 8/12/2015 7:34 PM, Daniel Murphy via dmd-internals wrote:
> I left -release off so that assertions would still trigger, like they
> do in the C++ version of dmd.
>
> On Wed, Aug 12, 2015 at 11:15 PM, Martin Nowak via dmd-internals
> <dmd-internals@puremagic.com> wrote:
>> On Wednesday, 12 August 2015 at 12:44:00 UTC, Iain Buclaw wrote:
>>> By the way, I noticed that ddmd is always built in non-release mode, and I
>>> discovered that I can squeeze out more performance by speculatively skipping
>>> unneeded _d_invariant calls.
>>
>> I already compiled ddmd w/ -release to get my numbers.
>>
>>
>> _______________________________________________
>> dmd-internals mailing list
>> dmd-internals@puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-internals
> _______________________________________________
> dmd-internals mailing list
> dmd-internals@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals

_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

Let's do that then. How about doing a PR for the sources? Seems to me we're just sitting around jawboning, and not moving forward!

On 8/12/2015 7:37 PM, Daniel Murphy wrote:
> I'll say again, 2.067 dmd is the hard minimum requirement to build
> ddmd on all of our major platforms.  2.066 does not work.  This is why
> I'm suggesting we stick with 2.067 as a baseline, and ideally wait
> until ldc and gdc have a 2.067 release.  2.067 is the version being
> tested on the autotester.
>

_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 13 August 2015 at 04:33, Daniel Murphy <yebblies@gmail.com> wrote:

> On Thu, Aug 13, 2015 at 12:53 AM, Iain Buclaw via dmd-internals <dmd-internals@puremagic.com> wrote:
> > On 12 August 2015 at 00:59, Martin Nowak <code@dawg.eu> wrote:
> >
> > These are all places where class allocations occur the most it seems.
> >
> > I was about to propose making this change:
> >
> >  extern (C) Object _d_newclass(const ClassInfo ci)
> >  {
> >      auto p = allocmemory(ci.init.length);
> > +    *(cast(void **) p) = cast(void*) ci.vtbl;
> > -    p[0 .. ci.init.length] = cast(void[])ci.init[];
> >      return cast(Object)p;
> >  }
> >
> > But then I checked and found out that Daniel removes all ctors in the D conversion. =)
> >
> > I guess this is the reason why memcpy calls have increased!
> >
>
> We don't have support for constructing classes across the language boundary, and without the memcpy the member variables will be uninitialized.  D (or at least dmd's druntime) requires the init[] blit before constructor calls anyway.
>


I did some testing with gdc and made another discovery:

https://issues.dlang.org/show_bug.cgi?id=14912

This is a sometimes-used pattern in dmd is to do the following when lowering code in the frontend.

  FooExp *fe = new FooExp(type, e);
  return fe->semantic(sc);

Regards
Iain

On Thursday, 13 August 2015 at 02:58:00 UTC, Walter Bright wrote:
> Let's do that then.

Yep, 2.067 sounds good and it seems one of gdc/ldc will have a 2.067 before 2.069.

> How about doing a PR for the sources? Seems to me we're just sitting around jawboning, and not moving forward!

This discussion is necessary. Switching to ddmd is a big change with lots of consequences and you should be willing to spent some time to make better decisions.

At least we're not excluding gdc/ldc now. We still have to decide on an update policy for the baseline compiler that works for dmd/gdc/ldc and we need to figure out how to test for compatibility.
https://trello.com/c/4NtxWDtK/48-ddmd-bootstraping-and-backwards-compatibility-guarantees

I'd propose that we require ddmd to be compilable with the latest 2 versions of dmd/ddmd, e.g. 2.067.x and 2.068.x and with the latest available versions of gdc and ldc.
This should be tested and enforced before releasing a new version of ddmd, so we should write a test script for that.
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 13 Aug 2015, at 7:35, Martin Nowak via dmd-internals wrote:
> On Thursday, 13 August 2015 at 02:58:00 UTC, Walter Bright wrote:
>> Let's do that then.
>
> Yep, 2.067 sounds good and it seems one of gdc/ldc will have a 2.067 before 2.069.

Most definitely. LDC already passes the test suite on x86_64 and we are currently just cleaning up the fallout of the many half-done fixes/improvements in 2.067. We could actually even release a beta right now if it helps you, but it would have a pretty big codegen speed regression.

> I'd propose that we require ddmd to be compilable with the latest 2 versions of dmd/ddmd, e.g. 2.067.x and 2.068.x and with the latest available versions of gdc and ldc.

It seems to me that just one version would be enough?

 — David
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On Thursday, 13 August 2015 at 05:35:41 UTC, Martin Nowak wrote:
> This should be tested and enforced before releasing a new version of ddmd, so we should write a test script for that.

https://trello.com/c/3cENE3ok/38-test-script-for-ddmd-compiler-compatibility
We could easily use Travis-CI for that.
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 13 August 2015 at 07:41, David Nadlinger via dmd-internals < dmd-internals@puremagic.com> wrote:

> On 13 Aug 2015, at 7:35, Martin Nowak via dmd-internals wrote:
>
>> On Thursday, 13 August 2015 at 02:58:00 UTC, Walter Bright wrote:
>>
>>> Let's do that then.
>>>
>>
>> Yep, 2.067 sounds good and it seems one of gdc/ldc will have a 2.067 before 2.069.
>>
>
> Most definitely. LDC already passes the test suite on x86_64 and we are currently just cleaning up the fallout of the many half-done fixes/improvements in 2.067. We could actually even release a beta right now if it helps you, but it would have a pretty big codegen speed regression.
>
> I'd propose that we require ddmd to be compilable with the latest 2
>> versions of dmd/ddmd, e.g. 2.067.x and 2.068.x and with the latest available versions of gdc and ldc.
>>
>
> It seems to me that just one version would be enough?
>
>  — David


You'd hope so...