Disappointing performance from DMD/Phobos
Jonathan M Davis
newsgroup.d at jmdavisprog.com
Tue Jun 26 19:36:56 UTC 2018
On Tuesday, June 26, 2018 10:38:42 Manu via Digitalmars-d wrote:
> On Mon, 25 Jun 2018 at 20:17, Jonathan M Davis via Digitalmars-d
> <digitalmars-d at puremagic.com> wrote:
> > dmd's inliner is notoriously poor,
> I know, but it's still the reference compiler, and it should at least
> to a reasonable job at the kind of D code that it's *recommended* that
> users write.
> That line of code is the sort of line that should showcase what you
> can do with D that you can't do with other languages... but DMD will
> lead you to believe that you can't do it with D either.
> My point is, it's a really bad thing to present to users. DMD should
> really care about that impression.
I think that it mainly comes down to priorities, and performance is not at
the top of the list for the work being done on dmd. It's desirable to be
sure, but with everything else that needs to be done, it tends to fall be
the wayside even when it arguably shouldn't.
> > but I don't know how much effort has
> > really been put into fixing the problem. I do recall it being argued
> > several times that it only should only be in the backend and that there
> > shouldn't be one in the frontend, but either way, the typical solution
> > seems to be to use ldc instead of dmd if you really care about the
> > performance of the generated binary.
> I'm using unreleased 2.081, which isn't in LDC yet. Also, LDC seems to
> have more problems with debuginfo than DMD.
> Once LDC is on 2.081, I might have to flood their bugtracker with
> debuginfo related issues.
Well, if you're using the newest stuff, then sadly, that tends to mean that
you're stuck with dmd and that your performance just isn't going to be as
good, and I doubt that that will be fixed anytime soon (though specific
cases may be improved).
> > Regardless, if you can give simple test cases that clearly should be
> > generating far better code than they are, then at least there's a clear
> > target for improvement rather than just "dmd should generate faster
> > code," so there's something clearly actionable.
> I'm pretty sure that's exactly what I did above...
> Build that code, suggest; don't generate a callstack 7-levels deep.
> Ideally, observe inline code that adds 4 ints together.
I wasn't trying to say that you didn't have a test case. My point was that
if you have an actual, reasonably-sized test case (which you do), then a bug
report can be opened for that particular example, and it has some chance of
being fixed. Too often with stuff like this, folks complain that "dmd's
inliner is bad" or that "dmd's error messages aren't clear enough" without
giving concrete examples, which makes it effectively unactionable even if
someone is trying to spend time on it (Walter has complained in the past
about folks saying that something about dmd isn't good enough without giving
concrete examples, which makes it really hard for him to fix the problem).
- Jonathan M Davis
More information about the Digitalmars-d