View mode: basic / threaded / horizontal-split · Log in · Help
July 07, 2012
Re: LLVM IR influence on compiler debugging
On Saturday, July 07, 2012 16:52:25 Adam Wilson wrote:
> Agreed, but not many people have push rights to the website, which is
> where I would start.

The lack of commit rights to d-programming-language.org doesn't stop you from 
submitting pull requests. It just stops you from putting your edits directly 
on the site without anyone else looking at them first. Granted, pull requests 
for d-programming-language.org aren't always handled quickly, but how quickly 
your changes get merged doesn't really affect your ability to make the changes 
in the first place.

- Jonathan M Davis
July 08, 2012
Re: LLVM IR influence on compiler debugging
On Saturday, July 07, 2012 16:54:48 Adam Wilson wrote:
> On Sat, 07 Jul 2012 16:38:27 -0700, Timon Gehr <timon.gehr@gmx.ch> wrote:
> > The DMD backend is very fast in comparison to other backends.
> > 
> > LLVM is unlikely to catch up in speed, because it is well architectured
> > and more general.
> 
> Oh, I agree that it is, but as I've been saying, raw compiler speed is
> rarely an important factor outside of small circles of developers, if it
> was, businesses would have given up on C++ LONG ago. It's nice to have,
> but the business case for it is weak comparatively.

Just because one set of developers has priorities other than compilation speed 
which they consider to be more important doesn't mean that a lot of developers 
don't think that compilation speed is important. I've worked on projects that 
took over 3 hours to build but that doesn't mean that I wouldn't have wanted 
them to be faster. I've known programmers who complained about builds which 
were over a minute!

If you rate something else higher than compilation speed, that's fine, but that 
doesn't mean that compilation speed doesn't matter, because it does.

And if the various D Compilers are consistent enough, it arguably becomes a 
good course of action to build your ultimate release using gdc or ldc but to 
do most of the direct development on dmd so that you get a fast compile-test-
rewrite cycle.

- Jonathan M Davis
July 08, 2012
Re: LLVM IR influence on compiler debugging
On 07/08/2012 01:54 AM, Adam Wilson wrote:
> On Sat, 07 Jul 2012 16:38:27 -0700, Timon Gehr <timon.gehr@gmx.ch> wrote:
>
>> On 07/08/2012 01:28 AM, Adam Wilson wrote:
>>> On Sat, 07 Jul 2012 16:15:11 -0700, Walter Bright
>>> <newshound2@digitalmars.com> wrote:
>>>
>>>> On 7/7/2012 4:08 PM, Adam Wilson wrote:
>>>>> On Sat, 07 Jul 2012 11:48:44 -0700, Walter Bright
>>>>> <newshound2@digitalmars.com>
>>>>> wrote:
>>>>>
>>>>>> On 7/7/2012 8:38 AM, Alex Rønne Petersen wrote:
>>>>>>> On a high-end 4-core x86, building LLVM and LDC can usually be
>>>>>>> done in less than an hour, even when building them in optimized
>>>>>>> mode.
>>>>>>
>>>>>> Building dmd on my Windows box takes 26 seconds, optimized, using a
>>>>>> single core.
>>>>>
>>>>> Build speed of the compiler itself is an utterly trivial matter, my
>>>>> primary
>>>>> concern is speed for the end-user. Even the build speed/memory usage
>>>>> of my
>>>>> projects is not a problem, I can always throw more money at hardware.
>>>>> For
>>>>> example, I am considering making the next round of developer box
>>>>> updates to
>>>>> Intel Xeon E1650's with 32GB RAM.
>>>>>
>>>>> Gentlemen, from a business prospective, compiler and/or project build
>>>>> times are
>>>>> the least of your problems. How well the code performs and most
>>>>> importantly the
>>>>> accuracy of the code generation is of key concern.
>>>>
>>>> Throwing more hardware at a problem isn't going to get you a 120x
>>>> increase in speed.
>>>
>>> I wont argue that, but again, that's not a primary concern. :-)
>>>
>>>> While you're right that the customer cares not how long it takes to
>>>> build the compiler, the speed is important for the edit-compile-debug
>>>> loop of developing the compiler. For me, it matters quite a bit.
>>>
>>> I imagine that it does, and honestly, I am not terribly concerned if DMD
>>> stays with it's current backend because once LLVM gets SEH, im gone. But
>>> I do wonder if DMD will become increasingly irrelevant as backends like
>>> GCC and LLVM advance. And I am particularly troubled by what seems like
>>> a duplication of effort in the face of more widely tested backends...
>>>
>>
>> The DMD backend is very fast in comparison to other backends.
>>
>> LLVM is unlikely to catch up in speed, because it is well architectured
>> and more general.
>>
>
> Oh, I agree that it is, but as I've been saying, raw compiler speed is
> rarely an important factor outside of small circles of developers, if it
> was, businesses would have given up on C++ LONG ago. It's nice to have,
> but the business case for it is weak comparatively.
>

