On Mon, Jul 04, 2011 at 08:27:27PM -0400, Jack Howarth wrote:
> On Mon, Jul 04, 2011 at 04:48:24PM -0700, Jeremy Huddleston wrote:
> >
> > On Jul 4, 2011, at 14:04, Jack Howarth wrote:
> >
> > > On Mon, Jul 04, 2011 at 01:29:31PM -0700, Blair Zajac wrote:
> > >>
> > >> On Jul 4, 2011, at 11:30 AM, Jack Howarth wrote:
> > >>
> > >>> On Mon, Jul 04, 2011 at 11:16:48AM -0700, Blair Zajac wrote:
> > >>>> On Jul 4, 2011, at 11:14 AM, Jeremy Huddleston wrote:
> > >>>>>
> > >>>>> All of the ports that are in my install-set (including many
> > >>>>> multimedia
> > >>>>> ports, x11, firefox, gnome, with most bloat variants set) have been
> > >>>>> working with trunk/base using llvm-gcc-4.2 on SL and Lion for a while
> > >>>>> now (trunk/base now chooses the compiler based on devtools version
> > >>>>> rather than os version). I'm still holding on to a couple
> > >>>>> NDA-squimish
> > >>>>> patches in leaf projects that I'll push after the actual release, but
> > >>>>> it mostly works out of the box.
> > >>>>>
> > >>>>> If you are uncertain if filing your bug would violate your NDA,
> > >>>>> please
> > >>>>> feel free to email me directly.
> > >>>>
> > >>>> Out of curiosity, Apple hasn't bumped to a newer gcc version? Does
> > >>>> anybody know why? Did they stick with 4.2 for compatibility for
> > >>>> libstdc++?
> > >>>>
> > >>>> Blair
> > >>>
> > >>> If Apple had access to clang in its current state at the start of
> > >>> Lion's
> > >>> development, I'm sure we would have had clang as the default compiler
> > >>> but
> > >>> alas they have no time machines. FYI, I rewrote fink to implement a
> > >>> prefix-path-clang
> > >>> that defaults fink to use clang for cc/gcc and clang++ for cxx/g++ as
> > >>> the default
> > >>> compilers for package builds under 10.7. So far we have had few
> > >>> problems with using
> > >>> clang as the default compiler under fink 10.7. The FreeBSD folks have
> > >>> been
> > >>> building with clang for awhile now...
> > >>>
> > >>> http://wiki.freebsd.org/BuildingFreeBSDWithClang
> > >>> http://wiki.freebsd.org/PortsAndClang
> > >>> http://rainbow-runner.nl/clang/patches/
> > >>>
> > >>> and is another resource for clang specific patches.
> > >>> Jack
> > >>
> > >> Thanks Jack.
> > >>
> > >> How's the performance of clang versus gcc 4.2?
> > >
> > > A quick and dirty benchmark with himenoBMTxpa.c at -O3 -ffast-math
> > > shows...
> > >
> > > Apple gcc-4.2 MFLOPS measured : 171.335360
> > > Apple clang MFLOPS measured : 186.050091
> > > clang svn MFLOPS measured : 230.703334
> > > FSF gcc 4.6.1 MFLOPS measured : 249.262880
> > > FSF gcc 4.7svn MFLOPS measured : 255.698154
> > >
I should also have added the results from dragonegg svn with llvm svn (current)
using
FSF gcc 4.6.1 and -O3 -ffast-math -fplugin-arg-dragonegg-enable-gcc-optzns
-fplugin-arg-dragonegg-llvm-ir-optimize=2 ...
MFLOPS measured : 268.211617
which shows exactly what llvm is capable of when fed the proper gimple from the
frontend.
Jack
> > > Hopefully by the time clang becomes the system compiler, clang/llvm will
> > > have caught up
> > > with FSF gcc in terms of vectorization support.
> > > Jack
> >
> > What are your "Apple clang" and "clang svn" versions? Be sure to report
> > version numbers since Apple has shipped multiple versions of clang and
> > "svn" doesn't say which branch nor revision you are using. I'm also
> > curious how llvm-gcc stacks up
> >
>
> Apple clang version 1.7 (tags/Apple/clang-77) (based on LLVM 2.9svn)
> Target: x86_64-apple-darwin10
> Thread model: posix
>
> clang version 3.0 (trunk)
> Target: x86_64-apple-darwin10
> Thread model: posix
> (r134377)
>
> Apple's clang have always performed less than expected in benchmarks compared
> to the current clang/llvm svn
> as I suspect the optimizations are more conservative than upstream. This is
> why dragonegg is so interesting
> in that it allows us to test the same gimple used by FSF gcc with the current
> llvm backend...
>
> http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-June/040589.html
>
> Once http://llvm.org/bugs/show_bug.cgi?id=2314 is fixed in llvm svn, we will
> see significant
> improvements (at least for dragonegg with
> -fplugin-arg-dragonegg-enable-gcc-optzns).
>
> > Also, make sure you're not reporting statistics from unreleased products
> > (XCode 4.1 and XCode 4.2 developer previews) as that would violate your NDA.
> >
> > Benchmarks are usually not reflective of "real world" computing, but it's
> > nice to see that even in this contrived example, clang svn is about 35%
> > faster than gcc-4.2.
>
> While it may be true that the difference between gcc and clang isn't as
> significant at -O2 or -Os, it is
> a bit of a cop out to claim these measurements are not relavent to real world
> applications (for at least
> scientific computational use anyway) at -O3 -ffast-math.
> Jack
>
> >
> > --Jeremy
> _______________________________________________
> macports-dev mailing list
> [email protected]
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
