On Thursday, 27 August 2015 at 13:49:18 UTC, Bruno Medeiros wrote:
> On 19/08/2015 09:22, Dmitry Olshansky wrote:
>>>
>>>>>> I'm interested in ways to reduce that gap.
>>> [...]
>>>
>>> Replace the backend with GDC or LLVM? :-P
>>>
>>
>> Oh come on - LLVM was an inferiour backend for some time.
>> So what? Let us no work on it 'cause GCC is faster?
>
> I can't figure out what you meant: LLVM has an inferiour backend to what? GCC or DMD?

I think he's saying that the argument: "Don't work on DMD because it's already far behind" could have been applied to working on LLVM when it was far behind GCC.  I don't agree, but I think that's what he means.

On Thursday, 27 August 2015 at 14:12:01 UTC, Bruno Medeiros wrote:
> On 18/08/2015 21:28, Walter Bright wrote:
>> 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
>
> My instinct also tells me it's extremely unlikely that DMD will be able to catch. But regardless of that, let's suppose it does catch up, that you (and/or others) are eventually able to make the DMD backend as good as LLVM/GCC. At what cost (development time wise) will that come? How much big chunks of development effort will be spent on that task, that could be spent on improving other areas of D, just so that DMD could be about as good (not better, just *as good*), as LDC/GDC?...

Honestly, while I don't see why dmd couldn't catch up to gdc and ldc if enough development time were sunk into it, I seriously question that dmd can catch up without way too much development time being sunk into it. And if ldc and gdc are ultimately the compilers that folks should be using if they want the best performance, then so be it. But if dmd can be sped up so that it's closer and there's less need to worry about the speed difference for most folks, then I think that that's a big win. Every little bit of performance improvement that we can get out of dmd is an improvement, especially when those improvements come at minimal cost, and I see no reason to not improve dmd's performance where it's not going to be a huge timesink to do so and where the appropriate precautions are taken to avoid regressions.

- Jonathan M Davis

On Thursday, 27 August 2015 at 17:59:48 UTC, Jonathan M Davis wrote:
> that's a big win. Every little bit of performance improvement that we can get out of dmd is an improvement, especially when those improvements come at minimal cost, and I see no reason to not improve dmd's performance where it's not going to be a huge timesink to do so and where the appropriate precautions are taken to avoid regressions.

Actually, if you think about PR, it does not matter. I might even be better to perform 50% worse and call it a development-mode than to perform 25% worse in release mode...

How about putting effort into making it easier to hook multiple backends into the same binary instead? People won't complain if they can toss in "-O" and get LLVM backend output from the same compiler.

"John Colvin"  wrote in message news:qlbnpjnizwpslrdpktsw@forum.dlang.org...

> I think he's saying that the argument: "Don't work on DMD because it's already far behind" could have been applied to working on LLVM when it was far behind GCC.  I don't agree, but I think that's what he means.

It helps that LLVM has a superior license. 

On Friday, 28 August 2015 at 01:42:22 UTC, Daniel Murphy wrote:
> "John Colvin"  wrote in message news:qlbnpjnizwpslrdpktsw@forum.dlang.org...
>
>> I think he's saying that the argument: "Don't work on DMD because it's already far behind" could have been applied to working on LLVM when it was far behind GCC.  I don't agree, but I think that's what he means.
>
> It helps that LLVM has a superior license.

+ LLVM started as an academic research project in compiler design, so it was never far behind conceptually...

On 27/08/2015 17:14, John Colvin wrote:
> On Thursday, 27 August 2015 at 13:49:18 UTC, Bruno Medeiros wrote:
>> On 19/08/2015 09:22, Dmitry Olshansky wrote:
>>>>
>>>>>>> I'm interested in ways to reduce that gap.
>>>> [...]
>>>>
>>>> Replace the backend with GDC or LLVM? :-P
>>>>
>>>
>>> Oh come on - LLVM was an inferiour backend for some time.
>>> So what? Let us no work on it 'cause GCC is faster?
>>
>> I can't figure out what you meant: LLVM has an inferiour backend to
>> what? GCC or DMD?
>
> I think he's saying that the argument: "Don't work on DMD because it's
> already far behind" could have been applied to working on LLVM when it
> was far behind GCC.  I don't agree, but I think that's what he means.

Duh, I somehow misread it as "LLVM has an inferiour backend for some time now", which is why I got confused. Yeah, it's clear he was comparing with GCC.

I don't agree with his point either.

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros

On 23/08/15 22:12, Walter Bright wrote:
> On 8/23/2015 11:42 AM, deadalnix wrote:
>> No, x32 is basically amd64 with 32 bits pointers. You can use all other
>> functions of amd64, like the extended number of registers.
>
> Makes sense.
At least right now, it sounds more useful than it actually is.

Since this is a different ABI, it actually requires its own version of the  libraries of everything, kernel support, etc. As of now, no one seriously uses it, and the cost of carrying two ABIs doesn't make it plausible, in my opinion, that this will change in the future.

To add insult to injury, Debian switched it off in their default kernel compilation, as they claim they don't want the extra exposure to security exploit through code the few test (this has saved them from at least one kernel security vulnerability since that decision was taken).

Also, I haven't seen any hard numbers as far as how much, if at all, this saves in space (likely a little) and in runtime efficiency (likely even less). If these are as compelling as I expect them to be, expect this platform to die without gaining much traction.

Shachar

The difference between theory and practice is that, in theory, there is no difference between theory and practice.
 -- Yoggi Berra

So comparing to llvm the idea of optimizing backend comes with:

1) LLVM optimizes code much better than DMD for now. And it's in active development, so it always will be far from DMD.
2) LLVM has over 120k commits, it has many financial investments from Google and Apple. Are you sure that ONE Walter can achieve what they done ?
3) LLVM supports many platforms while DMD will never support anything different from x86.
4) LLVM has free licensing, while DMD's backend is not.
5) Changing the backend often causes weird regressions to appear, it causes users to be afraid.

I think it's really better to fix current bugs than waste the time.

On 28-Aug-2015 14:18, Temtaime wrote:
> So comparing to llvm the idea of optimizing backend comes with:
>
> 1) LLVM optimizes code much better than DMD for now. And it's in active
> development, so it always will be far from DMD.

In producing better code very it well may be. Faster - I don't think so.

> 2) LLVM has over 120k commits, it has many financial investments from
> Google and Apple. Are you sure that ONE Walter can achieve what they done ?
> 3) LLVM supports many platforms while DMD will never support anything
> different from x86.

We do not need to do the new LLVM thing. Then the rest of argument is destroyed.

> I think it's really better to fix current bugs than waste the time.

Fixing bugs is certainly of higher priority but we need them found and reported first.

-- 
Dmitry Olshansky

Are we needing fastest or optimizing backend ?
Makes it able to optimize means it will become more complicated and slower. Don't touch it then.

There are TONS of bugs. For example from 2008.
https://issues.dlang.org/show_bug.cgi?id=2043