Subject: hpff-doc: portable.tex

From: Andy Meltzer <[email-masked]>
Date: Fri, 2 Aug 1996 13:38:58 -0500 (CDT)

---------------------------------------------------------------------------
[email-masked] is a mailing list for HPF 2.0 language specification
authors and editors.  Instructions for adding or deleting yourself from this
list appear at the bottom of this message.
---------------------------------------------------------------------------

% File: portable.tex

% Contents:
% Portable and Efficient Constructs chapter for HPF 2.0 document,
% including 
%	Kernel HPF
%	FORALL examples

% Revision history:
% May-10-96	Created by Andy Meltzer, Cray Research
%		(who thought it was ``Kernel HPF'')

\chapter{Portable and Efficient Constructs}
\label{ch-portable}

{\em
Comments on this chapter should be directed to 
Andy Meltzer ({\tt [email-masked]}),
Chuck Koelbel ({\tt [email-masked]}),
and {\tt [email-masked]}.
Please use ``{\tt Comments on Portable/Efficient}'' as the {\tt Subject:}
line.
\par
}

%  {Coding for Portable Performance in HPF}
%  {Ver 1.0}
%  {Andrew Meltzer}
%  {Cray Research, Inc.}
%  {April, 1996}

%\section{Introduction}

This chapter identifies a specific set of directives
and paradigms that are particularly easy to use.  This set compiles to an
efficient parallel program on the vast majority of platforms available.  The
aim of the chapter is to identify a set of features that will provide
portable high performance.

HPF 2.0 includes many features that offer ease of use, but
the excessive overhead associated with the implementation of these features
can severely
compromise performance on one or more (even all for some combination
of features) distributed memory parallel computers.  This ``Kernel'' set
of features, often referred to as the {\em HPF Kernel} is described in this
chapter.

The HPF Kernel is a high performance subset of HPF 2.0.  The features chosen
for were selected for the following reasons
\begin{itemize}
\item They allow high-performance across all platforms.
\item On no platform are there performance ``surprises,''  Few, if any,
      combinations
      of the portable, high-performance features unexpectedly lead
      the user into low-performance
      circumstances although it is still possible for application
      programmers to write low-performance codes and for vendors to
      provide low-performance implementations.
\item They are easily understood.
\item They are commonly used.
\item They are valuable for all platforms.
\end{itemize}

The features described in this chapter are also chosen to
simplify the HPF model by reducing the variety of mappings to
only those most commonly used and to simplify
the model by removing a level of abstraction.  These kernel features
might be a good place to begin learning to program in HPF.

The use of these features does not guarantee a high-performance application,
but these features increase the likelyhood that an application will get the
most out of the HPF language.   These features are also described here to
assist the user with an understanding of the sorts of operations that can
be efficiently executed.  Many vendors will have implemented many more
features that execute efficiently, a description of these is available
with the vendor's implementation.

The chapter is organized by HPF feature.  Features are listed and described
as restricted, not recommended, or recommended.   Restrictions are described.

\section{The {\tt {DISTRIBUTE}} Directive}

The {\tt {DISTRIBUTE}} directive remains mostly intact, only a few pieces
of functionality are not suggested when trying to achieve portable performance.
\subsection{Distribution Formats}

The HPF Kernel includes only the {\tt {BLOCK}} and {\tt {CYCLIC}} and
on-processor distributions.  It does
not include the {\tt {CYCLIC(N)}}, or {\tt {BLOCK(N)}}
distributions.  The effort to determine the locations of the elements
in an array with the {\tt {BLOCK}} and {\tt {CYCLIC}} distribution
is much less than the parameterized distributions.

\subsection{On-Processor Dimensions}
The ``*'' syntax is included in the {\tt {DISTRIBUTE}} directive
{\em {dist-format-clause}} to indicate on-processor dimensions.

This is a convenient technique for increasing locality of
reference, a goal for most high performance codes.  It can be accomplished
efficiently with reasonable compiler effort.

\section{\tt {DYNAMIC} Distributions}

The {\tt {DYNAMIC}} attribute is not recommended for portable
high-performance coding.   These distributions have obvious merit and
certain applications may require their general capabilities,  but
because of the inherent dynamic overhead required on even the most
advanced implementations, they cannot be recommended as high-performance
features.

\section{The {\tt {PROCESSORS}} Directive}

The {\tt {PROCESSORS}} directive is part of the HPF Kernel
with the following restrictions:
\begin{itemize}
\item The product of the extents must exactly match the number of
      processors or the processor arrangement must be scalar.
\item If an {\tt {ONTO}} clause is not specified, a default
      arrangement is provided which is identical for distributees
      that have identical shapes and identical explicit mappings.
\end{itemize}

If a processors directive is not specified a default arrangement is
provided which is identical for arrays that have identical shapes,
bounds, and identical explicit mapping directives.

\section{The {\tt {ALIGN}} Directive}

In The HPF Kernel the {\tt {ALIGN}} directive is restricted to
alignments that are direct;  there may be no offsets or strides
within an  {\tt {ALIGN}}.
Replication and collapse of dimensions is allowed.
In alignment expressions the dimensions may not be permuted.

\begin{itemize}
\item   Alignments may not contain offsets or strides.
\item   The {\em {align-subscript-use}} in the HPF 1.1 syntax rules should be
        replaced with {\em {align-dummy}}.

\item   Dimensions may not be permuted.

