On 06/19/2011 06:04 PM, "C. Bergström" wrote:
3) Fortran HPC community as a whole - The majority of Fortran users I
know work in or around HPC. (I may be biased) With that I can't say
most of them care about open source at all. (Some do) They buy/use
PathScale/PGI/Intel and for the larger labs I'm not sure if they use
gfortran.
I think you are biased that most Fortran users work around HPC. They
mostly do work in natural science; thus, the kind of programs which run
on HPC machines. But there are many users which have programs fast
enough to run them on a laptop or work station in serial mode. However,
a large minority of those programs also runs in parallel and thus on
multi-cores, small clusters up to the HPC machines. While for HPC sites
and larger institutions the compiler costs are negligible, for a smaller
university group or for the laptop/computer at home, it matters - and
gfortran fills the gap. That's also what I hear from vendors: The
availability of gfortran - other free Fortran compilers do not seem to
play a role (any more) - improves their sales.
For HPC sites themselves: All sites I know run Linux have have besides
one - or several - vendor compilers also GCC/gfortran installed - and
support it. Also some HPC vendors give support to their customers for
GCC/gfortran. The reason for having a backup compiler is on one hand
that code might not work with the vendor compiler (esp. in case of
C/C++) but also if the vendor compiler has a bug. (Someone told me that
gfortran saved a PhD thesis by being a replacement for a vendor compiler
- with being only minutely slower. The vendor compiler was fixed
eventually, but it took several months.)
My impression from both HPC sites, from users and other vendors is: All
HPC sites have GCC/gfortran installed and use it as additional compiler
besides the vendor/commercial compiler(s). Additionally, it is very
common to have a commercial compiler at work - and use gfortran at
home/on the laptop. Thus, many institutions require that their code also
runs with gfortran - even though their main work horse is a commercial
compiler. [Personal observation: On x86-64, gfortran is everywhere
installed, the Intel compiler is very often, on two systems I also saw
PGI - but I have never seen PathScale.]
I also do not agree about the statement that they do not care about Open
Source. I know several places (large institutions like weather services
or small projects) where the availability of a free (mostly: Open
Source) compiler is a requirement and features not supported by gfortran
my not be included. Thus, gfortran seems to be rather known among users
and in the lower management. I heard also of some aviation company which
considered to use gfortran because it was the only compiler supporting
all their platforms. On the other hand, there are places where only some
commercial compiler will do because the management does not trust
free/OpenSource software. (They still often have GCC installed
additionally.)
Most of them want their code to compile, get best performance and
sometimes use F2K3. You're not going to stop them from buying
commercially supported compilers.
First, one can also buy support for GCC and thus gfortran: Either
directly via support contracts or indirectly via buying an enterprise
Linux distribution. But having a commercial compiler does not rule out
having an Open Source compiler; similarly, producing a commercial
compiler does not stop companies of also supporting GCC - be it by bug
reports, support to customers or directly contribution to the
development of GCC. I also use all kinds of compiler: Having multiple
compilers helps to find bugs in the code; independent of performance, it
is convenient to use the default compiler on a given system - which
might be gfortran at home and some commercial compiler at work/HPC centers.
However, I do not buy the F2003 and performance argument. gfortran is
not really lagging behind Fortran 2003/2008. The number of compilers
which are further is quite low and they are also not years ahead.
(Though, having a more complete implementation is wished by everyone:
Users, compiler developers and also other vendors [at least if they
support that feature already].)
And with regards to performance, I think GCC is seriously underrated.
One reason might be that the default settings are rather on the safe
than on the performance side. If I look at benchmarks - such as at the
one at Polyhedron (http://www.polyhedron.com/compare0html) I do not see
a drastic difference (~25% slower than the fastest compiler for the
geometric means) - and the site compares an old version of gfortran
against the latest commercial compilers.
In my test, GCC 4.7 -Ofast -march=native -funroll-loops
-finline-limit=600 is on average 3 to 16% *faster* than the other
known-to-be-fast compilers I tested. [1] The variance is large and can
easily reach a factor 2 for single benchmarks. Experience shows that it
also can strongly depend on the math library. For instance, FSF GLIBC
seems to be slow on x86-64 for many single-precision math operations
(double precision is fine). Using a different math library, I can gain
another 5% performance (8 to 21% faster than the other compilers). Note:
Also my numbers are not completely fair as I have not tested the newest
version of other compilers and possibly some settings could be improved
(both for GCC and for the other compilers). However, those numbers do
not seem to indicate that other compilers are - on average -
significantly faster. Having a, e.g., 6% faster run time usually does
not really matter.
(https://users.physik.fu-berlin.de/~tburnus/gcc-trunk/benchmark/iff/#rt)
I think there are many reasons to buy a commercial compiler; better
diagnostic, better performance, or just different diagnostics and
different bugs are good reasons. But expecting a significant performance
gain by blindly buying a commercial compiler is doomed to fail. Either
one should not expect a big gain - or one should run performance tests
with the actual program.
In this case I serve the end user/community and not directly open
source. Why? Would it be good for Fortran if a F2K3 front-end was
freely available under a commercially friendly license? (This is a
deeper question I'd love feedback on)
a. I see people moving away from Fortran and more towards C++.
(Sorry no empirical data to back this, but how do we stop this trend)
Me too, though I think the main reason is that they simply do not know
any Fortran after FORTRAN 77 (written in a Fortran 66 style and without
indention). Hence, they think that Fortran is obsolete. That seems to be
in particular a problem for people who studied computer science. The
other reason is that the appearance of Fortran 90 compilers (commercial
but in particular free/opensource) was slow and F2003 implementation
takes also long (no difference between commercial and open source).
Admittedly, I do not see a difference between the status quo and your
proposal (F2003 front end under a commercially friendly license):
gfortran and also Intel's compiler are widely used from laptops and
desktops under Linux/Windows/MacOS to HPC systems. Those and the
HPC-specific IBM xlf and Cray ftn compilers support a large chunk of
Fortran 2003. I do not see either of these vendors changing their front
end. Also NAG (known for the diagnostic) and PGI have a substantial part
of Fortran 2003 implemented. While I would like to see a more complete
implementation of Fortran 2003 and 2008 in all listed compilers and also
a catching up of other compilers, I do not think that having a new
commercially licence-friendly front end will make much of a difference
in practice. Though I might be proven wrong.
b. People are trying to write books on F2K3, but what compiler can
they even base their book on?
None. At least until recently, I have not seen any full, sufficiently
bug-free Fortran 2003 compiler. Nowadays, the number of supported
features is quite large and usable, but not yet complete. On the other
hand, when book authors start writing about a new standard immediately
after it has been released, it is not surprising that not all features
work. I think that also not really a problem.
Additionally, it is also not restricted to Fortran. C99 has/had also the
problem of getting implemented and C++0x (or should it be now C++1x?)
will also only show a slow adoption and implementation.
c. Would there be any positive impact if every major vendor had
the same front-end as gfortran and implemented the latest standard?
(or even worse sent patches)
First part: Maybe. Having the same front-end is a double-edged sword: If
one compiler has a bug, the other compilers have the same bug - unless,
the vendors do not contribute back, which makes the advantage of having
initially the same front end mute. However, I find it unlikely that many
vendors would switch the front end. Either the lag behind so much that
they are essentially out of business - also swapping a front end costs
many months of integration work, or they have a nicely working front end
such that changing it wouldn't gain anything but introducing new bugs
(even if it fixes old bugs). Thus, I would assume the number of vendors
switching will be rather low.
Submitting (integrable) patches is of course positive. Also testing
gfortran or sharing bug reports is useful (the two latter also works
when using a different front end).
d. Would there be any negative impact to gfortran if PGI/Intel
took the front-end? (Or even worse PathScale *gasp*)
I think by itself not. As written, I doubt that PGI or Intel would do
this - contrary to PathScale. There is of course the issue of the
licence (for instance staying with the FSF licence or relicensing
contributions *also* under a more "commercially friendly" licence). I
have difficulties to assess the effect - especially in the mid and long
term. How will it effect the contribution to GCC - will it increase or
decrease in the long run?
Thus, any contribution to the FSF GCC is highly welcome, commercial
products in general but also commercial products based on GCC are
perfectly acceptable (even more so if the users/companies contributed
back). While with regards to licence issues, the effect is nontrivial to
assess. Having a better support for Fortran 2008 in any
commercial/noncommercial compiler definitely helps the language and also
every user (by giving them more choices between compilers and language
[features]).
Tobias
