## digitalmars.D - What's blocking DDMD?

• Tourist (2/2) Jul 22 2014 Just curious. I remember that there was some kind of a roadmap,
• Daniel Murphy (20/27) Jul 22 2014 Nice timing, I was about to post a DDMD status message.
• H. S. Teoh via Digitalmars-d (16/53) Jul 22 2014 Hmm. We should run a profiler to find out where the performance hit is
• Daniel Murphy (9/22) Jul 22 2014 I don't think any of it is caused by D itself (except maybe some druntim...
• safety0ff (4/11) Jul 22 2014 Did you find the cause of memory corruption you mentioned on
• safety0ff (3/13) Jul 22 2014 I forgot to ask, is it comparing with the stub GC (malloc no
• Daniel Murphy (7/9) Jul 22 2014 Which one was that? I found a member alignment bug that was certainly
• Daniel Murphy (7/9) Jul 22 2014 Wait I take that back. It still crashes when using the GC and GC
• Vladimir Panteleev (5/16) Jul 22 2014 I started a Dustmite reduction at DConf to attempt to reduce the
• Daniel Murphy (9/13) Jul 22 2014 I'm hoping I can get the GC's memstomp/sentinel to find it, although tha...
• safety0ff (6/11) Jul 23 2014 I'm wondering if the issue is related with the use of extern(C++)
• Daniel Murphy (6/10) Jul 23 2014 It does? It seems every time I add/remove a debugging printf it changes...
• safety0ff (9/11) Jul 24 2014 The consistency was likely due to running inside the debugger.
• safety0ff (3/6) Jul 25 2014 I think I found one reason: aav.* allows storing references to GC
• safety0ff (7/9) Jul 25 2014 Yup! I converted aav.c into d by hand and now I can compile hello
• safety0ff (5/11) Jul 22 2014 https://github.com/D-Programming-Language/druntime/pull/884#issuecomment...
• w0rp (3/3) Jul 22 2014 We should promote this DDMD news. There's promise of a
• Daniel Murphy (2/5) Jul 22 2014 I'd rather wait until we release it. Or at least merge it into master.
• Domingo Alvarez Duarte (7/9) Jul 22 2014 I'm not sure if there is instructions to build it on that link,
• safety0ff (4/7) Jul 22 2014 It's only in the src/*.mak files, so for example from root you
• Domingo Alvarez Duarte (9/11) Jul 22 2014 It doesn't seem to be only that, something is missing !
• safety0ff (4/8) Jul 22 2014 You mentioned not knowing which branch, are you on yebblies'
• Daniel Murphy (6/14) Jul 22 2014 As others have pointed out, that link is to a pull request from a branch...
• safety0ff (21/21) Jul 22 2014 Ok, tried building with LDC and ran into some issues:
• Daniel Murphy (12/32) Jul 22 2014 It won't build with anything except the latest dmd. In fact, it even ne...
• Orvid King (6/33) Jul 22 2014 I'd make a random guess at allocations being the difference in
• Tourist (2/5) Sep 25 2014 ...
• Suliman (1/4) Nov 12 2014 I do not see DDMD here. Is it was moved to another location?
• Jacob Carlborg (5/6) Nov 12 2014 I would guess it's "DMD Yebblies". "yebblies" is Daniel Murphy's name on...
• Daniel Murphy (4/8) Nov 12 2014 It is there at the moment, although I do occasionally use that autoteste...
• Iain Buclaw via Digitalmars-d (3/5) Jul 22 2014 I'm blocking DDMD. :o)
"Tourist" <gravatar gravatar.com> writes:
Just curious. I remember that there was some kind of a roadmap,
but I cannot find it now.

Jul 22 2014
"Daniel Murphy" <yebbliesnospam gmail.com> writes:
"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:
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.

Jul 22 2014
"H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
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:
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

Jul 22 2014
"Daniel Murphy" <yebbliesnospam gmail.com> writes:
"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.

Jul 22 2014
"safety0ff" <safety0ff.dev gmail.com> writes:
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?

Jul 22 2014
"safety0ff" <safety0ff.dev gmail.com> writes:
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?

Jul 22 2014
"Daniel Murphy" <yebbliesnospam gmail.com> writes:
"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.

Jul 22 2014
"Daniel Murphy" <yebbliesnospam gmail.com> writes:
"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.

Jul 22 2014
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.

Jul 22 2014
"Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Vladimir Panteleev"  wrote in message
news:wauoddrnxevfakktwhme forum.dlang.org...

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.

I'm hoping I can get the GC's memstomp/sentinel to find it, although that
might not work if it's a bug in the GC itself.

My other option is fixing my execution trace debugger (seems to get lost
inside a system dll) and spend a few days tracing backwards from the
segfault.

At least I found the (an) optimizer bug:
https://issues.dlang.org/show_bug.cgi?id=13190

Jul 22 2014
"safety0ff" <safety0ff.dev gmail.com> writes:
On Tuesday, 22 July 2014 at 17:59:02 UTC, Daniel Murphy wrote:
I'm hoping I can get the GC's memstomp/sentinel to find it,
although that might not work if it's a bug in the GC itself.

My other option is fixing my execution trace debugger (seems to
get lost inside a system dll) and spend a few days tracing
backwards from the segfault.

I'm wondering if the issue is related with the use of extern(C++)
classes.
It seems to consistently crash at the same place, which seems to
be a virtual function call.

Is there anything special about allocation of C++ classes?

Jul 23 2014
"Daniel Murphy" <yebbliesnospam gmail.com> writes:
"safety0ff"  wrote in message news:dzdiqnunamteyjcdcljn forum.dlang.org...

I'm wondering if the issue is related with the use of extern(C++) classes.

Haha well it could be.  This is the first project to use them after all.

It seems to consistently crash at the same place, which seems to be a
virtual function call.

It does?  It seems every time I add/remove a debugging printf it changes
position.

Is there anything special about allocation of C++ classes?

They're allocated without the finalize bit set, unlike normal classes.  And
they have their own member alignment rules and different vtable layout.

Jul 23 2014
"safety0ff" <safety0ff.dev gmail.com> writes:
On Wednesday, 23 July 2014 at 21:51:34 UTC, safety0ff wrote:
It seems to consistently crash at the same place, which seems
to be a virtual function call.

The consistency was likely due to running inside the debugger.

I tried looking a little deeper into this today, looks like the
GC is collecting live objects.
The reason it keeps crashing in virtual dispatches is because
when the GC places the free block into a list, it stomps on the
vtable pointer (this is my working theory.) I'll rebuild to get
the line numbers within druntime to have more confidence that
this is what is happening.

Jul 24 2014
"safety0ff" <safety0ff.dev gmail.com> writes:
On Tuesday, 22 July 2014 at 15:07:14 UTC, Daniel Murphy wrote:
"Daniel Murphy"  wrote in message
news:lqlugc$7l7$1 digitalmars.com...

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

I think I found one reason: aav.* allows storing references to GC
objects in the C/C++ heap.

Jul 25 2014
"safety0ff" <safety0ff.dev gmail.com> writes:
On Saturday, 26 July 2014 at 01:07:43 UTC, safety0ff wrote:
I think I found one reason: aav.* allows storing references to
GC objects in the C/C++ heap.

Yup! I converted aav.c into d by hand and now I can compile hello
world with GC enabled.

I also found some temporary allocations in the auto-ported files
that I changed to use root.rmem module.

We should check the other C++ sources to make sure they don't
store references to GC objects, but this was a good first step.

Jul 25 2014
"safety0ff" <safety0ff.dev gmail.com> writes:
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?

Jul 22 2014
"w0rp" <devw0rp gmail.com> writes:
We should promote this DDMD news. There's promise of a
self-hosting D compiler which should attract some attention, even
if it's not the best compiler in the world yet.

Jul 22 2014
"Daniel Murphy" <yebbliesnospam gmail.com> writes:
"w0rp"  wrote in message news:kuwjnyziibgxudtlgngo forum.dlang.org...

We should promote this DDMD news. There's promise of a
self-hosting D compiler which should attract some attention, even
if it's not the best compiler in the world yet.

I'd rather wait until we release it.  Or at least merge it into master.

Jul 22 2014
"Domingo Alvarez Duarte" <mingodad gmail.com> writes:
On Tuesday, 22 July 2014 at 14:34:10 UTC, Daniel Murphy wrote:
You can build it by following the instructions here:
https://github.com/D-Programming-Language/dmd/pull/3410

I'm not sure if there is instructions to build it on that link,
there is no "ddmd" entry on makefiles and I cant see any
branch/tag on git to checkout.

Can you provide more details about how to build it and where the
code are hosted?

Cheers !

Jul 22 2014
"safety0ff" <safety0ff.dev gmail.com> writes:
On Tuesday, 22 July 2014 at 18:29:23 UTC, Domingo Alvarez Duarte
wrote:
I'm not sure if there is instructions to build it on that link,
there is no "ddmd" entry on makefiles and I cant see any
branch/tag on git to checkout.

It's only in the src/*.mak files, so for example from root you
use: make -C src -f posix.mak ddmd

Jul 22 2014
"Domingo Alvarez Duarte" <mingodad gmail.com> writes:
On Tuesday, 22 July 2014 at 18:37:44 UTC, safety0ff wrote:
It's only in the src/*.mak files, so for example from root you
use: make -C src -f posix.mak ddmd

It doesn't seem to be only that, something is missing !

:::::::
$:~/dev/d/src/dmd$ make -C src -f posix.mak ddmd
no cpu specified, assuming X86
make: Entering directory /home/mingo/dev/d/src/dmd/src'
make: *** No rule to make target ddmd'. Stop.
make: Leaving directory /home/mingo/dev/d/src/dmd/src'
:::::::

Jul 22 2014
"safety0ff" <safety0ff.dev gmail.com> writes:
On Tuesday, 22 July 2014 at 20:32:41 UTC, Domingo Alvarez Duarte
wrote:
On Tuesday, 22 July 2014 at 18:37:44 UTC, safety0ff wrote:
It's only in the src/*.mak files, so for example from root you
use: make -C src -f posix.mak ddmd

It doesn't seem to be only that, something is missing !

You mentioned not knowing which branch, are you on yebblies'
"newmagic" branch?

Jul 22 2014
"Domingo Alvarez Duarte" <mingodad gmail.com> writes:
On Tuesday, 22 July 2014 at 21:36:01 UTC, safety0ff wrote:
You mentioned not knowing which branch, are you on yebblies'
"newmagic" branch?

On https://github.com/D-Programming-Language/dmd there is no such
branchs !

Is it a fork elsewhere ?

Jul 22 2014
On Tuesday, 22 July 2014 at 22:14:31 UTC, Domingo Alvarez Duarte
wrote:
On Tuesday, 22 July 2014 at 21:36:01 UTC, safety0ff wrote:
You mentioned not knowing which branch, are you on yebblies'
"newmagic" branch?

On https://github.com/D-Programming-Language/dmd there is no
such branchs !

Is it a fork elsewhere ?

Yes, it's in Daniel's fork.

https://github.com/yebblies/dmd/tree/newmagic

Daniel, you should do some spring cleaning on your branches :)

