View mode: basic / threaded / horizontal-split · Log in · Help
July 08, 2012
Re: LLVM IR influence on compiler debugging
On Sat, 07 Jul 2012 17:44:09 -0700, Joseph Rushton Wakeling  
<joseph.wakeling@webdrake.net> wrote:

> On 08/07/12 01:52, Adam Wilson wrote:
>> I personally don't feel it is terribly wise for  my business to by tied  
>> to the
>> Stallmanology of GCC
>
> What's the problem here?  The licence of the compiler places no  
> restrictions on the licence of the code you build with it.

Not everyone agrees philosophically with Stallman, and I highly suggest  
that we be very careful not to cram ideology down potential users throats,  
it's a good way to scare them off. Personally, I would use either, but  
getting GDC to work on Windows is a nightmare.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
July 08, 2012
Re: LLVM IR influence on compiler debugging
On 7/7/12 8:29 PM, Adam Wilson wrote:
> Sure they complain, but they would complain harder if the generated code
> was sub-optimal or had bugs in it. And I imagine that multiple hour
> build times are more the exception than rule even in C++, my
> understanding is that all 50mloc of Windows can compile overnight using
> distributed compiling. Essentially, my argument is that for business
> compilation time is something that can be attacked with money, where
> code generation and perf bugs are not.

I'm sorry, but I think you got that precisely backwards.

Andrei
July 08, 2012
Re: LLVM IR influence on compiler debugging
On Sat, 07 Jul 2012 19:33:22 -0700, Andrei Alexandrescu  
<SeeWebsiteForEmail@erdani.org> wrote:

> On 7/7/12 8:29 PM, Adam Wilson wrote:
>> Sure they complain, but they would complain harder if the generated code
>> was sub-optimal or had bugs in it. And I imagine that multiple hour
>> build times are more the exception than rule even in C++, my
>> understanding is that all 50mloc of Windows can compile overnight using
>> distributed compiling. Essentially, my argument is that for business
>> compilation time is something that can be attacked with money, where
>> code generation and perf bugs are not.
>
> I'm sorry, but I think you got that precisely backwards.
>
> Andrei

Why is that?

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
July 08, 2012
Re: LLVM IR influence on compiler debugging
On 7/7/12 11:26 PM, Adam Wilson wrote:
> On Sat, 07 Jul 2012 19:33:22 -0700, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> wrote:
>
>> On 7/7/12 8:29 PM, Adam Wilson wrote:
>>> Sure they complain, but they would complain harder if the generated code
>>> was sub-optimal or had bugs in it. And I imagine that multiple hour
>>> build times are more the exception than rule even in C++, my
>>> understanding is that all 50mloc of Windows can compile overnight using
>>> distributed compiling. Essentially, my argument is that for business
>>> compilation time is something that can be attacked with money, where
>>> code generation and perf bugs are not.
>>
>> I'm sorry, but I think you got that precisely backwards.
>>
>> Andrei
>
> Why is that?

Compilation is a huge bottleneck for any major C++ code base, and adding 
hardware (distributing compilation etc) is survival, but definitely 
doesn't scale to make the problem negligible.

In contrast, programmers have considerable control about generating fast 
code.


Andrei
July 08, 2012
Re: LLVM IR influence on compiler debugging
On Saturday, July 07, 2012 20:26:56 Adam Wilson wrote:
> On Sat, 07 Jul 2012 19:33:22 -0700, Andrei Alexandrescu
> 
> <SeeWebsiteForEmail@erdani.org> wrote:
> > On 7/7/12 8:29 PM, Adam Wilson wrote:
> >> Sure they complain, but they would complain harder if the generated code
> >> was sub-optimal or had bugs in it. And I imagine that multiple hour
> >> build times are more the exception than rule even in C++, my
> >> understanding is that all 50mloc of Windows can compile overnight using
> >> distributed compiling. Essentially, my argument is that for business
> >> compilation time is something that can be attacked with money, where
> >> code generation and perf bugs are not.
> > 
> > I'm sorry, but I think you got that precisely backwards.
> > 
> > Andrei
> 
> Why is that?

Well, considering that the general trend over the last ten years has been to 
move to languages which focus on programmer productivity (including 
compilation speed) over those which focus on speed of execution, there's a 
definite argument that programmers generally prefer stuff that makes programming 
easier and faster over stuff that makes the program faster. There are obviously 
exceptions, and there are some signs of things shifting (due to mobile and 
whatnot), but that's the way that things have been trending for over a decade.

