On 7/7/2012 11:59 AM, Alex Rønne Petersen wrote:
> By the way, is it planned that DMD will be able to use Microsoft's linker when
> compiling with COFF?

Yes, barring some horrible obstacle.

On Sat, 07 Jul 2012 11:49:16 -0700, Walter Bright <newshound2@digitalmars.com> wrote:

> On 7/7/2012 3:46 AM, Jacob Carlborg wrote:
>> Theoretically you should be able to just look at the documentation
>
>
> HAHAHAHAHAHAHAHAHAHAHAAAAA!!!
>

Unfortunately, I have to agree with this sentiment. I was merely under an incorrect impression of the scope of the license with which Walter is operating under. Based on my experience with D, it is utterly ridiculous to expect the documentation to be enough. However, I will maintain my position that being tied to the current backend will seriously constrain the capabilities of DMD when compared to the other options.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

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.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

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.

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.

Adam Wilson:

> Gentlemen, from a business prospective, compiler and/or project build times are the least of your problems.

If DMD compiles quickly, I am able to compile one or more times every day, so I'm able to test it frequently. Other people do the same. The result is a better compiler for the user.

Bye,
bearophile

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

All that said, I understand the legal predicament. You can't do anything about it and I'm not trying to convince you too. I just want to see more promotion and support of the other options available.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

On 7/7/2012 4:28 PM, Adam Wilson wrote:
> 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...

Different implementations will have their different strengths and weaknesses, and also competition between them is good. I'm very pleased that we have 3 strong implementations.


> All that said, I understand the legal predicament. You can't do anything about
> it and I'm not trying to convince you too. I just want to see more promotion and
> support of the other options available.

I think we'd all be better off if more involved here would get more active in promotion, rather than waiting for me to do it.

The whole "better mouse trap" thing is baloney. Promotion is necessary, even if you've got a great product. Even Apple has a huge promotion budget.

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.

> All that said, I understand the legal predicament. You can't do anything
> about it and I'm not trying to convince you too. I just want to see more
> promotion and support of the other options available.
>

On Sat, 07 Jul 2012 16:34:53 -0700, Walter Bright <newshound2@digitalmars.com> wrote:

> On 7/7/2012 4:28 PM, Adam Wilson wrote:
>> 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...
>
> Different implementations will have their different strengths and weaknesses, and also competition between them is good. I'm very pleased that we have 3 strong implementations.
>
>
>> All that said, I understand the legal predicament. You can't do anything about
>> it and I'm not trying to convince you too. I just want to see more promotion and
>> support of the other options available.
>
> I think we'd all be better off if more involved here would get more active in promotion, rather than waiting for me to do it.
>
> The whole "better mouse trap" thing is baloney. Promotion is necessary, even if you've got a great product. Even Apple has a huge promotion budget.
>

Agreed, but not many people have push rights to the website, which is where I would start. I am not trying to say that LLVM or DMD or GDC is better for all situations, but that we need to clear guidance as to which tools are best suited to which situations, for example, I find it incredibly hard to get a clean build of LDC on Linux (not even counting Windows) and found GDC's build process much easier to get working. However, I personally don't feel it is terribly wise for my business to by tied to the Stallmanology of GCC and GDC on Windows is nigh hopeless (no MinGW support). For the work *I* do LLVM is best, but situations vary wildly, which is why this is important.

I am talking here because I don't have merge rights on the website and pull requests are usually left languishing for many moons...

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

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.

>> All that said, I understand the legal predicament. You can't do anything
>> about it and I'm not trying to convince you too. I just want to see more
>> promotion and support of the other options available.
>>
>


-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/