Jul 22 2014
"Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Brad Anderson"  wrote in message
news:goeecibjsrobayeefbvx forum.dlang.org...

Daniel, you should do some spring cleaning on your branches :)

Never!  Although I now delete them after they are merged, since github added
a button to do it.

Jul 23 2014
"Domingo Alvarez Duarte" <mingodad gmail.com> writes:
On Tuesday, 22 July 2014 at 22:14:31 UTC, Domingo Alvarez Duarte
wrote:
On Tuesday, 22 July 2014 at 21:36:01 UTC, safety0ff wrote:
You mentioned not knowing which branch, are you on yebblies'
"newmagic" branch?

On https://github.com/D-Programming-Language/dmd there is no
such branchs !

Is it a fork elsewhere ?

I think the repository is this one ?

https://github.com/yebblies/dmd

Jul 22 2014
"Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Domingo Alvarez Duarte"  wrote in message
news:vwamsrkqngvnbnmdcakt forum.dlang.org...

On Tuesday, 22 July 2014 at 14:34:10 UTC, Daniel Murphy wrote:
You can build it by following the instructions here:
https://github.com/D-Programming-Language/dmd/pull/3410

I'm not sure if there is instructions to build it on that link, there is
no "ddmd" entry on makefiles and I cant see any branch/tag on git to
checkout.

