Volume 7, Issue 1 -
Spring/Summer 1999

Volume 6, Issue 3
Fall 1998

Volume 6, Issue 2
Spring/Summer 1998

Volume 6, Issue 1
Winter 1998

Volume 5, Issue 4
Fall 1997

Volume 5, Issue 3
Summer 1997

Volume 5, Issue 2
Spring 1997

Volume 5, Issue 1
Winter 1997

Volume 4, Issue 4
Fall 1996

Volume 4, Issue 3
Summer 1996

Volume 4, Issue 2
Spring 1996

Volume 4, Issue 1
Winter 1996

Volume 3, Issue 4
Fall 1995

Volume 3, Issue 3
Summer 1995

Volume 3, Issue 2
Spring 1995

Volume 3, Issue 1
January 1995

Volume 2, Issue 4
October 1994

Volume 2, Issue 3
July 1994

Volume 2, Issue 2
April 1994

Volume 2, Issue 1
January 1994

Volume 1, Issue 4
October 1993

Volume 1, Issue 3
July 1993

Volume 1, Issue 2
April 1993

Volume 1, Issue 1
January 1993


Ken Kennedy, Director, CRPC

It has been nearly a year since the release of the High Performance Fortran (HPF) informal standard. In that time we have seen the announcement of several product compilers. Applied Parallel Research (APR), in a joint project with Kuck and Associates, has produced a product that translates Fortran 77 plus HPF extensions to message- passing Fortran. The Portland Group has developed an HPF compiler for both Intel and Meiko, based in part on CRPC technology (see related article on p. 4). Within the past month, DEC announced a compiler for Alpha workstation farms. A number of other companies, including ACE, Archipel, Convex, IBM, Lahey, MasPar, NA Software, NEC, nCUBE, Pacific Sierra, and Thinking Machines have revealed that they have an HPF effort underway. The APR compiler was demonstrated at SUPERCOMPUTING '93 and has achieved some impressive speedups with modest programmer effort.

So with all of these successes, why am I worried? Because of the slow progress of parallel computing in the marketplace, a great deal of emphasis has been placed on languages like HPF that are intended to support machine-independent parallel programming. I am concerned that this has led to an unrealistic level of expectation for HPF in the user community. There are many problems to be overcome before the language can achieve all of its promise. First among these is the problem of compiler technology. In spite of laboratory demonstrations that HPF can be compiled efficiently for different parallel machines, there is a great deal of work that must be done to build a mature compiler. A good HPF compiler will be substantially more sophisticated than even a good vectorizing compiler. My concern is that the first compilers out of the box will have disappointing performance and that many users will give up on the language as a result. Just as automatic vectorization technology took a number of years to achieve a high level of effectiveness, HPF compilers may take some time before they generate code that is comparable to hand code in a low-level machine-specific programming interface.

A second major problem arises because of the high level of abstraction in the HPF language. HPF permits what is essentially a two-part specification for a parallel program--one part is a Fortran 90 program that embodies a parallel algorithm and the other is a machine- independent prescription for mapping data structures to a parallel machine. From those two parts, the HPF compiler generates a low- level parallel program that typically includes explicit message-passing. In other words, there is not much resemblance between the source and object program. Therefore, it is very likely that the user will encounter performance anomalies that are hard to understand and fix. It is important that we do not force the user to understand the low-level object program in order to achieve acceptable performance; otherwise, HPF will not have saved much work. Therefore, the HPF programming environment will need to include tools that help the user predict and analyze the performance of HPF programs. Such tools can be viewed as more complicated analogs of the interactive vectorizers that were so important in tuning programs on vector machines. In addition, tools for finding and eliminating bugs will also be needed. To be useful, these tools must interact with the user at a level of abstraction that is comparable to the level of the language itself. Although a number of researchers have begun looking at the problems of building such tools-- for example, the CRPC has a major activity in this area sponsored by ARPA--I know of no manufacturer who is actively working on an implementation.

Finally, there is the problem of HPF's missing functionality. In order to finish within a single year, the HPF Forum limited the scope of its activity, intentionally leaving some tasks for a later round of standardization. Support for problems on irregular meshes, explicit parallel I/O, and task parallelism are among the things that were left out. In addition, early compilers may not support all of the features in the standard document. First-time users of HPF may become discouraged when they discover that their problem requires functionality that is not supported in current versions of the language or its compilers.

Recognizing that this is a problem, the High Performance Fortran Forum (HPFF) has initiated a year-long activity in 1994 with three goals: (1) to collect and publish corrections and clarifications for the original standard, (2) to establish requirements for needed additional functionality, and (3) to foster an information exchange on high- performance implementations. The plan calls for a full-fledged round of standardization in 1995, to add the critical new functionality that is identified this year. We hope that this activity will make the language and its implementations much more useful. In the meantime, however, I urge users not to give up prematurely. If you have comments and questions that you would like to share with the members of the HPFF, send electronic mail to hpff-interpret@cs.rice.edu.

Table of Contents

News | From the Director | Parallel Profile | Research Focus | Work in Progress | Education / Outreach | Resources | Calendar | CRPC Home