darwin may lose primary target status on FSF gcc

[Jack Howarth]

On Sat, Sep 19, 2009 at 09:01:42AM +0200, vincent habchi wrote:
> Jack,
>
>> http://www.nabble.com/x86_64-apple-darwin-Polyhedron-2005-benchmarks-td25108861.html
>
> 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  
> Mac?

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

http://gcc.gnu.org/wiki/GFortran#news

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

http://gcc.gnu.org/wiki/Fortran2003

> 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?
               Jack
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
different approach..

http://llvm.org/docs/LinkTimeOptimization.html
http://www.mail-archive.com/gcc@gcc.gnu.org/msg12816.html

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
progressed significantly.

>
> Vincent