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

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

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'.

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/

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/

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

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/

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

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.

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/