Just curious. I remember that there was some kind of a roadmap, but I cannot find it now.

"Tourist"  wrote in message news:cmeqwpzglxjksmiekxbe@forum.dlang.org...

> Just curious. I remember that there was some kind of a roadmap, but I cannot find it now.

Nice timing, I was about to post a DDMD status message.

As of a few hours ago DDMD has gone green in the autotester on the main platforms.

https://auto-tester.puremagic.com/?projectid=10

Of the failing platforms:
OSX32: https://github.com/braddr/d-tester/pull/35 (OSX32 is crazy)
linux cross compilers: The tester machines currently have the wrong dmd host toolchain installed.
win64: Same sort of thing as the linux cross compilers

The autotester is showing a performance hit in the range of 25-50% slower. Memory consumption appears to have a less significant increase.

Also note that the autotester is only building ddmd in debug mode - the dmd I'm comparing it against was built in release mode with full optimizations.

As for what's left:
> Fix cross-compilers/osx32
> Actually test and inevitably fix win64
> Finish reducing memory consumption/reinstating custom allocation schemes that I've disabled
> Merge, test and release.

And then do the same things again for the other two backends.

You can build it by following the instructions here: https://github.com/D-Programming-Language/dmd/pull/3410

If things go well I may release a DDMD zip that matches 2.066 for people to try out. 

On Wed, Jul 23, 2014 at 12:34:28AM +1000, Daniel Murphy via Digitalmars-d wrote:
> "Tourist"  wrote in message news:cmeqwpzglxjksmiekxbe@forum.dlang.org...
> 
> >Just curious. I remember that there was some kind of a roadmap, but I cannot find it now.
> 
> Nice timing, I was about to post a DDMD status message.
> 
> As of a few hours ago DDMD has gone green in the autotester on the main platforms.
> 
> https://auto-tester.puremagic.com/?projectid=10

Nice!!


> Of the failing platforms:
> OSX32: https://github.com/braddr/d-tester/pull/35 (OSX32 is crazy)
> linux cross compilers: The tester machines currently have the wrong
> dmd host toolchain installed.
> win64: Same sort of thing as the linux cross compilers
> 
> The autotester is showing a performance hit in the range of 25-50% slower.  Memory consumption appears to have a less significant increase.

Hmm. We should run a profiler to find out where the performance hit is coming from. It should be interesting, since presumably, your script to translate dmd to D basically generates the D equivalent of the C++ code, so major performance differences would point us to areas that need improvement in D.


> Also note that the autotester is only building ddmd in debug mode - the dmd I'm comparing it against was built in release mode with full optimizations.

Oh. Could that be the reason for the performance hit?


> As for what's left:
> >Fix cross-compilers/osx32
> >Actually test and inevitably fix win64
> >Finish reducing memory consumption/reinstating custom allocation
> >schemes that I've disabled
> >Merge, test and release.
> 
> And then do the same things again for the other two backends.
> 
> You can build it by following the instructions here: https://github.com/D-Programming-Language/dmd/pull/3410
> 
> If things go well I may release a DDMD zip that matches 2.066 for people to try out.

Awesome.

One thought that occurred to me -- once the autotester goes green on all platforms, we should probably have the autotester include ddmd testing on all dmd PR's, so that during the transition period the C++ and D changes will be fully in sync.


T

-- 
Why can't you just be a nonconformist like everyone else? -- YHL

On Tuesday, 22 July 2014 at 14:34:10 UTC, Daniel Murphy wrote:
>
> The autotester is showing a performance hit in the range of 25-50% slower. Memory consumption appears to have a less significant increase.
>
> Also note that the autotester is only building ddmd in debug mode - the dmd I'm comparing it against was built in release mode with full optimizations.

Is it also comparing between GCC built DMD and DMD built DDMD?

> As for what's left:
>

Did you find the cause of memory corruption you mentioned on github?

