F90 just a toy? Newbie's Q
Mark Hays
I have a semi-serious question about FORTRAN 90. Is
it just a toy at this point?
I am an applied mathematician and have been
programming in C for a number of years. When I read
Metcalf and Reid's book on F90 I was excited -- a
FORTRAN that inspires source code you can actually
*read* (apologies to any veteran FORTRAN programmers
who take offense -- I just have difficulty remembering
what rpar(37) is, /usr/lib/cpp notwithstanding). Data
structures, etc. Plus the infinitely optimizable array
operations make finite differencing a breeze (and
fast).
At this point I have used 2 F90 compilers on 3
platforms. My experience has been that a great many
(critical) things vary between compiler
implementations and platforms. In particular, the lack
of control of the details of storage classes (stack
vs. heap -- unless you explicitly allocate()) and
(automagical) pointers have been particularly
difficult, especially between OS's. There are many
details, but I am left with the impression that the
vendors aren't serious about F90 -- because nobody
seems to be using it, other than on toy problems (< a
few megabytes).
Being an F90 newbie, I figured I'd ask: is it
worthwhile/intelligent writing large codes in F90? Or
was the standard dead before it became available
(wouldn't be the first time)? So far I have found that
the compilers leave something to be desired (i.e.,
many verified bugs) and that F90 code is far less
portable -- though much shorter, clearer, and simpler
-- than the corresponding F77 code.
Any feedback appreciated,
Mark
Prof. Loren Meissner
>
> I have a semi-serious question about FORTRAN 90. Is
> it just a toy at this point?
> My experience has been that a great many
> (critical) things vary between compiler
> implementations and platforms. In particular, the lack
> of control of the details of storage classes (stack
> vs. heap -- unless you explicitly allocate()) and
> (automagical) pointers have been particularly
> difficult, especially between OS's. There are many
> details, but I am left with the impression that the
> vendors aren't serious about F90 -- because nobody
> seems to be using it, other than on toy problems (< a
> few megabytes).
I think you have come to the right place. I hope you get a lot
of answers from "real people".
Fortran standards (since 66) have always tried to specify the
parts that have to work the same on all systems and to leave
the "implementation details" unspecified. [Witness recent
conversations about whether DATA implies SAVE in F77.]
As to who is using it, certainly SOME BIG users are. How many, I can't
say. You may have seen the following in one of my recent postings:
"You could read Prentice's article in Fortran Forum, March 95. He is
head of a computing service that does BIG projects; "...we employ
Fortran 90 as our main language.
..
"Mike Metcalf at CERN (they do BIG projects there, too) found that even
the early F90 compilers were doing about as good at "number crunching"
as their mature F77.
"Numerical Recipes is working hard on a F90 version of their codes that
can take advantage of ways of using F90 features along with the
parallelism possible on modern hardware.
"There were a lot of numerical-savvy people involved in F90 design,
and a lot of what went in (especially in the ARRAY area) was designed
to work faster and more smoothly on a variety of modern architectures.
"I firmly believe that modern scientific and engineering shops are
going to have to switch to F90 soon to stay competitive..."
-Loren Meissner
Dan Pop
> I have a semi-serious question about FORTRAN 90. Is
>it just a toy at this point?
Nope, it's a soon-to-be-superseded programming language.
> Being an F90 newbie, I figured I'd ask: is it
>worthwhile/intelligent writing large codes in F90? Or
Yes, if the problem is suitable for the language.
>was the standard dead before it became available
>(wouldn't be the first time)? So far I have found that
>the compilers leave something to be desired (i.e.,
>many verified bugs)
The compiler technology for F90 is still very young. The first native
compilers have been released less than 2 years ago. They'll get better
(less bugs and more efficient executables) in time.
> and that F90 code is far less
>portable -- though much shorter, clearer, and simpler
>-- than the corresponding F77 code.
The F90 code is as portable as you write it. If you break the standard
and rely on implementation specific features, your code won't be portable.
This is entirely your fault, not F90's. If you have examples of correct
F90 code which should be portable, but it isn't, please post them.
Dan
--
Dan Pop
CERN, CN Division
Email: Dan...@mail.cern.ch
Mail: CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland
Prof. Loren Meissner
>
> > ... FORTRAN 90
>
> it's a soon-to-be-superseded programming language.
>
be a better description of the change? And maybe not quite so scary
for the "newbies"?
-Loren Meissner
Dan Pop
Aren't the two expressions perfectly equivalent? Why should a newbie
by more scared by one than the other? :-)
The "newbies" who had followed the F95 discussions in c.l.f already know
that F95 is mostly a "maintenance release" and will contain only
"minor" additions to F90, so they shouldn't be scared at all.
Prof. Loren Meissner
>
> superseded
> ...
> "newbies" who had followed the F95 discussions in c.l.f
Sorry, Dan. I was looking at the wrong dictionary --
SUPERSEDED: replaced by C++
NEWBIE: Someone who has never heard of F95
I'll be glad to switch to your definitions for the future.
-Loren Meissner
Kenneth Plotkin
Prof. Loren Meissner <meis...@usfca.edu> wrote:
[snip]
Dan...@mail.cern.ch (Dan Pop) wrote:
[snip]
I have a question. Both of you have been advocates of F90. Despite my
retro attitude, I recognize that I'll need to follow the crowd. But
in this thread you've painted a picture of F90 compilers not quite being
right yet. Is that correct? Do I now have an excuse to hold off longer,
'til F95 is out and working?
BTW, I prefer the term "superseded" to "upgraded". When I hear the term
"upgrade" with regard to software, I feel like I'm about to be treated to a
nice pot of nail soup, at no charge.
Ken Plotkin
Klaus Wacker
> In <3vc8e1$g...@cortaro.math.arizona.edu> ha...@math.arizona.edu (Mark Hays) writes:
> > and that F90 code is far less
> >portable -- though much shorter, clearer, and simpler
> >-- than the corresponding F77 code.
> The F90 code is as portable as you write it. If you break the standard
> and rely on implementation specific features, your code won't be portable.
> This is entirely your fault, not F90's. If you have examples of correct
> F90 code which should be portable, but it isn't, please post them.
In the project I am working on, if I write perfectly standard-
confortming F90, it won't be portable to most of the 37 or so
institutes we are collaborating with. They don't have an F90 compiler.
F77 and C are portable, even with some non-standard features.
--
Klaus Wacker wac...@Physik.Uni-Dortmund.DE
Exp. Physik V +49 (231) 755 3587
Uni Dortmund
D-44221 Dortmund
Dan Pop
>Prof. Loren Meissner <meis...@usfca.edu> wrote:
>[snip]
>Dan...@mail.cern.ch (Dan Pop) wrote:
>[snip]
>
>I have a question. Both of you have been advocates of F90. Despite my
>retro attitude, I recognize that I'll need to follow the crowd. But
>in this thread you've painted a picture of F90 compilers not quite being
>right yet. Is that correct?
Compared to F77, which has been around for _many_ years and which didn't
introduce any major features over F66 (character variables and block IFs
were probably the most important new features), F90 is both revolutionary
and "young". There's no secret that _some_ of the new features are not
implemented as efficiently as the old ones on most compilers. There are
cases where hand optimized array processing using the classic syntax will
beat the array notation of F90 (at the cost of the code maintainability
however), but this is still no excuse for sticking to F77. The old
optimization tricks used by the performance hungry programmers still
work on the new compilers. But there are also lots of new features which
come without _any_ performance penalty. Ever been frustrated that your
"F77" code using automatic arrays or Cray pointers is rejected by another
compiler?
>Do I now have an excuse to hold off longer, 'til F95 is out and working?
No, you have no excuse. F95 clarifies certain aspects of the F90 standard,
adds a few new features and drops a few obsolete features. The F95
compilers will be simply upgrades to the current F90 compilers.
Dan Pop
>Dan Pop (Dan...@mail.cern.ch) wrote:
>> In <3vc8e1$g...@cortaro.math.arizona.edu> ha...@math.arizona.edu (Mark Hays) writes:
>[...]
>> > and that F90 code is far less
>> >portable -- though much shorter, clearer, and simpler
>> >-- than the corresponding F77 code.
>
>> The F90 code is as portable as you write it. If you break the standard
>> and rely on implementation specific features, your code won't be portable.
>> This is entirely your fault, not F90's. If you have examples of correct
>> F90 code which should be portable, but it isn't, please post them.
>
>In the project I am working on, if I write perfectly standard-
>confortming F90, it won't be portable to most of the 37 or so
>institutes we are collaborating with. They don't have an F90 compiler.
>F77 and C are portable, even with some non-standard features.
The original poster complained about F90 code not being portable between
F90 compilers (if I understood correctly). Your point is pointless :-)
because F77 code (with or without extensions) won't be portable to
someone who doesn't have an F77 compiler and C code won't be portable to
someone who doesn't have a C compiler.
Please remove your foot from your mouth before posting again.
Klaus Wacker
> In <3vi361$h...@nx2.hrz.uni-dortmund.de> wac...@kant.Physik.Uni-Dortmund.DE (Klaus Wacker) writes:
> >Dan Pop (Dan...@mail.cern.ch) wrote:
> >> In <3vc8e1$g...@cortaro.math.arizona.edu> ha...@math.arizona.edu (Mark Hays) writes:
> >[...]
> >> > and that F90 code is far less
> >> >portable -- though much shorter, clearer, and simpler
> >> >-- than the corresponding F77 code.
> >
> >> The F90 code is as portable as you write it. If you break the standard
> >> and rely on implementation specific features, your code won't be portable.
> >> This is entirely your fault, not F90's. If you have examples of correct
> >> F90 code which should be portable, but it isn't, please post them.
> >
> >In the project I am working on, if I write perfectly standard-
> >confortming F90, it won't be portable to most of the 37 or so
> >institutes we are collaborating with. They don't have an F90 compiler.
> >F77 and C are portable, even with some non-standard features.
> The original poster complained about F90 code not being portable between
> F90 compilers (if I understood correctly). Your point is pointless :-)
Well, maybe you misunderstood. He didn't say so explicitly. Maybe he
heard it as a rumour where the context got lost. I guess I didn't make
myself too clear, what I was trying to say is the following:
- There is a context in which the statement "F90 code is far less
portable" is true.
- In the environment I am working in (a High Energy Physics
experiment), this "portability" problem (call it something else if you
like) is the reason why I am not starting to use F90 features in newly
developed or upgraded programs.
- If there is any observable movement away from F77 in this environment,
then it is towards C and not towards F90.
> because F77 code (with or without extensions) won't be portable to
> someone who doesn't have an F77 compiler and C code won't be portable to
> someone who doesn't have a C compiler.
> Please remove your foot from your mouth before posting again.
Thank you for the advice. Last time I checked, both my feet were
firmly on the ground below the table I am sitting at.
Jim Glass ; JF ; GLASS ; x586-0375 ; (W) ; 634-000
You are violating the Unwritten Law.
Speak this particular truth and Men in Black will come visiting in the night.
You and me are the ONLY ONES who know that F90 is merely the result
of pointy-headed academics hijacking the once elegant and simple
Fortran language standard.
Softly now, I whisper the Central Mystery: why on Earth (if that's indeed
where they're from) would sane humans want to convert lovely, clean,
straightforward Fortran into (shudder) Pascal? Or is it one of those other
Wirth-less languages they're trying to mutate it into? I dunno.
Keep the faith. Keep yer head down. And watch out for the MIB...
Jim Glass
*********************************************************************************
* gl...@rdyne.rockwell.com * "The Earth is the cradle of the Mind, *
* Jim Glass * But you cannnot stay in the cradle forever." *
* Member of Technical Staff * - Konstantin E. Tsiolkovsky *
* Systems Architecture *************************************************
* Rocketdyne Division * *
* Rockwell International * I don't speak for Rocketdyne *
* Mail Stop IB-59 * and Rocketdyne doesn't speak *
* 6633 Canoga Avenue * for me. *
* P.O. Box 7922 * *
* Canoga Park, CA 91309-7922 * (But then, you knew that!) *
* (818) 586-0375 * *
*****************************************************************
Brian P. Tremaine
>someone who doesn't have an F77 compiler and C code won't be portable
to
>someone who doesn't have a C compiler.
>
>Please remove your foot from your mouth before posting again.
>
>--
>Dan Pop
I disagree, the point he made is if you are the the first on your block
to have the newest compiler you are not compatible with your neighbors.
If that is not an issue so be it, if it is an issue keep F77 around.
--
Brian P. Tremaine |
Seagate Technology |
Scotts Valley, CA |
(408) 439-2757 |
Prof. Loren Meissner
> ... F90 compilers not quite being
> right yet. Is that correct? Do I now have an excuse to hold off longer,
> 'til F95 is out and working?
Making a compiler for Fortran 90 is a non-trivial task and, as might
be expected, the new ones have had some bugs. By now, there are several
that have been around quite a while and have gone through a few
versions and are really pretty clean. The one I know most about is
NAG "f90" and I haven't sent them a bug report in more than a year.
The bugs I have found are not the "sneaky" kind, either. The F90
language is designed so that - IF you use the checks and warnings that
are available to you [e.g. "always use IMPLICIT NONE" and explicit
interfaces] - the compiler can generate code that is pretty
self-consistent. Most of the bugs I have encountered in the newer F90
compilers are failures to accept some valid construct (usually one that
works quite differently from anything in F77, such as certain kinds of
specification expressions).
Waiting for F95 is just a policy decision. My guess is that all of the
F95 compilers will be written right on top of the corresponding F90
products. A new c.l.f. posting showed up today ("Comments requested ..."
from Steve Lionel) that describes what is being added. These are the
sorts of things that do not require major restructuring of the compiler
code; mainly just minor additions.
By the same token, if you switch from F77 to F90 today you are not
going to have to make another major switch when F95 comes along. You
are just going to be able to start adding in the new features.
-Loren Meissner
Dan Pop
>Dan Pop (Dan...@mail.cern.ch) wrote:
>> In <3vi361$h...@nx2.hrz.uni-dortmund.de> wac...@kant.Physik.Uni-Dortmund.DE (Klaus Wacker) writes:
>
>> >Dan Pop (Dan...@mail.cern.ch) wrote:
>> >> In <3vc8e1$g...@cortaro.math.arizona.edu> ha...@math.arizona.edu (Mark Hays) writes:
>> >[...]
>> >> > and that F90 code is far less
>> >> >portable -- though much shorter, clearer, and simpler
>> >> >-- than the corresponding F77 code.
>> >
>> >> The F90 code is as portable as you write it. If you break the standard
>> >> and rely on implementation specific features, your code won't be portable.
>> >> This is entirely your fault, not F90's. If you have examples of correct
>> >> F90 code which should be portable, but it isn't, please post them.
>> >
>> >In the project I am working on, if I write perfectly standard-
>> >confortming F90, it won't be portable to most of the 37 or so
>> >institutes we are collaborating with. They don't have an F90 compiler.
>> >F77 and C are portable, even with some non-standard features.
>
>> The original poster complained about F90 code not being portable between
>> F90 compilers (if I understood correctly). Your point is pointless :-)
>
>Well, maybe you misunderstood. He didn't say so explicitly. Maybe he
>heard it as a rumour where the context got lost. I guess I didn't make
OK, let's read again his text instead of making speculations:
# At this point I have used 2 F90 compilers on 3
# platforms. My experience has been that a great many
# (critical) things vary between compiler
# implementations and platforms. In particular, the lack
# of control of the details of storage classes (stack
# vs. heap -- unless you explicitly allocate()) and
# (automagical) pointers have been particularly
# difficult, especially between OS's. There are many
# details, but I am left with the impression that the
# vendors aren't serious about F90 -- because nobody
# seems to be using it, other than on toy problems (< a
# few megabytes).
Well, maybe I misunderstood,
John A. Turner
[snip]
> The F90 code is as portable as you write it. If you break the standard
> and rely on implementation specific features, your code won't be portable.
> This is entirely your fault, not F90's. If you have examples of correct
> F90 code which should be portable, but it isn't, please post them.
The biggest headache I've had is modules. Every single F90 compiler I've
tried (Fujitsu, SGI, CraySoft, IBM) treats them differently. That is:
- the suffix given to module information files (.kmo, .M, etc.)
- how you tell the other routines how to find the module information files
(some allow a flag to specify a search path, like -I for includes, some
force you to explicitly name each one, etc.)
- where the module information files (some create them in the current
working directory, some create them in the directory where the source
file is, some allow you to specify where they end up, etc.)
This makes makefiles a nightmare for even moderately complicated source
structures.
I realize this isn't something that is addressed by the standard, but it
sure would have been nice if the vendors had talked about this issue and
come up with some de facto conventions.
When I have brought this up to vendors, they always seem surprised that
it's a problem at all. It's as if they've only done testing with source
where everything was all in one file, or at most in a single directory.
+---------------------------------------------------------------+
| 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 |
+---------------------------------------------------------------+
Prof. Loren Meissner
> ...
> optimization tricks
> ...
I agree that "optimization tricks" are not advantageous in the long
run.
For one thing, they have a way of going out of date. Any trick that is
widely useful will probably be picked up by the better compilers and
made "automatic" in a year or so.
A long time ago, if you needed A**7 and A**8 you were supposed to
write your program so it saved A**7 and multiplied it by A to get
A**8. Soon the compilers got good at figuring out integer exponents.
At that point, by saving the intermediate result, your program was
causing an unnecessary extra memory reference that slowed you down.
Soon after that, the compilers got good at deleting useles memory
references.
Analogously, there are still some things that could be done to speed
up whole-array and array-section operations, that some F90 compilers
have not yet put in. So you could do some fancy low-level stuff to
make your program run a little faster. But the chances are good that
your kludge will get in the way next year's compiler that has
figured out how to do your same speed-up automatically.
As a general principle, if you describe your problem to the compiler
in high-level terms, the compiler is free to use any optimizations
that it knows about. If you tell the compiler in detail how it must
be done, you have constrained it from using a variation that might
be better.
-Loren Meissner
Michel OLAGNON
>Hello,
>
> I have a semi-serious question about FORTRAN 90. Is
>it just a toy at this point?
>programming in C for a number of years. When I read
>Metcalf and Reid's book on F90 I was excited -- a
>FORTRAN that inspires source code you can actually
>*read* (apologies to any veteran FORTRAN programmers
>who take offense -- I just have difficulty remembering
>what rpar(37) is, /usr/lib/cpp notwithstanding). Data
>structures, etc. Plus the infinitely optimizable array
>operations make finite differencing a breeze (and
>fast).
I would be very interested to know of how control of
such details of a storage class improves portability,
or how they are critical. Certainly, if you want to
control everything, you better switch from C to assembly
language than to F90.
As for myself, I have written many small (about 10 000 lines)
applications in F90, and some of them are used routinely
365.2325 days a year by commercial firms.
I produce about 3 times more code in the same time as with F77.
There is a small performance penalty that I evaluate to 0% < < 30%,
and that I believe is due to optimisers' immaturity. But this
leaves me plenty of time for hand optimization (where my
scores have, for the last 15 years, always ranged between 50 and
99.85%) if the application is very performance sensitive,
and the higher level of abstraction makes it easier.
Yet, I certainly am not a typical F90 programmer, because I
only switch to specific F90 constructs when they show
improvement over their F77 counterparts ...
Michel
--
| Michel OLAGNON email : Michel....@ifremer.fr|
| IFREMER: Institut Francais de Recherches pour l'Exploitation de la Mer|
Sergio Gelato
Mark Hays <ha...@math.arizona.edu> wrote:
> I have a semi-serious question about FORTRAN 90. Is
>it just a toy at this point?
No, it's quite usable.
Most of the important points have already been made by others, but let me
add one or two.
> At this point I have used 2 F90 compilers on 3
>platforms. My experience has been that a great many
>(critical) things vary between compiler
>implementations and platforms. In particular, the lack
>of control of the details of storage classes (stack
>vs. heap -- unless you explicitly allocate()) and
>(automagical) pointers have been particularly
>difficult, especially between OS's. There are many
>details, but I am left with the impression that the
>vendors aren't serious about F90 -- because nobody
>seems to be using it, other than on toy problems (< a
>few megabytes).
Some vendors are dead serious. Others aren't, or weren't until
recently. (I am thinking mainly of the late starters on compiler
development: HP, SGI?)
I use Fortran (and on the machine where I do my production runs,
the only Fortran compiler supports the full 90 standard) on large
problems (>1 Gbyte of memory, 300-500 CPU hours per run). Granted,
my code still makes relatively modest use of the new features (it
was developed in F77, and I still occasionally need to run it on
systems that don't have F90 yet). But it does use a mix of stack
allocation (local variables, including some arrays) and heap allocation
(allocatable arrays). No pointers: the problem does not require them.
If you feel you must have explicit control of the low-level
details of storage classes, then (a) you probably missed that ALLOCATE()
*must* use a heap, at least for SAVEd variables, and that plain unSAVEd
local arrays are most likely to end up on the stack; and (b) either you
are running into system-dependent limits on stack or heap size (a possibility
if you have very large arrays) or your thinking is unduly conditioned by some
other programming language that forces you to be aware of low-level details.
Some of the new language features do incur appreciable space and/or
time penalties when used. Array sections with non-unit stride (and with
unsophisticated optimizers, even with unit stride) as actual arguments
to subprograms often require the section to be copied to a temporary, for
example. Someone someday will have to write a book that is to Fortran 90
what _Effective Fortran 77_ is to the old standard. In the meantime, think
about the implications of what you are coding and you should do all right.
> Being an F90 newbie, I figured I'd ask: is it
>worthwhile/intelligent writing large codes in F90? Or
>was the standard dead before it became available
>(wouldn't be the first time)? So far I have found that
>the compilers leave something to be desired (i.e.,
>many verified bugs) and that F90 code is far less
>portable -- though much shorter, clearer, and simpler
>-- than the corresponding F77 code.
Bugs are fixed when a customer reports them and complains about them.
I've found a few bugs in the F90 compilers I use---but none so far in
the latest versions. Portability to systems for which no F90 is available,
or where the institute cannot afford to buy a good F90 compiler, is still
problematic; but supercomputing centres rarely fall into that category,
and where else would you run large codes?
--
Sergio Gelato <gel...@sissa.it>
Harold Stevens
[Snip...]
|> The biggest headache I've had is modules. Every single F90 compiler I've
|> tried (Fujitsu, SGI, CraySoft, IBM) treats them differently.
[Snip...]
|> This makes makefiles a nightmare for even moderately complicated source
|> structures.
[Snip...]
Could we perhaps characterize F90/95 etc. as Pascal with a human face? :)
Regards, Weird
Byron Bodo
>
>
> Prof. Loren Meissner <meis...@usfca.edu> wrote:
> [snip]
> Dan...@mail.cern.ch (Dan Pop) wrote:
> [snip]
>
> I have a question. Both of you have been advocates of F90. Despite my
> retro attitude, I recognize that I'll need to follow the crowd. But
> 'til F95 is out and working?
>
> "upgrade" with regard to software, I feel like I'm about to be treated to a
> nice pot of nail soup, at no charge.
>
> Ken Plotkin
Same here, but there's usually a charge --- often very steep.
The decision to go F90 depends not merely on the compiler, but on
compatibility with 3rd party libraries and linkages to other software.
Just as F90 seemed to be stabilizing somewhat, now they're pushing on
to F95. Diving in now will likely assure another incessant barrage
of vendor propoganda demanding ever more $ for the latest minor
revision that's incompatible with everything else.
When F90-F95 reaches a reasonable level of maturity / stability
I'll reconsider. It doesn't seem to be there yet, specially for
add-on librairies & general 3rd party compatibility.
-bb
Kenneth Plotkin
Prof. Loren Meissner <meis...@usfca.edu> wrote:
[snip]
>A long time ago, if you needed A**7 and A**8 you were supposed to
>write your program so it saved A**7 and multiplied it by A to get
>A**8. Soon the compilers got good at figuring out integer exponents.
[snip]
I remember when the classic example of efficient programming was to do
A*A rather than A**2. I was absolutely delighted when I used DEC Fortran
IV in the late '70s, and the manual made a point of saying that A**2 was
faster for that compiler.
>in high-level terms, the compiler is free to use any optimizations
>that it knows about. If you tell the compiler in detail how it must
>be done, you have constrained it from using a variation that might
>be better.
That is a really good point. I think most Fortran users are experts in
some area, and we command some degree of professional respect. The same
respect should be accorded to the compiler writers, who are quite expert
at their thing. It's also nice to off-load part of the job onto somebody
else!
Ken Plotkin
Prof. Loren Meissner
>> F95 ... revision that's incompatible with everything else.
Do you know what you are talking about?
--Loren Meissner
Michael Lemke
Kenneth Plotkin <kplo...@access2.digex.net> wrote:
>
>I remember when the classic example of efficient programming was to do
>A*A rather than A**2. I was absolutely delighted when I used DEC Fortran
>IV in the late '70s, and the manual made a point of saying that A**2 was
>faster for that compiler.
It isn't on a Sun, Solaris, Fortran 3.0.1.
cass00> cat xx.f
a = 3.
x = 0.
do i = 1, 10000000
x = x + a**2
end do
type *, x
end
cass00> f77 -O4 -cg92 xx.f
xx.f:
MAIN:
cass00> time a.out
8.18641E+07
1.85u 0.08s 0:02.53 76.2%
cass00> time a.out
8.18641E+07
1.89u 0.09s 0:02.27 87.2% <------------- a**2
cass00> cat xx.f
a = 3.
x = 0.
do i = 1, 10000000
x = x + a*a
end do
type *, x
end
cass00> f77 -O4 -cg92 -V xx.f
f77: SC3.0.1 24 Jan 1995
f77pass1: SC3.0.1 01 Feb 1995 Sun FORTRAN 77 3.0.1 patch 101911-04
xx.f:
MAIN:
iropt: SC3.0.1 13 Jul 1994
cg: SC3.0.1 20 Jan 1995 patch 101934-04
ld: Software Generation Utilities (SGU) SunOS/ELF (LK-1.4 (S/I))
cass00> time a.out
8.18641E+07
0.82u 0.10s 0:02.53 36.3%
cass00> time a.out
8.18641E+07
0.81u 0.12s 0:01.39 66.9% <------------- a*a
cass00> uname -a
SunOS cass00 5.4 Generic_101945-32 sun4m sparc
Michael
--
Michael Lemke
Institute of Astronomy, Cambridge UK
(mic...@io.as.utexas.edu or UTSPAN::UTADNX::IO::MICHAEL [SPAN])
Michael Lemke
>kplo...@access2.digex.net (Kenneth Plotkin) wrote:
>>
>>
>> Prof. Loren Meissner <meis...@usfca.edu> wrote:
>> [snip]
>> [snip]
>>
>> I have a question. Both of you have been advocates of F90. Despite my
>> retro attitude, I recognize that I'll need to follow the crowd. But
>> in this thread you've painted a picture of F90 compilers not quite being
>> right yet. Is that correct? Do I now have an excuse to hold off longer,
>> 'til F95 is out and working?
>>
>> BTW, I prefer the term "superseded" to "upgraded". When I hear the term
>> "upgrade" with regard to software, I feel like I'm about to be treated to a
>> nice pot of nail soup, at no charge.
>>
>> Ken Plotkin
>
>Same here, but there's usually a charge --- often very steep.
>The decision to go F90 depends not merely on the compiler, but on
>compatibility with 3rd party libraries and linkages to other software.
This is actually what keeps me from learning it. I can't compile my new
routines with, say, NAG f90 (which is installed here) and link with the
graphics package that was compiled with Sun's f77. And there is no way
to get the grafix to compile with f90. Or make calls from a f90 program
to system lib functions that come with Sun Fortran (or possibly C
functions, like ioctl or so). Or simple stuff like this:
cass00> cat xx.f
character lin*20
call getarg( 1, lin )
print *, lin
end
cass00> f77 xx.f
xx.f:
MAIN:
cass00> a.out sdq
sdq
cass00> f90 xx.f
Extension: TAB format input at line 1
Extension: TAB format input at line 3
Extension: TAB format input at line 5
Extension: TAB format input at line 7
[f90 continuing despite warning messages]
Undefined first referenced
symbol in file
getarg_ xx.o
ld: fatal: Symbol referencing errors. No output written to a.out
Umph. Maybe I can add some -lF77 or some such but were's the guarantee
it won't conflict with f90 stuff?
Neil Carlson
> time penalties when used. Array sections with non-unit stride (and with
> unsophisticated optimizers, even with unit stride) as actual arguments
> to subprograms often require the section to be copied to a temporary, for
Ack! Is this true? Clearly, behind-the-scenes copying occurs with
expressions as actual arguments, but where else? I need to avoid these
situations.
A related question: In coding array expressions it's often convenient or
neccessary to use an automatic temporary array. Would I be correct in
assuming that the processor is not required to actually allocate the array?
I would hope that at most only a scalar temporary would actually be allocated,
but perhaps I'm being naive.
- Neil Carlson
Prof. Loren Meissner
>
> In article <3vmkm5$b...@access2.digex.net>,
> Kenneth Plotkin <kplo...@access2.digex.net> wrote:
> >
> >I remember when the classic example of efficient programming was to do
> >A*A rather than A**2. I was absolutely delighted when I used DEC Fortran
> >IV in the late '70s, and the manual made a point of saying that A**2 was
> >faster for that compiler.
>
> It isn't on a Sun, Solaris, Fortran 3.0.1.
>
cause. You can make it faster today, but you might be stepping on
the toes of tomorrow's optimizer technology.
Express your program at the highest level that is permitted by your
programming language. Let the compiler writers figure out how to
optimize it. [There are exceptions, of course, but mainly they are
advantageous only in the short term. The A*A case is a simple but
typical example.]
-Loren Meissner
Dr. Albert Hybl
hijacked FORTRAN and substituted their ethereal ideas.
The term "pinhead academic" is an oxymoron just as "standard
fortran" is. Differences between compilers are nightmares for
users who work with different OSs or hardware, although each
compiler may conform with the official documentation.
If we are interested in portability, then what we need are portable
compilers--like f2c/gcc and g77 along with a portable OS--like
Linux.
g77x might be an useful platform for experimenting with new features.
For a start, I suggest looking at the 21 items posted in a wish list
by W.R. Grunes.
Regards,
Albert
Byron Bodo
Sergio Gelato
>expressions as actual arguments, but where else? I need to avoid these
>situations.
It *has* to occur when passing an array section with non-unit stride to
a subprogram without an explicit interface. I think it also has to occur
when the interface is explicit but the dummy argument is not an assumed-
shape array, since the compiler then has to assume that the subprogram
might be called from a point where the interface is implicit and cannot
count on there being a dope vector in the argument list. The standard
probably does not prohibit a processor from testing for the presence of
a dope vector at run-time or other such tricks, but the compilers I know
of haven't reached that level of sophistication yet. They probably never
will, as it's easier to just tell the performance-conscious programmer
using these new features to make the dummy argument assumed-shape. Or
to pass a pointer to the array section, which should also work (and
prevent a temporary copy form being made at the point of call; though
you may find that the subprogram will make temporary copies internally,
and in some cases this may actually make the code run faster).
>A related question: In coding array expressions it's often convenient or
>neccessary to use an automatic temporary array. Would I be correct in
>assuming that the processor is not required to actually allocate the array?
That depends on the details of the array expression, but yes, there is a
large class of situations in which the compiler would be allowed to replace
the array temporary with a scalar.
>I would hope that at most only a scalar temporary would actually be allocated,
>but perhaps I'm being naive.
Whether current compilers are able to perform that optimization in all the
circumstances you would hope for is doubtful. But the situation is really
no different from that in the early days of vectorizing compilers, when
CFT (or VS Fortran) would vectorize some constructs but not others.
In performance-critical sections of the code, it still pays to write out
both versions of the loop, benchmark them, and use the faster one on any
given processor. Elsewhere, you can just wait for compiler technology to
improve. This particular point is definitely being worked on (on architectures
where it is relevant: on a classic Cray, a vector temporary might yield
faster code than a scalar one anyway; and a parallelizing compiler might
elect to evaluate the array expression in parallel instead.)
--
Sergio Gelato <gel...@sissa.it>
Michael Lemke
>>
>> In article <3vmkm5$b...@access2.digex.net>,
>> Kenneth Plotkin <kplo...@access2.digex.net> wrote:
>> >
>> >I remember when the classic example of efficient programming was to do
>> >A*A rather than A**2. I was absolutely delighted when I used DEC Fortran
>> >IV in the late '70s, and the manual made a point of saying that A**2 was
>> >faster for that compiler.
>>
>> It isn't on a Sun, Solaris, Fortran 3.0.1.
>>
>That's the whole point. Trying to outguess the optimizer is a lost
>cause. You can make it faster today, but you might be stepping on
>the toes of tomorrow's optimizer technology.
Though it looks as it hasn't made it in 20 years into Sun's product.
And I very much like to write
x = a(i)**2
instead of the 20 year old technique of
t = a(i)
x = t*t
I didn't check if this is still necessary (or if it hurts) but I have
tons of old code that does this sort of thing. And it was not without
reason when the stuff was written.
>
>Express your program at the highest level that is permitted by your
>programming language. Let the compiler writers figure out how to
>optimize it. [There are exceptions, of course, but mainly they are
>advantageous only in the short term. The A*A case is a simple but
>typical example.]
>
But I can't wait 20 years for that to happen (typical research grants
run out much sooner ;-|)
Dan Pop
>Byron Bodo <bo...@io.org> wrote:
>>
>> "Prof. Loren Meissner" <meis...@usfca.edu> wrote:
>> >
>> > Byron Bodo <bo...@io.org> wrote:
>> >
>> > >> F95 ... revision that's incompatible with everything else.
>> >
>> > Do you know what you are talking about?
>> >
>> > --Loren Meissner
>> >
>> Yes. That was my experience with F77. Do you?
>
>Apologies for the tone of my previous "flame". You were expressing
>a legitimate concern that F90, before people have a chance to
>evaluate it, might be "superseded" [as somebody put it] by another
>revision on the same scale as F77=>F90.
Despite the major _additions_ introduced by F90, it still preserved the
compatibility with F77, so Byron's point is moot.
OTOH, F77 _didn't_ perserve compatibility with F66, yet nobody's griping
about F77. So, maybe Byron was complaining about F77's incompatibility
with the previous standard. If this isn't the case, I'm confused.
Prof. Loren Meissner
>
>
> OTOH, F77 _didn't_ perserve compatibility with F66, yet nobody's griping
> about F77.
There were gripes at first, but they mostly died out when folks caught
on to the new version. The same will happen with any system. However,
F77->F90 is such a major change that the gripes will fade more
slowly, even though in principle compatability is preserved.
-Loren Meissner
Prof. Loren Meissner
>
> "Prof. Loren Meissner" <meis...@usfca.edu> wrote:
> >
> > Byron Bodo <bo...@io.org> wrote:
> >
> > >> F95 ... revision that's incompatible with everything else.
> >
> > Do you know what you are talking about?
> >
> > --Loren Meissner
> >
> Yes. That was my experience with F77. Do you?
Apologies for the tone of my previous "flame". You were expressing
a legitimate concern that F90, before people have a chance to
evaluate it, might be "superseded" [as somebody put it] by another
revision on the same scale as F77=>F90.
What I should have said is simply that the F90=>F95 revision is NOT
on that scale at all. F95 is a very minor revision -- more of a
clean-up. A few of the things that were added [e.g. FORALL] almost
made it into F90.
-Loren Meissner
Robert Corbett
Michael Lemke <mic...@mail.ast.cam.ac.uk> wrote:
>In article <3vo64t$7...@noc.usfca.edu>,
>>>
>>> In article <3vmkm5$b...@access2.digex.net>,
>>> Kenneth Plotkin <kplo...@access2.digex.net> wrote:
>>> >
>>> >I remember when the classic example of efficient programming was to do
>>> >A*A rather than A**2. I was absolutely delighted when I used DEC Fortran
>>> >IV in the late '70s, and the manual made a point of saying that A**2 was
>>> >faster for that compiler.
>>>
>>> It isn't on a Sun, Solaris, Fortran 3.0.1.
>>>
>>That's the whole point. Trying to outguess the optimizer is a lost
>>cause. You can make it faster today, but you might be stepping on
>>the toes of tomorrow's optimizer technology.
>
>Though it looks as it hasn't made it in 20 years into Sun's product.
>And I very much like to write
>
> x = a(i)**2
>
>instead of the 20 year old technique of
>
> t = a(i)
> x = t*t
>
>I didn't check if this is still necessary (or if it hurts) but I have
>tons of old code that does this sort of thing. And it was not without
>reason when the stuff was written.
>
It is not necessary to convert A(I)**2 into a multiplication for the
Sun f77 compiler. The compiler will do it for you.
For other powers, there are reasons one might not wish to expand
exponentiation into multiplications. The expansions of the powers -1,
1 and 2 produce answers that are correct to the last 1/2 ulp. The
expansions of other powers produce greater errors. The magnitude of
the error grows with the magnitude of the exponent. The exp and log
expansion of the power operation can, with a bit (or more precisely
8 bits for single and 12 bits for double) of extra significance,
produce an answer that is never off by more than 2 ulps for the largest
exponent that does not cause the result to overflow or underflow.
Yours truly,
Robert Corbett
Clive Page
I'd like to support that as being a serious problem in the use of
Fortran90 in the large. I'm still coding mostly in Fortran77 and just
beginning to use Fortran90 (we only have f90 compilers on one or two
machines). But it looks to me as if the way that modules are handled in
practice is a serious obstacle to portability. F77 programmers mostly
don't need to bother with make files: if a subprogram needs to be
modified you just recompile it, replace it in the appropriate library,
and re-link the program. A simple and fast process. The only
complication is if you need to modify a COMMON block, then you need to
recompile every subprogram that references it (on Unix systems you can
find these using grep).
But with Fortran90 the module rears its ugly head. I've read half a
dozen books on F90 and not found a single useful piece of advice on how
to deal with modules (perhaps because all compilers handle them
differently). Other threads on this group have pointed out how, in
Fortran90, it is better to use module (or internal) procedures than
external procedures because the error-checking is so much better. As I
see it, however, the snag is that, if you modify anything in a module,
you have to find all other bits of code (subprograms or modules) that
reference that module, then if these are also in modules, all the code
that references those, and so on recursively, before you can be sure you
have located everything that needs to be recompiled. All these
dependencies could (I think) be coded into a makefile, but it's a lot of
effort, and I'm not aware of any tools to do this automatically (and if
you don't do it automatically, it's awfully easy to make a mistake).
But, as I said, I'm new to F90, and maybe there is something that I
misunderstood?
--
-------------------------------------------------------------------------
Clive Page, Internet: c...@star.le.ac.uk
Dept of Physics & Astronomy,
University of Leicester.
Dan Pop
>I'd like to support that as being a serious problem in the use of
>Fortran90 in the large. I'm still coding mostly in Fortran77 and just
>beginning to use Fortran90 (we only have f90 compilers on one or two
>machines). But it looks to me as if the way that modules are handled in
>practice is a serious obstacle to portability. F77 programmers mostly
>don't need to bother with make files: if a subprogram needs to be
>modified you just recompile it, replace it in the appropriate library,
>and re-link the program. A simple and fast process. The only
>complication is if you need to modify a COMMON block, then you need to
>recompile every subprogram that references it (on Unix systems you can
>find these using grep).
Nope. make is the right way to go even with large F77 codes. It's far too
easy to make a mistake if you do all the updating manually.
And about F77 being easier because it doesn't have modules: if you call
a procedure with the wrong arguments, you're screwed and nobody's going
to give you a clue about your mistake. Finding it by yourself in a
1,000,000+ lines program might not be particularly easy, especially if
you don't have some adequate tools, like ftncheck.
>
>But with Fortran90 the module rears its ugly head. I've read half a
If you don't like them, don't use them. You can access all the other
F90 features without writing a single F90 module.
>dozen books on F90 and not found a single useful piece of advice on how
>to deal with modules (perhaps because all compilers handle them
>differently). Other threads on this group have pointed out how, in
>Fortran90, it is better to use module (or internal) procedures than
>external procedures because the error-checking is so much better. As I
>see it, however, the snag is that, if you modify anything in a module,
>you have to find all other bits of code (subprograms or modules) that
>reference that module, then if these are also in modules, all the code
>that references those, and so on recursively, before you can be sure you
>have located everything that needs to be recompiled. All these
>dependencies could (I think) be coded into a makefile, but it's a lot of
>effort, and I'm not aware of any tools to do this automatically (and if
>you don't do it automatically, it's awfully easy to make a mistake).
When dealing with large programs, it's even easier to make a mistake
if you don't use modules and makefiles.
>
>But, as I said, I'm new to F90, and maybe there is something that I
>misunderstood?
There are many things you misunderstood:
1. Dealing with large codes has never been easy. F90 makes this process
easier than any of its predecessors.
2. The creation of a makefile is part of the programming process. A bug
in the makefile is as dangerous as a bug in any other part of your
project.
3. It is possible to write an automated makefile generator for F90 (it's
been already done for C). I've no idea whether anobody wrote one or
not.
4. The annoyance caused by the fact that every vendor implemented the
modules in its own way is _minor_ compared to the advantages offered
by the modules. If you disagree, _nobody_ is forcing you to use
modules. To port a F90 code using modules between one platform and
another you don't have to touch any line of F90 code (assuming that the
code itself is portably written). Only the makefile.
Wclodius
1. Although I have not yet needed it, I believe there is a Perl script
that will automatically generate make files from f90 source code for some
systems.
2. With the extra requirements for Fortran 90 it appears to be a
"relatively" small task to automate developement systems to keep track of
file locations and relationships.
William B. Clodius
Michel OLAGNON
> been already done for C). I've no idea whether anobody wrote one or
> not.
Not practical. It is possible with C because the standard knows of file-scope,
and because #include refers to a file name, not to an external reference.
I believe that only the vendor of the compiler and linker can write a
foolproof automated makefile generator (look at the makefile generation
of my f90split: it works only with Nag, and it assumes that all code was split,
and in a single directory, ...)
>
>4. The annoyance caused by the fact that every vendor implemented the
> modules in its own way is _minor_ compared to the advantages offered
> by the modules. If you disagree, _nobody_ is forcing you to use
> modules. To port a F90 code using modules between one platform and
> another you don't have to touch any line of F90 code (assuming that the
> code itself is portably written). Only the makefile.
>
We want to use modules. We also want it to be easy. We don't want to have
to turn into makefile programming experts, and, as you state it yourself,
why do we have to pay for the advantages of modules by going through some
bug-prone makefile programming on each port of our code ?
The best technique whatever is not very good if it is not attractive.
>Dan
>--
>Dan Pop
>CERN, CN Division
>Email: Dan...@mail.cern.ch
>Mail: CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland
Michel
Byron Bodo
>>
>>Apologies for the tone of my previous "flame". You were expressing
>>a legitimate concern that F90, before people have a chance to
>>evaluate it, might be "superseded" [as somebody put it] by another
>>revision on the same scale as F77=>F90.
>
>Despite the major _additions_ introduced by F90, it still preserved the
>compatibility with F77, so Byron's point is moot.
>
>OTOH, F77 _didn't_ perserve compatibility with F66, yet nobody's griping
>about F77. So, maybe Byron was complaining about F77's incompatibility
>with the previous standard. If this isn't the case, I'm confused.
>
>Dan
>--
>Dan Pop
>CERN, CN Division
>Email: Dan...@mail.cern.ch
>Mail: CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland
The compiler's per se aren't that great a concern. Rather, I was
commenting on all the wrangling with suppliers, particularly of
3rd party add-ons such as graphics librairies, trying to get
a working system. The F77 experience involved far too many hours
re-installing, re-testing, re-coding, etc, not to mention
getting stiffed with some products that never worked as advertised.
A big problem was the 3rd party products always lagging the compiler
revisions, and/or never getting the upgrades right.
I know several dynamic modellers with big investments in F77 codes
that are standing pat for the time being until they're convinced that
they can get a full suite of compatible F90 products that are stable
in the sense that they won't be spending more time struggling to install
the revision/upgrade of the month, than doing productive work.
-bb
--
Byron Bodo 240 Markham St. tel: (416) 967 7286
|> |> Toronto, ON fax: (416) 967 9004
|> |> Canada M6J 2G6 email: bo...@io.org
David Singleton
In article <3vsokn$f...@hawk.le.ac.uk>, Clive Page <c...@le.ac.uk> writes:
|>
|> ..... F77 programmers mostly
|> don't need to bother with make files: if a subprogram needs to be
|> modified you just recompile it, replace it in the appropriate library,
|> and re-link the program. A simple and fast process. The only
|> complication is if you need to modify a COMMON block, then you need to
|> recompile every subprogram that references it (on Unix systems you can
|> find these using grep).
[....]
|> external procedures because the error-checking is so much better. As I
|> see it, however, the snag is that, if you modify anything in a module,
|> you have to find all other bits of code (subprograms or modules) that
|> reference that module, then if these are also in modules, all the code
|> that references those, and so on recursively, before you can be sure you
|> have located everything that needs to be recompiled.
If you do not use makefiles with f77, then I dont think f90 changes much
for you. Basically the program unit dependency knowledge needed for each
is not that different. If you change the dummy arguments to a subroutine,
you would have to change any calling routines and recompile them - module
procedures are no different. As you point out, if you change global
variables (common) in f77, you have to be consistent in (and recompile) all
routines using that common. Public module declarations are the same (but
include derived type declarations as well).
The major difference is that some (most) implementations of f90 require
you to compile modules before program units that USE them so that the
public parts are available in some implementation-dependent auxiliary
file.
HOWEVER, IF THE PUBLIC PARTS OF A MODULE DO NOT CHANGE (PUBLIC
DECLARATIONS AND IMPLICIT MODULE PROCEDURE INTERFACES), THEN THERE IS NO
NEED TO RECOMPILE "USE"ING PROGRAM UNITS.
It is only when you want to use the full power of make and the interface
checking etc of f90 that things get tricky (and where vendors dont help by
putting extraneous info in the auxiliary file). Without make, you can
either "get it right by hand" as you do in f77 or you can recompile
everything and be sure of getting the advantages f90 safety features.
|> All these dependencies could (I think) be coded into a makefile, ...
Yes, I have a makefile (with supporting scripts) that generates all
source unit dependencies and generates my own version of the module
auxiliary files (with the minimal public module info in it) which are used
in dependency checks in make. I'm sure it would be easy for vendors to
provide much more robust tools for this purposes or do it right with
their module "interface" files.
----------------------------------------------------------------------------
Dr David Singleton ANU Supercomputer Facility
David.S...@anu.edu.au Australian National University
Work Phone: +61 6 249 4389 Canberra, ACT, 0200, Australia
Home Phone: +61 6 248 7142 Fax: +61 6 279 8199
----------------------------------------------------------------------------
Michael Lemke
>for you. Basically the program unit dependency knowledge needed for each
>is not that different. If you change the dummy arguments to a subroutine,
>you would have to change any calling routines and recompile them - module
>procedures are no different. As you point out, if you change global
>variables (common) in f77, you have to be consistent in (and recompile) all
>routines using that common. Public module declarations are the same (but
>include derived type declarations as well).
>
>The major difference is that some (most) implementations of f90 require
>you to compile modules before program units that USE them so that the
>public parts are available in some implementation-dependent auxiliary
>file.
>
>HOWEVER, IF THE PUBLIC PARTS OF A MODULE DO NOT CHANGE (PUBLIC
>DECLARATIONS AND IMPLICIT MODULE PROCEDURE INTERFACES), THEN THERE IS NO
>NEED TO RECOMPILE "USE"ING PROGRAM UNITS.
>
But isn't it also the case that you have to compile everything in the
correct sequence? So a "f90 *.f" might do not the correct thing? I
haven't used f90 yet (NAG f90 cannot use Sun's f77 produced .o files,
i.e., use non-f90 libraries) so I don't know if this is actually the
case. If so it would *strongly* require Makefiles or at least a
compilation script. And is it possible to have a program where
everything is in the same file but in the wrong sequence, i.e., a
subroutine that USEs a module that appears later in the same file?