'raw compiler speed is rarely the most important factor' does not
necessarily imply 'raw compiler speed is rarely an important factor'.
July 08, 2012
Re: LLVM IR influence on compiler debugging
On Sat, 07 Jul 2012 17:22:27 -0700, Timon Gehr <timon.gehr@gmx.ch> wrote:

> On 07/08/2012 01:54 AM, Adam Wilson wrote:
>> On Sat, 07 Jul 2012 16:38:27 -0700, Timon Gehr <timon.gehr@gmx.ch>  
>> wrote:
>>
>>> On 07/08/2012 01:28 AM, Adam Wilson wrote:
>>>> On Sat, 07 Jul 2012 16:15:11 -0700, Walter Bright
>>>> <newshound2@digitalmars.com> wrote:
>>>>
>>>>> On 7/7/2012 4:08 PM, Adam Wilson wrote:
>>>>>> On Sat, 07 Jul 2012 11:48:44 -0700, Walter Bright
>>>>>> <newshound2@digitalmars.com>
>>>>>> wrote:
>>>>>>
>>>>>>> On 7/7/2012 8:38 AM, Alex Rønne Petersen wrote:
>>>>>>>> On a high-end 4-core x86, building LLVM and LDC can usually be
>>>>>>>> done in less than an hour, even when building them in optimized
>>>>>>>> mode.
>>>>>>>
>>>>>>> Building dmd on my Windows box takes 26 seconds, optimized, using a
>>>>>>> single core.
>>>>>>
>>>>>> Build speed of the compiler itself is an utterly trivial matter, my
>>>>>> primary
>>>>>> concern is speed for the end-user. Even the build speed/memory usage
>>>>>> of my
>>>>>> projects is not a problem, I can always throw more money at  
>>>>>> hardware.
>>>>>> For
>>>>>> example, I am considering making the next round of developer box
>>>>>> updates to
>>>>>> Intel Xeon E1650's with 32GB RAM.
>>>>>>
>>>>>> Gentlemen, from a business prospective, compiler and/or project  
>>>>>> build
>>>>>> times are
>>>>>> the least of your problems. How well the code performs and most
>>>>>> importantly the
>>>>>> accuracy of the code generation is of key concern.
>>>>>
>>>>> Throwing more hardware at a problem isn't going to get you a 120x
>>>>> increase in speed.
>>>>
>>>> I wont argue that, but again, that's not a primary concern. :-)
>>>>
>>>>> While you're right that the customer cares not how long it takes to
>>>>> build the compiler, the speed is important for the edit-compile-debug
>>>>> loop of developing the compiler. For me, it matters quite a bit.
>>>>
>>>> I imagine that it does, and honestly, I am not terribly concerned if  
>>>> DMD
>>>> stays with it's current backend because once LLVM gets SEH, im gone.  
>>>> But
>>>> I do wonder if DMD will become increasingly irrelevant as backends  
>>>> like
>>>> GCC and LLVM advance. And I am particularly troubled by what seems  
>>>> like
>>>> a duplication of effort in the face of more widely tested backends...
>>>>
>>>
>>> The DMD backend is very fast in comparison to other backends.
>>>
>>> LLVM is unlikely to catch up in speed, because it is well architectured
>>> and more general.
>>>
>>
>> Oh, I agree that it is, but as I've been saying, raw compiler speed is
>> rarely an important factor outside of small circles of developers, if it
>> was, businesses would have given up on C++ LONG ago. It's nice to have,
>> but the business case for it is weak comparatively.
>>
>
> 'raw compiler speed is rarely the most important factor' does not
> necessarily imply 'raw compiler speed is rarely an important factor'.

