Why are most HPC done in Fortran? 
Author Message
 Why are most HPC done in Fortran?

Why are most High performance computing (scientific and enginering) on supercomputers done in
fortran? Apart from the facts that there are better tuned math libraries in Fortran, and many
experienced HPC programmers are Fortran programmers, are there any other reasons for this, such as
the Fortran compilers are easier to write and Fortran programs are easier to optimize?


Wed, 19 Nov 1997 03:00:00 GMT  
 Why are most HPC done in Fortran?

Quote:
>Why are most High performance computing (scientific and enginering) on supercomputers done in
>Fortran? Apart from the facts that there are better tuned math libraries in Fortran, and many
>experienced HPC programmers are Fortran programmers, are there any other reasons for this, such as
>the Fortran compilers are easier to write and Fortran programs are easier to optimize?

Fortran code is easier to optimize.  Optimizations which are legal for
a piece of Fortran code are illegal for the C version of the same code,
because aliasing is kept under control in Fortran but is unrestricted
in C.

Most number crunching is done on matrices and there is no convenient way
to pass a matrix to a C function without taking a huge performance hit.

This might change in the next version of the C standard, but even if it
would happen, people won't start porting their Fortran codes to C (unless
they would be compelled by other reasons).

Dan
--
Dan Pop
CERN, CN Division

Mail:  CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland



Wed, 19 Nov 1997 03:00:00 GMT  
 Why are most HPC done in Fortran?
Some variants of C contain a restricted key word to allow for Fortran like
optimizations.  But you will never get the optimization that Fortran will
allow.  C++ is even worse.  I've seen stats indicating that C++ speeds are
only 65% of C.

--
Kirk Pepperdine
Communication Security Establishment

"You can observe a lot by just watching." - Yogi Berra



Wed, 19 Nov 1997 03:00:00 GMT  
 Why are most HPC done in Fortran?
Doing numerics in Fortran is also a long standing tradition.  Fortran was
intoduced in the 1950s so that engineers and scientists wouldn't have to
program, i.e., wouldn't have to write assembly language.  Fast
computation was very important (computers were slow), so Fortran has been
speed optimized from the beginning.  The language is also simpler to use
than something like C or C++, since Fortran is directed heavily toward
numeric stuff, rather than being able to do everything.  Fortran code
tends to look a lot like equations.

I do see a trend for many young engineers to use C/C++ or Matlab, rather
than Fortran.  That is most likely due to what is being taught.  The
ones who like programming will use C/C++.  The ones who don't like
computers, but just want answers, will use Matlab.  I assume that the
Matlab crowd is taking a performance hit, but not nearly as bad as a few
years ago when spreadsheets were all the rage.

Discussions in this group have proven that there is no definitive answer
as to which is the best computer language.

Ken Plotkin



Wed, 19 Nov 1997 03:00:00 GMT  
 Why are most HPC done in Fortran?

Quote:

>Why are most High performance computing (scientific and enginering) on supercomputers done in
>Fortran? Apart from the facts that there are better tuned math libraries in Fortran, and many
>experienced HPC programmers are Fortran programmers, are there any other reasons for this, such as
>the Fortran compilers are easier to write and Fortran programs are easier to optimize?

I dont want to start a religious war or anything like that, but yes, fortran
compilers have been around longer and are easier (or I should say
better understood) to construct.

That isnt necessarily why people doing HPC still use fortran though.

Apart from I/O operations, fortran allows for very direct expressions of
complex mathematical operations, in the sense that the method used to
describe the necessary steps to the computer are very well defined and do not
change meaning from one program to another.

Also, it is a comfortable and relatively easy to debug language.

Also, due to its long history, optimizers tend to be better for it (be they
scalar optimizers, automatic vectorizers/parallelizers, etc) than for other
languages.

Finally, there are a large number of people who simply dont want to spend
1-6 months learning a new language (like C++) for their work, when the other
language doesnt offer all the speed and ease of use/understanding that
fortran does.

This does not necessarily make fortran a good language, just a popular one,
and it doesnt necessarily make C++ a bad language, just not a common one
for HPC applications.  

