HPF, the Language

One way to put HPF into context is to consider another exploding field of interest in this same timeframe - DSM (Distributed Shared Memory). Language and runtime libraries in this area attempt to support a shared memory parallel programming paradigm while actually running on distributed memory machines. HPF, in contrast, attempts to support a single processor, single memory, serial programming paradigm while actually running on distributed memory machines or shared memory parallel processors or SIMD vector machines.

It does this by explointing data parallelism. Where the serial program would do the same thing to all elements of an object, you can have several processors doing that same thing to its piece of the object.

The main reference for HPF is the 1993 language specification [89] and the 1994 revision [90]. A full-length book explains the language in detail [112]. Good summaries of the language are the 3-page overview by Choudhary, Koelbel, and Zosel [51] and the more in depth analysis by Loveman [128]. A succinct summary appears in [147]. Wavren, a member of HPFF, summarized some HPFF minutes as an article for [78], as did A.C. Marshall . The full HPF language is based on Fortran 90 [70]. Subset HPF is based on Fortran 77. Some subset HPF implementations are based on Fortran 90.

And, there is an HPFF web site . Current items about HPF (and F90) can be found at an archive at LPAC Shortly after the HPF specification was published, several critical reviews of the language appeared [46,111]. Reviews of HPF compilers also began to appear [22,79,159,164,95].

Early reactions to HPF weren't entirely favorable:

• HPF isn't usable for programs where different nodes must execute different programs [82].
• HPF has limited capacity for control parallelism [111].
• Advanced applications such as particle-in-cell codes or unstructured mesh solvers cannot be expressed adequately [46].
• Most irregular applications do not run efficiently with BLOCK and CYCLIC data distribution[170].
• HPF is not able to generate efficient code for [matrix] computations [29,129].
• HPF is not appropriate for problems that require all-to-all communications [110].
• ``HPF-implemented applications have typically been an order of magnitude slower than their message-passing equivalents...'' [55]. This has not actually been our experience at Cornell.
• Initial implementations of HPF are likely not to be very efficient (David Bailey in the session moderated by Gary Montry at SC'93, on Massively Parallel vs. Parallel Vector Supercomputers.)
• It is hard to maintain load balance in HPF programs.
• There is no satisfactory way of using ... a data parallel program as a component in building larger programs - Jack Dennis in IPSS'94 because task parallelism is missing [184].
• You can't debug HPF programs because HPF language processors hide mapping information needed by debuggers [49].

However, research and interest in HPF has continued. There are enough advantages to data parallel and SPMD programming, that HPF may well be around for a while. Hence this report.

Another assertion:

• It is easier to optimize HPF performance on parallel computers, than to optimize ``parallel object-oriented'' models [116].