Correct, just less important that other things.

-- 
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 17:04:35 -0700, Jonathan M Davis <jmdavisProg@gmx.com>  
wrote:

> On Saturday, July 07, 2012 16:54:48 Adam Wilson wrote:
>> On Sat, 07 Jul 2012 16:38:27 -0700, Timon Gehr <timon.gehr@gmx.ch>  
>> wrote:
>> > The DMD backend is very fast in comparison to other backends.
>> >
>> > LLVM is unlikely to catch up in speed, because it is well  
>> architectured
>> > and more general.
>>
>> Oh, I agree that it is, but as I've been saying, raw compiler speed is
>> rarely an important factor outside of small circles of developers, if it
>> was, businesses would have given up on C++ LONG ago. It's nice to have,
>> but the business case for it is weak comparatively.
>
> Just because one set of developers has priorities other than compilation  
> speed
> which they consider to be more important doesn't mean that a lot of  
> developers
> don't think that compilation speed is important. I've worked on projects  
> that
> took over 3 hours to build but that doesn't mean that I wouldn't have  
> wanted
> them to be faster. I've known programmers who complained about builds  
> which
> were over a minute!

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.

> If you rate something else higher than compilation speed, that's fine,  
> but that
> doesn't mean that compilation speed doesn't matter, because it does.

That's been my whole point, we need ways to tell other people about the  
pro's and con's of each tool, so that they can choose the right tool,  
knowing it's capabilities and limitations. Right now, it's all DMD.

> And if the various D Compilers are consistent enough, it arguably  
> becomes a
> good course of action to build your ultimate release using gdc or ldc  
> but to
> do most of the direct development on dmd so that you get a fast  
> compile-test-
> rewrite cycle.
>
> - Jonathan M Davis

Except when you are working on architectures that DMD doesn't support.  
Such as Win64, our primary arch here at work. We also want to get into ARM  
on Windows. Win32 is fast becoming irrelevant for new work as almost all  
Win7 machines shipped these days are x64. Essentially, I cannot justify  
DMD under any circumstance for production work here.

However, I realize that for most people Win32 only is just fine. But we  
need a page that explains all these differences. As I said in my first  
post on the subject, I only know the differences because I've been here  
for many months, most decision makers aren't going to dedicate a trivial  
fraction of that time. They'll see that DMD doesn't support Win64 and move  
on without doing the investigation to find out that there is even an  
option for LLVM, because, as near as I can tell, it's not even mentioned.  
They may try GDC only to find that it's not well supported on Windows at  
all (i've heard mixed reports of people getting builds working and it  
seems extremely fragile).

If D is going to use the multiple-tool approach, which I agree it should,  
then we should do our best to promote all the tools and more importantly,  
the community is actively engaged in supporting and improving all of them.  
I am willing to do the website work, but I have no idea when I'll get to  
it as I have other D projects cooking, including GSoC; and more  
importantly, if I even understand the differences well enough myself to  
make accurate statements.

-- 
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 01:57, Jonathan M Davis wrote:
> On Saturday, July 07, 2012 16:52:25 Adam Wilson wrote:
>> Agreed, but not many people have push rights to the website, which is
>> where I would start.
>
> The lack of commit rights to d-programming-language.org doesn't stop you from
> submitting pull requests. It just stops you from putting your edits directly
> on the site without anyone else looking at them first. Granted, pull requests
> for d-programming-language.org aren't always handled quickly, but how quickly
> your changes get merged doesn't really affect your ability to make the changes
> in the first place.
>
> - Jonathan M Davis
>

No, but it does affect how long it takes to make them show up on the 
page that we present to users of/newcomers to D.

The slow pull request review/accept/reject time can be very demotivating 
at times.

-- 
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 17:32:28 -0700, Alex Rønne Petersen <alex@lycus.org>  
wrote:

