On 4/3/2015 9:41 AM, David Nadlinger wrote:
> On Friday, 3 April 2015 at 15:07:57 UTC, Andrei Alexandrescu wrote:
>> On 4/3/15 3:10 AM, Andrea Fontana wrote:
>>> It would be great to have dmd on embedded platforms.
>>
>> I agree. We just don't have the champion for that yet. -- Andrei
>
> I might obviously be biased, but to be honest I don't see much value in starting
> to port a largely obsolete backend to a whole new processor architecture.

It's not obsolete at all. There's nothing fundamentally wrong with it, or preventing new optimizations being added to it. After all, I didn't have trouble upgrading it from 16 to 32 bits, from 32 to 64, to Linux, to OSX, to SIMD, etc.

On 4/3/2015 2:59 PM, Kai Nacke wrote:
> My plan with LDC is to use the CPP backend to produce a boot strap compiler and
> then compile the D source. Much work...

I don't understand. Why can't you use the existing LDC compiler to bootstrap?

On Sat, Apr 04, 2015 at 01:10:43PM -0700, Walter Bright via Digitalmars-d wrote:
> On 4/3/2015 9:41 AM, David Nadlinger wrote:
> >On Friday, 3 April 2015 at 15:07:57 UTC, Andrei Alexandrescu wrote:
> >>On 4/3/15 3:10 AM, Andrea Fontana wrote:
> >>>It would be great to have dmd on embedded platforms.
> >>
> >>I agree. We just don't have the champion for that yet. -- Andrei
> >
> >I might obviously be biased, but to be honest I don't see much value in starting to port a largely obsolete backend to a whole new processor architecture.
> 
> It's not obsolete at all. There's nothing fundamentally wrong with it, or preventing new optimizations being added to it. After all, I didn't have trouble upgrading it from 16 to 32 bits, from 32 to 64, to Linux, to OSX, to SIMD, etc.

The trouble with the dmd backend is that it currently doesn't produce very well-optimized code. I have consistently observed a 20-30% performance degradation with code compiled with dmd vs. code compiled with gdc (both with all optimization switches turned to the max). From cursory investigation of the asm output, dmd appears to be unable to inline beyond the most trivial function calls, doesn't do loop refactoring / unrolling as well as gdc does, and a host of other little things that all add up to poorer performance when CPU-intensive inner loops are concerned. A lot of this deficiency shows up especially in range-based code, which consists of lots of calls to small functions from inner loops, where performance really matters.

Now, obviously, there's nothing (in theory) stopping you or anybody else from improving the backend so that it *can* perform better optimizations, but the fact of the matter is that there is a whole group of dedicated contributors to gdc/ldc backends who are constantly honing their respective optimizers, some of whom specialize in improving optimizers, whereas AFAICT you are the only one here who's truly comfortable with dmd's backend code and who can implement these improvements within a reasonable amount of effort. However, we need you for other, high-level things related to D -- we can't afford you to spend all of your time working only on the optimizer in the backend. Besides, even if you could, you're just one person, whereas gdc/ldc have a much larger number of contributors, some of whose specialty is optimization.  Do you realistically think you can singlehandedly outdo all of them? And now we're talking about adding whole new platforms to the backend, with all that it entails (need to write more optimization code for each new target and maintain it all, etc.).

With all due respect, I recognize that you produced superior C/C++ compilers back in the day in spite of the naysayers, but as they say, extraordinary claims require extraordinary proof. You had extraordinary proof back then, in the form of actual compilers that generated superior code. Unfortunately, today, staring me in the face is the irrefutable data that dmd-produced code consistently performs 20-30% poorer than gdc-produced code (sometimes I've seen it as bad as 40-50%). In light of that, I find it hard to justify investing more effort into the dmd backend when you could instead put your efforts into improving DMDFE and let the gdc/ldc backend guys do what they do best.


T

-- 
Give me some fresh salted fish, please.

On Saturday, 4 April 2015 at 20:10:45 UTC, Walter Bright wrote:
> On 4/3/2015 9:41 AM, David Nadlinger wrote:
>> On Friday, 3 April 2015 at 15:07:57 UTC, Andrei Alexandrescu wrote:
>>> On 4/3/15 3:10 AM, Andrea Fontana wrote:
>>>> It would be great to have dmd on embedded platforms.
>>>
>>> I agree. We just don't have the champion for that yet. -- Andrei
>>
>> I might obviously be biased, but to be honest I don't see much value in starting
>> to port a largely obsolete backend to a whole new processor architecture.
>
> It's not obsolete at all. There's nothing fundamentally wrong with it, or preventing new optimizations being added to it. After all, I didn't have trouble upgrading it from 16 to 32 bits, from 32 to 64, to Linux, to OSX, to SIMD, etc.

> There's nothing fundamentally wrong with it,

proprietary license hindering contributions and distribution, performs worse across the board against GDC/LDC in terms of optimized binaries, lack of manpower in comparison to LLVM/GCC that have massive corporation and educational backing.

On Friday, 3 April 2015 at 20:56:09 UTC, deadalnix wrote:
> On Friday, 3 April 2015 at 19:45:29 UTC, weaselcat wrote:
>> The reliance on GDC/LDC to produce production-level binaries(i.e, optimized) and the actual people working on them really is worrisome. If Iain or Kai decided one day to leave D, it would be a very big blow I think.
>
> Yes. And considering there is no hope that we bring dmd's backend up to speed with GCC or LLVM (let's be realistic one second) what is even more worrisome is how little they are integrated in the workflow.

