Subject: hpff-external: Re: Kernel HPF

From: [email-masked] (Andy Meltzer)
Date: Fri, 8 Sep 1995 14:59:46 -0500 (CDT)

---------------------------------------------------------------------------
[email-masked] is a mailing list for discussion of external
interfaces between HPF and other languages/systems.  Instructions for
adding or deleting yourself from this list appear at the bottom of this
message.
---------------------------------------------------------------------------

Chuck -

Thanks for the timely replies...

> 
> Random comments follow.
> 
> >\begin{abstract}
> >
> >HPF contains many directives which offer ease of use, but
> >the excessive overhead associated with these directives can severely
> >compromise performance on one or more (even all for some combination
> >of features) distributed memory parallel computers.
> >This report identifies a kernel of HPF which performs well across many
> >platforms.  It is an implementors view and may not contain all of the
> >features all applications developers desire, but all of the features
> >which are provided enhance performance.
> >
> >\end{abstract}
> 
> Something that I've never been sure about:
> Is the Kernel HPF implementation faster because only efficient features are
> included, or because the compiler knows it doesn't need to handle the
> general case?
> 
> I'm not sure how to make the distinction clear.  Basically, if the
> efficiency comes from "knowing" that the worst case won't happen, then
> calling Kernel HPF from Full HPF (or vice versa) raises questions about
> which assumptions (calling conventions) to use.  If efficiency comes from
> avoiding expensive features, then can't/won't the compiler optimize them
> away without Kernel HPF?

With the likely changes to the rules about requiring interface blocks,
I believe that an implementation can, without difficulty use the same
calling sequence for the kernel that it uses for full hpf.  That is why
I no longer am calling it an extrinsic, it simply uses a 
	
	!HPF$ HPF_KERNEL

directive to distinguish it from the rest of the code.  I believe that
it is useful to distinguish it because the compiler can make quite a 
few simplifying assumptions if it is known to be kernel code.

> 
> >\subsection{The \type {DISTRIBUTE} Directive}
> >
> >The {\type {DISTRIBUTE}} directive remains mostly intact, only a few pieces
> >of functionality have been removed.
> >\subsubsection{Distribution Formats}
> >
> >Kernel HPF includes only the {\type {BLOCK}} distribution.  It does
> >not include the {\type {CYCLIC}}, {\type {CYCLIC(N)}}, or {\type {BLOCK(N)}}
> >distributions.  The effort to determine the locations of the elements
> >in an array with the {\type {BLOCK}} distribution is much less than the
> >other distributions.
> 
> Uh, going from countably infinite distribution patterns (i.e. any value of
> N) to one is kind of a big reduction, isn't it? :-)
> 
> I'd favor having CYCLIC distribution as well, just to satisfy people doing
> Gaussian Elimination.  Having only one pattern seems kind of useless.
> (Although there is a choice of which dimension(s) get distributed.)
> 

This area is one of much debate.  I have changed the section in the document
a few times and if you look at the tex file itself you'll notice that 
there is a section commented out that allows all of the distributions 
except BLOCK(N).  I don't know what answer is best, but the kernel can
survive pretty well whatever the decision of the group.

> >\subsection{The \type {ALIGN} Directive}
> >
> >In Kernel HPF the {\type {ALIGN}} directive is restricted to
> >alignments that are direct;  there may be no offsets or strides
> >within an  {\type {ALIGN}}.  Replication and collapsing of dimensions
> >are also disallowed.
> 
> I'd favor collapsing dimensions, unless you have an example of how it makes
> addressing complex.
> 
>         !HPF$ ALIGN A(I,J) WITH B(I)
> 
> 
> >Collapsing of dimensions is disallowed because it can be accomplished
> >with the {\type {DISTRIBUTE}} directive.
> 
> But maintaining this correspondence when the DISTRIBUTE changes may not be easy.

I thought for a while about the problem of collapsing dimensions and the
ALIGN directive.  It is syntactically harder to concoct a kernel and much
harder to understand what we have created if ALIGN has this kind of limited 
functionality.  By stripping ALIGN of all of its power the kernel becomes
much more straightforward with an admitted loss of a feature that is
useful in many circumstances.  I believe that the simplicity of the 
result outweighs the loss of the functionality.

> 
> >\subsection{The {\type {TEMPLATE}} Directive}
> 
> If ALIGN is so restricted, it's sort of hard to imagine a need for
> TEMPLATE.  Just pick one of the arrays you were going to match against the
> template.

Good point and I agree.  TEMPLATE in the kernel has only one use: it is
a convenient placeholder for a distribution.  You can put the templates
into an include file and they are a convenient way to play with all of 
the distributions in a program.  Sort of like a distribution typedef.
I think this is part of the beauty of the simplification achieved above.

> 
> >\subsection{The {\type {FORALL}} Statement and Construct}
> >
> >These are included in Kernel HPF.
> >
> 
> I'm suprised (although not angry :-) that you don't want to restrict the
> expensive forms of FORALL.  For example, I'd be willing to disallow calling
> user functions from FORALL.  (Presumably PURE intrinsics are more-or-less
> straigh-forward.)

This is an area that can easily be mucked with in the kernel while it still
remains basically intact.  If you have a coherent set of changes you'd
like to propose, the subgroup can package them up in a way that we can
vote on them.  I am not averse to restricting the behavior of FORALL.  The
only argument I see against it is that it requires more for the user to
understand.

> 
> >\subsection{{\type {PURE}} Functions and Subroutines}
> >
> >These are included in Kernel HPF.
> >
> >{\em {Rationale}}: {\type {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.
> 
> 
> The key problem is that PURE functions can access global distributed data.
> As previous HPFF committee debates have shown, this is very hard to do on
> distributed memory machines.  If the purpose of Kernel HPF is "no
> performance suprises", this certainly seems to argue for restricting PURE.
> 
> Suggestion: Add constraints to PURE in Kernel HPF so that a PURE function
> cannot access global distributed data.  (Accessing global replicated data
> would seem safe, except Kernel HPF can't replicate data.)
> 

Again, as above, I am not necessarily against this, but it does make the
kernel less easy to immediately grasp.

> > Non-unit
> >strides may be specified when passing array sections as actual
> >arguments.
> 
> Why is this allowed, when strides in ALIGN are not?  After all, it causes
> the same addressing problems.

With the new rules in HPF, an implementation can use copy-in copy-out
semantics if desired.

>                                                 Chuck

---------------------------------------------------------------------------
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>
---------------------------------------------------------------------------