- Jonathan M Davis
July 08, 2012
Re: LLVM IR influence on compiler debugging
On Sat, 07 Jul 2012 21:05:12 -0700, Andrei Alexandrescu  
<SeeWebsiteForEmail@erdani.org> wrote:

> On 7/7/12 11:26 PM, Adam Wilson wrote:
>> On Sat, 07 Jul 2012 19:33:22 -0700, Andrei Alexandrescu
>> <SeeWebsiteForEmail@erdani.org> wrote:
>>
>>> On 7/7/12 8:29 PM, Adam Wilson wrote:
>>>> Sure they complain, but they would complain harder if the generated  
>>>> code
>>>> was sub-optimal or had bugs in it. And I imagine that multiple hour
>>>> build times are more the exception than rule even in C++, my
>>>> understanding is that all 50mloc of Windows can compile overnight  
>>>> using
>>>> distributed compiling. Essentially, my argument is that for business
>>>> compilation time is something that can be attacked with money, where
>>>> code generation and perf bugs are not.
>>>
>>> I'm sorry, but I think you got that precisely backwards.
>>>
>>> Andrei
>>
>> Why is that?
>
> Compilation is a huge bottleneck for any major C++ code base, and adding  
> hardware (distributing compilation etc) is survival, but definitely  
> doesn't scale to make the problem negligible.
>
> In contrast, programmers have considerable control about generating fast  
> code.
>
>
> Andrei
>
>

So work around backend bugs and slowness? I could see that, but the most  
widely used C++ compilers are based on GCC and LLVM and those have very  
few backend problems to begin with. I still see pretty heinous backend  
problems crop up in the bug reports for DMD.

As to compile speed, is LDC really *THAT* much slower than DMD so as to  
cause C++ style speed issues? I thought one of the whole points of D is  
that it doesn't need the epic numbers of passes and preprocessor that C++  
does precisely because that's what slows down C++ so much...

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
July 08, 2012
Re: LLVM IR influence on compiler debugging
On Sat, 07 Jul 2012 21:13:35 -0700, Jonathan M Davis <jmdavisProg@gmx.com>  
wrote:

> On Saturday, July 07, 2012 20:26:56 Adam Wilson wrote:
>> On Sat, 07 Jul 2012 19:33:22 -0700, Andrei Alexandrescu
>>
>> <SeeWebsiteForEmail@erdani.org> wrote:
>> > On 7/7/12 8:29 PM, Adam Wilson wrote:
>> >> Sure they complain, but they would complain harder if the generated  
>> code
>> >> was sub-optimal or had bugs in it. And I imagine that multiple hour
>> >> build times are more the exception than rule even in C++, my
>> >> understanding is that all 50mloc of Windows can compile overnight  
>> using
>> >> distributed compiling. Essentially, my argument is that for business
>> >> compilation time is something that can be attacked with money, where
>> >> code generation and perf bugs are not.
>> >
>> > I'm sorry, but I think you got that precisely backwards.
>> >
>> > Andrei
>>
>> Why is that?
>
> Well, considering that the general trend over the last ten years has  
> been to
> move to languages which focus on programmer productivity (including
> compilation speed) over those which focus on speed of execution, there's  
> a
> definite argument that programmers generally prefer stuff that makes  
> programming
> easier and faster over stuff that makes the program faster. There are  
> obviously
> exceptions, and there are some signs of things shifting (due to mobile  
> and
> whatnot), but that's the way that things have been trending for over a  
> decade.
>
> - Jonathan M Davis

I won't argue with this at all, I use C# after all. But there we shuffle  
the "backend" off to the JIT, so compilation is really more a translation  
to IR. IIRC this is how most of the popular productivity languages did it  
(Java, .NET, etc.).