Out of curiosity, what was the communication level between the decision to switch to ddmd frontend and the ldc/gdc team?

On Sat, Apr 04, 2015 at 09:15:01PM +0000, weaselcat via Digitalmars-d wrote:
> On Friday, 3 April 2015 at 20:56:09 UTC, deadalnix wrote:
> >On Friday, 3 April 2015 at 19:45:29 UTC, weaselcat wrote:
> >>The reliance on GDC/LDC to produce production-level binaries(i.e, optimized) and the actual people working on them really is worrisome. If Iain or Kai decided one day to leave D, it would be a very big blow I think.
> >
> >Yes. And considering there is no hope that we bring dmd's backend up to speed with GCC or LLVM (let's be realistic one second) what is even more worrisome is how little they are integrated in the workflow.
> 
> Out of curiosity, what was the communication level between the decision to switch to ddmd frontend and the ldc/gdc team?

I thought it was public knowledge for a while now that eventually we're gonna do this switch? It was just a matter of time. I mean, Daniel Murphy hasn't exactly been keeping hush-hush about progress on ddmd all this time.


T

-- 
Give me some fresh salted fish, please.

On 4/4/2015 1:48 PM, H. S. Teoh via Digitalmars-d wrote:
>Besides, even if you could, you're just one person, whereas gdc/ldc have
> a much larger number of contributors, some of whose specialty is
> optimization.  Do you realistically think you can singlehandedly outdo
> all of them?

I did for decades, until the early 2000's or so when I began spending all my time on the front end.

There's no great mystery how to do it. I know how to improve all the issues you've mentioned, and then some. It's just a matter of being able to spend the time on it - it is not a matter of the design being obsolete and it must be tossed, which was what I was responding to.

On 4/4/2015 1:59 PM, weaselcat wrote:
> proprietary license hindering contributions and distribution, performs worse
> across the board against GDC/LDC in terms of optimized binaries, lack of
> manpower in comparison to LLVM/GCC that have massive corporation and educational
> backing.

Massive manpower doesn't do much good when doing tricky things like getting the optimizer to work well. An optimizer/code generator can be kept all in one head at the same time.

MM pays off when you've got a galaxy of tools to be developed that are a bit independent of each other.

"weaselcat"  wrote in message news:rspoyryeklgjychqfyuk@forum.dlang.org...

> Out of curiosity, what was the communication level between the decision to switch to ddmd frontend and the ldc/gdc team?

The ldc and gdc teams have been involved since the first discussions at dconf13. 

On Saturday, 4 April 2015 at 22:05:33 UTC, H. S. Teoh wrote:
> On Sat, Apr 04, 2015 at 09:15:01PM +0000, weaselcat via Digitalmars-d wrote:
>> On Friday, 3 April 2015 at 20:56:09 UTC, deadalnix wrote:
>> >On Friday, 3 April 2015 at 19:45:29 UTC, weaselcat wrote:
>> >>The reliance on GDC/LDC to produce production-level binaries(i.e,
>> >>optimized) and the actual people working on them really is
>> >>worrisome. If Iain or Kai decided one day to leave D, it would be a
>> >>very big blow I think.
>> >
>> >Yes. And considering there is no hope that we bring dmd's backend up
>> >to speed with GCC or LLVM (let's be realistic one second) what is
>> >even more worrisome is how little they are integrated in the
>> >workflow.
>> 
>> Out of curiosity, what was the communication level between the
>> decision to switch to ddmd frontend and the ldc/gdc team?
>
> I thought it was public knowledge for a while now that eventually we're
> gonna do this switch? It was just a matter of time. I mean, Daniel
> Murphy hasn't exactly been keeping hush-hush about progress on ddmd all
> this time.
>
>
> T

I was just curious, didn't mean it to come off any other way : )