Soon ? Are you sure ?
Some people said that 2.068 frontend will be in D.
And it's not.

I think it's a really bad idea to optimize dmd's backend.
It will add new regressions and it will make it more complex and slower.

I think it's better to fix bugs and not to optimize that backend.

On Tuesday, 18 August 2015 at 12:37:37 UTC, Vladimir Panteleev wrote:
> I suggest that we revamp the compiler download page again. The lead should be a "select your compiler" which lists the advantages and disadvantages of each of DMD, LDC and GDC.

https://github.com/D-Programming-Language/dlang.org/pull/1067

On 2015-08-18 17:22, Joakim wrote:

> Well, you have to admit that it's pretty impressive that dmd's backend
> gets within 30% of those monumental backends despite having pretty much
> only Walter working on it sporadically.

DMD has only a very limited set of targets compared to LLVM and GCC. So they need more manpower to maintain and enhance the backends.

-- 
/Jacob Carlborg

On 8/18/2015 5:32 AM, Etienne Cimon wrote:
> Other than that, there was a recent Java vs D thread which showed it orders of
> magnitude faster on vtable calls. So I think the most amazing feature would be
> to allow profiling & sampling to compile with samples and select which functions
> to inline or do some magic around vtable pointers like what Java is doing.

There is some potential there, but since a static compiler doesn't do runtime profiling, some sort of hinting scheme would have to be invented.

> Finally, I'm going to write this down here and haven't had time to look more
> into it but I've never been able to compile Botan with optimizations on DMD64
> Win64 VS2013 (https://github.com/etcimon/botan), it's really strange having a
> crypto library that you can't optimize, building -O -g also gives me a ccog.c
> ICE error. I think it might be something about `asm pure` that uses some locals,
> does that eliminate the function call parameters?

Please file a bug report for that!

On 8/18/2015 5:37 AM, Vladimir Panteleev wrote:
> IIRC, I have had three releases affected by optimization/inlining DMD bugs (two
> of Digger and one of RABCDAsm). These do not speak well for D when end-users ask
> me what the cause of the bug is, and I have to say "Yeah, it's a bug in the
> official D compiler".

Are they filed in bugzilla?

On Tuesday, 18 August 2015 at 17:31:50 UTC, Jacob Carlborg wrote:
> On 2015-08-18 17:22, Joakim wrote:
>
>> Well, you have to admit that it's pretty impressive that dmd's backend
>> gets within 30% of those monumental backends despite having pretty much
>> only Walter working on it sporadically.
>
> DMD has only a very limited set of targets compared to LLVM and GCC. So they need more manpower to maintain and enhance the backends.

Target are the tip of the iceberg. GCC and LLVM do most of their magic in the middle, that is common accross front ends and targets. And honestly, there is no way DMD can catch up.

On Tue, Aug 18, 2015 at 07:38:43PM +0000, deadalnix via Digitalmars-d wrote:
> On Tuesday, 18 August 2015 at 17:31:50 UTC, Jacob Carlborg wrote:
> >On 2015-08-18 17:22, Joakim wrote:
> >
> >>Well, you have to admit that it's pretty impressive that dmd's backend gets within 30% of those monumental backends despite having pretty much only Walter working on it sporadically.
> >
> >DMD has only a very limited set of targets compared to LLVM and GCC. So they need more manpower to maintain and enhance the backends.
> 
> Target are the tip of the iceberg. GCC and LLVM do most of their magic in the middle, that is common accross front ends and targets. And honestly, there is no way DMD can catch up.

DMD's optimizer is far behind GDC/LDC.  Every one of my own programs that I ran a profiler on, shows a 30-50% decrease in performance when compiled (with all optimization flags on) with DMD, as opposed to GDC. For CPU-intensive programs, DMD's optimizer has a long way to go.


T

-- 
Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? -- Michael Beibl

On 18/08/15 12:45, Walter Bright via Digitalmars-d wrote:
> Martin ran some benchmarks recently that showed that ddmd compiled with dmd was
> about 30% slower than when compiled with gdc/ldc. This seems to be fairly typical.
>
> I'm interested in ways to reduce that gap.

All things considered, looking at the issues involved in the transition, and the benefits of being able to refactor in D, I can't see that it makes sense to worry about such things at this stage.  Surely the easiest way to handle the speed gap, in the short term, is to make it easy to use gdc/ldc as the D compiler to build ddmd, and to do exactly that when building dmd binaries for distribution.

Admittedly my answer may be Linux-centric (I guess gdc/ldc builds of ddmd are not feasible for Windows), but to be honest, I don't think a 30% slowdown is _that_ terrible a thing to have to deal with, in the short term, to manage such an important transition.  Stability at this stage seems _much_ more important.

On Tuesday, 18 August 2015 at 19:02:20 UTC, Walter Bright wrote:
> On 8/18/2015 5:37 AM, Vladimir Panteleev wrote:
>> IIRC, I have had three releases affected by optimization/inlining DMD bugs (two
>> of Digger and one of RABCDAsm). These do not speak well for D when end-users ask
>> me what the cause of the bug is, and I have to say "Yeah, it's a bug in the
>> official D compiler".
>
> Are they filed in bugzilla?

Yep, just search for wrong-code regressions. The specific bugs in question have been fixed, but that doesn't change the general problem.

On 8/18/2015 12:38 PM, deadalnix wrote:
> And honestly, there is no way DMD can catch up.

I find your lack of faith disturbing.

https://www.youtube.com/watch?v=Zzs-OvfG8tE&feature=player_detailpage#t=91