www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - What's blocking DDMD?

reply "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
next sibling parent reply "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:
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.
Jul 22 2014
next sibling parent reply "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:
 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
Jul 22 2014
parent "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
prev sibling next sibling parent reply "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
next sibling parent "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
prev sibling parent reply "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
next sibling parent reply "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
next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> 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...


 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
parent reply "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
parent reply "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
next sibling parent "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
prev sibling parent "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
prev sibling parent reply "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
parent "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
prev sibling parent "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
prev sibling next sibling parent reply "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
parent "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
prev sibling next sibling parent reply "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
next sibling parent reply "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
parent reply "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
parent reply "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
parent reply "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
next sibling parent reply "Brad Anderson" <eco gnuk.net> 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 ?


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
parent "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
prev sibling parent "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
prev sibling parent "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
prev sibling next sibling parent reply "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
parent reply "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 
 could follow labels with {}.


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
parent 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
prev sibling next sibling parent reply 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:
 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.


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
parent 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:
 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.


 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
penalty. See various threads started by myself about libphobos compilation
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
prev sibling next sibling parent reply "Tourist" <gravatar gravatar.com> writes:
 Of the failing platforms:
 OSX32: https://github.com/braddr/d-tester/pull/35 (OSX32 is 
 crazy)


...

So, this is fixed now, right?
Sep 25 2014
next sibling parent "Joakim" <dlang joakim.fea.st> writes:
On Thursday, 25 September 2014 at 17:06:48 UTC, Tourist wrote:

 Of the failing platforms:
 OSX32: https://github.com/braddr/d-tester/pull/35 (OSX32 is 
 crazy)


 ...

 So, this is fixed now, right?


Yep.

https://github.com/D-Programming-Language/dmd/pull/3970
Sep 25 2014
prev sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Tourist"  wrote in message news:ekvdxwosqarmsnkhkqle forum.dlang.org... 


 Of the failing platforms:
 OSX32: https://github.com/braddr/d-tester/pull/35 (OSX32 is 
 crazy)


 ...
 
 So, this is fixed now, right?


Yep.

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

Just windows left now.
Sep 25 2014
next sibling parent reply "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:
 OSX32: https://github.com/braddr/d-tester/pull/35 (OSX32 is 
 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
parent "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
prev sibling parent reply "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
Error: 'ofmagicport\magicport2.exe' not found
Sep 27 2014
parent "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
 Error: 'ofmagicport\magicport2.exe' not found


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

instead of
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
prev sibling parent reply "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
next sibling parent 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
prev sibling parent "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
prev sibling parent reply 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
parent reply "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
parent 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