> On 08-07-2012 01:57, Jonathan M Davis wrote:
>> On Saturday, July 07, 2012 16:52:25 Adam Wilson wrote:
>>> Agreed, but not many people have push rights to the website, which is
>>> where I would start.
>>
>> The lack of commit rights to d-programming-language.org doesn't stop  
>> you from
>> submitting pull requests. It just stops you from putting your edits  
>> directly
>> on the site without anyone else looking at them first. Granted, pull  
>> requests
>> for d-programming-language.org aren't always handled quickly, but how  
>> quickly
>> your changes get merged doesn't really affect your ability to make the  
>> changes
>> in the first place.
>>
>> - Jonathan M Davis
>>
>
> No, but it does affect how long it takes to make them show up on the  
> page that we present to users of/newcomers to D.
>
> The slow pull request review/accept/reject time can be very demotivating  
> at times.
>

Actually, this is the reason I haven't fixed my DI Generation pull yet. I  
have a lot of projects going right now (including GSoC) and knowing that  
fixing my pull won't get it merged even in the next few months is  
incredibly demotivating.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
July 08, 2012
Re: LLVM IR influence on compiler debugging
On Sunday, July 08, 2012 02:32:28 Alex Rønne Petersen wrote:
> On 08-07-2012 01:57, Jonathan M Davis wrote:
> > On Saturday, July 07, 2012 16:52:25 Adam Wilson wrote:
> >> Agreed, but not many people have push rights to the website, which is
> >> where I would start.
> > 
> > The lack of commit rights to d-programming-language.org doesn't stop you
> > from submitting pull requests. It just stops you from putting your edits
> > directly on the site without anyone else looking at them first. Granted,
> > pull requests for d-programming-language.org aren't always handled
> > quickly, but how quickly your changes get merged doesn't really affect
> > your ability to make the changes in the first place.
> > 
> > - Jonathan M Davis
> 
> No, but it does affect how long it takes to make them show up on the
> page that we present to users of/newcomers to D.
> 
> The slow pull request review/accept/reject time can be very demotivating
> at times.

True, but saying that you can't make changes just because you don't have the 
permissions to commit directly to the main repository is patently false, and 
that's what Adam's post implied.

- Jonathan M Davis
July 08, 2012
Re: LLVM IR influence on compiler debugging
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.
July 08, 2012
Re: LLVM IR influence on compiler debugging
On Sat, 07 Jul 2012 17:39:49 -0700, Jonathan M Davis <jmdavisProg@gmx.com>  
wrote:

> On Sunday, July 08, 2012 02:32:28 Alex Rønne Petersen wrote:
>> On 08-07-2012 01:57, Jonathan M Davis wrote:
>> > On Saturday, July 07, 2012 16:52:25 Adam Wilson wrote:
>> >> Agreed, but not many people have push rights to the website, which is
>> >> where I would start.
>> >
>> > The lack of commit rights to d-programming-language.org doesn't stop  
>> you
>> > from submitting pull requests. It just stops you from putting your  
>> edits
>> > directly on the site without anyone else looking at them first.  
>> Granted,
>> > pull requests for d-programming-language.org aren't always handled
>> > quickly, but how quickly your changes get merged doesn't really affect
>> > your ability to make the changes in the first place.
>> >
>> > - Jonathan M Davis
>>
>> No, but it does affect how long it takes to make them show up on the
>> page that we present to users of/newcomers to D.
>>
>> The slow pull request review/accept/reject time can be very demotivating
>> at times.
>
> True, but saying that you can't make changes just because you don't have  
> the
> permissions to commit directly to the main repository is patently false,  
> and
> that's what Adam's post implied.
>
> - Jonathan M Davis

I apologize, I wasn't trying to imply that. I was trying to imply that  
without such privileges it requires far too more effort on my part to  
advocate and cajole for someone to merge said changes than I have time for  
right now. I am quite exhausted after spending over a month trying to get  
some trivial changes merged into DRuntime. I wasn't trying to ask for  
merge rights. The merge process around here is glacial and that could  
easily kill D.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
1 2 3 4 5 6
Top | Discussion index | About this forum | D home