Can you provide more details about how to build it and where the code are
hosted?

As others have pointed out, that link is to a pull request from a branch in
my respository.  That branch is the one you need to check out in order to
build it.

https://github.com/yebblies/dmd/tree/newmagic

Jul 22 2014
"safety0ff" <safety0ff.dev gmail.com> writes:
Ok, tried building with LDC and ran into some issues:

At first I tried an older ldmd2 and it error'ed on labels
followed by closed brackets. Using a newer version fixed this,
but perhaps magicport could follow labels with {}.

Afterwards I ran into an issue with LDC on x86_64 with
__va_argsave, so I switched to 32 bit.

Next I ran into symbol conflicts between root.aav._aaLen and
object._aaLen (resolved by import'ing root.aav : _aaLen)

Afterwards I needed to change optimize.d's shift_optimize second
argument from:
Expression function(Type, Expression, Expression)
to:
typeof(&Shl)

This is a hack, I think it was getting tripped up on the
extern(C++).

Next I have an issue with outbuffer.o getting deleted, so I add a
step to the make file renaming outbuffer.o to routbuffer.o and I
change the name in the ddmd command to use routbuffer.o instead.

Unfortunately all that was for naught as I couldn't get it to
link. I tried to rebuild LDC's phobos and druntime for 32 bit but
the linker still complained that it was incompatible.

Jul 22 2014
"Daniel Murphy" <yebbliesnospam gmail.com> writes:
"safety0ff"  wrote in message news:ptaydiflclzapizmopmj forum.dlang.org...

Ok, tried building with LDC and ran into some issues:

Yeah, this was never going to work.

At first I tried an older ldmd2 and it error'ed on labels followed by
closed brackets. Using a newer version fixed this, but perhaps magicport

It won't build with anything except the latest dmd.  In fact, it even needs
one patch which is yet to be merged into master.

Afterwards I ran into an issue with LDC on x86_64 with __va_argsave, so I
switched to 32 bit.

Another one fixed in dmd which hasn't made it to your LDC yet.

Next I ran into symbol conflicts between root.aav._aaLen and object._aaLen
(resolved by import'ing root.aav : _aaLen)

Same thing, just fixed in dmd.

Afterwards I needed to change optimize.d's shift_optimize second argument
from:
Expression function(Type, Expression, Expression)
to:
typeof(&Shl)

Not sure what that is, but probably more of the same.

This is a hack, I think it was getting tripped up on the extern(C++).

Yah.

Next I have an issue with outbuffer.o getting deleted, so I add a step to
the make file renaming outbuffer.o to routbuffer.o and I change the name
in the ddmd command to use routbuffer.o instead.

I have no idea what's going on here.  'make ddmd' should never delete
outbuffer.o

Unfortunately all that was for naught as I couldn't get it to link. I
tried to rebuild LDC's phobos and druntime for 32 bit but the linker still
complained that it was incompatible.

If you post the errors I might be able to work it out, but I'd guess LDC's
C++ mangling is broken and that's why you're getting linker errors.

Jul 22 2014
Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 23 July 2014 07:31, Daniel Murphy via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
"safety0ff"  wrote in message news:ptaydiflclzapizmopmj forum.dlang.org...

Ok, tried building with LDC and ran into some issues:

Yeah, this was never going to work.

Likewise GDC won't work either incase anyone gets any ideas.

Unfortunately all that was for naught as I couldn't get it to link. I
tried to rebuild LDC's phobos and druntime for 32 bit but the linker still
complained that it was incompatible.

If you post the errors I might be able to work it out, but I'd guess LDC's
C++ mangling is broken and that's why you're getting linker errors.

GDC C++ mangling should be getting some TLC in the next weeks.

Jul 23 2014
Orvid King <blah38621 gmail.com> writes:
On 7/22/2014 9:34 AM, Daniel Murphy 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

Of the failing platforms:
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.

I'd make a random guess at allocations being the difference in
performance, DMD currently uses a bump-the-pointer allocator, which, if
I'm remembering correctly, produced performance boosts of about that
much when it was implemented.

Jul 22 2014
Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 23 Jul 2014 04:56, "Orvid King via Digitalmars-d" <
digitalmars-d puremagic.com> wrote:
On 7/22/2014 9:34 AM, Daniel Murphy 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

Of the failing platforms:
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.

I'd make a random guess at allocations being the difference in

performance, DMD currently uses a bump-the-pointer allocator, which, if I'm
remembering correctly, produced performance boosts of about that much when
it was implemented.

Not always true. For me it only I only found it to be a performance
of unittests freezing my system, and the eventual death of my hard drive
when building Phobos. ;)

Now I can't use dmd short lifetime in the generation of an executable as a
reasonable excuse here for why memory *should* be allocated and not freed,
because it was the rare occasion of building Phobos with dmd that was the
last thing my dead disk did.

It is true though that gdc and ldc suffer greatly from it though.
std.algorithm for instance may compile in 20 seconds for dmd, becomes 1
minute 20 seconds for gdc (let's assume compiling with optimisations). This
is a painful amount of time for a utility tool to spend consuming 2+GBs of
memory.  Especially if you are running concurrent builds.

Iain

Jul 22 2014
"Tourist" <gravatar gravatar.com> writes:
 Of the failing platforms:
crazy)

...

So, this is fixed now, right?

Sep 25 2014
"Joakim" <dlang joakim.fea.st> writes:
On Thursday, 25 September 2014 at 17:06:48 UTC, Tourist wrote:
Of the failing platforms:
crazy)