\item   A `*' is allowed either in the align-spec or in the alignee.
\end{itemize}

For example the following is code will likely execute efficiently:

        {\tt {CHPF\$           ALIGN A(I,J) WITH B(I,J)}}

But the following may not:

        {\tt {CHPF\$           ALIGN A(I,J) WITH B(I+1,J)}}

Offsets are not suggested for the {\tt {ALIGN}} directive when coding
for portable high-performance.  The effect of offsets can be
often be achieved by changing the bounds of arrays.
The following two examples will create the same alignment.

    {\em {Example 2a}}
\begin{verbatim}
                DIMENSION A(1:100), B(0:99)
        CHPF$   PROCESSORS P(32)
        CHPF$   DISTRIBUTE B(BLOCK) ONTO P
        CHPF$   ALIGN A(I) WITH B(I-1)  ! Disallowed
\end{verbatim}

    {\em {Example 2b}}
\begin{verbatim}
                DIMENSION A(1:100), B(0:99)
        CHPF$   PROCESSORS P(32)
        CHPF$   DISTRIBUTE A(BLOCK) ONTO P
        CHPF$   DISTRIBUTE B(BLOCK) ONTO P
\end{verbatim}

\section{The {\tt {TEMPLATE}} Directive}

The {\tt {TEMPLATE}} directive itself needs no restriction, but the use of
templates is restricted by the changes to the {\tt {ALIGN}} directive.

\section{The Reduction Clause in the {\tt INDEPENDENT} Directive}

The reduction clause in the {\tt INDEPENDENT} directive
may be used when coding for portable
high-performance.  The directive
only pertains to intrinsic operators and types.

\section{The {\tt {FORALL}} Statement and Construct}

Both the {\tt FORALL} statement and construct are recommended for
use when coding for portable high-performance.

{\tt {FORALL}} is a powerful and expressive way
to code parallelism.  It is true that not all {\tt {FORALL}}
statements and/or constructs can be fully parallelized, but because
of their general value and because they will be part of Fortran 95,
they are included in the HPF Kernel.

\section{{\tt {PURE}} Functions and Subroutines}

These are recommended for use when coding for portable high-performance.
{\tt {PURE}} functions can do no harm, and allow
an increased level of expressiveness.  They simplify the job for
the compiler and are part of Fortran 95.

\section{The {\tt {INDEPENDENT}} Directive}

The {\tt {INDEPENDENT}} directive is recommended for portable
high-performance, but with some caveats.  The {\tt {INDEPENDENT}}
directive gives a user access to facilities otherwise not available
by any means.  It can be abused, however, and not all implementations
may be able to handle all combinations of function calls within
{\tt INDEPENDENT} loops.  Care must be taken when exploiting this
feature.

Directives such as {\tt {INDEPENDENT}} have shown
their worth historically across a broad variety of platforms.  This
directive simplifies the analysis the compiler must do and can inform
the compiler about optimizations that it may do that otherwise
are expensive or impossible to deduce.   {\tt {INDEPENDENT}} allows
an increased level of optimization.

\section{Extrinsics and {\tt {HPF\_LOCAL}} and {\tt {HPF\_SERIAL}} }

The general purpose extrinsic mechanism, {\tt {HPF\_LOCAL}} and
{\tt {HPF\_SERIAL}} are all recommended for use when coding for
portable high-performance.

These allow a program to get at the highest performing features of a
particular architecture.

\section{Library}

All of the HPF 1.1 library routines are recommended for use when
coding for portable high-performance.  The intrinsics provide fast,
architecture specific
versions of many very important parallel functions.  To achieve a
similar level of performance for these functions a user would have
to write non-portable code.

\section{The {\tt {INHERIT}} Directive}

The  {\tt {INHERIT}} directive is recommended for use when coding
for portable high-performance.
The {\tt {INHERIT}} directive is not a high-performance
feature, but its impact can be isolated to the few places where it is
very useful.  The {\tt {INHERIT}} directive can be instrumental when
coding library and general purpose routines.

Care must be taken when using this directive as it is only a convenience
feature, not a high-performance feature.

\section{Pointers}

When coding for portable high-performance it is recommended that a
given pointer only point to identically explicitly mapped objects.

\section{Subroutine Interfaces}

Explicit interfaces are recommended for any subroutine
which remaps data.  This gives the language processor the necessary
means (without interprocedural optimizations) to remap data at
the call site statically, rather than dynamically at the callee.
Dummy arguments from actual argument array sections cannot be
mapped ``{\tt {DISTRIBUTE * ONTO *}}.'' Non-unit
strides may be specified when passing array sections as actual
arguments.

Assumed shape explicitly mapped dummies  may be used,
but explicit interfaces must be included where ever
they are used. Assumed shape dummies may use any mapping syntax.
The results of array valued functions may be explicitly mapped.  Assumed
size arrays are not recommended.

An explicit interface is required in the following cases:

\begin{itemize}

\item The dummy argument has the {\tt {INHERIT}} attribute.
\item  The mapping of a dummy argument is not the same as the mapping of
the corresponding actual argument, and at least one of the following
two conditions is true:

\begin{enumerate}
        \item the dummy argument is explicitly mapped;

        \item the actual argument is an explicitly mapped whole array or
           a section of an explicitly mapped array.
\end{enumerate}

\end{itemize}

Much better control of the remapping can be achieved
if the explicit interface is available and much less code to check
mappings and remap upon entry is necessary.

\section{Storage and Sequence Association}

It is not recommended that storage or sequence association be relied
upon when coding for portable performance.
The {\tt SEQUENCE} directive is not suggested.  This means that the user
should not use equivalence, common blocks must be declared identically
everywhere, and no arguments may be passed with mismatched shapes.

---------------------------------------------------------------------------
To (un)subscribe to this list, send mail to [email-masked].
Leave the subject line blank, and in the body put the line
(un)subscribe <email-address>
---------------------------------------------------------------------------