what's the plan for mac os x lion

[Jack Howarth]

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