Subject: hpff-doc: HPF Comments

From: Thomas MacDonald <[email-masked]>
Date: Fri, 8 Nov 1996 17:51:51 -0600 (CST)

---------------------------------------------------------------------------
[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.
---------------------------------------------------------------------------
I recently sent Email to Mary Zosel explaining that I'll be taking over
Andy Meltzer's HPF responsibilities here at Cray Research (an SGI
company).  Larry Meadows sent me the following comments and I agreed
to respond.  I hope they are not too late to be of use.

I'm a little new to this so please let me know when I'm missing the
point or heading down the wrong path.

I suppose I need to be on some Email reflectors, but I'm not sure
which ones.

I printed a copy of the HPF 2.0.delta, dated October 19.  My comments 
below are based on that version.

Tom MacDonald
[email-masked]

> >From [email-masked]  Tue Sep 17 05:49:06 1996
> From: <[email-masked]> (Henry Zongaro)
> Subject: hpff-doc: Comments on Portable/Efficient Constructs
> To: [email-masked], [email-masked], [email-masked]
> Date: Tue, 17 Sep 1996 08:41:02 -0400 (EDT)
> X-Mailer: ELM [version 2.4 PL24alpha3]
> 
> ---------------------------------------------------------------------------
> [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.
> ---------------------------------------------------------------------------
> Hello,
> 
>      I have the following comments on the "Portable and Efficient Constructs"
> chapter.  My page references are with respect to the August 17 draft.  My
> apologies if any of these have already been corrected:
> 
>  - In section 7.1.1, I think "(em i.e. *)" is a typo.

I couldn't find a section 7.1.1 anywhere.  I suspect thngs changed since
your comments were made.  It appears that your comments are now against
section 8.

Anyway, I couldn't find the type - so I hope it's already been fixed.

>  - In section 7.3, there are certain requirements being placed on HPF
>    compilers, whereas this chapter is supposed to describe the features which
>    a user should use.

Usually specifications are a treaty between the users and the implementors.
If the users follow the rules then the implementors will too (ideally).
So, specifications always place constraints on both sides (seems to me).
Section 8.3 is all about the RESIDENT directive.  This has been quite
useful here at Cray because it allows the users to increase the number
of local references.  

>                       In addition, I'm not sure I entirely agree with the
>   defaults being described.  In particular, I know of an implementation in
>   which the default processors arrangement selected will not always be the
>   same for identical shape distributees with identical mappings.  For example,
> 
>            program prog
>              integer a(100, 100)
>      !hpf$   processors p(number_of_processors()/2, 2)
>      !hpf$   distribute a(block, block)
>            end program prog
> 
>            subroutine sub
>              integer a(100, 100)
>      !hpf$   distribute a(block, block)
>            end subroutine sub
> 
>    In prog, the array will be distributed onto p, so on 16 processors this
>    would be an 8x2 processors arrangement, but in sub, a 4x4 arrangement will
>    be selected.

You state that "I'm not sure I entirely agree with the defaults being
described" but you do not say which default you want changed or what
you think the defaults should be.

The example you describe above is non-intuitive (IMHO).  I believe more
details are needed before we can come to a conclusion here.  The defaults
are based upon our best understanding, an existing implementation, and
a fair amount of testing.  It would be helpful to get some more details
here.  It isn't at all clear why, in the example above, different
processor arrangements are desired.  Nor is it clear what the performance
advantage is, or how much performance will suffer if the same processor
arrangement is used.

> - In section 7.4, the precise meaning of "Alignments may not contain offsets
>   or strides" needs to be spelled out.  Also, the way I read it, it means that
>   the following is not allowed

Sorry, I'm having trouble finding this reference.  Perhaps you could provide
the title of the section.

>           integer a(10), b(0:9)
>     !hpf$ align a(i) with b(i-1)

It seems that there is no need for this case.  The following directive
does nicely:

    !hpf$ align a with b

The presence of offsets and strides greatly increses the complexity of the
analysis when the compiler is trying to determine locality.  If we're
looking for a performance subset, then compiler implementation costs and
compile time are a consideration.  Seems we need to ask ourselves how much
compile time is reasonable to provide good performance, and one of the
keys to good performance is increased locality.

>   although the following equivalent alignment is allowed, since I've specified
>   no explicit "offsets" or "strides".
> 
>           integer a(10), b(0:9)
>     !hpf$ align a(:) with b(:)

I'm not sure what the point is here.  The above directive is all that's
needed here and accomplishes my goal of not having alignments and strides.
So, perhaps your just pointing out the intent just to make sure everyone
understands the intent.

>  - In 7.4, the first paragraph states that "In alignment expressions the
>    dimensions may not be permuted."  This is repeated as the third bullet in
>    the list that follows.
>
>  - In 7.4, the sentence that follows the list, the word "is" should be dropped.
> 
>  - In 7.8, further to the comment that begins "What does a naive programmer do
>    with this advice?", I believe the intent of this chapter was to steer the
>    user away from features which might perform poorly.  A DO loop that's
>    specified to be INDEPENDENT, but can't be parallelized will perform about
>    the same as the same DO loop without INDEPENDENT.  Telling them be careful
>    with INDEPENDENT doesn't really give them any benefit.
> 
>  - In 7.10, it is stated that HPF_LOCAL and HPF_SERIAL "allow a program to get
>    at the highest performing features of a particular architecture."  This
>    might be true of HPF_LOCAL, but is probably not true of HPF_SERIAL.
> 
>  - In 7.11, the second sentence begins "The intrinsics. . . ."  I believe this
>    should be "The HPF library procedures. . . ."  However, this brings up a
>    second point - is use of all intrinsics encouraged?  What about the
>    transformational intrinsics with non-constant DIM arguments?
> 
>  - 7.13.  Given the restrictions being put in place for pointers in HPF 2.0, I
>    think this section can probably go away.
> 
>  - In the second paragraph of 7.14, it's stated that assumed shape mapped
>    dummies may be used, that they may use any mapping syntax and that array
>    valued function results may be explicitly mapped.  However, there is no
>    indication as to whether these are restricted, recommended or not
>    recommended.
> 
>  - In 7.15, the second sentence, "not suggested" should be "not recommended".
> 
> Thanks,
> 
> Henry

I'm going to stop with my comments here.  I'm having trouble relating
the comments back to the HPF Spec.

> >From: "Scott B. Baden" <[email-masked]>
> To: [email-masked], [email-masked]
> Subject: Coments on Extrinsic Interfaces
> Cc: [email-masked]
> 
> Hi, I have a few comments on Appendinx A.  
> 
> page 242, line 4.  SPELL OUT the words for CCI
> Line 19 "A short paepr with the formal definition" 
> 
> How many pages?
> 
> line 47
> 
> should the "web mark-up language" be html?
> In any case, if we ar asking for html, then we should provide a
> web submission procedure, i.e. a url to be accesible from
> the HPFF home page.
> 
> 
> Page 243  HPF_CRAFT.  
> Insert a reference to Chapter 7 at the end of the sentence on line 19.

This seems reasonable.

> The second paragarph (lines 20-26) is a little hard on the reader.
> I suggest beginning it as
> 
> "The combination of SPMD features with muilti-threaded execution
> is a powerful one.  It provides  the flexibility necessary
> to take advantage of low-level access, offering the highest performance
> of a more general programming model."

No problem.  I'm also looking at the sentence that refers to "chapter on
coding for [ortable performance in HPF."  Where is this chapter?

> fentence on lines 22-23 "including HPF.." 
> How does "including HPF data distribution"
> give acces to the "highest performing aspects of both modesl".

The sentence could be clearer.  The intent is that the HPF data
distribution directives are convenient, and HPF-Craft provides some
low-level access that when combined with the convenient distribution gives
good performance on the right platforms.  I'll look at it some more.

> Line 24.
> "HPF is not appropriate for all platorms..."
> What are the restrictions.

Well, a pure SIMD platform comes to mind.  We don't want to get into
the Biz of creating an exhaustive list cause we'll leave something out.
The sentence could be sotened to something like:

    An implementation may decide that HPF-Craft is not
    appropriate for a particular platform.

> It may be easier to follow section A.2. if you simply fold it into the
> appropriate subsections of A.2.5 (you may have to reorder
> the subsections of A.2.5)  Many parts of A.2.5 are very sparse.

I'll read it again to see if it can be made clearer.  I think it's
a nice lead in.  The only time I think it'd be difficult to follow
is if you had no knowledge of the previous sections.  I'm open
to the opinion of others though.

> page 245, line 14.
> What is the purpose of the sentence
> "The user was allowed to specify this."

I agree this sentence could be improved.   The point is that the
user has control over where iterations are executed.  I'll look
at this some more.

> example 3 (discussion)
> make it clear that !HPF$ ATOMIC_UPDATE is part of HPF_CRAFT

OK.

> example 5
> Overall I felt that example 5 was too complicated at least as part of
> the overview section. Can you come up with something simpler?

I suppose, but it's kind of nice to have something a little more
complicated as the last example.  It ties things together some.

> The geometry directive bit doesn't illustrate the utility of the
> construct.  You only use it in one place.  I felt that this simply
> complicatied the exmaple, which was really about something else
> entirely.

But the point is that you change the GEOMETRY statement and the
distributions of FX, FY, and FZ all change too.  Note the difference with
FXP and FYP.  You have to change both distirbutions.

> I would take out the gemoetry part and move it to A.2.5.16
> (and chose an exmaple that REALLY illustrates the utility of the
> construct)

I'l consider this.  Thanks for the suggestion.

> Page 246, section A.2.3.
> line 22 "S" in "Subprogrtam" should be in lower case.
> 
> Lines 29-30.
> You can cut the second sentence, it merely reiterates what you
> said in the first one.

Seems like it makes it clearer though.  I'll think about this too.

> Page 247.
> last paragraph of section A.2.3
> I found this hard to understand.
> Isn't the "dummy argument of the HPF_CRAFT subprogram"
> the same as the dummy argument of the "EXTRINSIC("HPF_CRAFT") subprogram"?

Yes.  Good point.

> section A.2.4.  I would put this before A.2.3  The model should come
> first.

I think I agree with you here.  I want to study it some more.

> lines 40 and 41.
> You use "these" to refer to "these barriers" and "these points"

I'm having trouble finding this one.  Maybe it was fixed already?

> Paragraph on lines 42-48.
> You should provide an example which illusrates the concepts.

Unfortunately my line numbers do not correspond with the cited line numbers.
I need more information.

> Line 42.
> Simplify this to:
> "Implicit barriers are placed whereever"
> (cut "which" from line 43)

Seems to have been fixed already?

> Page 248
> Line 21.  Be sure an inset a reference to Chpater 7 here.

Line number problems again.

> Line 39
> "Processors need not co-operate if there are only reads to non-local
> data."
> How do you define "cooperate?" on a machine that does not provide single
> sided communication, all processors in theory might need to
> communicate to carry out remote reads.

I'll work on a better speficication.  I agree this needs to be better.

> Page 249 section A.2.5.3.
> Pargraph 3 (lines 19-25)  Where would this be useful?

Line number problems again.

> Last para. lines -2629.  Can you give an example?

Sorry, I need new line numbers again.

> Page 25, lines 38-39
> Don't all processors have to participate when 
> an explicitly mapped array appears on the right hand side?
> This is seimilar to discussion above regarding line 39, pg. 248.

Sometimes you only want the elements that the particiapting
processors access.  For example, in a MASTER region:

     PRIVATE_ARRAY = MAPPED_ARRAY;

You don't need all processors to participate to make a local copy.

> Page 251.
> lines 26. Show syntax for CRITICAL.

Ok.

> Page 25, line 3.
> What is the "identifier for thetask executing the call"
> Is this the same as the physical processor, virtual processor?

I'm sorry, I can't find this reference.

> That's all folks!
> Scott

Thanks for your comments.

Tom MacDonald
[email-masked]
---------------------------------------------------------------------------
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>
---------------------------------------------------------------------------