What's blocking DDMD?

[Iain Buclaw via Digitalmars-d]

On 23 Jul 2014 04:56, "Orvid King via Digitalmars-d" <
digitalmars-d at puremagic.com> wrote:
>
> On 7/22/2014 9:34 AM, Daniel Murphy wrote:> "Tourist"  wrote in message
news:cmeqwpzglxjksmiekxbe at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140723/0b1b9732/attachment-0001.html>