llvm dev - Jun 2009 - [LLVMdev] Some understanding of LLVM vs gCC vs Intel C++ Compilers

Are there any papers in the works which benchmark some specification suite
of C programs on GCC, LLVM-GCC, and CLANG?
The only stuff I have seen so far are some bar charts in a few LLVM
presentations, would be nice to have something a little more comprehensive.

Cheers,

Granville

On Tue, Jun 16, 2009 at 6:51 AM, Jon Harrop <jon at ffconsultancy.com>
wrote:
> On Tuesday 16 June 2009 00:43:58 David Greene wrote:
> > But hey, we use LLVM to do it!
>
> Hello David,
>
> I just noticed your post and was wondering what Cray are doing with LLVM?
> Are
> you using it in production?
>
> I am trying to keep an eye on the fast moving LLVM project and like to keep
> up
> to date with respect to its industrial applications...
>
> --
> Dr Jon Harrop, Flying Frog Consultancy Ltd.
> http://www.ffconsultancy.com/?e
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20090616/1a803d3f/attachment.html>

Trying to capture a notion of overall compiler optimization
in a representative set of benchmarks is a hard problem.
If you're interested in performance, it's best to measure it
on the applications you're interested in.

You should be suspicious of any one-dimensional analysis
of compiler optimization, especially if it's presented by
someone with an interest in a particular compiler.

Dan

On Jun 16, 2009, at 5:59 AM, Granville Barnett wrote:
> Are there any papers in the works which benchmark some specification  
> suite of C programs on GCC, LLVM-GCC, and CLANG?
>
> The only stuff I have seen so far are some bar charts in a few LLVM  
> presentations, would be nice to have something a little more  
> comprehensive.
>
> Cheers,
>
> Granville
>
> On Tue, Jun 16, 2009 at 6:51 AM, Jon Harrop <jon at
ffconsultancy.com>
> wrote:
> On Tuesday 16 June 2009 00:43:58 David Greene wrote:
> > But hey, we use LLVM to do it!
>
> Hello David,
>
> I just noticed your post and was wondering what Cray are doing with  
> LLVM? Are
> you using it in production?
>
> I am trying to keep an eye on the fast moving LLVM project and like  
> to keep up
> to date with respect to its industrial applications...
>
> --
> Dr Jon Harrop, Flying Frog Consultancy Ltd.
> http://www.ffconsultancy.com/?e
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

On Tuesday 16 June 2009 09:49, Dan Gohman wrote:
> Trying to capture a notion of overall compiler optimization
> in a representative set of benchmarks is a hard problem.
> If you're interested in performance, it's best to measure it
> on the applications you're interested in.
>
> You should be suspicious of any one-dimensional analysis
> of compiler optimization, especially if it's presented by
> someone with an interest in a particular compiler.
That's exactly right.

I have seen codes where even minor tweaks to a register allocation spilling 
heuristic can have a 10-20% performance impact on X86.  Compiler 
transformations are often very sensitive to particular pieaces of code.

It's impossible to declare one compiler "better" than another
because it's
likely the design goals of the compilers are quite different.

The great advantage of LLVM/Clang, in my mind, is its clean design and
relatively shallow learning curve.  It's not only a smart business decision
to use the code because of its utilitarian value, it's smart from an
employee training perspective as well.

All IMHO, nothing I say here is an official Cray position, blah, blah, 
blah.  :)

                             -Dave