Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!convex!bleikamp From: bleikamp@convex.com (Richard Bleikamp) Newsgroups: comp.lang.fortran Subject: Re: Fortran 90 status Message-ID: <1991Apr26.142249.21064@convex.com> Date: 26 Apr 91 14:22:49 GMT References: <1991Apr24.202115.16119@dragon.wpd.sgi.com> <1991Apr25.235111.26282@alchemy.chem.utoronto.ca> Sender: newsadm@convex.com (news access account) Organization: Convex Computer Corporation, Richardson, Tx. Lines: 167 Nntp-Posting-Host: mozart.convex.com In article <1991Apr25.235111.26282@alchemy.chem.utoronto.ca> mroussel@alchemy.chem.utoronto.ca (Marc Roussel) writes: >Before I write anything more, I wish to make it clear that I am just >trying to satisfy my curiosity. I do not wish in any way to denigrate >the efforts nor to question the motives of anyone on X3J3. > >In article khb@chiba.Eng.Sun.COM > ... deleted text ... > >Why would anyone vote against the standard at this late date? Are there >outstanding technical problems with the standard which these objectors >felt needed to be adressed before the standard is released? > > Marc R. Roussel > mroussel@alchemy.chem.utoronto.ca I'll try to briefly summarize my feelings on the Fortran Extended draft standard (I was one of the no votes). See the last few paragraphs for a summary of what users can expect in the future from vendors. Technical Concerns 1) The array notation is potentially better looking, and more portable than optimization directives, but will NOT produce better performance from a program. In fact, on vector machines, array notation is very likely to run slower! In essence, this is because many algorithms contain loop carried dependencies which a smart optimizer can deal with and still vectorize, but the array notation equivalent will involve user specified vector temps and multiple array notation assignments. The optimizers in Fortran 90 compilers will need to be even smarter than todays best in order to break even performance wise. Certain array operations, such as vector valued subscripts and passing array sections, will dramatically impact performance on most existing architectures (slower!). Although you only pay the performance penalty when you use the features, they still seem extraneous. Note that some users (as opposed to implementors) disagree with this. 2) Modules are defined in such a way as to mandate an extra compiler pass over the parse tree (or some similar structure). It seems likely that a 386/486 based PC with 4+ megabytes will be the minimum architecture able to compile Fortran Extended programs. If it takes 4-5 years for PC based implementations to show up, this isn't a problem, but if user's were hoping to use Fortran Extended on their 286 boxes they are going to be surprised. The new standard has de-emphasized execution time performance in order to make the programmer's life easier. To do this to Fortran, long known for its good execution speed, seems a little crazy. 3) Parameterized datatypes, although providing a potentially portable way to declare variables with the required attributes, are awkward to use portably. KIND numbers are a compromise that neither encourage portability nor adopt existing practice. Procedural Concerns 1) The interactions between X3J3 and WG5 have not always been optimal. Both groups are responsible for this. If X3J3 had produced a more timely standard, friction between the groups would have been much less. 2) The process X3J3 has followed does not work well. In the future, the committee needs to define the desired functionality, get that reviewed (in a public forum), and then design the language features to implement that functionality. This current committee has spent (wasted?) a lot of time taking out and putting in again many features. The lack of consensus on the desired functionality was responsible for this, and it turn lead to many errors being introduced into the document whenever a feature was added or deleted. 3) Public review comment from the 2nd and 3rd public review was largely ignored. Only real serious errors were addressed. Much of this was undoubtly due to the desire to finish the standard before the next ice age started. Earlier public reviews of the intended functionality would have helped. Philosophical Concerns 1) Parallelism and data partitioning for distributed memory architectures are not really addressed. When Fortran 8x was first started, this was not an issue yet, but it is now. Fortran needs a way to express very coarse grained parallelism. 2) This new language is BIG. Almost as big as Ada. I personally feel that a prototype implementation, like DoD funded for Ada, is necessary to shake out the bugs. There is no mechanism in place at ANSI or ISO to undertake an effort like this. 3) Related to 2), much new functionality has been added. Most of this functionality is available in other forms in existing implementations (not always Fortran). But, the committee has consistently chosen to implement new functionality in a different way than existing practice. This significantly increases the risk of introducing unintended functionality which adds to the implementation cost, or impacts execution time performance, or worst of all, in internally inconsistent, making the feature useless. The committees charter was to standardize existing practice. Some of us feel that the resultant draft is really a new language. 3+)Note that programs which use Cray pointers or VAX records, two commonly available extensions, will have to be substanially modified to use the Fortran Extended equivalents. In general, existing extensions to Fortran 77 do not merge well with Fortran Extended and are unlikely to show up in Fortran Extended compilers (due to technical considerations in the design of the compilers). 4) Companies will need to retrain their programmers to use the new features in Fortran Extended. The changes are so many (many syntactical) that this retraining effort may be similar to that required for Ada. It is unlikely that many companies will spend the money to do this, so programmers will continue to use the Fortran 77 subset. If X3J3 had produced the standard in a more timely manner, with fewer changes, the impact on the users could be spread out over time. 5) Fortran Extended will cost implementors an order of magnitude more $ to implement than Fortran 77. All within 2-3 years. These costs will have to be passed onto the users. If smaller changes had been made in more frequent standards, the cost could be spread out. What's good about Fortran Extended ? 1) Array notation does provide a portable way to express vectorizable and parallelizable operations. Codes will run a bit slower than possible with careful hand tuning (inserting directives), but one code can run on many architectures without any changes (except for datatypes). 2) Structures are long overdue. But VAX structures they aren't. 3) The INCLUDE statement is long overdue, and almost didn't make it into the standard. 4) Pointers are overdue. Cray pointers are available on many platforms (Cray, Convex, Sun, some IBMs and some DEC machines), but the new Fortran Extended pointers are not the same. 5) Allocatable and automatic arrays are great. 6) It is finally done! What Next? Some vendors (including some no voters) will start working towards Fortran Extended implementations. You might see a few in 2-3 years. If these initial implementations are successful and generate public interest, Fortran Extended should be generally available in the late 1990's. Partial implementations (such as limited array notation) is available now on some implementations, and will show up on many large scientific oriented systems. Commercial systems may chose to implement modules first. You should avoid using features such as Cray pointers and VAX records (and any other Fortran 77 extensions) in the meantime, so that your code will port more easily to Fortran Extended compilers. Although it may be technically feasible for a vendor to provide for these extensions, it will add a lot of implementation effort and some risk to do so; therefore, it is unlikely that all vendors who support VAX records and Cray pointers now will support them in their Fortran Extended compilers. If you would like a more detailed discussion, come to the next X3J3 meeting and buy me a beer :-). -- ------------------------------------------------------------------------------ Rich Bleikamp bleikamp@convex.com Convex Computer Corporation