Why are most HPC done in Fortran?
Jianlin Chang
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?
Dan Pop
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
Email: Dan...@mail.cern.ch
Mail: CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland
Kirk Pepperdine
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
email: kpep...@cse.dnd.ca
"You can observe a lot by just watching." - Yogi Berra
Kenneth Plotkin
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
Joe Landman
>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 | | |
email: lan...@detroit.sgi.com | ---
------------------------------------------------------+ / \
_| |_
Tanmoy Bhattacharya
<lan...@detroit.sgi.com> writes:
<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
--
tan...@qcd.lanl.gov(128.165.23.46) DECNET: BETA::"tan...@lanl.gov"(1.218=1242)
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 ]
Tom Head
> 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
Tim Hollebeek
Joe Landman <lan...@detroit.sgi.com> wrote:
:cha...@Jeff-Lab.QueensU.CA (Jianlin Chang) wrote:
:>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'
Lucio Chiappetti
|> Why are most High performance computing (scientific and enginering) on supercomputers done in
|> Fortran?
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
Internet: LU...@IFCTR.MI.CNR.IT |
Decnet: IFCTR::LUCIO | (Rabisch, II 46, 119-120)
----------------------------------------------------------------------------
Jan Reimers
>cha...@Jeff-Lab.QueensU.CA (Jianlin Chang) wrote:
>>Why are most High performance computing (scientific and enginering) on supercomputers done in
>>experienced HPC programmers are Fortran programmers, are there any other reasons for this, such as
>
>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. |
| ja...@molienergy.bc.ca | |
Manuel Galan Moreno
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
Craig Dedo
>In article <3qsf13$2...@murrow.corp.sgi.com> Joe Landman <lan...@detroit.sgi.com> writes:
>>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!
>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.
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,
--
Craig T. Dedo Internet: Craig...@mixcom.com
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
Dan Pop
> 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.
WIlliam B. Clodius
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).
Kirk Pepperdine
>>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
>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.
Rodney James
> 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.
I don't think everyone would agree with your assertion that (full) Fortran (90),
in all its verbosity, is necessarily easier to read and write than C++ or C.
--
-Rodney James (rod...@oce.orst.edu)
Jens Bloch Helmers
Could you give us some explanations?
Fortran has been ISO/ANSI standardized since the 60s. That means that
people have been able to write portable Fortran programs for several
decades.
When was C standardized?
>..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.
*Wrong, wrong, wrong*
Software written in f66 way back in the 60s, will still work
on modern PC, workstation, supercomputer, ... using f77 or f90 compilers.
Jens.
Dan Pop
>>Last but not least, the standarization in C is much more strict than
>>in FORTRAN,...
>
>Could you give us some explanations?
>
>Fortran has been ISO/ANSI standardized since the 60s. That means that
>people have been able to write portable Fortran programs for several
>decades.
Yes, but none of the pre-F90 standards was barely adequate for the
programmers' needs, hence the huge number of non-standard extensions
which are (more or less) de-facto standards, like TYPE*n or Cray
pointers, which never found their way into a Fortran standard, yet
they're widely used in real world software.
>When was C standardized?
A fully functional C standard was available 2 years before a fully
functional Fortran standard, despite the fact that the C standardization
process started about 20 years after the Fortran one.
>
>>..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.
>
>*Wrong, wrong, wrong*
>
>Software written in f66 way back in the 60s, will still work
>on modern PC, workstation, supercomputer, ... using f77 or f90 compilers.
*Wrong, wrong, wrong*
We read every week in comp.lang.fortran questions from people who have to
port old codes to other platforms and get lots of errors when they try
to compile them. Even codes which are 100% standard F66 codes might
not compile today, because some F66 features have been dropped in F77.
Craig Dedo
>Craig Dedo (Craig...@mixcom.com) wrote:
>: 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.
>So how long do you think until all of those 100k+ lines of F77 code
>that scientific labs insist on holding on to are converted to F90? :)
>-Jeff
>a numerical C programmer and damn proud of it! :-)
>--
>Jeffrey N. Woodford | "All the world's indeed a stage, And we are merely
>jwoo...@unlinfo.unl.edu | players, Performers and portrayers..." -- Rush
>Physical Chemistry Graduate Student, University of Nebraska - Lincoln
They can hold onto it and compile it with a standard-conforming F90 compiler
as long as they want to. F90 is a complete superset of F77. Also, there
are tools available (plusFORT comes to mind) that can automatically convert
F77 code to F90 code. Some can even convert God-awful F66 spaghetti code to
standard F90.
Please note that my answer is in response to a claim that C++ is far better
than Fortran in terms of modularity, maintainability, and data integrity. I
simply sought to debunk that claim.
Dan Pop
>In <3r344j$c...@crcnis3.unl.edu> jwoo...@unlinfo.unl.edu (Jeffrey N Woodford) writes:
>
>>Craig Dedo (Craig...@mixcom.com) wrote:
>>: 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.
>
>>So how long do you think until all of those 100k+ lines of F77 code
>>that scientific labs insist on holding on to are converted to F90? :)
>
>>-Jeff
>>a numerical C programmer and damn proud of it! :-)
>
>They can hold onto it and compile it with a standard-conforming F90 compiler
>as long as they want to. F90 is a complete superset of F77. Also, there
>are tools available (plusFORT comes to mind) that can automatically convert
>F77 code to F90 code. Some can even convert God-awful F66 spaghetti code to
>standard F90.
>
>Please note that my answer is in response to a claim that C++ is far better
>than Fortran in terms of modularity, maintainability, and data integrity. I
>simply sought to debunk that claim.
And Jeff's point was that the Fortran code which is actually used in
real world applications doesn't take any advantage of the F90 modularity,
maintainability, and data integrity features. The fact that those codes
might be compiled with an F90 compiler is completely irrelevant.
Harold Stevens
|>
|> So how long do you think until all of those 100k+ lines of F77 code
|> that scientific labs insist on holding on to are converted to F90? :)
|>
|> -Jeff
|> a numerical C programmer and damn proud of it! :-)
|>
Done, while "obsolete" FORTRAN syntax is retained in current/new compilers.
We don't have to "convert" to F90 as long as syntax is backward compatible;
this is not to trvialize the problems inherent in any code porting efforts.
But it's a *lot* easier to do than translate codes to C or IBM360 Autocoder
or whatever manually. To *create* original code in your language of choice
is only reasonable, but an employer has the right to ask if using existing
tools makes more financial sense for the task at hand.
Weird
Grizzled old veteran of the Numeric Wars and damn well warped by it :) :0 :)
victor allan kelson
Oh Darn.
For quite a while, I was enjoying this thread because it was positive
and helpful. But alas, the flamers have arrived... *sigh* off to the
killfile...
/v...
************************************************************************
* Vic Kelson When do we dance? *
* Groundwater Modeling Laboratory *
* School of Public and Environmental Affairs *
* Indiana University *
* vke...@ucs.indiana.edu *
* URL: http://silver.ucs.indiana.edu/~vkelson/home.html *
************************************************************************
Jeffrey N Woodford
: 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.
So how long do you think until all of those 100k+ lines of F77 code
that scientific labs insist on holding on to are converted to F90? :)
-Jeff
a numerical C programmer and damn proud of it! :-)
Peter Shenkin
Jens Bloch Helmers <he...@dhow.vr.dnv.no> wrote:
>>Last but not least, the standarization in C is much more strict than
>>in FORTRAN,...
>
>Could you give us some explanations?
>
>Fortran has been ISO/ANSI standardized since the 60s. That means that
>people have been able to write portable Fortran programs for several
>decades.
>
....
The problem is that many of the features which Fortran programmers
have come to rely on are not in the f77 standard. Examples:
bit manipulations
INCLUDE
dynamic allocation
identifier names longer than 6 characters
recursion.
All these have been part of C from the beginning, and are part of the
C standard. (Exception: long identifier names for externals.)
These features are also part of f90, but before f90 the absence of
these features in the standard made much "real world" Fortran code
less portable, in practice, than C code.
-P.
--
************************ The secret of life: *************************
*Peter S. Shenkin, Box 768 Havemeyer Hall, Chemistry, Columbia Univ.,*
* New York, NY 10027; she...@columbia.edu; (212) 854-5143 *
************* If you find a loose thread, don't pull it. *************
Peter Shenkin
Jeffrey N Woodford <jwoo...@unlinfo.unl.edu> wrote:
>Craig Dedo (Craig...@mixcom.com) wrote:
>: 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.
>
>So how long do you think until all of those 100k+ lines of F77 code
>that scientific labs insist on holding on to are converted to F90? :)
>
>-Jeff
>a numerical C programmer and damn proud of it! :-)
They are already F90 and proud of it, since F90, with few exceptions,
is a superset of F77.
Tim Hollebeek
I think Fortran 90's biggest problem is:
As long as you're switching languages, why not consider switching to
something else instead?
Tim Hollebeek
Craig Dedo <Craig...@mixcom.com> wrote:
:In <1995Jun5.2...@molienergy.bc.ca> ja...@molienergy.bc.ca (Jan Reimers) writes:
:
:>Hmm ... I think this is a bad example. Any good C++ programmer would use a
:>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.
: 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.
Hmm ... as long as we're discussing container implementation, does
Fortran 90 have templates? As I remember, it doesn't, in which case
the dispersion of your container code increases significantly.
: 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.
True if your world is the ANSI standards. However, of all the
scientific Fortran codes I have seen, I have yet to see a single line
of Fortran 90. Withdrawing the standard doesn't change the reality of
the situation.
F77 is definately on the way out. What is on the way *in* is not so
clear.
Dan Pop
>In article <3r1qd4$d...@newshost.lanl.gov>,
>WIlliam B. Clodius <wclo...@lanl.gov> wrote:
>>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).
>
>I think Fortran 90's biggest problem is:
>
>As long as you're switching languages, why not consider switching to
>something else instead?
Because switching from F77 to F90 is a very smooth process, that can be
done incrementally. Switching to something else is rather painful and
pointless, as long as Fortran has no real competitor for its intended
purpose (i.e. number crunching).
Manuel Galan Moreno
: > 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.
AGREED
Manolo
Manuel Galan Moreno
: 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).
Yes, you are right, however I had so bad experience with FORTRAN77's lack
of portability, let's say ONE year of work LOST (infamous M-vector!), that
I am reluctant to use FORTRAN90, maybe when the standard settles down
and stabilizes... (Same problems with C++)
Manolo
P.S: BTW I use a vector/parallel machine from Kubota Pacific and, with appropri
ate '#pragma' directives, I have no problem to get C code fully optimized for
vector/parllel execution... I _do_ insist: maybe the 'best' language is the
one that you know 'best' :-) (Same with word processors, I, myself, like 'vi')
Peter Shenkin
>>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).
>
>
>As long as you're switching languages, why not consider switching to
>something else instead?
This is a reasonable question. But I think the answer is that you
don't really have to switch. You can take part of your code and
turn it into modern F90, and later convert another part, if you so
desire.
For instance, it commonly arises that one must rewrite one module
or portion of an old code. This could be done using F90 constructs,
while making only minimal changes to the rest of the code.
Dan Pop
>WIlliam B. Clodius (wclo...@lanl.gov) wrote:
>: 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).
>
>Yes, you are right, however I had so bad experience with FORTRAN77's lack
>of portability, let's say ONE year of work LOST (infamous M-vector!), that
>I am reluctant to use FORTRAN90, maybe when the standard settles down
>and stabilizes... (Same problems with C++)
Unlike C++, which doesn't have a standard at all, F90 has been pretty
stable during the last 4 years (it was adopted in '91 :-)
r...@dstos3.dsto.defence.gov.au
> 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...
>
You're right; it's not really proof of anything. Sparce matrices tend
to be handled poorly by FORTRAN programmers, because the language doesn't
lend itself to that. (F90 may be better than 77; I don't know).
Anyone with experience knows that FORTRAN codes for handling sparce
matrices are real pigs to either design or implement. And them some
lucky soul has to *use* the code .....
> 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.
>
Ah (as I stated above before I read this far).
> 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.
>
You're drawing the longbow a bit here. Sparce matrices are important
for an number of numerical analysis areas, but they're certainly not
the only type of problem involved in high end computing.
Many problems in numerical analysis, involving dense matrices, complex
arithmetic, iterative approaches, etc can be handled admirably by
FORTRAN because that is what the language is designed for.
C/C++ offers many nice features, which can make the job of a programmer
much simpler....pointers, structs, dynamic memory... But, when you're
out for a high performance code, these same features can hamper the
compiler efforts to optimise the code. F77, because it's a much
simpler language, can often do a better job of optimisation.
It's horses for courses.....
> 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.
>
Wrong..the FORTRAN standards are reasonably rigorous. The problem is that
vendors implement extensions. While some of those extensions are
going into F90, there is still a great deal of code out there
which claims to be F77, but is really an extended form. Fortunately,
many of the extensions available in existing F77 are available across
platforms. The fact the vendors have tended to document their extensions
as a part of the language has muddied the water.
As long as you avoid things like graphical toolkits and certain
extensions (case statements, do while, namelist I/O, and a few others)
most numerical code written in FORTRAN will be portable....probably
more than C. Look at all the Unix extensions, DOS extensions, etc for C.
> 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
Too right; use the language for the job. Don't fit a job to a
language. Use multiple languages if necessary.
---------------- <Standard Trailer>
Robert O'Dowd Phone : +61 8 259 7097
Bldg. 113 TSAN Fax : +61 8 259 6104
P.O. Box 1500 E-mail : r...@dstos3.dsto.gov.au
DSTO Salisbury, South Australia, 5108 OR r...@mod.dsto.gov.au
Disclaimer: Opinions above are MINE and probably worth what you paid for them.
Shigeki Misawa
> Followup-To: comp.lang.fortran,comp.lang.c
> NNTP-Posting-Host: dstos3.dsto.gov.au
***** HUGE CHUNKS DELETED *****
>
> Wrong..the FORTRAN standards are reasonably rigorous. The problem is that
> vendors implement extensions. While some of those extensions are
> going into F90, there is still a great deal of code out there
> which claims to be F77, but is really an extended form. Fortunately,
> many of the extensions available in existing F77 are available across
> platforms. The fact the vendors have tended to document their extensions
> as a part of the language has muddied the water.
Huh? The impression I get is that the vendors are being dragged
kicking and screaming by the Fortran programmers into implementing
extensions. (At least that's the way it seems in the UNIX world.)
It's not clear what fraction of FORTRAN programmers are willing to code
in ANSI Fortran 77. (It's also not clear how many programmers know
exactly what features they use are standard and what features are
"extensions")
>
> As long as you avoid things like graphical toolkits and certain
> extensions (case statements, do while, namelist I/O, and a few others)
> most numerical code written in FORTRAN will be portable....probably
> more than C. Look at all the Unix extensions, DOS extensions, etc for C.
Huh ? What UNIX extensions ? Are you sure you aren't confusing system
libraries with language extensions ? I haven't programmed a lot in C
on MS-DOS platforms, but the impression I get is that the only
extension to C in DOS is the near/far pointer garbage. (Even in this
case, I believe this is due to limitations of DOS and/or the original
8086/8088 CPU architecture.)
>
> > 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
>
>
> Too right; use the language for the job. Don't fit a job to a
> language. Use multiple languages if necessary.
>
This is the correct attitude. Unfortunately, this is difficult to do
in practice. *Most* people don't have the time to become proficient in
multiple languages or programming paradigms. Also, multi-language
programming projects are probably fraught (is this the right word ?)
with difficulties, technical and "political".
>
> ---------------- <Standard Trailer>
> Robert O'Dowd Phone : +61 8 259 7097
> Bldg. 113 TSAN Fax : +61 8 259 6104
> P.O. Box 1500 E-mail : r...@dstos3.dsto.gov.au
> DSTO Salisbury, South Australia, 5108 OR r...@mod.dsto.gov.au
>
> Disclaimer: Opinions above are MINE and probably worth what you paid for them.
Shigeki Misawa
Graduate Student
UCB Physics Department
"Will Code ANSI Draft C++ for food"
William G. Royds
Jianlin Chang (cha...@Jeff-Lab.QueensU.CA) writes:
> 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?
C and C++ still does not have arrays. It has a notation for pointers
that looks like arrays, but is limited by the fact that the dimensionality
of the array needs to be known explictly by all routines that use it.
Fortran, especially Fortran 90, handles arrays in about the clearest manner
possible in a compiled language. Only APL is better in a standardized language.
--
Bill Royds az...@freenet.carleton.ca CLBRR
Ottawa, Ontario ROY...@EM.agr.ca Scientific Software Support
C.L.B.R.R. Ag Canada has no opinion on this
Manuel Galan Moreno
: >Last but not least, the standarization in C is much more strict than
: >in FORTRAN,...
: Could you give us some explanations?
: Fortran has been ISO/ANSI standardized since the 60s. That means that
: people have been able to write portable Fortran programs for several
: decades.
: When was C standardized?
The problem is not which one was the first but which of them achieved a better
standarization...
Committees do not enforce standarization, USERS DO!!
Fortran mentality was not to be standard and portable but to achieve
good quick 'n dirty optimization.
: >..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.
: *Wrong, wrong, wrong*
Just make a test, (of course not the "hello world" program) and check
different architectures ( IBM-RS6000 AIX / HP-730 HPUX ) you will know
what I meant... (equivalence, common block, preprocessing, ...)
: Software written in f66 way back in the 60s, will still work
: on modern PC, workstation, supercomputer, ... using f77 or f90 compilers.
Yes, this is more logical, f66 is way more restricted, but F77 and its
jungle of propietary extensions... (VAX FORTRAN, HP-FORTRAN, MS-FORTRAN,...)
A colleage of mine (very good fortran programmer) always said to me
that the problem with FORTRAN was that commercial compilers had extensions
and defaults which were meant for optimization and ease of use, normally
you were __encouraged__ to use those extensions because of performance
or pure sloth... The problem was that different suppliers had different
extensions and defaults, which were normally 'nearly' compatible. That
meant that source code 'nearly' compiled and 'nearly' run from one platform
to another... :-)
I think that there is a reason for all this, software developers get much
more $$$ from their C/C++ compilers than from FORTRAN compilers, the amount
of applications/users/sales is, by far, much more in the C/C++ field (just
look at your favorite computer magazine ads), go to the software department
of some general store, you will find plenty of books about C/C++, very few
on FORTRAN, so market laws...
By this I __DO NOT__ mean that C is better than FORTRAN (DOS is not better
than UNIX!).
However, never forget that C is the language of Computer Science while
FORTRAN is mainly used in Engineering, but CS people are the ones who make
compilers; engineers make planes, bridges, ...
Manolo
Jeffrey N Woodford
: In <1995Jun7.1...@mixcom.com> Craig Dedo <Craig...@mixcom.com> writes:
: >In <3r344j$c...@crcnis3.unl.edu> jwoo...@unlinfo.unl.edu (Jeffrey N Woodford) writes:
: >
: >>Craig Dedo (Craig...@mixcom.com) wrote:
: >>: 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.
: >
: >>So how long do you think until all of those 100k+ lines of F77 code
: >>that scientific labs insist on holding on to are converted to F90? :)
: >
: >>-Jeff
: >>a numerical C programmer and damn proud of it! :-)
: >
: >They can hold onto it and compile it with a standard-conforming F90 compiler
: >as long as they want to. F90 is a complete superset of F77. Also, there
: >are tools available (plusFORT comes to mind) that can automatically convert
: >F77 code to F90 code. Some can even convert God-awful F66 spaghetti code to
: >standard F90.
: >
: >Please note that my answer is in response to a claim that C++ is far better
: >than Fortran in terms of modularity, maintainability, and data integrity. I
: >simply sought to debunk that claim.
: And Jeff's point was that the Fortran code which is actually used in
: real world applications doesn't take any advantage of the F90 modularity,
: maintainability, and data integrity features. The fact that those codes
: might be compiled with an F90 compiler is completely irrelevant.
Actually, Jeff's point was to crack a joke.
-Jeff
Jeffrey N Woodford
: P.S: BTW I use a vector/parallel machine from Kubota Pacific and, with appropri
: ate '#pragma' directives, I have no problem to get C code fully optimized for
: vector/parllel execution... I _do_ insist: maybe the 'best' language is the
: one that you know 'best' :-) (Same with word processors, I, myself, like 'vi')
VI? Barf! How could _anyone_ like VI! It's not intuitive, you have
to use these funky "codes" to do anything on it. Emacs is far
superior, dammit! :-)
Followups to alt.flame :)
-Jeff
a happy emacs user
Manuel Galan Moreno
: Manuel Galan Moreno (man...@fobos.ulpgc.es) wrote:
: : P.S: BTW I use a vector/parallel machine from Kubota Pacific and, with appropri
: : ate '#pragma' directives, I have no problem to get C code fully optimized for
: : vector/parllel execution... I _do_ insist: maybe the 'best' language is the
: : one that you know 'best' :-) (Same with word processors, I, myself, like 'vi')
: VI? Barf! How could _anyone_ like VI! It's not intuitive, you have
: to use these funky "codes" to do anything on it. Emacs is far
: superior, dammit! :-)
: Followups to alt.flame :)
best alt.religion.emacs :-) :-) :-)
Manolo
Rick Venable
> We read every week in comp.lang.fortran questions from people who have to
> port old codes to other platforms and get lots of errors when they try
> to compile them.
This is *very* misleading statement; many of the porting problems are due to
the use of extensions in an undisciplined way, and have *nothing* to do with
the use of standard Fortran. If one takes care to isolate non-standard
code, and document extensions properly, Fortran 77 code is extremely portable.
Would you characterize the problems novices have with the distinction between
K&R and and ANSI C or maybe SysV vs. BSD system calls as problems with the
C standard? Why single out Fortran? Both languages are flawed; old news.
I've not read anything in this or similar threads which convinces me that C
or C++ offers any advantage over Fortran for numerically intensive problems;
likewise, I wouldn't try to write a GUI in Fortran. So what? Give it a rest.
--
Rick Venable =====\ |=| "Eschew Obfuscation"
FDA/CBER Biophysics Lab |____/ |=|
Bethesda, MD U.S.A. | \ / |=| / Not an official statement \
rven...@deimos.cber.nih.gov \/ |=| \ or position of the FDA. /
Dan Pop
>On Wed, 7 Jun 1995 11:45:59 GMT Dan Pop wrote:
>> We read every week in comp.lang.fortran questions from people who have to
>> port old codes to other platforms and get lots of errors when they try
>> to compile them.
>
>This is *very* misleading statement; many of the porting problems are due to
>the use of extensions in an undisciplined way, and have *nothing* to do with
>the use of standard Fortran. If one takes care to isolate non-standard
>code, and document extensions properly, Fortran 77 code is extremely portable.
This is plain wrong. No matter how disciplinately the extensions are
used, they simply won't work on a compiler which doesn't have them or
implement them in a different way. The problem is even worse for
pre-F77 codes (and there is still quite a bunch of them in use).
Pure F77 codes are portable, indeed, but there is a huge amount of
"impure F77" code floating around, and we (those who read c.l.f on
a regular basis) _know_ people have problems porting it.
Bart Childs
the most common model for scientific computing is Ax=b and C does not
even have a matrix data type? You can do it, but you can do it in at
least a half-dozen ways! Standardization?? Get serious! Oh, you did
not mean at that level?
Anybody that thinks that C codes are automatically portable is also
dreaming. EVERY language has its own quirks at implementation time.
(I have to work on AIX, two SUN versions, and DOS. They certainly
seem different to me (even gcc on all four.)) I recommend reading
Andrew Koenig's ``C Traps and Pit
f
a
l
ls'', an Addison Wesley book.
The comparisons of codes having different running times in any two
languages often measures the different care done in constructing the
programs in the two languages AND the care done in creating the compilers.
I often claim that UNIX is an acronym for Uniformly Nefarious
Implementations of all compiler eXcept c. There have really been
some horrible Pascal and FORTRAN compilers on unix systems.
Face it! We are talking about emerging technologies. Every Fortran
revision has been a step forward. Every C revision (maybe that is not
the right word in this case) has been a step forward.
Our professions are really evolutionary. For some reason we keep coming
back to the old argument of `which one language is best?' This stream
of discussion has that thread to it although it may not have been intended.
Whenever we seriously try to contribute to such a discussion, we should
read C. A. R. Hoare's Turing Lecture again. The title was about the
Emperor's Old Clothes. Good points have been made in this discussion about
the huge growth in F90 constructs. Those writing new standards should
probably try to discard as many old constructs as the new ones added.
(Yeah, I know: COMPATIBILITY with previous versions. It will be worth
watching to see how Lahey's F90 subset [by throwing out the antiquated
features] does.)
Just my little contribution.
Bart Childs Prof of C.S. Texas A&M Univ
ba...@cs.tamu.edu
Tanmoy Bhattacharya
Moreno) writes:
<snip>
|> A colleage of mine (very good fortran programmer) always said to me
|> that the problem with FORTRAN was that commercial compilers had extensions
|> and defaults which were meant for optimization and ease of use, normally
|> you were __encouraged__ to use those extensions because of performance
|> or pure sloth... The problem was that different suppliers had different
For optimization and ease of use? Examples please!
I have been coding in Fortran for quite some time: and most often
I used vendor extensions for two reasons:
1) I was using a state of the art machine which did not yet have a stable
compiler. The extensions were calls to library routines that (even with
the overhead of the call) did something faster than the normal way of
doing things.
This was, in my mind, akin to coding the most computationally intensive
parts in assembly. I would not expect that to be portable: I knew it was
not portable when I wrote it: it would not have been portable if I had
written it in any language; and, yet, all that one needed to do to
`port' was to drop in replacement subroutines (Sure that did not give an
optimized result on the new platform, but it would run.)
2) Some system specifics (like getting the current date and username to stamp
the output datafiles, screen handling, secondary storage management), some
of which is not portable in any language whatesoever.
3) Mental laziness: as I know that when I have to port, I have to change a
lot of things anyway, I commit myself to one particular
compiler/installation for _ease_ of coding. I try to avoid this in
production code, but sometimes I fail to remove a few of these uses.
4) Accepted extensions: Certain extensions I accept, and use; and if these
result in lack of portablity... well, I change them :-(. This includes
certain flexibilities in the order of statements, slightly longer variable
names, lower case letters, short lines (though with no unterminated
character constants), and very reluctantly, comments at the end of the
file and real*8. (The last two only because I cannot convince my
collaborators not to do :-)
5) Ignorance: Most of us are programming because we need to: and most of us,
do not have time to learn the language well. I have often heard, usually
when something fails drastically: and I am mad at whoever coded that part:
`How am I supposed to know that was non-portable'.
I have rarely come across cases where I used vendor extensions because I
_needed_ them. But, in this particular field there is so much to porting than
merely to making it run, that usual portability is not much of an issue. When
I port from a cray to a connection machine, I am essentially changibg the
architecture on which my code runs: and getting it to run is a small comfort
when I am looking to finish a run in a day instead of half a week :-) And
efficient coding tricks for one machine; though related, are completely
different from what it is on another.
Cheers
Tanmoy
--
tan...@qcd.lanl.gov(128.165.23.46) DECNET: BETA::"tan...@lanl.gov"(1.218=1242)
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 ]
Kurt Kallblad
ig...@fg70.rz.uni-karlsruhe.de says...
>
>In comp.lang.fortran, t...@handel.Princeton.EDU (Tim Hollebeek) wrote:
>
>>This is IMO the worst one. Many vendors are still very bad at
>>indicating what is/is not an extension.
>
>I found the IBM VS compiler to be exemplary in this respect. Standard
>Fortran features were printed in black in the handbook; extensions
>were printed in blue.
>--
>Thomas Koenig
The same black and blue is also used in the manuals for MS's Fortran. So
there are some good things even from MS :-)
Have a nice day,
Kurt
--
Kurt Kaellblad E-mail: kurt.k...@bkl.lth.se
Department of Building Science Phone: +46 46 222 7358
Lund Institute of Technology Fax: +46 46 222 4719
P.O.Box 118, LUND
S-221 00 Sweden
<Speaking for myself, not the department, nor ...>
Thomas Koenig
>This is IMO the worst one. Many vendors are still very bad at
>indicating what is/is not an extension.
I found the IBM VS compiler to be exemplary in this respect. Standard
Fortran features were printed in black in the handbook; extensions
were printed in blue.
--
Thomas Koenig, Thomas...@ciw.uni-karlsruhe.de, ig...@dkauni2.bitnet.
The joy of engineering is to find a straight line on a double
logarithmic diagram.
Tim Hollebeek
Bart Childs <ba...@stellar.NoSubdomain.NoDomain> wrote:
>Standardization in C? The word is used loosely when you consider that
>the most common model for scientific computing is Ax=b and C does not
>even have a matrix data type? You can do it, but you can do it in at
>least a half-dozen ways! Standardization?? Get serious! Oh, you did
>not mean at that level?
And all six of them will work exactly the same way on everything from
the most obscure (ANSI) compiler to the most common, provided they are
written in standard (ANSI) C. That is what is meant by
standardization.
In Fortran, on the other hand, you couldn't even use 'enddo' until
1990 without opening yourself up to possible portability problems.
>Face it! We are talking about emerging technologies. Every Fortran
>revision has been a step forward. Every C revision (maybe that is not
>the right word in this case) has been a step forward.
C and Fortran compilation are hardly 'emerging technologies'. No one
is arguing that each successive standards aren't better, simply that
the C standards are ahead of the Fortran ones as far as portability is
concerned. Similarly, the Fortran standards are ahead of the C ones
with respect to giving the compiler the maximum ammount of freedom to
optimize (mangle, mutilate, rearrange, create misleading results from)
your code.
>Our professions are really evolutionary. For some reason we keep coming
>back to the old argument of `which one language is best?' ...
Well, the solution to that discussion (which obviously won't reach a
conclusion) isn't simply to declare all languages equal. C is simply
more portable than Fortran is.
Tim Hollebeek
Tanmoy Bhattacharya <tan...@qcd.lanl.gov> wrote:
>
>5) Ignorance: Most of us are programming because we need to: and most of us,
> do not have time to learn the language well. I have often heard, usually
> when something fails drastically: and I am mad at whoever coded that part:
> `How am I supposed to know that was non-portable'.
>
This is IMO the worst one. Many vendors are still very bad at
indicating what is/is not an extension. Luckily, at least with C,
most compilers have a strict ANSI switch which helps somewhat.
Peter Shenkin
Thomas Koenig <ig...@fg70.rz.uni-karlsruhe.de> wrote:
>In comp.lang.fortran, t...@handel.Princeton.EDU (Tim Hollebeek) wrote:
>
>>indicating what is/is not an extension.
>
>Fortran features were printed in black in the handbook; extensions
>were printed in blue.
As a result, anyone trying to learn Fortran on that system wound
up black and blue. :-)
Timusk Peter
only about three hundred statement lines experiance. What bothers me though
is the interface problems and other seemingly hardware problems I can't solve
and with the computer explosion can only find that I have to spend money to
get ahead.
--
Peter Timusk Kiitos Paljon, Merci, and thank you.
Member of these various groups: IATSE local 417, CASI, and
the Canadian Math society. E-mail at...@freenet.carleton.ca
Radicle: The minute root of an embryo plant.
John A. Turner
> I found the IBM VS compiler to be exemplary in this respect. Standard
> Fortran features were printed in black in the handbook; extensions
> were printed in blue.
Cray has always been very good about this as well...
+---------------------------------------------------------------+
| John A. Turner |
| Los Alamos National Laboratory, MS B226, Los Alamos, NM 87545 |
| Group: XTM (Radiation Transport Methods) |
| Location: TA-3, Bldg. 43, Rm. D263 |
| Phone: 505-665-1303 e-mail: tur...@lanl.gov |
+---------------------------------------------------------------+
Lucio Chiappetti
|>
|> I have been coding in Fortran for quite some time: and most often
|> I used vendor extensions for two reasons:
then you list 5. Of course YOU know where your towel is in cases
1/2/4 and I'd say also 3. Then you do the trade off between
portability and your immediate needs (and are aware of it)
Obviously case 5 does not apply to you.
|> 1) I was using a state of the art machine which did not yet have a stable
|> compiler.
|>
|> 2) Some system specifics (like getting the current date and username to stamp
|>
|> 3) Mental laziness: as I know that when I have to port, I have to change a
|>
|> 4) Accepted extensions: Certain extensions I accept, and use; and if these
|>
|> 5) Ignorance: Most of us are programming because we need to: and most of us,
|> do not have time to learn the language well. I have often heard, usually
|> when something fails drastically: and I am mad at whoever coded that part:
|> `How am I supposed to know that was non-portable'.
Well, in this case the old RTFM adage will never be reiterated too
much : all good vendor Fortran manuals have extensions clearly
marked, usually printed in a different colour.
--
----------------------------------------------------------------------------
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
Internet: LU...@IFCTR.MI.CNR.IT |
Decnet: IFCTR::LUCIO | (Rabisch, II 46, 119-120)
----------------------------------------------------------------------------
Steve Lionel
writes:
>>Fortran features were printed in black in the handbook; extensions
>>were printed in blue.
>
>there are some good things even from MS :-)
Digital also does this in the DEC Fortran manuals - I think that we first
used blue for extensions back in 1980 for VAX FORTRAN V2.0. We've seen
comments, mainly from universities, that they like this method as it allows
them to photocopy the manual and, since the blue doesn't reproduce well
(at least it used not to), what they'd end up with is a manual containing
only standard features.
We've been thinking of how to handle extensions now that F90 is here. I
think IBM's manual uses red for F90 features not in F77 and blue for
extensions not in either standard. (I may have the colors reversed.) We
wondered if users liked this, or might some find it too cluttered. Is it
necessary in a F90 compiler to highlight in this manner F90 features not
in F77?
Steve Lionel Mail: lio...@quark.enet.dec.com
DEC Fortran Development WWW: http://www.digital.com/info/slionel.html
Digital Equipment Corporation CompuServe: 75263,3001
110 Spit Brook Road, ZKO2-3/N30
Nashua, NH 03062-2698 "Free advice is worth every cent"
For a summary of Digital's Internet services, send mail to in...@digital.com
Dan Pop
>We've been thinking of how to handle extensions now that F90 is here. I
>think IBM's manual uses red for F90 features not in F77 and blue for
>extensions not in either standard. (I may have the colors reversed.) We
>wondered if users liked this, or might some find it too cluttered. Is it
>necessary in a F90 compiler to highlight in this manner F90 features not
>in F77?
I don't think so. Learning a programming language from the vendor
documentation is not a good idea in the first place. A vendor independent
book is a much better choice.
The compiler documentation is used as a reference text and the only
distinction that has to be _clearly_ made is that between standard
features and extensions.
Someone who wants to use a F90 compiler to develop F77 compliant code
can simply use his F77 book. But this would be a very "exotic" user,
most people use a F90 compiler because they want or need to use the new
features, not because they don't have access to a F77 compiler :-)
Just my $0.02,
fair...@sldb6.slac.stanford.edu
lio...@quark.enet.dec.com (Steve Lionel) writes:
[...]
> Digital also does this in the DEC Fortran manuals - I think that we first
> used blue for extensions back in 1980 for VAX FORTRAN V2.0. We've seen
> comments, mainly from universities, that they like this method as it allows
> them to photocopy the manual and, since the blue doesn't reproduce well
> (at least it used not to), what they'd end up with is a manual containing
> only standard features.
>
> think IBM's manual uses red for F90 features not in F77 and blue for
> extensions not in either standard. (I may have the colors reversed.) We
> wondered if users liked this, or might some find it too cluttered. Is it
> necessary in a F90 compiler to highlight in this manner F90 features not
> in F77?
Thanks for asking, Steve.
First, I would find _multi-colored_ manuals (as opposed to black
plus one color) too cluttered. Please DON'T imitate IBM (or anyone
else) in that manner. :-)
Secondly, I agree with Dan Pop's remark, there's no need to
separately indicate F90 and F77 features in the same manual.
Someone who needs to know the distinctions could either (a) get a
copy of the F77 standard, (b) get a copy of the F90 standard, and/or
(c) be referred to an Appendix within the (F90) manual which
delineates the F77 subset of F90. For the case of F90 features
included in DEC Fortran (a Fortran 77 implementation), these
features are clearly _extensions_ to F77 and should be indicated as
such, along with the other extensions. An Appendix would suffice to
indicate which extensions are standard F90 features.
Too many colors, like too many fonts, interferes with normal
reading...
-Ken
--
Kenneth H. Fairfield | Internet: Fair...@Slac.Stanford.Edu
SLAC, P.O.Box 4349, MS 46 | DECnet: 45537::FAIRFIELD (45537=SLACVX)
Stanford, CA 94309 | Voice: 415-926-2924 FAX: 415-926-3515
-------------------------------------------------------------------------
These opinions are mine, not SLAC's, Stanford's, nor the DOE's...
Glen Reesor
> writes:
> >In article <3rpbap$d...@fg70.rz.uni-karlsruhe.de>,
> >ig...@fg70.rz.uni-karlsruhe.de says...
> >>
> >>I found the IBM VS compiler to be exemplary in this respect. Standard
> >>Fortran features were printed in black in the handbook; extensions
> >>were printed in blue.
> >
> >The same black and blue is also used in the manuals for MS's Fortran. So
> >there are some good things even from MS :-)
>
> used blue for extensions back in 1980 for VAX FORTRAN V2.0. We've seen
> comments, mainly from universities, that they like this method as it allows
> them to photocopy the manual and, since the blue doesn't reproduce well
> (at least it used not to), what they'd end up with is a manual containing
> only standard features.
HP does the Black and Blue thing too. However, I just ordered another set
of manuals, and I got photocopies since they're out of print now (not sure
why). However, the photocopies are too good! You can't tell the difference
between the blue and black.
--
Glen Reesor Opinions are mine, only mine, and definitely
<ree...@crl.aecl.ca> not my employer's.
Bernward Bretthauer
Much of the work is done in library functions and the compiler don't know about
side effects. Another pitfall for performance is the for statement:
Look at the following program which counts the primes up to 300000:
#include <stdio.h>
#include <math.h>
main()
{
unsigned long p, w;
int pcount=1;
for (p=3;p<300000;p+=2) {
for (w=3; w<=(unsigned long)(sqrt((double)p)+0.1); w+=2) {
if (!(p%w)) goto no_prime;
}
pcount++;
no_prime:;
}
printf ("%d primes\n", pcount);
}
The expensive test w<=(unsigned long)(sqrt((double)p)+0.1) is executed on
each loop iteration because of the syntax of the for-loop. The compiler don't
know about the side effects of the sqrt function, so it can't do any
optimisation on this.
In FORTRAN, the number of loop iterations is calculated before and cannot
be changed while the loop is running:
So the equivalent FORTRAN do-loop is correct:
do 10, w=3,int(sqrt(real(p)+0,1)),2
But in C, you have to da hand optimization by introducing an additional variable
and calculation storing the value of sqrt... in it before the loop starts.
This gave me a factor of 3 in speed in this little example. I once had a real world
program, which suffered from this pitfall and the effect was even higher.
Bernward Bretthauer
Tim Hollebeek
Robin Vowels <r...@goanna.cs.rmit.edu.au> wrote:
>
>---This is a problem?? How so? If you want portable code, you
>simply ignore extensions. You have to go out of your way
>to use them! You have to get them out of the supplier's
>manual!
As soon as you realize that things as simple as the 'enddo' construct
are _nonstandard extensions_ to Fortran 77, you realize how much trouble
you're in.
The preface to Numerical Recipes has a nice discussion of this
problem.
Tanmoy Bhattacharya
(Robin Vowels) writes:
|> tan...@qcd.lanl.gov (Tanmoy Bhattacharya) writes:
<snip>
|> >5) Ignorance: Most of us are programming because we need to: and
most of us,
|> > do not have time to learn the language well.
|>
|> you're looking up a reference book -- you have to know it well
|> in order to use it ! ! !
Welcome to the real world! I do not know what your definition of `using a
language a lot' is, but over 10 hours a day, 6 days a week, years (except for
small vacations), qualifies in my view. And I do not know what your
definition of `knowing' is; but I can tell you knowing what is guaranteed by
the standard is often not part of that definition. (Sure, nobody makes the
same mistake twice: but we probably change compilers once in six months, and
platforms once in two years. That is a rare enough occurrence that `practice'
does not necessarily teach us what is guaranteed independent of platform.)
Ultimately, I do not believe it is an issue of whether manuals are printed in
blue or green: most of us look at a manual as a last resort. It is a question
of culture: in high performnace computing, we are after performance ... we
write in assembly if need be. There just does not exist enough of a `culture'
of portability to write the non-critical parts in straight fortran without
using vendor extensions. Ignorance of the difference certainly aids this
process.
Tim Hollebeek
Bernward Bretthauer <br...@es.go.dlr.de> wrote:
:In general, C is not very good for compiler optimization:
:Much of the work is done in library functions and the compiler don't know about
:side effects. Another pitfall for performance is the for statement:
:Look at the following program which counts the primes up to 300000:
:
:
:#include <stdio.h>
:#include <math.h>
:main()
:{
: unsigned long p, w;
: int pcount=1;
:
: for (p=3;p<300000;p+=2) {
: for (w=3; w<=(unsigned long)(sqrt((double)p)+0.1); w+=2) {
: if (!(p%w)) goto no_prime;
: }
: pcount++;
: no_prime:;
: }
: printf ("%d primes\n", pcount);
:}
:
:
:The expensive test w<=(unsigned long)(sqrt((double)p)+0.1) is executed on
:each loop iteration because of the syntax of the for-loop. The compiler don't
:know about the side effects of the sqrt function, so it can't do any
:optimisation on this.
Of course, the real question is what the heck are you using floating
point for ?????
for (w = 3; w * w <= p; w += 2) { ...
is much better. This is a classic example of 'If you want something
to run fast, try using the correct algorithm ...'
Tanmoy Bhattacharya
writes:
<snip>
|> The expensive test w<=(unsigned long)(sqrt((double)p)+0.1) is executed
on
|> each loop iteration because of the syntax of the for-loop. The compiler
don't
|> know about the side effects of the sqrt function, so it can't do any
|> optimisation on this.
It does too. The ANSI standard prohibits an user function to be named `sqrt'
(see 7.1.3 of the ISO document) so the compiler has every right to optimize
based on the fact that `sqrt' does not have a side-effect. (Technically, the
user can have a static function called sqrt: but that is like saying that in
Fortran, an user can say EXTERNAL SQRT. In both cases, the compiler has to
guard against this eventuality.)
And by the way once you have included the headers (as you have), and if
you are writing in ANSI C, feel free to write w <= sqrt(p): the cost
of a floating point comparison that this entails is probably pretty small (or
may even be better). (And the (double) cast is not needed: the sqrt function
_must_ have a prototype in the header. Of course you may need it for
compatibility with pre-ANSI C).
I have no idea why you wanted to go to floating point anyway: are you really
on a machine in which squaring an unsigned long is more expensive than taking
the sqrt of a floating point number? But, that is beside the point.
Craig Burley
In general, C is not very good for compiler optimization:
Much of the work is done in library functions and the compiler don't know about
side effects.
[snip]
The expensive test w<=(unsigned long)(sqrt((double)p)+0.1) is executed on
each loop iteration because of the syntax of the for-loop. The compiler don't
know about the side effects of the sqrt function, so it can't do any
optimisation on this.
Not really true. The C compiler _can_ know about the sqrt function, because
it is part of the standard. gcc, for example, generates an "fsqrt"
instruction in-line for sqrt() calls in i386 machines. (So does g77 as
of a recent version, I forget which offhand.)
In FORTRAN, the number of loop iterations is calculated before and cannot
be changed while the loop is running:
This is really the point. The Fortran iterative DO _requires_ a conforming
compiler to implement the loop in a way that can be more optimal (and
other times less optimal) than a more general form of DO, a la C's. But,
either way, we're talking dumb vs. smart compilers, and both constructs
(C's and Fortran's) have their advanatages and disadvantages, and either
can be coded in the other's language if necessary. (C's is easier to
code in Fortran than vice-versa -- which I think is a point in
Fortran's favor.)
Not that all Fortrans get this right. f2c doesn't appear to generate
correct code for "DO R=S,T,V", for example -- it does R=S, then R=R+V
until R reaches T (in whatever direction). It properly uses the
values of T and V at the beginning of the loop, but improperly does
the iterative addition instead of doing the initial division to determine
the iteration count. The result is that, for some combinations of values,
f2c-generated code will experience a different number of iterations through
the loop than code generated by other conforming Fortran implementations
on the same machine. (Strictly, I suppose f2c cannot be said to
be nonconforming here, since precision of floating-point is not
specified by the F77 standard, but it certainly is violating the
spirit of the standard.)
And note that for certain (probably rather obscure) cases, whether using
a smart or dumb compiler in the respective language, Fortran's DO construct
can produce slower code than C's corresponding for, precisely because
C's for does _not_ require the precalculation of the iteration count.
--
James Craig Burley, Software Craftsperson bur...@gnu.ai.mit.edu
Craig Burley
Gcc has the -ffast-math option to supress this behaviour and generate
non - standard conforming code.
I believe -ffast-math works for g77 as well. I think I checked this
a couple of months ago, when I wrote the code to get g77 to turn on the
gcc back end's ability to inline sqrt() and such.
BTW, gcc-2.7.0 probably improves on the generated code for sqrt() when
using the default (-fno-fast-math), and either at 2.7.0 or I hope at
2.8, g77 will be able to tell the back end to simply not bother with
setting errno at all (since errno is a C kludge, not a Fortran blessing :-).
Thomas Koenig
>Not really true. The C compiler _can_ know about the sqrt function, because
>it is part of the standard. gcc, for example, generates an "fsqrt"
>instruction in-line for sqrt() calls in i386 machines.
True.
However, the ISO C standard stupidly specifies:
7.5 Mathematics <math.h>
[...]
7.5.1 Treatment of error conditions
[...]
For all functions, a domain error occurs if an input argument is outside
the domain over which the mathematical function is defined. [...]
On a domain error the function returns an implementation - defined
value; the value of the macro EDOM is stored in errno.
In Fortran, you can use a single machine instruction to take a
square root. In C, you have to do additional checking, and set
errno accordingly.
Gcc has the -ffast-math option to supress this behaviour and generate
non - standard conforming code.
Bernward Bretthauer
>Of course, the real question is what the heck are you using floating
>point for ?????
>
>for (w = 3; w * w <= p; w += 2) { ...
>
>is much better. This is a classic example of 'If you want something
>to run fast, try using the correct algorithm ...'
>
This is only true for small p. For p=299999 you have appr. 270 multiplikations
with your "better" algorithm, but the sqrt has to be calculated only once
(if you use the second version of the code with additional variable).
Of course, in the example with the prime numbers, there is an other
loop around this one and p is only incremented by two. This is used in the following
example for a really fast version without sqrt:
#include <stdio.h>
main()
{
unsigned long p, w, s;
int pcount=1;
s=1;
for (p=3;p<300000;p+=2) {
while (s*s < p) s++;
for (w=3; w<=s; w+=2) {
if (!(p%w)) goto no_prime;
}
pcount++;
no_prime:;
}
printf ("%d primes\n", pcount);
}
Execution times on SparcStation 10/40 (seconds user time).
gcc -O2 acc -O4 acc -O4 -cg92
Above example: 12.660 12.870 6.1
sqrt with additional variable: 13.290 13.110 6.610
sqrt without additional variable: 18.980 35.120 28.610
Your version: 16.960 16.910 6.970
Remarks:
-cg92 generates inline code for integer multiplication and division. This is
not available on older Sparcs.
gcc seems to be better in optimizing the inefficient version, but it still
don't get the performence of the hand optimized versions.
Because the programs where run on a Multitasking system, execution times (measured
by the time command) are only exact to about 0.5 seconds.
Bernward Bretthauer
Tomislav Vujec
Try this,
I wouldn't even consider writing compiler or some sort of a system
tool in any language but C. Okay maybe some script in sh, perl, or lisp,
but not in FORTRAN, PASCAL, or any similar language. In case I got to work
on some engineering project, maybe I'll use FORTRAN, but that's matter of
personal choice in the first place, and field oriented choice on the second
place. In that order. I learned to write in C so if I can use it in current
project, I'll use it. Maybe FORTRAN programmers thinks in the same way as me,
but v.v. I have never seen useful compiler for any language written in FOR-
TRAN, but there is many engineering tools written in C. Further than that is
useless to discuss this subject, because we enter to an area of personal
choices. Also we all can conclude one thing, and that is that no perfect
programming language exists. Just use what you like to use, and be good at
that.
Tomislav
--
"640K ought to be enough for anybody" - Bill Gates 1981
--------------------------------------------------------------------
E-mail: Tomisla...@etf.hr Tel: +385-(0)42-210-486
Adr: Tomislav Vujec Hercegovacka 15 42000 Varazdin Croatia
r...@dstos3.dsto.defence.gov.au
> tan...@qcd.lanl.gov (Tanmoy Bhattacharya) writes:
>
> >Moreno) writes:
> ><snip>
> >|> A colleage of mine (very good fortran programmer) always said to me
> >|> that the problem with FORTRAN was that commercial compilers had extensions
> >|> and defaults which were meant for optimization and ease of use, normally
> >|> you were __encouraged__ to use those extensions because of performance
> >|> or pure sloth... The problem was that different suppliers had different
>
> simply ignore extensions. You have to go out of your way
> to use them! You have to get them out of the supplier's
> manual!
>
The problem is that the documentation provided by too many vendors does
NOT make clear what features are extensions and what are not. Certainly,
this is not true of ALL vendors .... some do a fantastic job with colour
coded docs or other schemes to make the reader know what is an extension.
Reading the official language spec is not the way most people learn a
language. Some read text books (and some texts get it wrong), others look
at docs provided with the local compiler.
> >I have been coding in Fortran for quite some time: and most often
> >I used vendor extensions for two reasons:
>
[A few reasons deleted [4 to be exact]]
>
> >5) Ignorance: Most of us are programming because we need to: and most of us,
> > do not have time to learn the language well.
>
> ---Don't be ridiculous. If you're using the language a lot,
> you're looking up a reference book -- you have to know it well
> in order to use it ! ! !
>
Come on... In the real world, you're still tied in to the truth as
presented in that reference. Also remember that not everyone CARES
about porting --- they're out to do a particular job, and latch on
to the first feature they find which does it.
Hands up those who believe there is an IMAG intrinsic and that case
statements, enddo, do while are part of the language. Bit manipulation
functions? Different vendors provide some or all of these, and document
them as part of the "FORTRAN language". None are standard (at least in F77).
One or two have caught me from time to time when porting code; I know
some people who are adamant that compiler X is broken because it doesn't
provide a case statement.
---------------- <Standard Trailer>
Robert O'Dowd Phone : +61 8 259 7097
Bldg. 113 TSAN Fax : +61 8 259 6104
P.O. Box 1500 E-mail : r...@dstos3.dsto.gov.au
DSTO Salisbury, South Australia, 5108 OR r...@mod.dsto.gov.au
Disclaimer: Opinions above are MINE and probably worth what you paid for them.
Rick Venable
> on some engineering project, maybe I'll use FORTRAN, but that's matter of
> personal choice in the first place, and field oriented choice on the second
> place. In that order. I learned to write in C so if I can use it in current
> project, I'll use it. Maybe FORTRAN programmers thinks in the same way as me,
> but v.v. I have never seen useful compiler for any language written in FOR-
> TRAN, but there is many engineering tools written in C. Further than that is
Actually, for quite some years a few major Fortran compilers were written
in Fortran, but I suspect that may no longer be the case. I compliment
your ability to determine what language a program is written in just by
using it and not seeing the source code.
> useless to discuss this subject, because we enter to an area of personal
> choices. Also we all can conclude one thing, and that is that no perfect
> programming language exists. Just use what you like to use, and be good at
> that.
Isn't it better to use the best tool for the job? Sure, write your OS and
compilers in C, since it is best for that, but I remain unconvinced that
anything but Fortran should be used for numerically intensive code where
raw speed is the objective. The superior performance of Fortran on number
crunching applications in science, engineering, and statistics is more than
personal choice; "use what you like to use" is not the most rational way to
choose your tools.
--
Rick Venable =====\ |=| "Eschew Obfuscation"
FDA/CBER Biophysics Lab |____/ |=|
Bethesda, MD U.S.A. | \ / |=| / Not an official statement \
rven...@deimos.cber.nih.gov \/ |=| \ or position of the FDA. /