<p dir="ltr"><br>
On 23 Jul 2014 04:56, "Orvid King via Digitalmars-d" <<a href="mailto:digitalmars-d@puremagic.com">digitalmars-d@puremagic.com</a>> wrote:<br>
><br>
> On 7/22/2014 9:34 AM, Daniel Murphy wrote:> "Tourist"  wrote in message news:cmeqwpzglxjksmiekxbe@forum.dlang.org...<br>
><br>
> ><br>
> >> Just curious. I remember that there was some kind of a roadmap, but I<br>
> >> cannot find it now.<br>
> ><br>
> > Nice timing, I was about to post a DDMD status message.<br>
> ><br>
> > As of a few hours ago DDMD has gone green in the autotester on the main<br>
> > platforms.<br>
> ><br>
> > <a href="https://auto-tester.puremagic.com/?projectid=10">https://auto-tester.puremagic.com/?projectid=10</a><br>
> ><br>
> > Of the failing platforms:<br>
> > OSX32: <a href="https://github.com/braddr/d-tester/pull/35">https://github.com/braddr/d-tester/pull/35</a> (OSX32 is crazy)<br>
> > linux cross compilers: The tester machines currently have the wrong dmd<br>
> > host toolchain installed.<br>
> > win64: Same sort of thing as the linux cross compilers<br>
> ><br>
> > The autotester is showing a performance hit in the range of 25-50%<br>
> > slower. Memory consumption appears to have a less significant increase.<br>
> ><br>
> > Also note that the autotester is only building ddmd in debug mode - the<br>
> > dmd I'm comparing it against was built in release mode with full<br>
> > optimizations.<br>
> ><br>
> > As for what's left:<br>
> >> Fix cross-compilers/osx32<br>
> >> Actually test and inevitably fix win64<br>
> >> Finish reducing memory consumption/reinstating custom allocation<br>
> >> schemes that I've disabled<br>
> >> Merge, test and release.<br>
> ><br>
> > And then do the same things again for the other two backends.<br>
> ><br>
> > You can build it by following the instructions here:<br>
> > <a href="https://github.com/D-Programming-Language/dmd/pull/3410">https://github.com/D-Programming-Language/dmd/pull/3410</a><br>
> ><br>
> > If things go well I may release a DDMD zip that matches 2.066 for people<br>
> > to try out.<br>
><br>
> 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.</p>

<p dir="ltr">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. ;)</p>

<p dir="ltr">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.</p>

<p dir="ltr">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.</p>

<p dir="ltr">Iain</p>