...

So, this is fixed now, right?

Yep.

https://github.com/D-Programming-Language/dmd/pull/3970

Sep 25 2014
"Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Tourist"  wrote in message news:ekvdxwosqarmsnkhkqle forum.dlang.org...

Of the failing platforms:
crazy)

...

So, this is fixed now, right?

Yep.

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

Just windows left now.

Sep 25 2014
"Tourist" <gravatar gravatar.com> writes:
On Friday, 26 September 2014 at 03:55:38 UTC, Daniel Murphy wrote:
"Tourist"  wrote in message
news:ekvdxwosqarmsnkhkqle forum.dlang.org...

Of the failing platforms:
crazy)

...

So, this is fixed now, right?

Yep.

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

Just windows left now.

Cool. Is there an open ticket for Windows?

Sep 26 2014
"Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Tourist"  wrote in message news:ccumfjjyzzjvlfjmyfbg forum.dlang.org...

Just windows left now.

Cool. Is there an open ticket for Windows?

Nope.

Sep 27 2014
"Trass3r" <un known.com> writes:
 https://auto-tester.puremagic.com/?projectid=10

Just windows left now.

Looks like a dash is missing?

ofmagicport\magicport2.exe magicport\magicport2.d magicport\ast.d
magicport\scanner.d magicport\tokens.d  magicport\parser.d
magicport\dprinter.d  magicport\typenames.d magicport\visitor.d
magicport\namer.d

