wsb@boise.Eng.Sun.COM (Walt Brainerd) (06/22/91)
[Richard Maine pointed out that this was in the Fortran Journal.
Normally, we wouldn't give away our "scoops", but we think
this will be of general interest, historical and otherwise.
One reader already has complained that this a commercial
announcement and possibly "vaporware", but I think many
will want to know about it and evaluate the information
for what it is--i.e., based mostly on information from NAG.
We'll try to provide a review as soon as it is feasible.
Apologies for sending troff (acutally profficient) source.
Officially, it's copyrighted of course, but please distribute
this freely as you like. --Walt Brainerd, Editor, Fortran Journal.]
From the 1991 May/June issue of the Fortran Journal:
..Title "The First Fortran 90 Implementation"
The approval of Fortran 90 as an international standard was
reported in the
..r "Fortran Journal"
in just the last issue.
Now we are pleased to learn of the world's first Fortran 90
implementation, available soon from Numerical Algorithms Group, Ltd.
This article presents some information about this software
and other NAG activities of interest to the Fortran programmer.
..pp
NAG has the first announced compiler that implements all of Fortran 90.
The output language is Kernighan and Ritchie C,
chosen to make it portable to many architectures and operating systems.
It has been tested extensively.
..sub.head "Design Goals"
The design goals of the development were:
..in.level bu
..ip
to produce a true compiler, not just a translator
..ip
to provide good speed of compilation and reasonable efficiency of execution
..ip
to provide good error checking with comprehensible error messages
..ip
to produce a full standard-conforming compiler, with all
constraints identified
..ip
to provide \f2no\fP language extensions
..ip
to produce a modular system that can be modified easily
and used to build other software tools and compilers
..out.level
NAG has been able to produce this compiler in such a timely manner
because they started early and maintained commitment to the development.
Experiments in Fortran 90 compiler
construction started at NAG as long ago as 1987.
The current system is the result
of nearly 18 months development by Malcolm Cohen and others at the NAG
offices in Oxford, UK.
..pp
The NAG f90 compiler is not a
..q "stretched"
Fortran\ 77 system, enhanced beyond its original design.
NAG has continuously tracked the discussions, debates, and draft standards
proposed for Fortran 90 since the Fortran 8X saga began
and has incorporated the changes as agreed into the compiler design.
It is a true compiler in that it utilizes global information
to generate the resulting C code.
..pp
Testing of the NAGWare f90 Compiler has gone on continuously during development.
NAG has encouraged the early development of an extensive
Fortran 90 test suite by Brian Smith,
a leading member of the standardization activity;
this test suite has been used at all stages
to ensure conformance of the activity.
Additionally, NAG's commitment to Fortran 90 and the development
of Fortran 90 based facilities has meant the compiler has received
extensive internal use.
..pp
The use of modular construction and tools such as \f2yacc\fP
mean that
the compiler is supportable and a separate maintenance
service is available.
Extensive error messages are given by the compiler,
both those required by the ISO standard and additional information.
The messages are informative rather than cryptic and often contain context
information to assist in identifying and rectifying the problem.
For this reason the compiler is particularly suited to teaching
and for programmers wishing to update their skills to the new language,
as well as those who want to develop Fortran 90 programs.
..sub.head "Implementation Methodology"
The compiler is written in Kernighan and Ritchie\ C.
The two independent lexers (one per source form) are hand coded.
The parser is generated using \f2yacc\fP with additional error recovery added.
..pp
The compiler has four passes, and the passes have been kept distinct to improve
maintainability and to allow re-use of the components in tools and
customized compilation systems.
The four passes are as follows:
..nr ip1.type 0
..in.level
..nr ip1.indent .8i
..nr ip1.hang .8i
..ip "Pass\ 1:"
Lexical and syntactic analysis is performed; the symbol table and abstract
syntax tree are built.
..ip "Pass\ 2:"
Semantic analysis is done; the parse tree is annotated;
the symbol table is filled in;
all major error and constraint detection takes place.
..ip "Pass\ 3:"
Code is generated form the parse tree transformation.
..ip "Pass\ 4:"
The code is output; declarations are generated;
the flattened parse tree is transformed to K&R C source code
(the system can be modified to produce other dialects).
..out.level
..nr ip1.type 1
..pp
Passes 1 and 2 have been undergoing beta test for many months.
Passes 3 and 4 are being completed at present and have recently
undergone internal alpha-test.
By the end of June, 1991, the complete system, including the
run-time library, will have been throughly beta tested.
..pp
The compiler will have the full range of intrinsic functions
described in the ISO standard.
Intrinsics are implemented using a combination of a run-time library and
in-line code (produced by the code generator), depending on
efficiency and implementation complexity.
..pp
The compiler will have a full implementation of the
input/output capabilities of the standard,
including list-directed, formatted and unformatted,
namelist, and nonadvancing input/output.
Input/output will be handled through a run-time library written in C.
..sub.head "Documentation"
Documentation of the system will be brief.
A note will describe the installation of the software
and a short document will be provided to describe its use
and any implementation specific information.
In addition, NAG intends to provide a copy of the book
..i "Fortran 90 Explained"
by Mike Metcalf and John Reid.
..pp
Because of the implementation language chosen (Kernighan and Ritchie\ C),
the compiler and its output code will be highly portable.
During porting, however, there may need to be modifications to ensure variable
storage is correctly aligned (i.e. byte aligned, short aligned or long
aligned).
The performance of the compiled Fortran 90 code will be directly
dependent upon the C system and run-time libraries employed.
..sub.head "Debugging"
In general the C code resulting from the compiler is legible.
It contains directives that set the file name and line number
so that run-time errors are reported with respect to the original
Fortran 90 source line.
These directives also allow the relationship between the Fortran 90 code
and the resulting C code to be more clearly understood.
The Fortran 90 variable names are maintained in the source code.
A semantics checking version of the compiler
(one without the third and fourth phases) is available
and this can dump a human readable form of the parse tree and
symbol table information.
..sub.head "Availability"
NAG will be launching the NAGWare f90 Compiler in June 1991.
The compiler will be available initially on some Unix workstations.
The system will be provided to the user in executable form only.
Later implementations will include non-Unix hosts.
The licensing of the system will be on a per-machine basis.
Costs will be scaled by machine power.
Annual maintenance will be available.
The user will require access to a C compiler and run-time system;
normally the one provided by the hardware or operating system
vendor will suffice.
..pp
In addition to selling the portable version of the compiler NAG is prepared
to sell or license the Fortran 90 compiler technology to interested parties.
The nature of the sales is open to discussion and negotiation.
For example, it is possible to use the
compiler front-end (passes 1 and 2) to link in with existing code
generation, optimization, and tool technologies.
In addition, NAG is willing
to discuss consultancy to assist in modifying the compiler to integrate it
into existing or planned systems, back-ends, and language extensions.
..last.line -28P
..sub.head "Other Fortran 90 Activities at NAG"
Much of the testing is being undertaken in association with the development
of a comprehensive Fortran 90 test suite.
NAG will be launching the test suite as a product aimed at compiler writers
during the second or third quarter of 1991.
NAG will also be announcing a Fortran 90 Compiler/Tool Validation Service.
A Fortran 90 tool suite containing polishing, transformation,
and analysis tools will be launched in the near future.
A Fortran 90 numerical library is undergoing development.
..sub.head "Fortran 77 Tools"
NAGWare f77 Tools will also be launched during June 1991.
They are a collection of tools for processing, analyzing,
and transforming Fortran 77 source code.
These programs include a
..q "pretty printer" ,
a declaration standardizer,
a tool to change from single to double precision or vice versa,
a restructuring tool,
and a program to provide a static analysis of a whole program,
producing a call graph,
and a portability verifier.
The tools can be used in a range of ways\(emquality assurance,
standardization, porting support or simply in
association with normal development.
Regular use of the tools will speed
development by helping to prevent and find errors and in making the source
code easier to read and understand.
Real benefits can be gained from the
use of the tools during maintenance of existing software as the checks help
to ensure that modifications are properly applied and that the style of the
code remains consistent.
..pp
For more information about the NAG Fortran 90 compiler
and other tools, contact:
..list.start i
In the UK:
NAG Ltd.
Wilkinson House
Jordan Hill Road
Oxford, OX2 8DR, UK
+44 865 511245 865 310139 (fax)
..sp .5
In the US:
NAG Inc.
1400 Opus Place, Suite 200
Downers Grove, IL 60515-5702 USA
+1 708/971-2337 971-2706 (fax)
..list.end
--
Walt Brainerd Sun Microsystems, Inc.
walt.brainerd@eng.sun.com MS MTV 5-40
Mountain View, CA 94043
415/336-5991jrbd@craycos.com (James Davies) (06/24/91)
In article <15634@exodus.Eng.Sun.COM> wsb@boise.Eng.Sun.COM (Walt Brainerd) writes: (from NAG's Fortran-90 announcement) >..sub.head "Fortran 77 Tools" >NAGWare f77 Tools will also be launched during June 1991. >They are a collection of tools for processing, analyzing, >and transforming Fortran 77 source code. >These programs include a >..q "pretty printer" , >a declaration standardizer, >a tool to change from single to double precision or vice versa, >a restructuring tool, >and a program to provide a static analysis of a whole program, >producing a call graph, >and a portability verifier. Is this something new, or is it a new name for TOOLPACK?
jlg@cochiti.lanl.gov (Jim Giles) (06/24/91)
The thing that's most disappointing about NAG's implementation is that it's a preprocessor to C. (They claim that it's a compiler because it does "global" (throughout a whole program unit) analysis, but it still outputs C as it's "object" code.) This means that those users who are the most anxious to try out the 'whole array' notation will get an very unsatisfactory comparison because of the pessimizing effect of C on array (in C: pointers) calculations. Let's hope that someone takes them up quickly on their offer to sell the compiler to anyone who wants it and can afford to white a backend which generates native code on some interesting machines. J. Giles
przemek@rrdstrad.nist.gov (Przemek Klosowski) (06/25/91)
>>>>> On 24 Jun 91 16:31:36 GMT, jlg@cochiti.lanl.gov (Jim Giles) said:
Jim> The thing that's most disappointing about NAG's implementation is that
Jim> it's a preprocessor to C. (They claim that it's a compiler because it
Jim> does "global" (throughout a whole program unit) analysis, but it still
Jim> outputs C as it's "object" code.) This means that those users who are
Jim> the most anxious to try out the 'whole array' notation will get an very
Jim> unsatisfactory comparison because of the pessimizing effect of C on
Jim> array (in C: pointers) calculations.
I understand that Jim is known for his dislike of UNIX and C, so I suppose
that I shouldn't be surprised by his criticism. However, I have to object to
his claim that C is pessimizing the array calculations. Au contraire, it is
well known that some of the optimizations used to treat multidimensional
arrays in Fortran are much easier expressed in C---strength reduction in
index calculations, for example, is naturally expressed in C by having a
pointer to the column (row in C, actually). As far as I can tell, Fortran
could only do it by static (compile time) equivalence.
About translation vs. compilation in general, I believe that the
distinction nowadays became moot. Most of the compilers are multipass,
and use multiple intermediate representations: RTL, ucode, assembler,
and yes, why not C. The bottom line is the speed of the program
(usually not very dependent on the language) and speed of compilation
(admittedly smaller for compilers using many intermediate phases). As
to the former, let me tell you about my own experience: my friend had
a hydrodynamics code in Fortran (many array accesses!). I have heard
rumors that people observed speedups on their fortran code by
translating to C (using f2c). I tried f2c; the result was that the C
code after the automatic translation was 10% slower. I could easily
tune it (avoiding unnecessary intrinsics argument conversion etc), but
the point was that both Fortran and C code was spending time in the
same places! I am afraid that with the current compiler technology it
doesn't matter much. The algorithms DO matter, however, and C seems to
be better in allowing for more complicated data structures etc.
In the case of my friend's code, a lot of time was spent in
calculating distances between particles. Many of these calculations
were unnecessary because the particles were far apart. If I were
writing in C, I would venture to create linked lists of particle
clusters, "topologically" limiting the interactions to clusters of particles
that are known to lie close to each other (a la Jon Bentley). I do not
know of a good way of expressing such things in Fortran (flameproof suit on)
przemek
--
przemek klosowski (przemek@ndcvx.cc.nd.edu)
Physics Department
University of Notre Dame IN 46556jlg@cochiti.lanl.gov (Jim Giles) (06/26/91)
In article <PRZEMEK.91Jun24225047@rrdstrad.nist.gov>, przemek@rrdstrad.nist.gov (Przemek Klosowski) writes: |> [...] |> I understand that Jim is known for his dislike of UNIX and C, so I suppose |> that I shouldn't be surprised by his criticism. However, I have to object to |> his claim that C is pessimizing the array calculations. Au contraire, it is |> well known that some of the optimizations used to treat multidimensional |> arrays in Fortran are much easier expressed in C---strength reduction in |> index calculations, for example, is naturally expressed in C by having a |> pointer to the column (row in C, actually). As far as I can tell, Fortran |> could only do it by static (compile time) equivalence. It is well known that a lot of C bigots promote that myth. It is also well known that a state-of-the-art compiler does not need the user to "express" anything in order to do these optimizations. Strength reduction in index calculations, for example, has been done in Fortran compilers for over 30 years now (that's right, IBM had a proprietary compiler in the early 60's that could do it). The pointer to the row that you talk about C using is the type of pessimization that I'm talking about. In C, the compiler must assume that all pointers are _aliased_ to one another. This means that a simple loop to swap two rows can't be optimized in C because the C compiler can't tell whether the two row pointers are aliased or not. Further, the pointer-to-pointer-to-...-row implementation is only efficient if you access your multidimentional array in the same order as it's declared. If (and many numerical algorithms _require_ this) you have to traverse your array sometimes in row order and sometimes in column order in the _same_ code, you will have an extra address fetch in the inner loop part of the time. The fact that C turns _all_ arrays (regardless of dimensionality) into pointers in the procedure call mechanism means that C must always assume that array parameters are mutually aliased and can't optimize operations on them. All known optimizatation techniques are inhibited to some extent or other by aliasing. On vector or massively parallel machines, the presence of aliasing may mean factors of _hundreds_ in performance. |> [...] As |> to the former, let me tell you about my own experience: my friend had |> a hydrodynamics code in Fortran (many array accesses!). I have heard |> rumors that people observed speedups on their fortran code by |> translating to C (using f2c). [...] Yes, many Fortran compilers (especially on UNIX) are _junk_. Many UNIX Fortran compilers are actually front-ends to the C compiler's code generator. Since, in this arrangement, the backend was tuned to produce good code for _C_, it does not do well for the different constraints that Fortran entails. So what? Outside of UNIX, it is well known that Fortran is usually _much_ faster than C. |> [...] I tried f2c; the result was that the C |> code after the automatic translation was 10% slower. [...] The Fortran Journal published a benchmark on f2c a few issues back. As I remember, the average slowdown was about 15%. The benchmark was done on minis or micros and didn't show the enormous slowdown you'd expect on a vector machine or a massively parallel machine. |> [...] I do not |> know of a good way of expressing such things in Fortran (flameproof suit on) I don't know that you should be flamed. You admitted you didn't know. That's a far cry from the usual C bigot who claims he _does_ know and then spouts a lot of false statements. As for linked lists in Fortran, a lot of us have been doing them for years. Unfortunately, we've had to either use non-standard extensions or we've had to pre-allocate the maximum required memory. Even so, most Fortran implementations have the necessary extensions. The Sun Fortran compiler has Cray style pointers in it (as do several other of the better class of UNIX Fortrans). Fortran 90 will also allow such things as a standard capability (with a pointer facility which has very _bad_ interactions with the whole array features of the language). J. Giles
gsh7w@astsun8.astro.Virginia.EDU (Greg Hennessy) (06/26/91)
In article <26453@beta.gov> jlg@cochiti.lanl.gov (Jim Giles) writes:
#The fact that C turns _all_ arrays (regardless of dimensionality)
#into pointers in the procedure call mechanism means that C must
#always assume that array parameters are mutually aliased and can't
#optimize operations on them.
#The Fortran Journal published a benchmark on f2c a few issues back.
#As I remember, the average slowdown was about 15%. The benchmark
#was done on minis or micros and didn't show the enormous slowdown
#you'd expect on a vector machine or a massively parallel machine.
Why don't you take a benchmark of your choice, run it through f2c,
then use one of the vectorizing C compilers on it, and measure the
"enormous slowdown", that way we would have facts?
--
-Greg Hennessy, University of Virginia
USPS Mail: Astronomy Department, Charlottesville, VA 22903-2475 USA
Internet: gsh7w@virginia.edu
UUCP: ...!uunet!virginia!gsh7wrap@csadfa.cs.adfa.oz.au (Robert Pearson) (06/26/91)
From article <26453@beta.gov>, by jlg@cochiti.lanl.gov (Jim Giles): > > The fact that C turns _all_ arrays (regardless of dimensionality) > into pointers in the procedure call mechanism means that C must > always assume that array parameters are mutually aliased and can't > optimize operations on them. > .. . On vector or massively parallel machines, > the presence of aliasing may mean factors of _hundreds_ in performance. > |> [...] I do not > |> know of a good way of expressing such things in Fortran (flameproof suit on) > I don't know that you should be flamed. You admitted you didn't know. > That's a far cry from the usual C bigot who claims he _does_ know and > then spouts a lot of false statements. As for linked lists in Fortran, > a lot of us have been doing them for years. Unfortunately, we've had > to either use non-standard extensions or we've had to pre-allocate > the maximum required memory. > J. Giles As I also put on my 'flame-proof suite' I have recently had a reaonable amount of experiance in C on a Convex. ( approx 19,000 lines mixed C FORTRAN) I chose C because the problem is essentially building a tree structure and C pointers make the job easier. The mixture of both is related to some existing subroutines which were considerably modified rather than rewriting them completely and also I found it preferable to call NAG and other machine 'veclib' from within fortran. As an aside writing fortran for vectors is much simpler. It is quite possible to write C that translates to vector; espescially if one writes it 'like' fortran and uses the alias array-args on the compiler. I have found some 'quirks'. I always use a local or Global simple integer as loop bounds. ( never in structures, pointers or passed as a paremeter) On earlier versions of the same compiler it was necessary to 'force' even the simplest loops with a consequential compiler warning. For those that are interested some code actually appears in IJHCS vol 2 1990 pp 85-100. Robert Pearson ISD: +61 6 268 8171 STD: (06) 268 8171 Dept. Computer Science Email: rap@csadfa.oz.au University College Aust. Defence Force Academy Canberra. ACT. 2600. AUSTRALIA Robert Pearson ISD: +61 6 268 8171 STD: (06) 268 8171 Dept. Computer Science Email: rap@csadfa.oz.au University College Aust. Defence Force Academy Canberra. ACT. 2600. AUSTRALIA
vsnyder@jato.jpl.nasa.gov (Van Snyder) (06/26/91)
In article <PRZEMEK.91Jun24225047@rrdstrad.nist.gov> przemek@rrdstrad.nist.gov (Przemek Klosowski) writes: [stuff deleted] > In the case of my friend's code, a lot of time was spent in >calculating distances between particles. Many of these calculations >were unnecessary because the particles were far apart. If I were >writing in C, I would venture to create linked lists of particle >clusters, "topologically" limiting the interactions to clusters of particles >that are known to lie close to each other (a la Jon Bentley). I do not >know of a good way of expressing such things in Fortran (flameproof suit on) > > przemek >-- Flameproof suit or none, linked lists in F90 are no more difficult than in C (although sometimes a bit more wordy). -- vsnyder@jato.Jpl.Nasa.Gov ames!elroy!jato!vsnyder vsnyder@jato.uucp
jlg@cochiti.lanl.gov (Jim Giles) (06/26/91)
In article <1991Jun25.214710.21152@murdoch.acc.Virginia.EDU>, gsh7w@astsun8.astro.Virginia.EDU (Greg Hennessy) writes: |> In article <26453@beta.gov> jlg@cochiti.lanl.gov (Jim Giles) writes: |> [...] |> #The Fortran Journal published a benchmark on f2c a few issues back. |> #As I remember, the average slowdown was about 15%. The benchmark |> #was done on minis or micros and didn't show the enormous slowdown |> #you'd expect on a vector machine or a massively parallel machine. |> |> Why don't you take a benchmark of your choice, run it through f2c, |> then use one of the vectorizing C compilers on it, and measure the |> "enormous slowdown", that way we would have facts? And the Fortran Journal _didn't_ publish facts? Is that what you're saying? J. Giles
userAKDU@mts.ucs.UAlberta.CA (Al Dunbar) (06/26/91)
In article <PRZEMEK.91Jun24225047@rrdstrad.nist.gov>, przemek@rrdstrad.nist.gov (Przemek Klosowski) writes: > >>>>>> On 24 Jun 91 16:31:36 GMT, jlg@cochiti.lanl.gov (Jim Giles) said: > >Jim> The thing that's most disappointing about NAG's implementation is that >Jim> it's a preprocessor to C. (They claim that it's a compiler because it >Jim> does "global" (throughout a whole program unit) analysis, but it still >Jim> outputs C as it's "object" code.) This means that those users who are >Jim> the most anxious to try out the 'whole array' notation will get an very >Jim> unsatisfactory comparison because of the pessimizing effect of C on >Jim> array (in C: pointers) calculations. > >I understand that Jim is known for his dislike of UNIX and C, so I suppose >that I shouldn't be surprised by his criticism. However, I have to object to >his claim that C is pessimizing the array calculations. Au contraire, it is >well known that some of the optimizations used to treat multidimensional >arrays in Fortran are much easier expressed in C---strength reduction in >index calculations, for example, is naturally expressed in C by having a >pointer to the column (row in C, actually). As far as I can tell, Fortran >could only do it by static (compile time) equivalence. I have a few problems with a Fortran "compiler" that produces "C" code (or BASIC, or ADA, or ...): 1) experience. Once used a 68000 box (WICAT) with a Fortran of this sort. List directed input of "-9.4" resulted in a value of "-8.6", or "-9" plus ".4". Some precision problems (forget the details). 2) philosophy: I believe (but cannot prove) that the extra translation step will impose non-Fortran-like limits or problems Conversely, that compile time may go up in order to produce a functionally equivalent "C" program, which still must be compiled. Something is always lost in translation, at least in natural languages. Would those Korean assembly instructions be any more intelligible if first translated through French and Latin? 3) support: whose "C" compiler would be used? Hopefully the vendors, and it would be invoked without the user needing to realize it. This means: no "C" related compiler error messages, runtime error messages, or listing messages; availability of Fortran symbols for debugging; no necessity to understand "C" to either use the compiler or generate efficient code with it; and finally, NO phone support operator telling callers that they should switch to "C", and NO $surcharge for purchasing the "C" compiler. No, I'm not "C" bashing. I wouldn't mind being proven wrong, but fail to see the advantage of doing it this way. Once it has been done, of course, it *might* be the best Fortran Compiler choice; I just don't think so. Speaking of language bashing, one of the manuals with the WICAT referred over and over to "ugly old Fortran". It would be as hard for someone with that mindset to produce a good Fortran compiler as it would be for Jim Giles to produce a good "C" compiler, whether or not he chose Fortran as the intermediate language :-) It has been said that what finally (almost) killed Fortran was not its opponents, but the recent standardization (?) exercise. Perhaps this compiler is seen as a way for Fortran's opponents to "finish it off". (another ":-)"). -------------------+------------------------------------------- Al Dunbar | Edmonton, Alberta | Disclaimer: "not much better than CANADA | datclaimer" -------------------+-------------------------------------------
jot@fig12.cray.com (Otto Tennant) (06/26/91)
I'm missing something here. In an earlier post, Mr. Giles noted that one must be able to sweep through an array with equal ease by either rows or columns. This is a simple fact. The C language seems to require that arrays be implemented as pointers to things. This means that one direction is preferred. C is not alone in this. (Thousands will correct me on this, but when I looked at Ada some years ago, it shared this problem.) A translator which produces C, however, is not required to produce readable C. Multi-dimensional Fortran arrays become C vectors with hairy subscripts. In the absence of "#pragma" directives, this does not address the efficiency issue: the aliasing problem is merely directed to a different part of the compiler. But what boots it? The F90 compiler produces a correct description of the described computation in a different language. If the different language is feeble in some respects, well, compilers get smarter every day. -- =============================================================================== J.Otto Tennant Forsan et haec olim meminisse juvabit. jot@cray.com Cray Research, Inc. Virgil (612) 683-5872 665 Lone Oak Drive Eagan, MN 55121
bglenden@colobus.cv.nrao.edu (Brian Glendenning) (06/26/91)
In article <1991Jun26.003429.6364@jato.jpl.nasa.gov> vsnyder@jato.jpl.nasa.gov (Van Snyder) writes:
Flameproof suit or none, linked lists in F90 are no more difficult
than in C (although sometimes a bit more wordy).
F90 looks like a very nice language - but it's not here now, and it
might be years (if ever) before good tools are available for it.
Another worry is that it might not catch on - i.e. Fortran programmers
may stick with F77 and F90 will languish.
The NAG compiler lets you start development now, but if F90 doesn't
catch on you won't have done yourself any favours (no source level
debugging, probably harder to optimize, hard to find programmers...).
NAG lets those who are betting on the future of F90 get a head start.
Despite the fact that we're a traditional Fortran shop, we recently
decided to code a ~50 man year project in something other than Fortran
(C++) because the history of the ANSI committee and our reading of the
tea leaves doesn't lead us to believe that F90 is safe. This decision
was driven by strategic guesses about the next 5 years, F90 would have
been a very suitable language.
Summary: F90 is a fine language with nice features. I fear that the
delays and ANSI making it an alternate Fortran standard may have
killed it.
Brian
--
Brian Glendenning - National Radio Astronomy Observatory
bglenden@nrao.edu bglenden@nrao.bitnet (804) 296-0286orville@weyrich.UUCP (Orville R. Weyrich) (06/27/91)
In article <PRZEMEK.91Jun24225047@rrdstrad.nist.gov> przemek@rrdstrad.nist.gov (Przemek Klosowski) writes: > >>>>>> On 24 Jun 91 16:31:36 GMT, jlg@cochiti.lanl.gov (Jim Giles) said: > >Jim> The thing that's most disappointing about NAG's implementation is that >Jim> it's a preprocessor to C. (They claim that it's a compiler because it >Jim> does "global" (throughout a whole program unit) analysis, but it still >Jim> outputs C as it's "object" code.) This means that those users who are >Jim> the most anxious to try out the 'whole array' notation will get an very >Jim> unsatisfactory comparison because of the pessimizing effect of C on >Jim> array (in C: pointers) calculations. > I would say that if the NAG f90 is truly standard conforming, then it is a great product, regardless of the efficiency of its output. I would greatly prefer having a standard implementation available to compare my results to while I was writing my own whiz-bang hot optimizing f90 compiler. So how about moving this discussion in the direction of how accurately the NAG implementation adheres to the standard? > In the case of my friend's code, a lot of time was spent in >calculating distances between particles. Many of these calculations >were unnecessary because the particles were far apart. If I were >writing in C, I would venture to create linked lists of particle >clusters, "topologically" limiting the interactions to clusters of particles >that are known to lie close to each other (a la Jon Bentley). I do not >know of a good way of expressing such things in Fortran (flameproof suit on) Uh, they were talking at one time about adding pointers to Fortran-9x. Did that get cut during the revision process? -------------------------------------- ****************************** Orville R. Weyrich, Jr., Ph.D. Certified Systems Professional Internet: orville%weyrich@uunet.uu.net Weyrich Computer Consulting Voice: (602) 391-0821 POB 5782, Scottsdale, AZ 85261 Fax: (602) 391-0023 (Yes! I'm available) -------------------------------------- ******************************
orville@weyrich.UUCP (Orville R. Weyrich) (06/27/91)
In article <26487@beta.gov> jlg@cochiti.lanl.gov (Jim Giles) writes: >In article <1991Jun25.214710.21152@murdoch.acc.Virginia.EDU>, gsh7w@astsun8.astro.Virginia.EDU (Greg Hennessy) writes: >|> In article <26453@beta.gov> jlg@cochiti.lanl.gov (Jim Giles) writes: >|> [...] >|> #The Fortran Journal published a benchmark on f2c a few issues back. >|> #As I remember, the average slowdown was about 15%. The benchmark >|> #was done on minis or micros and didn't show the enormous slowdown >|> #you'd expect on a vector machine or a massively parallel machine. >|> >|> Why don't you take a benchmark of your choice, run it through f2c, >|> then use one of the vectorizing C compilers on it, and measure the >|> "enormous slowdown", that way we would have facts? > >And the Fortran Journal _didn't_ publish facts? Is that what you're >saying? Perhaps the issue here is whether 15% slower is an "enormous slowdown"? Perhaps the issue is what happens when one is not using minis or micros? Perhaps the issue is that the Fortran Journal did not consider the use of vectorizing C compilers on machines that could take advantage of vectorization? -------------------------------------- ****************************** Orville R. Weyrich, Jr., Ph.D. Certified Systems Professional Internet: orville%weyrich@uunet.uu.net Weyrich Computer Consulting Voice: (602) 391-0821 POB 5782, Scottsdale, AZ 85261 Fax: (602) 391-0023 (Yes! I'm available) -------------------------------------- ******************************
jlg@cochiti.lanl.gov (Jim Giles) (06/27/91)
In article <1991Jun25.233323.17684@sserve.cc.adfa.oz.au>, rap@csadfa.cs.adfa.oz.au (Robert Pearson) writes: |> [...] |> It is quite possible to write C that translates to vector; |> espescially if one writes it 'like' fortran and uses the alias array-args |> on the compiler. I have found some 'quirks'. Yes, if you use local extensions or non-standard features, _any_ language can have vectorization capability added. The question was whether the output of the NAG Fortran "compiler" or of f2c will vectorize. I suspect not. J. Giles
leipold@eplrx7.uucp (Walt Leipold) (06/28/91)
In article <26334@lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes: >The thing that's most disappointing about NAG's implementation is that >it's a preprocessor to C. (They claim that it's a compiler because it >does "global" (throughout a whole program unit) analysis, but it still >outputs C as it's "object" code.) I like to draw the somewhat fuzzy line between "compiler" and "translator" based on the relative "level" of the source and target languages: source level > target level --> "compiler" source level = target level --> "translator" source level < target level --> "decompiler" Thus, I'd have to say that NAG has come up with a decompiler :-). -- -------------------------------------------------------------------------- "Ninety percent of the politicians give Walt Leipold the other ten percent a bad reputation." (leipolw%esvax@dupont.com) -------------------------------------------------------------------------- -- The UUCP Mailer
gsh7w@astsun8.astro.Virginia.EDU (Greg Hennessy) (06/28/91)
Jim Giles wrotes (in a message that hasn't made it to my machine, so apologies if I missed something important): Me: #>|> Why don't you take a benchmark of your choice, run it through f2c, #>|> then use one of the vectorizing C compilers on it, and measure the #>|> "enormous slowdown", that way we would have facts? #>And the Fortran Journal _didn't_ publish facts? Is that what you're #>saying? I am saying that from your discription the Fortran Journal did not consider vectorizing C compilers, so there are no facts to support you guess that there would be an "enormous slowdown" in code translated into C rather than compiled directly by a fortran compiler. Now, I don't have any facts about the speed loss in a vectorizing C compiler. Do you Jim? Anyone have have speculation. -- -Greg Hennessy, University of Virginia USPS Mail: Astronomy Department, Charlottesville, VA 22903-2475 USA Internet: gsh7w@virginia.edu UUCP: ...!uunet!virginia!gsh7w
mrl@uai.com (Mark R. Ludwig) (06/28/91)
In article <BGLENDEN.91Jun26022131@colobus.cv.nrao.edu>, bglenden@colobus (Brian Glendenning) writes: >Summary: F90 is a fine language with nice features. I fear that the >delays and ANSI making it an alternate Fortran standard may have >killed it. I happen to agree, but I appear to be among the minority at our company. We maintain a medium large, fairly stable scientific application written by government workers and contractors in the '60s and '70s. The people here who've been around Fortran for that whole time think F90 is "not Fortran" any more: it's too radically different. But then these same people aren't "comfortable" using strings in F77 either...$$ -- INET: mrl@uai.com UUCP: uunet!uaisun4!mrl PSTN: +1 213 822 4422 USPS: 7740 West Manchester Boulevard, Suite 208, Playa del Rey, CA 90293 WANT: Succinct, insightful statement to occupy this space. Inquire within.
jlg@cochiti.lanl.gov (Jim Giles) (06/28/91)
In article <1991Jun27.180712.7293@murdoch.acc.Virginia.EDU>, gsh7w@astsun8.astro.Virginia.EDU (Greg Hennessy) writes: |> [...] |> I am saying that from your discription the Fortran Journal did not |> consider vectorizing C compilers, so there are no facts to support you |> guess that there would be an "enormous slowdown" in code translated |> into C rather than compiled directly by a fortran compiler. The following codes (Fortran and C): subroutine copyit(a,b,n) void copyit(a,b,n) integer n int n; real a(n), b(n) float *a, *b; integer i, p, q { float *z; int p, q; p = irtc() p = _rtc(); do i=1,n a(i) = b(i) for(z=a; z<a+n; *z++ = *b++); enddo 1 a(1) = a(n) a[0] = a[n-1]; q = irtc() q = _rtc(); print *, q-p printf("%d\n",q-p); end } Both do the same thing. (CFT77 acepts the Fortran 90 do-loop syntax.) The line labeled 1 is there to force the last vector full of the move to complete before the timing is taken. Irtc() and _rtc() are the real time clock intrinsics on Crays for Fortran and C respectively. For n=10, the Fortran routine is 5 times as fast as the C version. For n=10000, the Fortran version is 1.46 times as fast as the C version. I was puzzled by how fast the C version was able to run. It turns out that the new standard C compiler generates two copies of every loop and does a run-time check for aliasing in the loop prolog. If there is no aliasing, the vector version of the loop is taken, otherwise the scalar version is taken. So, at least for this simple test case, C did not lose vectorization. Still a factor of 5 for small moves is pretty important. So is a slowdown of 46% for big moves. If anyone has a benchmark for a real production code on the Cray using f2c, I'd like to see it. J. Giles
jlg@cochiti.lanl.gov (Jim Giles) (06/28/91)
PS. About the benchmark. If the test case had been complicated enough to lose vectorization, the slowdown would have been a factor of 35 on the n=10000 case. Dependency analysis is hard enough when you can do it statically, I suspect that real codes will lose vectorization on many of their loops even with the standard C compiler's run-time tests installed. Of course, I don't have a _specific_ example of this - it is only a suspicion.
dik@cwi.nl (Dik T. Winter) (06/28/91)
In article <1991Jun27.205204.21086@uai.com> mrl@uai.com (Mark R. Ludwig) writes: > The people here who've been around Fortran for that whole > time think F90 is "not Fortran" any more: it's too radically > different. But then these same people aren't "comfortable" using > strings in F77 either...$$ Yes, and ELSE, END IF and so on. The Fortran I write is still Fortran 66. Lots of GOTO's. (Although Dijkstra, who came from this institute, has something against it; I wonder why.) -- dik t. winter, cwi, amsterdam, nederland dik@cwi.nl