note: part of my job is to optimize other peoples codes to run rapidly on our
supercomputers.  When we get a fortran code, we can usually spot the time
consuming steps and adjust them (reordering array indicies to take advantage
of cache lines, loop unrolling and reorg-ing, etc.  When we get a C or C++ code
we have a problem.  You see, in fortran you can usually bet that A(i+1) is
immediately adjacent to A(i), annd thus likely to be on the same (or an
adjacent) cache line.  In C or C++ you do not have the guarantee.  *(A+0),
and *(A+1) not only dont have to be adjacent to each other, there is
frankly no restriction on where they may be in relation to each other.  In HPC
you need to be able to tweak memory reference access patterns to wring more
performance out of the code.  You cant do a credible job with that other
popular programming language without basically removing the major advantage it
has over fortran, mainly, runtime memory allocation of arrays.  That is a
problem, a relatively large one.  Memory bandwidth is a big issue in HPC
codes...  It is not the only one though...

Joe

--
Joe Landman   Systems Engineer                        |
Silicon Graphics, 24155 Drake Rd, Farmington MI 48335 |  {}{}-------{}{}
voice: (810) 615 2169                                 |       \ O /
  fax: (810) 478 3181                                 |        | |

------------------------------------------------------+       /   \
                                                            _|     |_



Thu, 20 Nov 1997 03:00:00 GMT  
 Why are most HPC done in Fortran?

<snip>
|> we have a problem.  You see, in fortran you can usually bet that A(i+1) is
|> immediately adjacent to A(i), annd thus likely to be on the same (or an
|> adjacent) cache line.  In C or C++ you do not have the guarantee.  *(A+0),
|> and *(A+1) not only dont have to be adjacent to each other, there is
|> frankly no restriction on where they may be in relation to each other.  In
HPC

???? I thought *(A+0) was always adjacent to *(A+1) (where adjacent is as
adjacent as can be: there addresses differ by sizeof(*A)). For one-D arrays,
I guess there is no difference. In fact, a parameter declared as a[3][5] is
probably as good as Fortran's A(5,3) and as long as the programmer always
writes a[2][4] (and not *(*(a+2)+4) or some such non-sense), it is as easy to
optimize. the relation between *(a+0) and *(a+1) in this case, is just the
same as that between A(:,1) and A(:,2) in Fortran 90 syntax.

Of course, optimizing some one else's code is always difficult: I tend to
rewrite code written by other people :-) (Or is that :-() It is true that you
can mess up your code in C, but I have worked with someone else's Fortran II
code (with arithmetic ifs all over the place): and I believe even C is
better.

In any case, in my numerical work I use Fortran, and very much for the
same reasons as these posts mentioned (In the following parallel mainly means
data parallel.)

1) Existence of an inbuilt `complex' type which can be used in expressions
   using ordinary arithmetic operators (*, + etc.) without changing them from
   infix to prefix form. C++ allows this (?), but I do not think the
   compilers are smart enough to optimize these constructs specially. (I maybe
   completely off base here: in fact general principles like propagation,
   dead store elimination etc. should give the same optimization.)
   I do not know whether this point was mentioned in this thread before.

2) Fortran usually takes the attitude that whenever something is difficult to
   optimize, it is illegal (e.g. passing two overlapping objects to a
   subprogram and modifying any one or both of them; function calls are
   allowed to be optimized away, _even if_ they have side effects; No
   `statements are executed in sequence' nonsense). C takes
   the attitude that a compiler should handle the general case correctly; and
   optimize when _it_ knows that there is no problem. (This could be fixed by
   pragmas).
   `C is difficult to optimize'

3) Run time dimensioned arrays are not there in standard C. (They exist in
   Fortran at least as the `dummy parameters' of subprograms even before
   Fortran 90). As a result, in standard C, one has to do the index
   calculation by hand; and compilers may not be smart enough to notice that.
   (Many C compilers provide extensions.)
   I do not know whether this point has been mentioned before.

4) Fortran 90, or its subset that I use, treats arrays as first class types:
   making it easier to express many parallel program constructs. (The C
   compiler has extensions to allow this).
   `Fortran has array notation and is better parallelized.'

5) When we started our coding for the current project, the Fortran compiler
   was far better optimized for number crunching. (I do not know whether it
   is still true.)
   `Fortran traditionally had compilers dedicated to number crunching.'

