View mode: basic / threaded / horizontal-split · Log in · Help
July 07, 2012
Re: LLVM IR influence on compiler debugging
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.
July 07, 2012
Re: LLVM IR influence on compiler debugging
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/
July 07, 2012
Re: LLVM IR influence on compiler debugging
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/
July 07, 2012
Re: LLVM IR influence on compiler debugging
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.
July 07, 2012
Re: LLVM IR influence on compiler debugging
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
July 07, 2012
Re: LLVM IR influence on compiler debugging
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/
July 07, 2012
Re: LLVM IR influence on compiler debugging
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.
July 07, 2012
Re: LLVM IR influence on compiler debugging
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.
>
July 07, 2012
Re: LLVM IR influence on compiler debugging
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/
July 07, 2012
Re: LLVM IR influence on compiler debugging
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/
1 2 3 4 5 6
Top | Discussion index | About this forum | D home