darwin may lose primary target status on FSF gcc
howarth at bromo.med.uc.edu
Sat Sep 19 10:05:05 PDT 2009
On Sat, Sep 19, 2009 at 09:01:42AM +0200, vincent habchi wrote:
> These figures are very interesting, but I don't understand why they lack
> the gcc 4.2.4 -m64 performance; was that unavailable at that time? I
> would be also curious to see the relative performance of the two
> compilers on C-based scientific benchmarks (like BLAS or gsl or
> whatever). I know that because of aliasing, C compilers cannot optimize
> as much as Fortran ones do, but that may be at least partly solved by
> using the new C99 syntax.
Aren't those showing up for you? At the bottom of that url link is another
message with more complete benchmarks for...
benchmark gcc-4.2.4 gcc-4.2.4 llvm-gcc-svn llvm-gcc-2.6 llvm-gcc-2.6 gcc-4.4.1 gcc-4.4.1
at -m32 at -m64 20081031 -m32 at -m32 at -m64 at -m32 at -m64
..that I ran later.
> It also raises other questions:
> 1. Could we compare those figures with the ones obtained with a
> "professional" compiler like, e.g. the Intel C/Fortran compilers for
I don't have any of the professional compilers myself on the Mac (hence
my obession with keeping gfortran healthy). However I would argue that the
results from http://users.physik.fu-berlin.de/~tburnus/gcc-trunk/benchmark/
give a pretty accurate idea of how gfortran rates compared to the other
commercial compilers. The only caveat is that those are for AMD chipsets.
> 2. What are the relative possibilities of progression of GCC and LLVM? I
> mean, maybe LLVM is lagging these days, but if the intermediate code
> representation it uses is potentially more powerful that the one chosen
> for GCC (as it is publicized), it might be just a matter of months before
> the results get close to a draw.
The focus in llvm is really on clang these days. There also are Link
Time Optimizations available at -O4 for both llvm-gcc-4.2 and clang
but you have to link with the cctools in /Developer/usr/bin and not
those in /usr/bin (at least for Leopard) to obtain that. Last I looked
the optimizations centered around dead-code elimination but the LTO
is being expanded. Do keep in mind that clang really doesn't have a
usable c++ compiler yet so as you can imagine that is where their focus is
for development (not fortran).
> 3. What is the place of Fortran in modern scientific computing compared
> to C-based languages? More specifically, in the scientific packages
> available in MacPorts like, e.g. SparseSuite, what part of the Fortran
> code is actively under development and what part is only legacy code?
Well, in NMR we still have a number of packages (like xplor-nih) which
require a fortran compiler. Legacy code isn't going to disappear. That
said, gfortran is constantly adapting to the latest standards...
Also I would argue that the availablity of a free high quality compiler
that supports the latest standards alone can be a big driver of what
how things get written. FYI, this link shows how much for the fortran
2003 support is implemented...
> 4. What is the place of Open-CL? Of course, Open-CL is brand new, but
> with its capacities to unleashed massive parallel computing power, it
> could represent an awesome tool for matrix operations. Yet, I understand
> that due to the overhead of moving data to and fro the video RAM, Open-CL
> is inefficient for small matrix sizes; but that's also simply where
> optimization of CPU code is not really significant either.
I haven't had a chance to look into OpenCL yet. Frankly, I am mainly
concerned that our current tool suite remains functional so folks don't
feel the need to resort to linux for scientific computing. If we do
lost access to a solid gfortran at any point that could become a issue.
It is easy to say just port it all to c/c++ but who has the resources
and the time for that?
ps As I see, the biggest challenges facing FSF gcc on darwin is
1) adapting to the fact that darwin 10 and later have subsumed
libgcc 4.2.1 into libSystem and 2) surviving the LTO merge intact.
We won't ever use the LTO in gcc because Apple is taking an entirely
Needless to say, FSF gcc decided to go with an approach different
from llvm's, I think in part because their own LTO project had already
More information about the macports-dev