It'd be an interesting research project to modify LDC to output IR only  
and run the IR later on an LLVM based VM and then see what kind of compile  
times you get...

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
July 08, 2012
Re: LLVM IR influence on compiler debugging
On 08-07-2012 06:44, Adam Wilson wrote:
> On Sat, 07 Jul 2012 21:13:35 -0700, Jonathan M Davis
> <jmdavisProg@gmx.com> wrote:
>
>> On Saturday, July 07, 2012 20:26:56 Adam Wilson wrote:
>>> On Sat, 07 Jul 2012 19:33:22 -0700, Andrei Alexandrescu
>>>
>>> <SeeWebsiteForEmail@erdani.org> wrote:
>>> > On 7/7/12 8:29 PM, Adam Wilson wrote:
>>> >> Sure they complain, but they would complain harder if the
>>> generated code
>>> >> was sub-optimal or had bugs in it. And I imagine that multiple hour
>>> >> build times are more the exception than rule even in C++, my
>>> >> understanding is that all 50mloc of Windows can compile overnight
>>> using
>>> >> distributed compiling. Essentially, my argument is that for business
>>> >> compilation time is something that can be attacked with money, where
>>> >> code generation and perf bugs are not.
>>> >
>>> > I'm sorry, but I think you got that precisely backwards.
>>> >
>>> > Andrei
>>>
>>> Why is that?
>>
>> Well, considering that the general trend over the last ten years has
>> been to
>> move to languages which focus on programmer productivity (including
>> compilation speed) over those which focus on speed of execution,
>> there's a
>> definite argument that programmers generally prefer stuff that makes
>> programming
>> easier and faster over stuff that makes the program faster. There are
>> obviously
>> exceptions, and there are some signs of things shifting (due to mobile
>> and
>> whatnot), but that's the way that things have been trending for over a
>> decade.
>>
>> - Jonathan M Davis
>
> I won't argue with this at all, I use C# after all. But there we shuffle
> the "backend" off to the JIT, so compilation is really more a
> translation to IR. IIRC this is how most of the popular productivity
> languages did it (Java, .NET, etc.).
>
> It'd be an interesting research project to modify LDC to output IR only
> and run the IR later on an LLVM based VM and then see what kind of
> compile times you get...
>

It would be kind of useless in practice, unfortunately. LLVM IR is very 
unsuited for VM use: 
http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/043719.html

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org
July 08, 2012
Re: LLVM IR influence on compiler debugging
On Sat, 07 Jul 2012 21:58:04 -0700, Alex Rønne Petersen <alex@lycus.org>  
wrote:

> On 08-07-2012 06:44, Adam Wilson wrote:
>> On Sat, 07 Jul 2012 21:13:35 -0700, Jonathan M Davis
>> <jmdavisProg@gmx.com> wrote:
>>
>>> On Saturday, July 07, 2012 20:26:56 Adam Wilson wrote:
>>>> On Sat, 07 Jul 2012 19:33:22 -0700, Andrei Alexandrescu
>>>>
>>>> <SeeWebsiteForEmail@erdani.org> wrote:
>>>> > On 7/7/12 8:29 PM, Adam Wilson wrote:
>>>> >> Sure they complain, but they would complain harder if the
>>>> generated code
>>>> >> was sub-optimal or had bugs in it. And I imagine that multiple hour
>>>> >> build times are more the exception than rule even in C++, my
>>>> >> understanding is that all 50mloc of Windows can compile overnight
>>>> using
>>>> >> distributed compiling. Essentially, my argument is that for  
>>>> business
>>>> >> compilation time is something that can be attacked with money,  
>>>> where
>>>> >> code generation and perf bugs are not.
>>>> >
>>>> > I'm sorry, but I think you got that precisely backwards.
>>>> >
>>>> > Andrei
>>>>
>>>> Why is that?
>>>
>>> Well, considering that the general trend over the last ten years has
>>> been to
>>> move to languages which focus on programmer productivity (including
>>> compilation speed) over those which focus on speed of execution,
>>> there's a
>>> definite argument that programmers generally prefer stuff that makes
>>> programming
>>> easier and faster over stuff that makes the program faster. There are
>>> obviously
>>> exceptions, and there are some signs of things shifting (due to mobile
>>> and
>>> whatnot), but that's the way that things have been trending for over a
>>> decade.
>>>
>>> - Jonathan M Davis
>>
>> I won't argue with this at all, I use C# after all. But there we shuffle
>> the "backend" off to the JIT, so compilation is really more a
>> translation to IR. IIRC this is how most of the popular productivity
>> languages did it (Java, .NET, etc.).
>>
>> It'd be an interesting research project to modify LDC to output IR only
>> and run the IR later on an LLVM based VM and then see what kind of
>> compile times you get...
>>
>
> It would be kind of useless in practice, unfortunately. LLVM IR is very  
> unsuited for VM use:  
> http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/043719.html
>

Ahh, well maybe we'll have to use MCI, since I hear that the D.NET project  
is quite dead.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
July 08, 2012
Re: LLVM IR influence on compiler debugging
On 7/7/2012 9:16 PM, Adam Wilson wrote:
> I still see pretty heinous backend problems crop up in
> the bug reports for DMD.

Come on, it's pretty stable. Do you watch the bug reports for gcc? I remember a 
guy recently ran some exhaustive code gen tests over C compilers, and dmc (the 
same back end as dmd) was the only one that did them correctly.

http://news.ycombinator.com/item?id=4131508
1 2 3 4 5 6
Top | Discussion index | About this forum | D home