Subject: hpff-doc: Comments on Portable/Efficient Constructs

From: <[email-masked]> (Henry Zongaro)
Date: Tue, 17 Sep 1996 08:41:02 -0400 (EDT)

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

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

 - 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

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

   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(:)

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