July 07, 2012
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
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
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
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
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
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
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
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
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
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/