Sep 27 2014
"Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Trass3r"  wrote in message news:fturaeslxjggkucprxpn forum.dlang.org...

Looks like a dash is missing?

ofmagicport\magicport2.exe magicport\magicport2.d magicport\ast.d
magicport\scanner.d magicport\tokens.d  magicport\parser.d
magicport\dprinter.d  magicport\typenames.d magicport\visitor.d
magicport\namer.d

No, HOST_DC is not set so after expansions make sees:

-ofmagicport\magicport2.exe magicport\magicport2.d magicport\ast.d
magicport\scanner.d magicport\tokens.d  magicport\parser.d
magicport\dprinter.d  magicport\typenames.d magicport\visitor.d
magicport\namer.d

path\to\dmd -ofmagicport\magicport2.exe magicport\magicport2.d
magicport\ast.d
magicport\scanner.d magicport\tokens.d  magicport\parser.d
magicport\dprinter.d  magicport\typenames.d magicport\visitor.d
magicport\namer.d

Then removes the '-' and tries to run the compiler switch.

Sep 27 2014
"Suliman" <evermind live.ru> writes:
As of a few hours ago DDMD has gone green in the autotester on
the main platforms.

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

I do not see DDMD here. Is it was moved to another location?

Nov 12 2014
Jacob Carlborg <doob me.com> writes:
On 2014-11-12 09:01, Suliman wrote:

I do not see DDMD here. Is it was moved to another location?

I would guess it's "DMD Yebblies". "yebblies" is Daniel Murphy's name on
Github.

--
/Jacob Carlborg

Nov 12 2014
"Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Suliman"  wrote in message news:tzwckeesoiotlabdyxkb forum.dlang.org...

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

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

I do not see DDMD here. Is it was moved to another location?

It is there at the moment, although I do occasionally use that autotester
project for testing other branches.  As you can see, it's passing everywhere
except windows.

Nov 12 2014
Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 22 July 2014 15:00, Tourist via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
Just curious. I remember that there was some kind of a roadmap, but I cannot
find it now.

I'm blocking DDMD.  :o)

Jul 22 2014
"Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Iain Buclaw via Digitalmars-d"  wrote in message
news:mailman.157.1406065213.32463.digitalmars-d puremagic.com...

On 22 July 2014 15:00, Tourist via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
Just curious. I remember that there was some kind of a roadmap, but I
cannot
find it now.

I'm blocking DDMD.  :o)

And DGDC!

Jul 22 2014
Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 23 July 2014 07:42, Daniel Murphy via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
"Iain Buclaw via Digitalmars-d"  wrote in message
news:mailman.157.1406065213.32463.digitalmars-d puremagic.com...

On 22 July 2014 15:00, Tourist via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
Just curious. I remember that there was some kind of a roadmap, but I >
cannot
find it now.

I'm blocking DDMD.  :o)

And DGDC!

We'll see how things go about that... :)
`
Jul 23 2014