6) Most of my collaborators can probably read C, but _write_ Fortran.
   `Fortran has a historical advantage.'

I prefer C for its strong type-checking (coming from Fortran :-) (e.g.
prototypes checkable against the _definition_ in addition to against the
use), ease of dynamic allocation (malloc), easy control of machine hardware
(e.g. conversion of int to pointer), better modularity (I should really learn
C++ some day, or at least full Fortran 90) (e.g. structs containing pointers
to functions), and better source layout (Free form source in Fortran 90 will
alleviate this problem somewhat). But, when it comes to collaborative number
crunching, I shall stick to Fortran in the near future.

(In fact, I mainly work with the Connection Machines these days, where I
 write the main code in CM Fortran, and fall through to a C like language to
 control the parallel hardwire directly: somewhat like assembly language;
 where Fortran fails to optimize.)

Cheers
Tanmoy
--

Tanmoy Bhattacharya O:T-8(MS B285)LANL,NM87544-0285,USA H:#3,802,9 St,NM87545
Others see <gopher://yaleinfo.yale.edu:7700/00/Internet-People/internet-mail>,
<http://alpha.acast.nova.edu/cgi-bin/inmgq.pl>or<ftp://csd4.csd.uwm.edu/pub/
internetwork-mail-guide>. -- <http://nqcd.lanl.gov/people/tanmoy/tanmoy.html>
fax: 1 (505) 665 3003   voice: 1 (505) 665 4733    [ Home: 1 (505) 662 5596 ]



Thu, 20 Nov 1997 03:00:00 GMT  
 Why are most HPC done in Fortran?

Quote:

> Why are most High performance computing (scientific and enginering) on supercomputers done in
> Fortran? Apart from the facts that there are better tuned math libraries in Fortran, and many
> experienced HPC programmers are Fortran programmers, are there any other reasons for this, such as
> the Fortran compilers are easier to write and Fortran programs are easier to optimize?

  1) Classical: Many of these scientific codes have been
     around a long time. Why rewrite 50K lines of fortran in
     language X without a VERY good reason?

  2) Contemporary: Array syntax operations in f77 extentions,
     f90 and hpf are consistant between HPC platforms, so
     vector or massively parallel architectures can efficiently
     process fortran code that is highly portable between
     systems. Currently this is not true of C. The CM-5 uses
     C*, Maspar has MPL, and those are the only array syntax/
     data parallel C derivitives I know of, are there others?
     I have heard indirectly about High Performance C in the
     works, but I have not seen it available on any HPC
     platforms that I am familiar with.

       The advantage of this is that we use a numerically intense
     scientific code that with minimal changes, for system calls
     and such, runs efficiently on vector, shared memory multi-
     processors, distributed and data parallel massively parallel
     systems, as well as work station platforms. It probably wont
     be long before other languages can make this claim, but we
     were not willing to wait.

Regards,

Tom



Thu, 20 Nov 1997 03:00:00 GMT  
 Why are most HPC done in Fortran?


:>Why are most High performance computing (scientific and enginering)
:>on supercomputers done in Fortran? Apart from the facts that there
:>are better tuned math libraries in Fortran, and many experienced
:>HPC programmers are Fortran programmers, are there any other reasons
:>for this, such as the Fortran compilers are easier to write and
:>Fortran programs are easier to optimize?
:
:I dont want to start a religious war or anything like that, but yes, fortran
:compilers have been around longer and are easier (or I should say
:better understood) to construct.
:
:That isnt necessarily why people doing HPC still use fortran though.
:
:Apart from I/O operations, fortran allows for very direct expressions of
:complex mathematical operations, in the sense that the method used to
:describe the necessary steps to the computer are very well defined and do not
:change meaning from one program to another.

The prime examples, of course, being the existence of a complex
datatype and the lack of exponentiation operator in C.  C++ has a
chance here as you can define a nice complex class and overload ^,
but we'll have to wait for C++ compilers to overcome the optimization
limitations of dealing with a non-basic type.

:Also, it is a comfortable and relatively easy to debug language.

I'd strongly disagree here, but I'll drop that as a matter of opinion :)

:Also, due to its long history, optimizers tend to be better for it (be they
:scalar optimizers, automatic vectorizers/parallelizers, etc) than for other
:languages.
:
:Finally, there are a large number of people who simply dont want to spend
:1-6 months learning a new language (like C++) for their work, when the other
:language doesnt offer all the speed and ease of use/understanding that
:fortran does.

This is partly true.  If you think about it, C is a hideously hard
language to learn, despite it's power (remember, we are assuming
you're coming from a language where you haven't even learned what a
pointer is yet.  Learning C is easier if you already know a more
advance language like Modula 2 or Pascal.)  C++ again has a chance
here since C++ code is easier to maintain.

:This does not necessarily make fortran a good language, just a popular one,
:and it doesnt necessarily make C++ a bad language, just not a common one
:for HPC applications.  
:
:note: part of my job is to optimize other peoples codes to run rapidly on our
:supercomputers.  When we get a fortran code, we can usually spot the time
:consuming steps and adjust them (reordering array indicies to take advantage
:of cache lines, loop unrolling and reorg-ing, etc.  When we get a C or C++ code
:we have a problem.  You see, in fortran you can usually bet that A(i+1) is
:immediately adjacent to A(i), annd thus likely to be on the same (or an
:adjacent) cache line.  In C or C++ you do not have the guarantee.  *(A+0),
:and *(A+1) not only dont have to be adjacent to each other, there is
:frankly no restriction on where they may be in relation to each other.  In HPC
:you need to be able to tweak memory reference access patterns to wring more
:performance out of the code.  You cant do a credible job with that other
:popular programming language without basically removing the major advantage it
:has over fortran, mainly, runtime memory allocation of arrays.  That is a
:problem, a relatively large one.  Memory bandwidth is a big issue in HPC
:codes...  It is not the only one though...

--
---
Tim Hollebeek                   'There will be a better sig when I have time'



Thu, 20 Nov 1997 03:00:00 GMT  
 Why are most HPC done in Fortran?

|> Why are most High performance computing (scientific and enginering) on supercomputers done in
|> Fortran?
|> the Fortran compilers are easier to write and Fortran programs are easier to optimize?

   Or Fortran programs are easier to read (and write :-) )

--
----------------------------------------------------------------------------
       A member of  G.ASS : Group for Astronomical Software Support          
----------------------------------------------------------------------------
Lucio Chiappetti - IFCTR/CNR     | Ma te' vugl' da' quost avis a ti' Orsign  
via Bassini 15 - I-20133 Milano  | Buttet rabios intant te se' pisnign      

Decnet:   IFCTR::LUCIO           |             (Rabisch, II 46, 119-120)    
----------------------------------------------------------------------------



Fri, 21 Nov 1997 03:00:00 GMT  
 Why are most HPC done in Fortran?

Quote:


>>Why are most High performance computing (scientific and enginering) on supercomputers done in
>>Fortran? Apart from the facts that there are better tuned math libraries in Fortran, and many
>>experienced HPC programmers are Fortran programmers, are there any other reasons for this, such as
>>the Fortran compilers are easier to write and Fortran programs are easier to optimize?

>note: part of my job is to optimize other peoples codes to run rapidly on our
>supercomputers.  When we get a fortran code, we can usually spot the time
>consuming steps and adjust them (reordering array indicies to take advantage
>of cache lines, loop unrolling and reorg-ing, etc.  When we get a C or C++ code
>we have a problem.  You see, in fortran you can usually bet that A(i+1) is
>immediately adjacent to A(i), annd thus likely to be on the same (or an
>adjacent) cache line.  In C or C++ you do not have the guarantee.  *(A+0),
>and *(A+1) not only dont have to be adjacent to each other, there is
>frankly no restriction on where they may be in relation to each other.  In HPC

Hmm ... I think this is a bad example.  Any good C++ programmer would use a
container class (matrix, vector, tensor ....) to represent thier data.
If you find a container implementation is inefficient on your particular
architecture just tweek the implementation of the container.  In fortran
such changes always have huge dispersion, i.e. you have make changes
throughout ALL of the client code.
        In good C++ code any changes you make to optimize should have very
low dispersion.  Unless you end up changing interfaces.
        Of you course, if you receive spagetti code in any langauge, it will
be difficult to optimize.

--
 +--------------------------------------+-------------------------------------+
 | Jan N. Reimers,  Research Scientist  | Sorry, Don't have time to write the |
 | Moli Energy (1990) Ltd. B.C. Canada  | usual clever stuff in this spot.    |



Fri, 21 Nov 1997 03:00:00 GMT  
 Why are most HPC done in Fortran?
I do agree that historical reasons are the most important ones to explain
FORTRAN success in HPC.

However, the effort and economical/human resources put in improvement is,
by far, bigger in C than in FORTRAN.

I work in numerical analysis in a mixed C/FORTRAN environment and I can
wittness a curious test case.

On an HP 735/HPUX 9.05, taking the __same__ subroutine with the __same__
data (an ILU(0) factorization of a __very__ big sparse matrix) with the
strongest compiler optimization, C code performed about 30% faster than
FORTRAN code.

This is __NOT__ a proof of anything, but I think that superior performance
of FORTRAN is a 'commonplace' that some years ago was valid, but no longer...

On the other side there are cases where C is, by its own nature, much faster
than FORTRAN, i.e. swapping the rows of a matrix, bitwise operators, structs,
pointers, dynamic memory allocation, etc.

We cannot forget that the search of optimal algorithms is done according
to the language possibilities, when you code in FORTRAN, you 'restrict'
yourself to the 'normal' features of the language, in C you have
much more liberty so you can devise algorithms wich FORTRAN implementation
would be problematic or, at least, bizarre.

In Numerical Analysis (FEM) you normally face 'sparse' matrices (matrices
with a very high number of null entries), the traditional treatment
in FORTRAN of this kind of matrices is clumsy and full of problems,
the C treatment seems, by far, much more natural.

Last but not least, the standarization in C is much more strict than
in FORTRAN, if you change your platform you may have to review all
your FORTRAN code because it no longer works with new compilers and/or
hardware.

Anyway, I think that there is not such a thing as the __BEST__ language
all them are useful depending on the problem, environment, etc. so
making a point on the 'virtues' of a language over another one seems
to me a waste of time.

Traditionally, C has been the language of Computer Sciences while FORTRAN
was the one used in Engeneering, I think that a good interchange would be
good for both fields...

Manuel J. Galan



Sat, 22 Nov 1997 03:00:00 GMT  
 Why are most HPC done in Fortran?

Quote:

>>note: part of my job is to optimize other peoples codes to run rapidly on our
>>supercomputers.  When we get a fortran code, we can usually spot the time
>>consuming steps and adjust them (reordering array indicies to take advantage
>>of cache lines, loop unrolling and reorg-ing, etc.  When we get a C or C++ code
>>we have a problem.  You see, in fortran you can usually bet that A(i+1) is
>>immediately adjacent to A(i), annd thus likely to be on the same (or an
>>adjacent) cache line.  In C or C++ you do not have the guarantee.  *(A+0),
>>and *(A+1) not only dont have to be adjacent to each other, there is
>>frankly no restriction on where they may be in relation to each other.  In HPC
>Hmm ... I think this is a bad example.  Any good C++ programmer would use a
>container class (matrix, vector, tensor ....) to represent thier data.
>If you find a container implementation is inefficient on your particular
>architecture just tweek the implementation of the container.  In fortran
>such changes always have huge dispersion, i.e. you have make changes

 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^---NOT TRUE!
Quote:
>throughout ALL of the client code.

 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Quote:
>    In good C++ code any changes you make to optimize should have very
>low dispersion.  Unless you end up changing interfaces.
>    Of you course, if you receive spagetti code in any langauge, it will
>be difficult to optimize.

    This is NO LONGER true, IF you use MODULEs.   Fortran 90 has FULL
support for modules and interface blocks.  Therefore, IF the programmer
takes advantage of these capabilities, changing Fortran code should be no
harder than in a comparable C++ case.  Probably easier, since Fortran is
easeier to read and write.

    Please don't give me anything of the nature of "But I was talking about
FORTRAN 77, not Fortran 90."  Fortran 90 is the ONLY recognized
International Standard.  F77 is still an archival American (i.e. ANSI)
standard but even in the USA, it is on the way OUT.  In March 1994, X3J3
voted by 21-6 to recommend to ANSI that the F77 standard be withdrawn.

Sincerely,
--

Elmbrook Computer Services      Voice Phone: (414) 783-5869
17130 W. Burleigh Place        
Brookfield, WI   53005          Disclaimer:  These opinions are mine alone.
USA                             They do NOT represent any organization.

"Those who would give up essential Liberty, to purchase a little temporary
    Safety, deserve neither Liberty nor Safety."    -- Benjamin Franklin



Sat, 22 Nov 1997 03:00:00 GMT  
 Why are most HPC done in Fortran?

Quote:
>    This is NO LONGER true, IF you use MODULEs.   Fortran 90 has FULL
>support for modules and interface blocks.  Therefore, IF the programmer
>takes advantage of these capabilities, changing Fortran code should be no
>harder than in a comparable C++ case.  Probably easier, since Fortran is
>easeier to read and write.                              ^^^^^^^^^^^^^^^^

 ^^^^^^^^^^^^^^^^^^^^^^^^^^
This is only your, _very_ personal, opinion.

Dan
--
Dan Pop
CERN, CN Division

Mail:  CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland



Sat, 22 Nov 1997 03:00:00 GMT  
 Why are most HPC done in Fortran?
Manuel:

Note that for the tasks of interest to you, most of the clumsiness that you
attribute to FORTRAN (77) has been fixed in Fortran (90).



Sat, 22 Nov 1997 03:00:00 GMT  
 Why are most HPC done in Fortran?

Quote:
>>we have a problem.  You see, in fortran you can usually bet that A(i+1) is
>>immediately adjacent to A(i), annd thus likely to be on the same (or an
>>adjacent) cache line.  In C or C++ you do not have the guarantee.  *(A+0),
>>and *(A+1) not only dont have to be adjacent to each other, there is
>>frankly no restriction on where they may be in relation to each other.  In HPC

>Hmm ... I think this is a bad example.  Any good C++ programmer would use a
>container class (matrix, vector, tensor ....) to represent thier data.
>If you find a container implementation is inefficient on your particular
>architecture just tweek the implementation of the container.  In fortran
>such changes always have huge dispersion, i.e. you have make changes
>throughout ALL of the client code.
>    In good C++ code any changes you make to optimize should have very
>low dispersion.  Unless you end up changing interfaces.
>    Of you course, if you receive spagetti code in any langauge, it will
>be difficult to optimize.

Actually, this is a good example.  Right now, if you code in C++ on a
super computer platform, you can expect to see performace at 65-70% of code
written in C.  Performace in Fortran is typically better than in C.  This is
due to optimization assumptions a compiler writter can make in a Fortran
that you cannot make with C. Cray uses #pragma's, compiler options and key
words such as restricted to assist the optimzer in dealing with pointers in
C code.  It is a safe bet to say performance will get better as people
learn how to write optimizers for C++.

Most of the coders I've seen working on super computer platforms are
exceptional programmer who write their code with the optimizations in
mind right up front. To make this work, they must use structured approches
to coding their applications.  I've seen very little spagetti code.  It
dosn't optimize very well.

--
Kirk Pepperdine
Communication Security Establishment

"You can observe a lot by just watching." - Yogi Berra



Sat, 22 Nov 1997 03:00:00 GMT  
 
 [ 25 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Why are most HPC done

2. Why are most HPC done

3. Why are most HPC don

4. Fortran in HPC

5. What am I doing wrong!

6. What am I doing wrong?

7. Stupid newb question: What am I doing wrong?

8. What am I doing Wrong

9. what am i doing wrong

10. Help - What am I doing wrong

11. Saving a Variable to a field in a record- what am i doing wrong

12. What am I doing wrong?

 

 
Powered by phpBB® Forum Software