On Tuesday, 22 July 2014 at 14:50:33 UTC, safety0ff wrote:
> On Tuesday, 22 July 2014 at 14:34:10 UTC, Daniel Murphy wrote:
>>
>> The autotester is showing a performance hit in the range of 25-50% slower. Memory consumption appears to have a less significant increase.
>>
>> Also note that the autotester is only building ddmd in debug mode - the dmd I'm comparing it against was built in release mode with full optimizations.
>
> Is it also comparing between GCC built DMD and DMD built DDMD?
>

I forgot to ask, is it comparing with the stub GC (malloc no free) or actual GC?

"H. S. Teoh via Digitalmars-d"  wrote in message news:mailman.136.1406040115.32463.digitalmars-d@puremagic.com...

> Hmm. We should run a profiler to find out where the performance hit is
> coming from. It should be interesting, since presumably, your script to
> translate dmd to D basically generates the D equivalent of the C++ code,
> so major performance differences would point us to areas that need
> improvement in D.

I don't think any of it is caused by D itself (except maybe some druntime startup/shutdown overhead).  I think it's all coming from the memory allocation strategies I changed to get it working and haven't finished changing back, and from using different optimization settings/optimizer when compiling.

> > Also note that the autotester is only building ddmd in debug mode -
> > the dmd I'm comparing it against was built in release mode with full
> > optimizations.
>
> Oh. Could that be the reason for the performance hit?

I'm sure that's part of it.

> One thought that occurred to me -- once the autotester goes green on all
> platforms, we should probably have the autotester include ddmd testing
> on all dmd PR's, so that during the transition period the C++ and D
> changes will be fully in sync.

That's exactly the plan. 

"safety0ff"  wrote in message news:sraekimgazczrakpxxsq@forum.dlang.org...

> Is it also comparing between GCC built DMD and DMD built DDMD?

Yes!  I didn't think of that.

> Did you find the cause of memory corruption you mentioned on github?

Which one was that?  I found a member alignment bug that was certainly causing memory corruption and a badly-handled OOM condition that _looked_ like memory corruption.

The crash when using the GC as the allocator seems to have gone away (!!) so it may have been one of the others in disguise. 

"Daniel Murphy"  wrote in message news:lqlugc$7l7$1@digitalmars.com...

> The crash when using the GC as the allocator seems to have gone away (!!) so it may have been one of the others in disguise.

Wait I take that back.  It still crashes when using the GC and GC collections enabled.

Usually it uses Walter's bump-pointer allocator for classes, malloc/free for most buffers, and the GC (with collections disabled) for structs and some misc allocations.

I don't know why enabling the GC makes it crash. 

On Tuesday, 22 July 2014 at 15:03:41 UTC, Daniel Murphy wrote:
> "safety0ff"  wrote in message news:sraekimgazczrakpxxsq@forum.dlang.org...
>
>> Did you find the cause of memory corruption you mentioned on github?
>
> Which one was that?

https://github.com/D-Programming-Language/druntime/pull/884#issuecomment-48818456

Though now I see that you've followed that up with a comment.

> I don't know why enabling the GC makes it crash.

Does this mean that GC allocation works as long as collection is disabled?

On Tuesday, 22 July 2014 at 15:07:14 UTC, Daniel Murphy wrote:
> "Daniel Murphy"  wrote in message news:lqlugc$7l7$1@digitalmars.com...
>
>> The crash when using the GC as the allocator seems to have gone away (!!) so it may have been one of the others in disguise.
>
> Wait I take that back.  It still crashes when using the GC and GC collections enabled.
>
> Usually it uses Walter's bump-pointer allocator for classes, malloc/free for most buffers, and the GC (with collections disabled) for structs and some misc allocations.
>
> I don't know why enabling the GC makes it crash.

I started a Dustmite reduction at DConf to attempt to reduce the input that made DDMD corrupt memory. The blasted thing ran for weeks and got nowhere close... it seemed almost random. I guess a different approach is required.