Ready for review: new std.uni

[Jonathan M Davis]

On Sunday, January 13, 2013 22:46:21 H. S. Teoh wrote:
> On Mon, Jan 14, 2013 at 06:33:44AM +0100, David Nadlinger wrote:
> > On Monday, 14 January 2013 at 04:42:33 UTC, Andrei Alexandrescu
> > 
> > wrote:
> > >I'll candidly mention that David's request was unclear to me. It's
> > >been winding enough that I missed the key sentence. Was it that we
> > >switch dmd to using llvm as backend?
> > 
> > If you want, yes - but not in the form of an actionable proposal
> > yet. I was trying to argue that the benefits of using an existing
> > solution like GCC or LLVM are large enough (resp. the costs of using
> > a custom backend high enough) that we should seriously consider
> > doing so. Especially because it looks as if the amount of work
> > needed to keep the DMD backend and thus the reference D compiler
> > competitive is going to increase further as other backends are
> > gaining things like auto-vectorization to light up modern CPUs and
> > ARM is gaining in importance.
> 
> [...]
> 
> I have to say, as a bystander to this discussion, that I *have* felt the
> dilemma of whether to use dmd (I want to try out the latest D features)
> vs. gdc/ldc (I want maximal performance for compute-heavy apps).
> 
> I don't mean to downplay dmd in any way, but IME code generated by gdc
> -O3 has been *consistently* 30-40% faster than code generated by dmd -O,
> sometimes even 50% or more. I have compared the assembly code generated
> by either compiler, and I have to say that, at least IME, the code
> produced by gdc is indisputably superior to the code produced by dmd.
> Due to this, I have wanted to use only gdc for my D projects, and I'd
> expect that any project where performance is a concern would feel the
> same way. But I was forced to use dmd because I wanted to try out the
> newest features and get the latest bugfixes as well.  So now I'm torn
> between wanting competitive performance vs. getting the bugfixes I need
> or the latest and greatest features.
> 
> This is far from ideal, IMHO. Users shouldn't have to choose between
> up-to-date language support vs. performance. Having the reference D
> compiler match gdc/ldc in performance would be a big factor in D
> adoption IMO (how many people would spend the time to look up gdc, or
> even know it exists, instead of just compiling a C/C++ program with
> gcc/g++, compare it to dmd output for a comparable D program, and walk
> away?).

If you want to use the lastest master, then you're going to be stuck with dmd. 
If you're willing to use the latest release, then you have a choice. And 
assuming that you don't need the latest master, I would argue that if 
performance is critical, what you'll want to do is develop with dmd (because 
of its fast compilation items), and then you'll actually want to release using 
gdc or ldc so that you actually get fast programs. And given the fact that 
Walter is rightly focused on language features rather than optimizing dmd's 
backend and the fact that almost no one else seems likely to spend time 
optimizing dmd's backend, it's a foregone conclusion at this point that dmd is 
going to generate slower programs than gdc and ldc for the forseeable future. 
On the other hand, it wouldn't surprise me if having Walter switch to another 
backend for the reference compiler would cost us so much development time from 
him (as he learns the new backend) that it wouldn't be even vaguely worth it.

- Jonathan M Davis