bearophile wrote:
> Travis Boucher:
>> Although it's design promotes all sorta of optimization techniques, its still pretty young (compared to gcc) and just doesn't have all of the optimization stuff gcc has.
> 
> I have already done hundred of tests and benchmarks with LDC and llvm-gcc, and I'm starting to understand its optimizations. I am mostly ignorant of LLVM still, but I'm giving a bit of help tuning it, this improvement was motivated by me:
> http://blog.llvm.org/2009/12/advanced-topics-in-redundant-load.html
> 
> Compared to GCC LLVM lacks vectorization (this can be important for certain heavy numerical computing code), profile-guided optimization (this is usually less important, it's uncommon that it gives more than 5-25% performance improvement), but it has a link-time optimizations that gcc lacks (about as important as profile-guided optimization or a little more).
> 
> LLVM produces bad X86 floating point code still, but its int/FP SSE code is about as good as GCC one or better (but it's not vectorized, so far).
> 
> GCC is older and it knows few extra small/tiny optimization tricks, but in most situations they don't create a large difference in performance, they are often quite specific.
> 
> So overall LLVM may sometime produce a little slower code, but in many situations it's about as good or even better (I can show a large amount of cases where LLVM is better). So the asm quality difference is smaller than you seem to imply. If the size of such performance differences are important for you, then you may want to use the Intel compiler instead of GCC, because it's sometimes better than GCC.
> 
> Bye,
> bearophile


I am not trying to get into the benchmark game, for every example of gcc generating better code then llvm, there could be an example of llvm generating better code then gcc.

What I was trying to state is the overall differences between the two:

 - ldc supports newer versions of the dmd front end then gcc.
 - gdc tend to generate better code then ldc (in many cases)
 - gdc supports more targets (the code generator, not the runtime)

I personally use an old-ass gdc because it works for what I need.  I'd like to switch to ldc, but there is limited support for my target platform.

dsimcha:
> Does Intel even make compilers for any language outside the horribly crufty legacy language category (C, C++, Fortran)?

Mostly C++/Fortran.
The problem is, probably those crufty legacy languages aren't going away in the next 20 years :-)

Bye,
bearophile

bearophile, el 23 de diciembre a las 00:13 me escribiste:
> Compared to GCC LLVM lacks vectorization (this can be important for certain heavy numerical computing code), profile-guided optimization (this is usually less important, it's uncommon that it gives more than 5-25% performance improvement)

I don't know if that are accurate numbers, but 5-25% looks like a *lot* to me.

> but it has a link-time optimizations that gcc lacks (about as important as profile-guided optimization or a little more).

And GCC have LTO too, see: http://gcc.gnu.org/wiki/LinkTimeOptimization

I'm not arguing that GCC is way better than LLVM, just wanted to add some lacking information to this thread. I really think they are very close, sometimes one is better, sometimes the other is better), but LLVM is very young compared to GCC so it's very promising that they are so close to GCC in so little time (and using less memory and CPU time).

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
If you want to be alone, just be alone
If you want to watch the sea, just watch the sea
But do it now, timing is the answer, do it now
Timing is the answer to success

Leandro Lucarella:

> bearophile, el 23 de diciembre a las 00:13 me escribiste:
> > Compared to GCC LLVM lacks vectorization (this can be important for certain heavy numerical computing code), profile-guided optimization (this is usually less important, it's uncommon that it gives more than 5-25% performance improvement)
> 
> I don't know if that are accurate numbers, but 5-25% looks like a *lot* to me.

Vectorization can improve 2X or 3X+ the performance of certain code (typical example: matrix multiplication done right).

Performance differences start to matter in practice when they are 2X or more. In most situations users aren't able to appreciate a 20% performance improvement of an application. (But small improvements are important for the compiler devs because they are cumulative, so many small improvements may eventually lead some a significant difference).

Regarding the accuracy of those numbers, it's not easy to tell how much accurate they are, because they are quite sensitive to the details of the code.


> > but it has a link-time optimizations that gcc lacks (about as important as profile-guided optimization or a little more).
> 
> And GCC have LTO too, see: http://gcc.gnu.org/wiki/LinkTimeOptimization

Oh, nice, I have not tried this yet. Is this going in Gcc 4.5?
LTO of LLVM is pretty good, I don't know if GCC implements it equally well (I fear that the answer is negative.


> I'm not arguing that GCC is way better than LLVM, just wanted to add some lacking information to this thread.

Thank you.


> I really think they are very close,
> sometimes one is better, sometimes the other is better), but LLVM is very
> young compared to GCC so it's very promising that they are so close to GCC
> in so little time (and using less memory and CPU time).

LLVM devs are also very nice people, they help me when I have a problem, and they even implement large changes I ask them, often in a short enough time. Helping them is fun. This means that probably the compiler will keep improving for some more time, because in open source projects the quality of the community is important.

Bye,
bearophile

bearophile, el 23 de diciembre a las 12:02 me escribiste:
> Leandro Lucarella:
> 
> > bearophile, el 23 de diciembre a las 00:13 me escribiste:
> > > Compared to GCC LLVM lacks vectorization (this can be important for certain heavy numerical computing code), profile-guided optimization (this is usually less important, it's uncommon that it gives more than 5-25% performance improvement)
> > 
> > I don't know if that are accurate numbers, but 5-25% looks like a *lot* to me.
> 
> Vectorization can improve 2X or 3X+ the performance of certain code (typical example: matrix multiplication done right).
> 
> Performance differences start to matter in practice when they are 2X or more. In most situations users aren't able to appreciate a 20% performance improvement of an application. (But small improvements are important for the compiler devs because they are cumulative, so many small improvements may eventually lead some a significant difference).

Well, you are talking about a single user, but for servers, if you have to provide a minimum quality of service, a 20% difference means you can serve 20% more people, for example (not that people would have to wait 0.2 secs more, because that is not an option).

> > > but it has a link-time optimizations that gcc lacks (about as important as profile-guided optimization or a little more).
> > 
> > And GCC have LTO too, see: http://gcc.gnu.org/wiki/LinkTimeOptimization
> 
> Oh, nice, I have not tried this yet. Is this going in Gcc 4.5?
> LTO of LLVM is pretty good, I don't know if GCC implements it equally
> well (I fear that the answer is negative.

I think it will be in GCC 4.5 but I don't know the details.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Se va a licitar un sistema de vuelos espaciales mendiante el cual, desde una
plataforma que quizás se instale en la provincia de Córdoba. Esas naves
espaciales va a salir de la atmósfera, va a remontar la estratósfera y desde
ahí elegir el lugar donde quieran ir de tal forma que en una hora y media
podamos desde Argentina estar en Japón, en Corea o en cualquier parte.
	-- Carlos Saúl Menem (sic)

Wed, 23 Dec 2009 12:02:53 -0500, bearophile wrote:

> Leandro Lucarella:
> 
>> bearophile, el 23 de diciembre a las 00:13 me escribiste:
>> > Compared to GCC LLVM lacks vectorization (this can be important for certain heavy numerical computing code), profile-guided optimization (this is usually less important, it's uncommon that it gives more than 5-25% performance improvement)
>> 
>> I don't know if that are accurate numbers, but 5-25% looks like a *lot* to me.
> 
> Vectorization can improve 2X or 3X+ the performance of certain code (typical example: matrix multiplication done right).
> 
> Performance differences start to matter in practice when they are 2X or more. In most situations users aren't able to appreciate a 20% performance improvement of an application. (But small improvements are important for the compiler devs because they are cumulative, so many small improvements may eventually lead some a significant difference).

Aren't able to appreciate? Where are those numbers pulled from? Autovectorization mostly deals with expression optimizations in loops. You can easily calculate how much faster some code runs when it uses e.g. SSE2 instructions instead of plain old x86 instructions.


> LLVM devs are also very nice people, they help me when I have a problem, and they even implement large changes I ask them, often in a short enough time. Helping them is fun. This means that probably the compiler will keep improving for some more time, because in open source projects the quality of the community is important.

And GCC devs aren't nice people? They won't help you if you have a problem? Helping them isn't fun? GCC won't keep improving because it's open source? You make no sense. How much do the LLVM devs pay you for advertising them?

On 12/23/2009 10:40 PM, retard wrote:
> Wed, 23 Dec 2009 12:02:53 -0500, bearophile wrote:
>
>> Leandro Lucarella:
>>
>>> bearophile, el 23 de diciembre a las 00:13 me escribiste:
>>>> Compared to GCC LLVM lacks vectorization (this can be important for
>>>> certain heavy numerical computing code), profile-guided optimization
>>>> (this is usually less important, it's uncommon that it gives more
>>>> than 5-25% performance improvement)
>>>
>>> I don't know if that are accurate numbers, but 5-25% looks like a *lot*
>>> to me.
>>
>> Vectorization can improve 2X or 3X+ the performance of certain code
>> (typical example: matrix multiplication done right).
>>
>> Performance differences start to matter in practice when they are 2X or
>> more. In most situations users aren't able to appreciate a 20%
>> performance improvement of an application. (But small improvements are
>> important for the compiler devs because they are cumulative, so many
>> small improvements may eventually lead some a significant difference).
>
> Aren't able to appreciate? Where are those numbers pulled from?
> Autovectorization mostly deals with expression optimizations in loops.
> You can easily calculate how much faster some code runs when it uses e.g.
> SSE2 instructions instead of plain old x86 instructions.

I think you miss the point, he said vectorization was a big deal. The numbers on profile guided optimization seem a bit odd though.

>> LLVM devs are also very nice people, they help me when I have a problem,
>> and they even implement large changes I ask them, often in a short
>> enough time. Helping them is fun. This means that probably the compiler
>> will keep improving for some more time, because in open source projects
>> the quality of the community is important.
>
> And GCC devs aren't nice people? They won't help you if you have a
> problem? Helping them isn't fun? GCC won't keep improving because it's
> open source? You make no sense. How much do the LLVM devs pay you for
> advertising them?

LLVM is way younger than GCC. In my experiments, I get mostly better performance out of clang than out of gcc. Working with LLVM seems like more fun to me.

Pelle MÃ¥nsson:
>The numbers on profile guided optimization seem a bit odd though.<

You are right. It's not easy to give average numbers for any kind of C or C++ software. In benchmark-like code I've seen up to 20-25% improvements, but I assume that in much larger programs the situation is different. Probably if you try to compute a true average, the average percentage of improvement is lower, like 5% or less. It's a feature useful for hot spots of the code.

Bye,
bearophile

bearophile wrote:
> You are right. It's not easy to give average numbers for any kind of
> C or C++ software. In benchmark-like code I've seen up to 20-25%
> improvements, but I assume that in much larger programs the situation
> is different. Probably if you try to compute a true average, the
> average percentage of improvement is lower, like 5% or less. It's a
> feature useful for hot spots of the code.


Small benchmarks tend to have a high 'beta', or variance from the norm. The results in actual applications tend to be much closer together.

Wed, 23 Dec 2009 17:04:49 -0800, Walter Bright wrote:

> bearophile wrote:
>> You are right. It's not easy to give average numbers for any kind of C or C++ software. In benchmark-like code I've seen up to 20-25% improvements, but I assume that in much larger programs the situation is different. Probably if you try to compute a true average, the average percentage of improvement is lower, like 5% or less. It's a feature useful for hot spots of the code.
> 
> 
> Small benchmarks tend to have a high 'beta', or variance from the norm. The results in actual applications tend to be much closer together.

It's difficult to measure performance improvements overall in applications like image manipulation software or sound wave editors. E.g. if a complex effect processing takes now 2 seconds instead of 4 hours, but all GUI event processing is 100% slower, during the workday the application might only work 10% faster overall. The user spends much more time in the interactive part of the code. From what I've read, bearophile mostly only uses synthetic tests.