CCI Record of Action
September 14, 1994
About question numbering: Ideally, these would be numbered by document section,
but nothing so rational is used...
#1.x - items submitted prior to April meeting, appearing to be typos,e tc.
#2.x - items submitted prior to April meeting, appearing to be minor interp.
#3.x - items submitted prior to April meeting, possibly nontrivial discussion
#4.x - items submitted prior to April meeting, didn't classify
#5.x - items submitted at April meeting
#6.x - items submitted before June meeting
#7.x - items submitted before Aug. meeting - for G1 subgroup
#8.x - items submitted before Aug. meeting - for G2 subgroup
________________________
*Question: #1.1 Definitions of LB/UB in example
Submitted by: David Loveman
Answer: Correction noted.
Rationale:
(reference to document change:) page 114 table at top: change the C column for
LB to read [20,N/A,1] and change the C column for UB to read [1,N/A,10]
Status: G2 Document needs to be changed. Formal reply needs to be sent.
________________________
*Question: #1.2 List of corrections
Submitted by: Michael Hennecke
Answer: (a) Fix the fonts in the pseudo-code comments, if possible. (This
is a LaTex problem.)
(b) grammatical change noted
(c) may -> must
(d) on page 56, change to R216 / action-stmt
(d) rejected - the document is consistent with F90 style indentation
(e) rejected - we are not editing at this level of style
(f) add a comma after forall-assignment
Rationale:
(reference to document change:) pages 61,62,68,69,70: fix the font to italicize
the first letter of the comments in the examples.
page 41, line 39 - Rationale. Note that the second (insert the)
page 44, beginning of line 23 - change may to must.
page 56, line 22 - change 215 -> 216 and executable-construct -> action-
stmt
page 67, line 26 - insert comma after forall assignment
page 76, lines 8 and 9 - change to read ... prevent the side effect of
realignment and ... pure function.
Status: G2 Document needs to be changed. Formal Reply needs to be sent
________________________
*Question: #1.3 Comment character in example
Submitted by: James Cownie
Answer: No. Example correct as is, but should reword the 1st paragraph of 2.3 to
be clear that it takes more than just removing !HPF$ to make a "conceptual F90
program" in fixed form - blanks must be substituted.
Rationale: ........indirect answer here ....
(reference to document change:)
page 20, line 10 replace may only with "in free source form must," and
remove this phrase from the end of the sentence.
Status: G2 Document needs to be changed. Formal reply needs to be sent.
________________________
*Question: #1.4 Align with inherit.
Submitted by: Adam Marshall adamm@nasoftwr.demon.co.uk
Answer: Agree with both corrections noted.
Rationale:
(reference to document change:) page 48 line 4 strike "ALIGN or" and page 49
line 43 change dist-target-clause to dist-onto-clause
Status: G2 Document needs to be changed. Formal reply needs to be sent.
________________________
*Question: #2.1 Clarify that all combinations of upper/lower case are ok
Submitted by: David Loveman loveman@mps.mlo.dec.com
Answer: Add sentence to page 20 line 7 to verify that the entire directive is
case insensitive.
Rationale:
(reference to document change:)
page 20 change beginning of line 7 to be "An hpf-directive-line is case
insensitive and conforms ..."
page 19, lines 22-23 - replace the end of the sentence from "would be to
remove ... " with "would be to replace the directive-origin with blanks
Status: G2 Document needs to be changed. Formal reply needs to be sent.
________________________
*Question: #2.2 Resolve IARRAY or ARRAY spelling issue in library
Submitted by: Stephen Ehrlich bud@psrv.com
Answer: Change the instance of IARRAY to ARRAY.
Rationale:
(reference to document change: 5.7.18, 5.7.22) Change IARRAY -> ARRAY three
times in section 5.5.5 on page 96.
Status: G2 Document needs to be changed. Formal reply has been sent.
________________________
Question: #2.3 Clarify text on access to COMMON in HPF_LOCAL and in extrinsics
Submitted by: Mary Zosel zosel@llnl.gov
Answer: New interface rules defined.
Rationale:
(reference to document change:) add this text to page 142, item 4 (line 18):
Note in particular that even though an HPF_LOCAL routine is not permitted to
access and modify HPF global data, other kinds of extrinsic routines may do so
to the extent that an HPF procedure could.
Status: G2 ( 2.3, 6.16, 6.17, 8.15 - see 6.16 for proposal) Also some text for
this item specifically.
_____________________
*Question: #2.4 Clarify limits on DIM limits - fix text in subset
Submitted by: originally question from marc@sisters.cs.uoregon.edu
Answer: Strike "and hence delivers a known shape at compile time" in the subset.
Rationale: Consistent with HPFF vote.
reference to document change: page 152 lines 21-22 strike the phrase "and hence
deliver a known shape at compile time".
Status: G2 Document needs to be changed. Formal reply was sent.
_____________________
*Question: #2.5 Expand H312-318 wording
Submitted by: Matt Snyder lahey!adonis!msnyd@uunet.uu.net
Answer: On page 31, we recommend replacing the entire constraint with
"If the alignee is scalar an align-source-list is not defined. In this case,
the statement form of the directive is not allowed. Final vote on this change
is proposed for the next meeting to allow people time to check that the details
are correct.
Rationale:
(reference to document change:)
Status: G1 wording 21-0-4; send formal reply.
-------
#2.5 H312-318 wording ... 7/26/93
H312 - H318, 3rd constraint, p. 31, roughly line 30: "(In some cases this will
preclude the use of the statement form of the directive.)" Can we get a
clarification on what those cases are? Isn't it true that use of the statement
form of the directive is precluded whenever the alignee is a scalar?
_____________________
*Question: #2.6 Converting Alignments
Submitted by: den-wja@tpd.tno.nl
Answer: Can't say this in HPF1 - Referred to general issues chapter for HPF 2
requirements document.
Rationale:
(reference to document change:)
Status: G1 Closed. See also item #6.8. Send Reply.
add the example to show
align with a(*) :: s
align A(I) with B(3*i)
which has the effect
ALIGN with B(3:n:3) :: s
This cannot be directly stated in HPF
In further discussion at the June meeting - this issue became not so clear.
Example:
real S a(20) B(100)
align with A(X):S
Align with B(50:69) :: A
The effect is: align with B(1:69)::S
This looks like s is replicated over only a section of B
One possibility is replication everywhere - but this isn't acceptable either.
This is not a clarification or interpretation .... large change
__________________________
*Question: #2.7 BLOCK distribution question
Submitted by: Michael Hennecke
Answer: Yes it is legal - add an example to the document.
Rationale:
(reference to document change:)
Status: G1 Document needs to be changed. Formal reply needs to be sent.
________________________
*Question: #2.8 Extrinsic inquirues
Submitted by: David Loveman
Answer: The answer is two to both cases.
Rationale: Both ask about the alignment of an array to its associated template,
which is the same template in both cases. The two "quibbles" are dismissed with
the comments that (1) is F90 conforming and (2) ok to call HPF_LIBRARY in an
HPF_LOCAL.
(reference to document change:)
Status: G2 - Formal reply needed.
________________________
*Question: #2.9 DIM F90 compatibility
Submitted by: Larry Meadows
Answer: Can be handled with generic overloading. Argument types disambiguate.
Rationale: This is the solution adopted by X3J3. They endorse the added argument.
(reference to document change:)
Status: Closed.
________________________
*Question: #3.1 Clarify/expand the interface to other program models
Submitted by: Mary Zosel zosel@llnl.gov
Answer: No change to document.
Rationale: Discussed environments and acknowlege they exist but vote 2-13-9 not
to say anything about HPF called from other environments and 3-11-11 not to say
anything about hpf calling something else that calls hpf.
(reference to document change:)
Status: Closed.
-----
Check/clarify/expand the interface to other program models, especially how HPF
can be invoked from other models:
HPF code calls Message-code calls auery functions might be limited.code
or F90 code calls HPF-code calls tasking model calls ...
This should be mainly the case of making sure that scope/role of global data is
understood.
________________________
Question: #3.2 PURE functions - restrict the use of prescriptive distributions
Submitted by: ?
Answer:
Rationale:
(reference to document change:)
Status: G2: Prescriptive DISTRIBUTE in PURE: DISTRIBUTE is not allowed, so the
immediate answer is RnoS. Prescriptive align is ok, but read access to global
data may be a problem in a similar way. Chuck will supply text for review.
________________________
*Question: #3.3 PURE functions - exclude alternate returns
Submitted by: hendrick@acset.be (Dick Hendrickson)
Answer: Agree - eliminate alternate return in PURE functions.
Rationale: F95 is proposing to eliminate alternate return altogether.
(reference to document change:)
Status: G2: need document change. Needs formal reply.
________________________
*Question: #3.4 Clarify the scope of the index name in a FORALL
Submitted by: David Loveman & hendrick@acset.be (Dick Hendrickson)
Answer: The index has statement scope and the constraints about use of globals as
indexes should be eliminated.
Rationale: This is what X3J3 has proposed for F95.
(reference to document change:)
Status: G2 Document change is needed. Formal reply is needed.
______________________
*Question: #3.5 Rework propagation of SEQUENTIAL
Submitted by: Mary Zosel zosel@llnl.gov
Answer: SEQUENTIAL attribute must match.
Rationale: Otherwise argument passing is too expensive.
(reference to document change:) Add text 2nd reading:
149 line 16 - add 4. Without an explicit interface, a sequential actual may not
be associated with a nonsequential dummy and a nonsequential actual may not be
associated with a sequential dummy.
line 35 same page --- "by rules 2 AND 4".
line 38: "or that ET and X have the same shape and have the same sequence
attribute".
Status: G1 (of 3.5 and 3.6) Closed. Document change needed.
------
real a(100,100)
call sub(a)
subroutine sub(b)
real b(100,100)
!HPF$ sequence b
call sub1(b)
end
subroutine sub1(c)
real c(10000)
!HPF$ sequence c
end
option 1 nonconforming actual and dummy must agree in sequential.
option 2 on call to sub the dummy is remapped as necessary - prescriptive mapping
of dummy. Lots more thought is needed about this one, but as a guide, a straw
poll was taken: Prefer option 1: 8; Prefer option 2: 10; Abstain: 10.
----
The document says that if there is a mismatch in shape, that both sides of the
call must be designated sequential. The document does not say what happens when
the arguments match in shape, but just one side (caller or callee) is sequential.
...
____________________
*Question: #3.6 The interaction of sequential and scalar arguments
Submitted by: Larry Meadows
Answer:
Rationale:
(reference to document change:)
Status: G1 Closed. See status of 3.5 - these were discussed together. Send
reply.
-------
The spec is pretty clear on requirements for sequence association across calls if
an actual argument is sequential. However, the situation where an actual
argument is non-sequential, but the associated dummy argument is sequential,
isn't clear. Consider the following case:
real a(100,100)
call sub(a)
subroutine sub(a)
real a(100,100)
sequence a
call sub1(a)
end
subroutine sub1(a)
real a(10000)
sequence a
end
Is the above program conforming? If so, it seems that some sort of remapping
must occur across the call to sub. What is the intention here?
And another sequence association question
Consider the following:
subroutine sub(S)
real S
...
end
...
...
real B(100)
sequence B
call sub(B(3))
...
real C(100)
sequence C
call sub(C(4))
This appears to be a conforming program. However, in the absence of
interprocedural information, we must assume that the second call might be taking
advantage of sequence association. It seems to me that this implies that ALL
arguments must be passed by descriptor, even if they are scalars or constants; I
argue as follows:
1. Sequential array elements MUST be passed by descriptor, since they may be
treated as arrays in the callee. Passing just the address is not sufficient, as
they might be mapped (otherwise, they could just be replicated and everything
would work).
2. If a dummy argument is a scalar, then the subroutine doesn't know if the
actual argument was an element of a sequential array (and thus passed by
descriptor), or an element of a non-sequential array. Therefore it must assume
that ALL scalars are passed by descriptor, and thus
3. Even elements of non-sequential arrays must be passed by descriptor, since the
called subroutine expects all scalars to be passed by descriptor.
Was this the intention of the committee? If not, what is the correct resolution?
For example, one could require that, if a sequential argument is ever passed to a
dummy argument, then the dummy must be declared sequential EVEN if a scalar; AND,
that an non-sequential actual argument can never be passed to a sequential dummy
argument.
Alternatively, one could require interface blocks in some situations.
__________________
*Question: #3.7 Alignment of dummy variables
Submitted by: Dave Watson
Answer: This item is illustrated with the example
subroutine murky(thick,dense)
!HPF$ distribute(block) :: dense
align with *dense :: thick
This is fine; it means the actual thick will be aligned with dense after dense is
remapped. This is a good example to add to the document.
subroutine clear (lucid, bright)
!HPF$ align with *lucid :: bright
This is not conforming since user is leaving the mapping of lucid to the
compiler, and there is no way that the user can assert that bright is aligned
with the compiler's choice.
Rationale:
(reference to document change:)
Status: G1 Example to add to document. Original email replys may suffice for
reply.
______________________
*Question: #3.8 Mapping inquiries - need intrinsic functions
Submitted by: John Merlin jhm@ecs.soton.ac.uk
Answer: Nothing will be added at this tim.e
Rationale: Closer examination (by John Merlin) shows usefulness is limited.
Anyone with a strong case for a useful intrinsic can make a new proposal.
Status: G2 Formal reply needs to be sent.
-------
This is in response to Mary's invitation to develop a preliminary
proposal for mapping enquiry functions.
Actually, this is really a non-proposal, because having though about
it I'm not so sure now whether mapping enquiry functions would be
very useful! Also this is more 'food for thought' rather than a
proper proposal.
Basically, the use I perceive(d) for them is to enquire about the
mapping of dummy arguments with the INHERIT attribute or transcriptive
distribution, in order to map local objects in a related way. The
problem with the idea is that, to use this facility sensibly, the
user must already know a lot about the dummy argument mapping a priori,
as we'll see.
As a toy example of where mapping enquiry functions might be useful,
consider this matrix multiplication function:
FUNCTION matprod (a, b)
REAL a (:, :), b (SIZE(a,2), :)
!HPF$ INHERIT a, b
REAL matprod (SIZE(a,1), SIZE(b,2))
FORALL (i = 1 : SIZE(a,1), k = 1 : SIZE(b,2))
matprod (i,k) = DOTPRODUCT (a (i,:) * b(:,k))
END FORALL
END FUNCTION
How should we map the result variable 'matprod'?
Assume that the user *knows* that the actual arguments (which may be
array sections, not necessarily whole arrays) are aligned to a
2-dimensional template 't' as follows:
a (i,j) is aligned with t (X1*i + X2, *)
b (j,k) is aligned with t (*, X3*k + X4)
where X1...X4 can be anything and the template may be distributed anyhow.
Then a sensible mapping of 'matprod' is:
ALIGN matprod (i,k) WITH t (X1*i + X2, X3*k + X4)
which avoids any communications within the function.
To specify this requires that 'a' & 'b's parent template 't' is
recreated locally within the function and distributed as before,
and that 'matprod' is appropriately aligned with it. This could
be done with suitable enquiry functions, and might look something
like this:
!HPF$ TEMPLATE t (T_LB(a,1) : T_UB(a,1), T_LB(b,2) : T_UB(b,2))
!HPF$ ALIGN matprod (:, :) WITH &
!HPF$ t (AL_LB(a,1) : AL_UB(a,1) : AL_STR(a,1), &
!HPF$ AL_LB(b,2) : AL_UB(b,2) : AL_STR(b,2)) &
!HPF$ PROCESSORS p (P_SIZE(a,1), P_SIZE(b,2))
!HPF$ DISTRIBUTE t (T_DISTR(a,1), T_DISTR(b,2)) ONTO p
where the enquiry functions are defined as follows:
T_LB (var, dim) } returns the lower bound / upper bound / size
T_UB (var, dim) } of dimension 'dim' of the template with which
T_SIZE (var, dim) } 'var' is ultimately aligned
P_LB (var, dim) } as above, but for the processor arrangement
P_UB (var, dim) } over which 'var's ultimate template is
P_SIZE (var, dim) } distributed.
AL_LB (var, dim) } returns the values l,u,s of the alignment of
AL_UB (var, dim) } dimension 'dim' of 'var' with its ultimate
AL_STR (var, dim) } target, i.e. the values in:
ALIGN var (.., :,..) WITH T(.., l:u:s, ..)
T_DISTR (var, dim)-- returns the distribution format for
dimension 'dim' of the template with which
'var' is ultimately aligned. (For use only
in a (RE)DISTRIBUTE directive!)
As I mentioned, a drawback with using mapping enquiry functions
is that in general the user must already know a lot about the mapping
that he is enquiring about. E.g., I can't see any obvious way of
reconstructing a parent template or processors arrangement without
knowing its rank (i.e. number of dimensions) a priori. Also, to use
the template sensibly, the user must know which template dimension
each dummy argument dimension is aligned with. This facility therefore
introduces scope for errors; e.g. the above directives are presumably
erroneous if the parent template or processors arrangement were
1-dimensional. If used correctly, this facility seems in general
make procedures less portable and general purpose, and it's arguable
that this conflicts with the reason for using INHERITed and
transcriptive mappings in the first place. On the other hand, it
may allow flexibility to be traded for efficiency.
Of course, an alternative to using enquiry functions would be
to explicitly pass-in all the required mapping info through
the procedure interface, as additional arguments. Then the
dummy argument mapping could be specified descriptively, rather
than inherited. Arguably this is stylistically better, since
we're considering cases where the actual argument mapping is
constrained somewhat. On the other hand, it can be argued that it's
undesirable to pass-in a lot of arguments that are used only in
data mapping directives; a non-HPF compiler might warn that they
are unused variables.
I should point out that the only reason for introducing enquiry
functions is to use them in mapping declarations. For other purposes,
e.g. to provide alternative branches in the code which depend on
data mapping, the existing enquiry subroutines suffice.
As you can tell, I'm now fairly neutral about the desirability of
enquiry mapping functions. I'll leave it to the HPFF to decide.
I may easily have overlooked applications where they'd be indisputably
useful. If the consensus favours them, I'll try to firm-up this
'proposal' a bit.
Best regards,
John Merlin.
__________________________
Question: #3.9 What object names are legal where?
Submitted by: David Loveman
Answer: Part 1 What about overload of names such as REAL X(10), template x,
processors x? This is illegal. The F90 class-one names takes care of the issue.
#3.9 part 2 - Subobjects of derived types are not mappable in HPF. The top-
level of any type is mappable. A proposal is needed to clarify and address the
mapping of components. We should allow one level of mapping, but not two levels.
Answer: Part 2 This is a good idea, but not at this time. Reconsider for HPF2.
General Question: David asks about the existing document phrase "non-terminal
symbols that are not defined". This needs further action.
Rationale:
(reference to document change:)
Status: G1 Part 1 & 2. Closed. Forward 2 to requirements.
General question about non-terminal symbols - PROPOSAL NEEDED.
--------
'object_name', one of the "Nonterminal Symbols That Are Not Defined" is valid
as:
a distributee
an alignee
an align target
a processor name
a template name.
One of the conditions by which a variable is determined to be sequential is
that
'it is a component of a derived type with the Fortran 90 SEQUENCE
attribute'
which seems to imply that non-sequential components of derived types may be
mapped and used as processor names or template names. Any clue as to how this is
done?
type ta
integer ii(10)
real rr(20)
!hpf$ DISTRIBUTE ii ...
!hpf$ ALIGN ii ...
!hpf$ ALIGN ... with ii(:)
!hpf$ PROCESSORS ii
!hpf$ TEMPLATE ii
type(ta) a_ta,b_ta,c_ta,d_ta,e_ta
end type ta
################ OR ################
type ta
integer ii(10)
real rr(20)
end type ta
type(ta) a_ta,b_ta,c_ta,d_ta,e_ta
!hpf$ DISTRIBUTE a_ta%ii ...
!hpf$ ALIGN b_ta%ii ...
!hpf$ ALIGN ... with c_ta%ii(:)
!hpf$ PROCESSORS d_ta%ii
!hpf$ TEMPLATE e_ta%ii
Can you clarify, please.
...........................................
In reviewing the HPF Language Spec, I can only find the following:
Constraint: An object-name mentioned as a distributee must be a simple name
and not a subobject designator. (p. 26, l. 35)
In the language of section 14.1.2 of the Fortran 90 standard, processor
arrangements are local entities of class (1); ...
(p. 40, l. 8-12)
In the language of section 14.1.2 of the Fortran 90 standard, templates are
local entities of class (1); ... (p. 42, l. 42-45)
The first seems to disallow
!hpf$ DISTRIBUTE ii ...
!hpf$ DISTRIBUTE a_ta%ii ...
The next two seem (I think) to disallow
!hpf$ PROCESSORS ii
!hpf$ TEMPLATE ii
!hpf$ PROCESSORS d_ta%ii
!hpf$ TEMPLATE e_ta%ii
I can't find anything pro or con on aligning parts of derived types, placement of
hpf directives within derived type definitions, etc.
And I think we really should have a definition somewhere for the "Nonterminal
Symbols That Are Not Defined."
____________________________
*Question: #3.10 Clarify that DISTRIBUTE applies to the template associated with
a variable
Submitted by: Mary Zosel zosel@llnl.gov
Answer:
Rationale:
(reference to document change:) Change text on p44, 27-29:
Note that the rank of the dummy argument and the rank of the dummy argumentUs
template need not match. The distribute applies to the template, not the array.
Status: G1 Closed.
----
(also see text following 3.11)
We have some text somewhere that makes sure that
the number of dimensions distributed is correct - but I always
assumed that it referred to the array's dimension, not it's
associatated template's dimension. I must admit, I haven't gone
into the document and looked.
The point is that in the case of a dummy with INHERIT, the dummy name is used to
talk about a template that may have very different shape than the dummy. THIS
CAUSES CONFUSION. I suggest (HPF 2) some modified syntax to use in this case:
e.g.
!HPF$ DISTRIBUTE (DUMMY) [ONTO ]
(I've invented these BNF names for the moment. You know what I mean). The use of
the parens may lead to syntactic ambiguity -- I dont care what the syntax *is* so
long as it is unique to this situation.
This could be generalized, at some significant peril, to allow one to always have
a handle on "the template to which foo is ultimately aligned" for any variable
foo.
If it refers to the associated template --- are we in a different
set of trouble, because one might call the subroutine with
actuals from arrays/templates of different dimensionality - and
still be ok as long as the size of the section matches in all cases.
In that case, one could not *describe* the distribution of the inherited template
because there is no unique such distribution. If you want to describe the
distribution of the dummy, dont use inherit! If you want to use inherit and you
cant describe the template distribution because of the ambiguity, you are just
outside the subset as it now stands.
Rob
------------
Discussion of notes of June meeting:
3.10 3.11 6.9 -
There exists distributions of dummies which cannot be described descriptively.
If INHERIT is present and an explicit mapping is present, ranks of actual and
dummy templates must match.
The rank of a dummy template need not matcch the rank of the dummy.
eal x(100), y(100,10)
call foo(x)
call doo (y(:,3))
sub foo(z)
real z(100)
interit z
!comment - both of the following are illegal
!HPF$ distribute z(*block)
!HPF$ distribute z(block, block)
When I call foo with x --- the template is 1d.When I call foo with y ... the
template is 2d. Guy wants a rewording of the restriction as stated. Text to be
provided and reviewed.
________________________
Question: #3.11 Review PROCESSOR arrangements, sizes, and equivalence
Submitted by: Originally from Adam Marshall adamm@nasoftwr.demon.co.uk
Answer:
Rationale:
(reference to document change:)
Status: G1 Subgroup reply was to remove INHERIT - but the issue of restrictions
on processor arrangements still needs to be reviewed. Still under consideration.
(See 3.10 and 6.9). Text to be provided. Consideration postponed at Aug.
meeting.
(Action Mary who requested the postponement.)
-------
Background for question #3.10 and #3.11
the template of the dummy is (a copy of) the template of the actual; and the
template of the actual is not necessarily just the size an shape of the section,
but is a large as (or larger than) the whole array of which a section was passed.
The awkward thing is that this template might have more dimensions than the
section, and the specification really doesn't address what you do in that
situation! ... Maybe instead of A(1,:) you have to pass A(1:1,:) as the actual.
That's pretty ugly.
--Guy
>From schreibr@riacs.edu Wed Dec 8 16:22:42 1993
I think this example raises some really interesting stuff:
A. The number of processors in a procs arrangement restriction
B. The identification of equally shaped procs arrangements
C. (And least important) Whether inherit should be in the subset
... extended examples and email deleted here
________________________
*Question: #3.12 INHERIT in subset etc.
Submitted by: (Marshall)
Answer: INHERIT is removed from subset.
Rationale: Straw poll on removing inherit from subset 25 - 0 - 6. As the email
discussion pointed out, other restrictions on the subset and full language make
the use of INHERIT in the subset meaningless. The case where it is useful - (to
talk about the original map of an array whose section is passed to the
subroutine) - is made useless because of the limit on use of the lone star in the
subset.
(reference to document change:)
Status: G1 Document change needed. Formal reply needs to be sent.
________________________
*Question: #3.13 Alignment to allocatable arrays
Submitted by: vas@watson.ibm.com (Vasanth Bala)
Answer: Illegal - already covered in the document.
Rationale:
(reference to document change:)
Status: G1 Reply explaining why illegal needs to be sent.
__________________________
*Question: #3.14 Unstructured distribution
Submitted by: Paul.Wesson@na.ox.ac.uk
Answer: No, can't do this in HPF1.
Rationale:
(reference to document change:)
Status: G1 Needs formal reply. Might be input to unstructured data requirements.
----------
Date: Wed, 9 Jun 93 15:30:25 BST
From: Paul.Wesson@na.ox.ac.uk
Message-Id: <9306091430.AA26451@client29.comlab.ox.ac.uk>
To: hpff-comments@cs.rice.edu
Subject: HPFF Question.
Dear Sir/Madam, 9th June '93
>>> Ref: DISTRIBUTION DIRECTIVES <<<
I'm involved in developing a parallel program for
electromagnetic calculations on unstructured three dimensional
meshes. The basic sequential code is running and I'm working on
porting the code to a "general distributed memory" parallel
machine.
To load balance the calculations the mesh is allocated
over the available processes using standard partitioning
algorithms, in my case, Recursive Spectral Bisection. Anyway
I'm at the position where I know where to allocate my unknowns.
Using this information a "compiler" should be able to generate
the correct message routines. Rather than coding this myself I
wondered if HPF would be a practical option.
My rough impression of HPF is that it's similar to
using "tiles" on the KSR1 where arrays are allocated in blocks,
or cyclically, over the available processors. This is similar to
the !HPF$ DISTRIBUTE directive. This is ideal if you're working
on regular grids but no for unstructures meshes.
Well my main question is that can the DISTRIBUTE directive
be used to allocate the array A(10), say over the processes so that
Process 1 gets components 2,5,6,7
Process 2 1,3,4,8,9,10
using HPF directives? If not, will HPFF version 2.0 do it? Or
have I overlooked another directive.
Any help would be welcomed.
Paul.
__________________________
*Question: #4.1 Cyclic example
Submitted by: Denis.Hugli@irisa.fr (Denis Hugli)
Answer: Illegal in HPF.
Rationale: A 2-dimensional array may not be mapped onto a single dimensional
processors arrangement.
(reference to document change:)
Status: G1 Reply needs to be sent.
________________________
*Question: #4.2 Distribution question
Submitted by: Stanly Steinberg, stanly@math.unm.edu
Answer: Mistake in question.
Rationale:
(reference to document change:)
Status: G1 Formal reply - (pointing out mistake) needed.
____________________
*Question #4.3 - dropped from list - not a formal question
____________________
*Question: #4.4 Ragged Array pointer example
Submitted by: Henk Sips henk@cp.tn.tudelft.nl
Answer: Referred to irregular data requirements group for consideration. Answer
to the true? question in text is .yes, true.
Rationale:
(reference to document change:)
Status: G2 - Formal reply needed. Make sure requirements group records.
________________________
*Question: #5.1 (D1): Arguments to HPF_LOCAL routines
Submitted by: David Loveman
Answer: Don't allow explicit shape in interface-spec for HPF_LOCALS.
Rationale: There is a rational for the existing apparent inconsistency (error
checking), BUT the potential confusion factor and potential classroom hours
wasted explaining dark-corners of HPF outweighs the benefit.
(reference to document change:)
Status: G2 Document change needed. Formal reply needed.
________________________
*Question: #5.2 (D2) Do loop indexes
Submitted by: David Loveman.
Answer: No.
Rationale: This is a machine-dependent advice to user issue. Individual vendors
can address this in documentation.
(reference to document change:)
Status: G2 Formal reply needed.
________________________
Question: #5.3 (D3) Don't allow CYCLIC(n) arguments to HPF_LOCALS
Submitted by: David Loveman
Answer:
Rationale:
(reference to document change:)
Status: G2 The example given does illustrate a problem, but the suggested fix may
be overkill. Action - Guy and David to prepare a new proposal.
-----
!hpf$ template t(50)
!hpf$ distribute t(cyclic(5))
real a(46)
!hpf$ align a(i) with t(i+3)
a(1:46:3) =...
If a is distributed over 5 processors, this slice is very ugly and irregular.
________________________
Question: #5.4 (D4) Directives in explicit interfaces
Submitted by: David Loveman
Answer: The program is illegal.
Rationale: This is the same issue as #3.7.
(reference to document change:)
Status: G1 Formal reply needed.
-------
Some restrictions are placed on directives which occur in explicit interfaces.
In
particular, we make the following restriction:
*** If two dummies are ultimately aligned to the same template, then one can
be passed descriptively only if the other is also.
For example, the following specification should not be allowed:
SUBROUTINE foo(A,B)
INTEGER A(:), B(:)
!HPF$ ALIGN A(i) WITH *B(i)
!HPF$ DISTRIBUTE B(BLOCK)
________________________
Question: #5.5 (D5): Extrinsic Program Units
Submitted by: David Loveman
Answer: (a) routine defined only at top-level of HPF_LOCALS (b) ...
Rationale:
(reference to document change:)
Status: G2 Open (a) Needs document change and (b) second reading of a scalar
interface proposal - the straw poll about whether this should be HPF 1+ or HPF 2
was 13-14-5. Agreement to put in appendix. Action Henry and David to get
together on details, including review of proposed requirement for sequential
args, and name.
-----
Original questions:
#D.5 (a) What happens if GLOBAL_ALIGNMENT is called with an HPF_LOCAL local
variable? Due to the nature of F90 argument association, the example of
usefulness isn't legal F90. These routines are only defined at the "top-level"
of HPF_LOCALS. Guy will provide text to clarify.
More specific text provided by Guy: Clarify that GLOBAL_TEMPLATE,
GLOBAL_ALIGNMENT and GLOBAL_DISTRIBUTION take a first argument that must
be a
dummy array that is associated with a global HPF array actual argument. Also
clarify that such argument association is not transitive for this purpose.
#D.5 (b) Define SCALAR extrinsic interface. Action - invite a formal proposal.
We will decide later if this is HPF1.1 or HPF2.
-----
excerpt from related Aug. minutes:
Item 5.5(b): Henry Zongarro prepared a specific proposal for a SCALAR
extrinsic interface. Two questions were noted: (1) Is SCALAR the right name?
(2) Why do the arguments have to be sequential? The subcommittee recommended
that this be added to the requirements for tasking in HPF 2. There was
discussion about whether this should be considered for HPF 1+. The need for a
convenient mechanism for this early on was noted.
Straw poll: should this go in HPF 1+? 13 yes, 14 no, 5 abstain.
Agreement to put in such a proposal in the appendix (ala HPF_LOCAL), so that
vendors wishing early implementation would use the same interface. Henry and
David Loveman will confer on details of the proposed interface. Second straw
poll: Is SCALAR the wrong word? 23 yes, 1 no, 8 abstain. Possible names noted
were: SINGLE, UNI, UNIPROCESS.
________________________
Question: #5.6 (D6) : Pure Functions
Submitted by: David Loveman
Answer:
Rationale:
(reference to document change:)
Status: G2 Deferred to Loveman for more information.
------ The meaning of a PURE function in HPF should be further restricted by
adding the following constrain to the conditions in the hPF Language report:
*** No name in the scope of a PURE procedure and no entity that is associated
other than by argument association (that is: use, host, pointer, storage, or
sequence association) with any name in the scope of a PURE proceudre may be
explicitly (by user-written HPF directives) mapped.
The purpose of this restriction is to allow interations of FORALL constructs
containing PURE functions to be distributed over processors. This restriction is
capable of being checked by the compiler.
In addition, we interpret the HPF specification to say that a PURE function may
not modify any of its arguments. (A PURE subroutine may, however; but note that
PURE subroutines cannot be called directly from insdie a FORALL construct.)
________________________
*Question: #5.7 (D7): Does m have to positve in block and cyclic directives.
Submitted by:
Answer: Yes. Modify the document to clarify.
Rationale:
(reference to document change:)
Status: G1 Document needs changes. Formal reply needs to be sent.
________________________
Question: #5.8 (D8) HPF_LOCAL_LIBRARY
Submitted by: David Loveman
Answer: New routines added to library.
Rationale:
(reference to document change:)
Status: G2: In progress - several parts identified - (a) 3 routines accepted in
second reading. - more routines under consideration - action David. (b) new
routine accepted in second reading - and document changes needed to eliminate
procid.
---
Accepted for (a) (22-0-3) new local functions added to HPF 1 as a part of the
HPF_LOCAL library:
LOCAL_BLKCNT(ARRAY, DIM, PROC) (
returns the number of pieces of a given array that are allocated to the
given processor.
LOCAL_LINDEX (LOCAL_LINDEX (ARRAY, BLK, DIM, PROC)
returns the low indexes associated with each block.
LOCAL_UINDEX LOCAL_UINDEX (ARRAY, BLK, DIM, PROC)
returns the upper indexes associated with each block.
DIM and PROC are optional in the above routines.
More routines still proposed for (a): action David. Need a way given a specific
index associated with a dummy to find out what other processor has that part of
the array - and also to find out whether or not the array is replicated. DL
Proposal presented. For replication, it was suggested that a logical argument be
added for "is replicated". As a first reading, these routines were accepted
(including the replication issue): 25-0-6. The question remains about replacing
global_to_local. Maybe different optional arguments are needed. In the second
reading must address name, address the overlap between these and global_to_local,
and also check on the details of specifying replication.
Accepted for (b) (25-0-0): Add new local function to HPF 1 ps a part of the
HPF_LOCAL library:
MY_PROCESSOR()
Returns the returns a scalar of type integer with a value in the range of
0 to n-1 where n is the number of physical processors.
Clarify in the document that n is the same value as is returned by
NUMBER_OF_PROCESSORS. Remove all references to PROCID from the document,
modifying other routines as needed.
-------
#5.8 (a) Define GLOBAL_TO_PHYSICAL for use in HPF_LOCALS. Discussion - Andy
Meltzer would like to see a variation on this call that also returns the
blocksize of the data on the given processor. This is an efficiency short-cut,
but the place where it is most likely used is where the efficiency payoff is very
important. Action: Andy to prepare a modified proposal for consideration.
#5.8 (b) Define HPF_MY_PROCESSOR() for use in HPF_LOCALS. Needs function write-
up for a function that returns integer 1-n.
Yes - this is probably useful to standardize spelling, but there are issues -
(a) does it return a pid or and int and (b) if it is an int is it 1 to n or 0 to
n-1? Straw polls were taken for guidance in a formal proposal - with a
preference for pid - and 1-n based values, if int. This item was proposed with
an invitation for proposals.
-----
____________________
*Question: #6.1 Can named constants be distributees, etc.
Submitted by: Henry Zongaro zongaro@vnet.ibm.com
Answer: Yes.
Rationale:
(reference to document change:) No change needed.
Status: G1: Formal reply to be sent.
-----
Section 3
p. 23, lines 20-21, p. 31, line 17 and p. 32, line 43
All of these lines refer to object-names. I just wanted to be
certain that it was the intention to allow named constants to be
distributees, alignees and align-targets. Since the term "data
object" is used pretty consistently throughout this section, I
assume named constants are allowed, but I didn't see any example
demonstrating this.
________________________
*Question: #6.2 Is "not subobject designator" necessary?
Submitted by: Henry Zongaro zongaro@vnet.ibm.com
Answer:
Rationale:
(reference to document change:) Add text p 31 lines 23+ p 26 lines 35+
RA ... must be a simple name. It must not be a compound-name of a derived type.S
Status: G1: Closed. Document change needed. Send reply.
-------
p. 26, lines 35-36. Is the constraint, "An object-name mentioned as a
distributee must be a simple name and not a subobject
designator," necessary? According to the Fortran 90 standard
(R304), a name is a letter followed by alphanumeric-characters.
Since subobjects contain percent signs or parentheses, they are
not names.
________________________
Question: #6.3 Do mapping directives restrict pointer target?
Submitted by: Henry Zongaro zongaro@vnet.ibm.com
Answer:
Rationale: Straw poll decision that pointers cannot be mapped - 18-5-7.
(reference to document change:) page 33 line 33 new const - an alignee in an
ALIGN may not have the pointer attribute
page 27 line 11 a distributee in a DISTRIBUTE may not have the pointer attribute
Status: G1: Closed. Document change needed. Send reply.
what about replicating pointers? --- leave it to the compiler to optimize this
... it is ok to use in realign and redistribute ...
first reading. Action GLS to fix text.
----------
pp. 38-40. Do mapping directives specified for a variable with the POINTER
attribute apply only when the variable becomes associated with a
target through an ALLOCATE statement, or do they also restrict
the targets with which the variable may be associated? Or does
a pointer acquire the mapping of its target, regardless of the
mapping of the pointer (explicit or default)? For example, is
the following HPF conforming?
program p
pp. 38-40. Do mapping directives specified for a variable with
the POINTER
attribute apply only when the variable becomes associated with a
target through an ALLOCATE statement, or do they also restrict
the targets with which the variable may be associated? Or does
a pointer acquire the mapping of its target, regardless of the
mapping of the pointer (explicit or default)? For example, is
the following HPF conforming?
integer, pointer :: ptr(:)
integer, target :: t1(100), t2(100)
!HPF$ processors :: proc1(10), proc2(20)
!HPF$ distribute (block) onto proc1 :: ptr, t1
!HPF$ distribute (cyclic) onto proc2 :: t2
ptr => t1
! Does the difference in the distributions of ptr and t2 make
! the following pointer assignment invalid? If not, what are
! the mappings of ptr and t2 after the pointer assignment?
ptr => t2
end program p
________________________
*Question: #6.4 Is processor or template declaration in module PUBLIC by default?
Submitted by: Henry Zongaro zongaro@vnet.ibm.com
Answer:
Rationale: One can't say PRIVATE unless the whole module is PRIVATE.
(reference to document change:)
page 40 line 17 .... a processor arrangement declared in a module has the default
accessibility of the module
page 42 line 15 - same text with template replaced
Status: G1: Document text change needed. Formal reply needs to be sent.
-------
pp. 40-44. If a processor arrangement or a template is declared in the
specification-part of a module, does it have the PUBLIC attribute
by default? If PRIVATE is specified with no access-id-list, does
the processor arrangement or template have the PRIVATE attribute?
________________________
*Question: #6.5 Does appearance of object-name in directive impact scope?
Submitted by: Henry Zongaro zongaro@vnet.ibm.com
Answer: (Good question.) As stated program is in error. Directives don't
affect scoping rules.
Rationale:
(reference to document change:)
Status: G1: Formal Reply needs to be sent.
-----------
General Does the appearance of an object-name in a static mapping
directive make that a local-entity of the scoping unit? In
particular, what is the result of the following program?
program p
integer i
i = 13
call sub
print *, i
contains
subroutine sub
!HPF$ processors :: proc
!HPF$ distribute onto proc :: i
i = 17
end subroutine sub
end program p
Does this program print the value "17", print the value "13" or
is it an invalid attempt to specify the DISTRIBUTE attribute for
a host associated object? On page 2, lines 31-33, it is stated
that "The new directives. . . do not change the value computed
by the program." Given that, the value cannot be "13", since the
value printed would be "17" if the directives were not present.
However, the similarity of the new directives to Fortran 90
syntax make it seem that "13" would be a more desirable result.
The following program will print the value "13". To my mind,
the DISTRIBUTE directive above should be playing a role similar
to the STATIC statement below.
program p
integer i
i = 13
call sub
print *, i
contains
subroutine sub
static i
i = 17
end subroutine sub
end program p
________________________
*Question: #6.6 Should ALIGN be restricted in the subset?
Submitted by: Mary Zosel, zosel@llnl.gov
Answer: No, don't restrict align.
Rationale:
(reference to document change:)
Status: G1: Closed.
----------
I propose that in the HPF subset, the form of the align statement
be limited so that arbitrary permutations of array dimensions are
not required.
...
______________________________
*Question: #6.7 Expectations for replicated data
Submitted by: Mary Zosel zosel@llnl.gov
Answer: It is the responsibility of the compiler to enforce the correct values
for replicated data. Add advice to implementors.
Rationale:
(reference to document change:)
Status: G1: Closed. Decided not to add text about replication.
--------
Please clarify the expectations for replicated data.
If a variable, scalar or array is replicated across multiple
processors, is it the responsibility of the compiler or the
programmer to keep the data values in sync.
...
___________________________________
*Question: #6.8 Collapsing to single alignment
Submitted by: John Merlin jhm@ecs.soton.ac.uk
Answer: Can't say this in HPF1 - refered to the general issues section for
HPF2 requirements document.
Rationale:
(reference to document change:)
Status: G1: Closed. Send reply.
-----
2.6/6.8 Question of replications of sections not an entire array.
straw poll - if via aligns (multilevel) you say that an object is replicated over
a portion of a template, then is it replicated over the entire axis? ...
Replication is either not at all or total? Straw poll 4-5-18
Some discussion from item 2.6
add the example to show
align with a(*) :: s
align A(I) with B(3*i)
which has the effect
ALIGN with B(3:n:3) :: s
This cannot be directly stated in HPF
In further discussion at the June meeting - this issue became not so clear.
Example:
real S a(20) B(100)
align with A(X):S
Align with B(50:69) :: A
The effect is: align with B(1:69)::S
This looks like s is replicated over only a section of B
One possibility is replication everywhere - but this isn't acceptable either.
This is not a clarification or interpretation .... large change
------
original question:
Consider the following toy code (which is supposed to do the forward
elimination bit of LU decomposition):
REAL A (n,n)
DO r = 1,n
r1 = r+1
CALL LU_itn (A(r1:n, r1:n), A(r1:n, r), A(r, r1:n), A(r,r), (n-r))
END DO
...
SUBROUTINE LU_itn (array, row, col, elem, m)
INTEGER m
REAL array (m,m), row (m), col (m), elem
row = row / elem
array = array - SPREAD (col, 2, m) * SPREAD (row, 1, m)
END SUBROUTINE
(1) I could presumably write the following mapping directives in
subroutine 'LU_itn':
!HPF$ INHERIT array
!HPF$ ALIGN row (:) WITH array (*, :)
!HPF$ ALIGN col (:) WITH array (:, *)
!HPF$ ALIGN elem WITH array (*, *)
In this case, 'row', 'col' and 'elem' are replicated over a regular
section of a dimension of the parent template (i.e. the template of
'A'), rather than over a complete dimension of it.
The same effect, replication over a regular section of a template,
can also be achieved by a 2-stage alignment (which is , e.g.:
REAL S, A(20), B(100)
!HPF$ ALIGN S WITH A(*)
!HPF$ ALIGN A(:) WITH B(51:70)
!HPF$ DISTRIBUTE B (BLOCK)
However, it can't be achieved by a single alignment.
This seems to conflict with the principle, stated in section 3.1
of the Language Spec, that an alignment of A with B and B with C
is immediately `collapsed' so that A is aligned directly with C.
I take this to mean that any indirect alignment via intermediaries
can also be expressed as a direct alignment.
What's the interpretation? Can we interpret these cases as meaning
replication over whole dimensions, or is replication over regular
sections of templates (and thus processors) supposed to be supported?
________________________
*Question: #6.9 (related to 6.8) Mapping inherited arguments
Submitted by: John Merlin jhm@ecs.soton.ac.uk
Answer: See 3.10/3.11 - Inherit removed from subset.
Rationale:
(reference to document change:)
Status: G1: Closed - send reply. see 3.10 and 3.11 (Check that this was really
answered.)
---------
(2) In subroutine 'LU_itn', if we have
!HPF$ INHERIT array, row, col, elem
then I presume that 'row', 'col' and 'elem' cannot have their
distributions prescribed or described, because their rank is different
to that of their parent template ('A'). E.g.:
!HPF$ DISTRIBUTE row (BLOCK)
is illegal, because 'row' here actually means its parent template,
which is 2d.
!HPF$ DISTRIBUTE row (BLOCK, BLOCK)
is also illegal, because 'row' itself is 1d, and the length of the
distr-format-list must equal the rank of the distributee (a constraint
in section 3.3).
Is this correct? If so, is a remedy possible?
__________________________
Question: #6.10 Should variables in NEW be restricted to named variables
Submitted by: Henry Zongaro zongaro@vnet.ibm.com
Answer: NEW variables will be limited to variable names (scalars, arrays, and
derived types).
Rationale: This was the probably original intent. The overall usefulness of
other forms of NEW variables in considered limited and it is unlikely that
implementors handle the more complicated cases anyway.
(reference to document change:) page 81 line 6 change variable-list to variable-
name-list
page 81 line 12 change A variable named to Any object specified
Status: G2 Part accepted, part still needs second reading. Send formal reply.
Not ready for second reading - postponed at Aug. meeting. Rob will think about.
Specific postponed item:
Drop the words Rpointer orS from p.81 line 14 and allow a NEW variable to be a
POINTER
---
NEW variables: A proposal to limit NEW list to variable names (i.e. scalars &
whole arrays & whole derived types) was accepted without controversy. An
additional proposal was made to remove restriction on pointer (allow NEW to be
pointer). There will be a second reading next time. Note: new applies to the
pointer itself, not its target (to avoid aliasing problems).
________________________
*Question: #6.11 Can INDEPENDENT be used on loop with no loop control?
Submitted by: Henry Zongaro zongaro@vnet.ibm.com
Answer: Agree.
Rationale: Only possible use is on loops with 0 or 1 trips.
(reference to document change:) page 80 line 45 change "precede a DO" to "precede
an indexed DO"
Status: G2 document change needed. Formal reply needed.
--------
p. 81, lines 7-16. Is there any way in which a do-construct with no loop
control or a do-construct with WHILE can perform "useful" work
and terminate without violating the conditions under which a
do-construct may be considered to be INDEPENDENT? If not, should
a constraint be added prohibiting these forms of do-construct
from having the INDEPENDENT applied? For example, the following
appear to be HPF conforming, given the current rules, but are
they useful?
!HPF$ independent
do
end do
!HPF$ independent
do while(.true.)
end do
------------
comment from chk@rice.edu
I do not believe this could ever do useful work. Reasoning: terminating
the loop would require a branch (or STOP), which would trivially affect
later iterations (i.e. the ones that aren't executed).
> !HPF$ independent
> do while(.true.)
> end do
This particular WHILE has the same properties as the DO above. A slight
variation does have slightly less useless properties:
!HPF$ INDEPENDENT
do while (complicated_condition(x))
...
end do
This is essentially an infinite loop guarded by complicated_condition(x) -
i.e. it is equivalent to
if (complicated_condition(x)) then
do
...
end do
end if
(Reasoning: If complicated_condition(x) ever switches from .TRUE. to
.FALSE., then it is dependent on something that happened in the loop. If
the loop exits due to a branch or STOP, see discussion of the empty DO
above.)
Calling such a construct "useful work" is probably stretching a point. I
suppose it might be a way to assert that code is unreachable, but there
must be better ways to do that.
In short, these constructs are not useful, but their meaning is
well-defined. I would support adding the constraint, but I don't think
it's an absolute requirement.
_________________________
Question:#6.12 Restrict variables in NEW from COMMON, etc.
Submitted by: Henry Zongaro zongaro@vnet.ibm.com
Answer:
Rationale:
(reference to document change:) The text has now been expanded to read:
On page 82, line 39, change RMore formallyS to RmoreoverS.
On page 81, line 16, add these bullets:
Be, or be storage associated with, an object in COMMON;
Be use associated;
Be host associated; nor
Be accessed by host association.
Second reading vote: 23 - 0 - 1 Action Chuck to provide a rational related to
this one.
Status: Closed. document change needed. Send reply. Second reading vote: 23 - 0
- 1 Action Chuck to provide a rational related to this one.
_______________________
Question:#6.13 Interference using pointer, etc.
Submitted by: Henry Zongaro zongaro@vnet.ibm.com
Answer:
Rationale:
(reference to document change:)
Status: New G2 - checking with chk - notes from meeting say "yes, Chuck to
provide text".
------------
p. 81, lines 17-48,
p. 82, lines 1-29. Should bullets be added defining interference
involving the use of pointer assignment, ALLOCATE, DEALLOCATE,
NULLIFY and inquiry functions?
For example, I believe that, assuming the following declarations,
integer, allocatable :: a(:)
integer :: sizes(2)
neither of the following loops should be HPF conforming:
1) !HPF$ INDEPENDENT
do i = 1, 2
if (i .eq. 1) allocate(a(2))
if (allocated(a)) a(i) = i
end do
! Does a(2) == 2, or is a(2) undefined?
2) allocate(a(10))
!HPF$ INDEPENDENT
do i = 1, 2
sizes(i) = size(a)
if (i .eq. 1) then
deallocate(a)
allocate(a(2))
end if
end do
! Does sizes == (/10, 2/) or (/2, 10/)?
------------------
comment from chk@rice.edu
This was our intent. You are right, the first two bullets should be more
explicit that "assignment" includes modifications to pointers, etc.
____________________
Question:#6.14 Atomic objects across iterations.
Submitted by: Henry Zongaro zongaro@vnet.ibm.com
Answer: No, the locals are considered distinct. If an implementation is not
stack-based, this may require serialization of the look.
Rationale: If a subroutine with locals is called from inside an independent loop
- are the locals distinct? Observation: In stack-based implementation locals
called from inside an independent loop are the locals distinct. But the Fortran
carefully standard skirts the issue.
(reference to document change:)
Status: G2: Action Guy Steele - clarify text in advice to implementor that the
loop must be serialized if unique storage is not provided for the locals.
------
p. 81, lines 21-25. Is the following program HPF conforming? In
particular, is j considered to be the same atomic object during
both iterations? If j had the SAVE attribute, clearly it would
be the atomic object which was being assigned to during each
iteration, and so this would not be HPF conforming. But is it
the same atomic object without the SAVE attribute?
program p
!HPF$ independent
do i = 1, 2
call sub(i)
end do
end program p
subroutine sub(i)
integer :: i, j
j = i ! Am I assigning to the same atomic
! object?
end subroutine sub
---------------
comment from chk@rice.edu
It is not the same atomic object. This derives from the Fortran 90
definition, which states that automatic (i.e. local) variables in
procedures represent new objects on every call unless they have the SAVE
attribute. (Sorry, can't cite the page - my copy of the reference is
elsewhere.) I believe this was also true in FORTRAN 77. Of course,
compilers do not always allocate new objects - however, programs that rely
on this behavior are not standard-conforming.
-----
from June meeting
If a subroutine with locals is called from inside an independent loop - are the
locals distinct? Observation - In stack-based implementation the answer is yes.
but Fortran standard skirts the issue. Action GLS provide advice to
implementors. Note the requirement to serialize if not unique storage.
________________________
*Question:#6.15 SUM_PREFIX example result
Submitted by: Henry Zongaro zongaro@vnet.ibm.com
Answer: Yes. It is an error in the example of sumprefix
Rationale:
(reference to document change:)
Status: G2: need document change; need reply to author
-------------
Section 5
p. 94, lines 38-41. Should the third example from the bottom have
the following result?
_ _
| 0 11 0 0 0 |
SUM_PREFIX(B, MASK=M, SEGMENT=S, EXCLUSIVE=.TRUE.) is | 0 13 0 4 5
|
|_0 13 8 0 0_|
________________________
Question:#6.16 May internal/module subprograms be HPF_LOCAL?
Submitted by: Henry Zongaro zongaro@vnet.ibm.com
Answer: No.
Rationale:
(reference to document change:)
Status: G2: (See 2.3, 6.16, 6.17, 8.15) First reading
Allow the EXTRINSIC(...) prefix to appear at the beginning of PROGRAM, MODULE,
and BLOCK DATA statements. As with FUNCTION and SUBROUTINE program units,
if the
first statement of the program unit has no extrinsic prefix, then an HPF compiler
assumes EXTRINSIC(HPF).
Extrinsic kind keywords whose names begin with RHPFS are reserved for
present or future definition by this specification. At present only the
keywords HPF and HPF_LOCAL have defined meaning. A program unit whose
extrinsic kind keyword begins with RHPFS is said to be Rof an HPF extrinsic
kindS.
Within any module of an HPF extrinsic kind, every module-subprogram must be of
that same extrinsic kind and any module-subprogram whose extrinsic kind is not
given explicitly is assumed to be of that extrinsic kind. Similarly, within any
main-program or external-subprogram of an HPF extrinsic kind, every internal-
subprogram must be of that same extrinsic kind and any internal-subprogram whose
extrinsic kind is not given explicitly is assumed to be of that extrinsic kind.
A function-stmt or subroutine-stmt that appears within an interface-block within
a program unit of an HPF extrinsic kind may have an extrinsic prefix mentioning
any extrinsic kind supported by the language processor; but if no extrinsic-
prefix appears in such a function-stmt or subroutine-stmt, then it is assumed
to be of the same HPF extrinsic kind as the program unit.
If a module of one HPF extrinsic kind is used from a program unit of another HPF
extrinsic kind, then the effect must be that only names of procedures, procedure
interfaces, and type definitions in the module are made accessible to the using
program unit; names of data objects may not be used. Any data defined by the
module must be private, or else the USE statement must have an ONLY option that
specifies only name of procedures, procedure interfaces, and type definitions.
[Note, however, that the existing prohibition on calling a global HPF routine
from an HPF_LOCAL routine remains as a separate restriction. See section A.2.1,
second paragraph.]
A named COMMON block in any program unit of an HPF kind will be associated with
the COMMON block, if any, of that same name in every other program unit of that
same extrinsic kind; similarly for unnamed COMMON. But a COMMON block in a
program unit of one HPF kind is distinct from and not associated with any COMMON
block in a program unit of any other HPF kind. (Implementors are advised to
follow a similar rule for all extrinsic kind keywords, not just those starting
with RHPF_S.)
________________________
Question: #6.17 Initialization of local HPF common blocks
Submitted by: Henry Zongaro zongaro@vnet.ibm.com
Answer: New extrinsic interface proposal.
Rationale:
(reference to document change:)
Status: G2 ( 2.3, 6.16, 6.17, 8.15 - see 6.16 for proposal)
-----------
May variables in local HPF COMMON blocks be initialized? If so, how? In
Fortran 90, a variable in a named COMMON may only be initialized in a
BLOCK DATA program unit, but I assume that an HPF compiler would treat any
such COMMON blocks as global HPF COMMON blocks, since there's no way to
specify the EXTRINSIC attribute on a BLOCK DATA. Was this an oversight?
________________________
*#6. 18 Question: Is the space required in double-word keywords?
Submitted by: David Loveman
Answer: No - both NO SEQUENCE and NOSEQUENCE,
Rationale: Consistent with Fortran 90
(reference to document change:) #6. 18 Question: Is the space required in
double-word keywords?
Submitted by: David Loveman
Answer: No - both NO SEQUENCE and NOSEQUENCE,
Rationale: Consistent with Fortran 90
(reference to document change:) change needed in 2.3
Status: G2 Mary to supply text. Instead of syntax - do this in document section
2.3, copying the F90 text for split keywords. Formal reply needed.
________________________
#7.1 Question: Why the constraint that a function result is nonsequential?
Submitted by: Henry Zongaro , 15 Jun 94
Answer:
Rationale:
(reference to document change:)
Status: G1 Minutes from Aug. discussion:
The subcommittee took a straw poll :- allow sequential array functions 8, - don't
allow sequential array function 4 - abs. 4. Such functions must have an
explicit interface. By default they are non-sequential , but can make
sequential. If there is an alternate entry, F90 says that the result has storage
association, so it must be sequential. NOTE this requires a change to be able to
say function name in p145, H701.
First reading vote to allow sequential array functions 20 - 4 - 5. Text
change needed.
--------
Hello,
According to the constraint on page 145, lines 47-48, of the HPF Language
Spec, "The result variable of an array-valued function that is not an intrinsic
function is a nonsequential array." According to page 144, lines 23-24,
"A sequential variable can be storage associated or sequence associated;
nonsequential variables cannot." Therefore, the result variable of an array-
valued function cannot be storage associated.
However, according to the Fortran 90 standard, section 14.6.3.3, "An ENTRY
statement in a function subprogram causes storage association of the result
variables."
It appears that an array-valued function must not contain an ENTRY
statement, since that would cause it to be storage associated (unless all
ENTRYs specify the same result variable.) Is this true? If not, I believe the
wording of the constraint on page 145 needs to be changed.
Thanks,
Henry Zongaro
---- notes from minutes Aug ---
The subcommittee took a straw poll :- allow sequential array functions 8, -
dontU sequential array function 4 - abs. 4. Such functions must have an
explicit interface. By default they are non-sequential , but can make
sequential.
If there is an alternate entry, F90 says that the result has storage association,
so it must be sequential. NOTE this requires a change to be able to say function
name in p145, H701. check for sure that variable name covers function names.
MARY check this.
First reading vote to allow seqential array functions 20 - 4 - 5.
____________________________________________________
#7.2 Question: Is a scalar template legal?
Submitted by: Larry Meadows , 8 Jun 94
Answer: Yes - scalar templates are ok (but we probably don't want to call
attention to it.
Rationale:
(reference to document change:)
Status: G1 Closed. Sent reply.
________________________________________________
#7.3 Question: Circular distribution definitions
Submitted by: Tom MacDonald tam@cray.com 20 Jun 94
Answer:
Rationale:
(reference to document change:)
Status: G1 First reading text change proposed --- add in the appropriate place:
"... and there may be no subsequent static mapping directive affecting the
mapping of the array ... after 7.1.6.2 of F90 standard ...."
_________
...
The following example contains a circular definition
between A and B.
subroutine S( A, NA, B, IA, N, IB )
dimension A(NA), B(A(IA))
!hpf$ distribute B(block(N))
!hpf$ distribute A(block(B(IB)))
I couldn't find anything in the HPF spec. that prohibits this kind of
circularity (though I certainly could have missed it) and it seems to me
that the implementation is going to have a hard time knowing how to
distribute "A" and "B" when their definitions depend upon each other.
I recommend a constraint against any use of an "object-name" before the
declaration is complete. Since, the "distribute" directive is part of the
declaration, the use of "A" in the "dimension" statement violates the
constraint when the "distribute" directive for A is encountered.
Any comments?
Thanks in advance.
Tom MacDonald
tam@cray.com
Date: Tue, 21 Jun 1994 10:20:10 -0700
From: Rob Schreiber
To: tam@ironwood.cray.com
Dear Tom,
The wierdness and difficulty that your example illustrates is only now
becoming clear to me. It is ncessary, however, to define what is
forbidden in order to forbid it.
dimension A(NA)
dimension B(A(IA)) ! requires an access of A
chpf$ distribute B(block) ! requires knowing how big is
B
chpf$ distribute A(block(B(IB))) ! requires an access of B
! before A can be distributed
The circularity is as follows:
Need to know the (XXX) ------> (in order to know the) (YYY) :
distribution of A
/ /|\
/ |
|/ |
-- |
value of A(NA) |
\ |
\ |
\| |
-- |
Size of B |
/ |
/ |
|/ |
-- |
distribution of B |
\ |
\ |
\| |
-- |
value of B(IB) -/
Here is a possible solution. The expressions that occur in mapping
directives chould be restricted further.
Possible new syntax constraint:
In addition to being specification expressions, the primaries must
not be array elements, unless the array is replicated and distributed
in such a manner that it is present on all processors.
Rob
Date: Fri, 8 Jul 94 11:04:46 EDT
From: "Henry Zongaro"
Hello,
In the circularity problem,
> dimension A(NA)
> dimension B(A(IA)) ! requires an access of A
> chpf$ distribute B(block) ! requires knowing how big is B
> chpf$ distribute A(block(B(IB))) ! requires an access of B
> ! before A can be distributed
>
>The circularity is as follows:
[picture removed]
>Here is a possible solution. The expressions that occur in mapping
>directives should be restricted further.
>Possible new syntax constraint:
>
>In addition to being specification expressions, the primaries must
>not be array elements, unless the array is replicated and distributed
>in such a manner that it is present on all processors.
another possibility might be to try to adapt the language of Section 7.1.6.2
of the Fortran 90 standard to the situation. There it's stated that:
If a specification expression includes a reference to the value of
an element of an array specified in the same specification-part,
the array bounds must be specified in a prior declaration.
Perhaps something like the following could be added for HPF:
and any explicit mapping or inherit attribute for the array
must be completely specified in prior specification-directives.
This language needs some work, but by saying completely, I'm trying to
eliminate the possibility that A could be aligned with an object which had its
mapping specified after the distribute was specified for B, and at the same
time trying to harmonize with Fortran 90.
I believe that would eliminate the potential circularity and ensure that
the compiler has all the necessary information when it sees a reference to an
element of A, without being quite as restrictive. (Though admittedly, the
restriction is unlikely to seriously hinder any real program development.)
In the example given, A's distribution follows the specification of the
bounds of B, which refers to an element of A, so it would be invalid. Placing
the distribute of A(block(B(IB))) before the declaration of B's bounds wouldn't
be valid either, because the reference to an element of B would come before the
specification of B's bounds. However, the following would be valid:
dimension A(NA)
dimension B(A(IA)) ! requires an access of A
chpf$ distribute B(block) ! requires knowing how big is B
The circularity is broken. When the compiler sees the reference to A(IA), it
must assume that the mapping of A is implicit. (With your suggestion, Rob,
the preceding example would not be valid if the compiler didn't assume a
replicated distribution.) It would also be valid if A was explicitly mapped
prior to the specification of the bound of B, with no reference to an element
of B.
Now the question is, can anyone spot any circularity which might still be
allowed by this alternative? Are there any other pitfalls with this?
Thanks,
Henry
Response to Zongaro's comments by Merlin:
I agree that this extension of the definition of specification expressions
is the best way to eliminate circularity in dummy argument mapping.
However, there is an alternative attitude one could adopt: circularity
of dummy argument mapping actually doesn't cause any implementation
problems, and so needs no solution!
This claim is based on the (reasonable) assumption that the implementation
will pass all of the actual arguments' mapping parameters as extra
(invisible) arguments (just as in Fortran, the length of character
variables is passed as extra invisible arguments). Therefore the
mapping of the actual arguments is fully known on entry to the procedure,
regardless of any explicit dummy argument mapping directives that may be
given. Therefore specification expressions as defined by F90 can
always be evaluated.
Indeed, the example above uses *prescriptive* distribution directives.
This means that the actual arguments may actually have completely
different mappings on entry, so these directives give no info about
their actual mappings on entry -- that *has* to be derived from the
extra invisible parameters I talked about. Using these parameters
to determine the actual mapping, the implementation can then evaluate
the specification expressions, and perhaps do a redistribution if
necessary to satisfy the prescriptive directives.
Regards,
John Merlin.
email: jhm@ecs.soton.ac.uk
Response to Merlin's comments by Koelbel
At 17:18 7/8/94 +0100, John Merlin wrote:
...
...
>I agree that this extension of the definition of specification expressions
>is the best way to eliminate circularity in dummy argument mapping.
This may be a moot point, then, but some general food for thought.
>However, there is an alternative attitude one could adopt: circularity
>of dummy argument mapping actually doesn't cause any implementation
>problems, and so needs no solution!
>
>This claim is based on the (reasonable) assumption that the implementation
>will pass all of the actual arguments' mapping parameters as extra
>(invisible) arguments (just as in Fortran, the length of character
>variables is passed as extra invisible arguments). ...
I claim that any argument that explicitly assumes a particular
implementation strategy is dangerous. Such an argument may restrict future
(or current) compilers in ways that are hard to avoid. For example, your
assumption seems to rule out redistributing data in the caller (admittedly
difficult to do, but I think possible with sufficient interprocedural
analysis).
>Indeed, the example above uses *prescriptive* distribution directives...
Would your analysis change if the directives were descriptive? No
redistribution would be needed, but the distributions are fairly well
hidden from the compiler.
In this case, I actually agree that with sufficient runtime work the
problem is solvable. But avoiding circularity has plenty of advantages,
so we should take that approach. And I just want to caution against
assuming your favorite implementation is the same as everyone else's.
Chuck Koelbel
Response to Koelbel's comments by Merlin
>
> I claim that any argument that explicitly assumes a particular
> implementation strategy is dangerous. Such an argument may restrict future
> (or current) compilers in ways that are hard to avoid. For example, your
> assumption seems to rule out redistributing data in the caller (admittedly
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> difficult to do, but I think possible with sufficient interprocedural
> analysis).
Not at all. I don't understand why passing details of the actual
argument mapping should rule out the argument being remapped by the caller.
If it did, it wouldn't conform to the HPF standard, as that dictates
that the caller will redistribute the arguments if necessary if an
explicit interface is given.
> >Indeed, the example above uses *prescriptive* distribution directives...
>
> Would your analysis change if the directives were descriptive? No
> redistribution would be needed, but the distributions are fairly well
> hidden from the compiler.
No, my analysis wouldn't change. If the mapping parameters were
still passed as extra arguments, they could still be derived from
the argument list rather than from the mapping directives.
> In this case, I actually agree that with sufficient runtime work the
> problem is solvable. But avoiding circularity has plenty of advantages,
> so we should take that approach. And I just want to caution against
> assuming your favorite implementation is the same as everyone else's.
Ok. I didn't intend to rule out anyone else's implementation
-- I just wanted to add a point to the discussion for information,
in case anyone was unaware of it.
(For the record, I raised this circularity issue in email to
'hpff-distribute' on 6 March 93 (I checked!) and intended to follow
it up at the next 'distribute' subgroup meeting. I didn't because
(i) it was after midnight by the time we got around to it, and I was
jet-lagged! (ii) I realised in the meantime that there was this
simple implementation 'fix'. However, I've really no objection to
fixing the circularity problem this time round.)
John.
____________________________________________________
*#7.4 Question: Is there a chronological order of directives?
Submitted by: Wilfried GANSTERER 22 Jun 1994
Answer: No chronological order of directives is assumed.
Rationale:
(reference to document change:)
Status: G1: Closed. Needs reply.
In the following questions page and line numbers are from
HPF LANGUAGE SPECIFICATION Version 1.0 of May 3, 1993.
concerning data alignment/distribution:
Does HPF specify a chronological order of alignment and distribution?
(The question arose because of lines 23-25, page21: ...Data objects...are first
aligned...group of arrays is then distributed...)
If yes, what's the reason for it?
____________________________________________________
*#7.5 Question: Is DYNAMIC needed for aligned objects?
Submitted by: Wilfried GANSTERER 22 Jun 1994
Answer: Yes, an alignee must be dynamic if align target is dynamic. Text will be
clarified.
Rationale:
(reference to document change:)
Status: G1: (closed) A text change still needed : action Rich Shapiro. Reply
needed.
____________
concerning data alignment/distribution:
Suppose, an object A is ultimately aligned with an object B, which
is explicitly declared DYNAMIC. If B is explicitly redistributed,
A will be remapped, too. Is it necessary for A to be explicitly
declared DYNAMIC?
____________________________________________________
*#7.6 Question: communications and dynamic data
Submitted by: Wilfried GANSTERER 22 Jun 1994
Answer: Pretty far.
Rationale:
(reference to document change:)
Status: G1 Closed. Needs reply.
In the following question page and line numbers are from
HPF LANGUAGE SPECIFICATION Version 1.0 of May 3, 1993.
There are several ways to communication via realignment
or redistribution directives of HPF. How far are these directives
intended to provide means for explicitly
communication on the high level of HPF? If these directives are
to program explicit message-passing, this seems
contradictory to the high-level approach, and your warnings (e.g.
page 26, lines 1-2: ...can require a lot of computational and
communication effort at run time; the programmer must take care when
using this feature...) seem to advise not to use the directives this
way.
Nevertheless, allowing the programmer to
sometimes could be useful for reaching higher performance.
________________________________________________
*#7.7 Question: Alignment and optional arguments
Submitted by: Henry Zongaro 21 Jul 94
Answer: Yes, an over sight, an align target must not be OPTIONAL .
(reference to document change:)
Status: G1 - Closed. Text change needed. Action Shapiro. Reply needed.
_____
Hello,
Section 3.6 of the HPF Language Spec. states, when treating allocatable
arrays and pointers, that "when an object X is created it may be aligned to
another object Y only if Y has already been created or allocated."
Should this be extended to dummy arguments with the OPTIONAL attribute as
well? For example,
subroutine sub(i, j)
integer, optional :: i(:)
integer :: j(:)
!hpf$ align j(:) with i(:)
end subroutine sub
I believe that the alignment of "j" with "i" should be considered to be
nonconforming if "i" is not present, but I don't think either term, "created"
or "allocated", covers this case. Though it's obviously similar in spirit to
the above restriction, I think OPTIONAL should be handled explicitly. Or is
there some text that takes care of this that I'm missing?
Thanks,
Henry
________________________________________________
*#7.8 Question: blank common and sequence-directive
Submitted by: Henry Zongaro 22 Jul 94
Answer: Syntax error. Blank common can be sequential.
(reference to document change:)
Status: G1 Closed. Document change needed. Send reply.
Hello,
The syntax for the sequence-directive in section 7.1.3 of the HPF Language
Spec. is as follows:
H701 sequence-directive is SEQUENCE [ [ :: ] association-name-list
or NO SEQUENCE [ [ :: ] association-name-list
H702 association-name is variable-name
or / common-block-name /
Was it intended that blank common could not be declared to be sequential
or nonsequential?
...
________________________________________________
*#7.9 Question: regular array sections
Submitted by: Henry Zongaro 23 Jul 94
Answer: Yes - regular array sections should be defined in the document.
Rationale:
(reference to document change:)
Status: G1 - Closed. Needs document text - Shapiro. Send reply.
Hello,
On page 44, line 32 and on page 45, lines 19 and 44, there are references
to "regular array sections". I couldn't find a definition of this term in
either the HPF Language Spec. or the Fortran 90 standard.
My guess is that it refers to an array section, none of whose section
subscripts are vector subscripts. Is that correct?
Thanks,
Henry
________________________________________________
*#7.10 Question: Block and Cyclic definition
Submitted by: John.Zigman John.Zigman@cs.anu.edu.au 27 Jul 1994
Answer: Answer sent by Chuck ok.
Rationale:
(reference to document change:)
Status: G1, Closed.
___________
Hi,
I have a couple of questions about hpf;
1) Why is there a BLOCK directive when it is a subset of cyclic?
2) Why is the CYCLIC directive by default 1, and not left to the
implementor of hpf?
Thanks for your time.
John N Zigman
__________
>From chk@cs.rice.edu Fri Jul 29 08:29:48 1994
>Hi,
> I have a couple of questions about hpf;
>1) Why is there a BLOCK directive when it is a subset of cyclic?
>2) Why is the CYCLIC directive by default 1, and not left to the
> implementor of hpf?
>
>Thanks for your time.
>
>John N Zigman
1) BLOCK ensures that every processor has at most one section of the array.
This additional information may be helpful to the compiler; for example,
the global index to local index translation is simpler.
2) We wanted the definition to be complete. 1 seemed a more general
default than "the size of a cache line" or so on.
Chuck
----------------------------------------
#7.11 Question: Repeated directives.
Submitted by: Henry Zongaro , 4 Aug 94
Answer:
Rationale:
(reference to document change:)
Status: G1 Need text change. In the section on directives, disallow giving an
object an attribute more than once. First reading: action Rich to provide text.
------------------
1) Page 24, lines 14-15, state that, "The same combined-attribute must not
appear more than once in a given combined-directive." I assume that it was
the intent that no entity could be given the same attribute more than once in
separate directives as well. The only place I could find that sort of
constraint was under the sequence-directive, page 146, lines 1-2: "A variable
or COMMON block name may appear at most once in a sequence-directive within any
scoping unit." But there doesn't appear to be anything like that for the
ALIGN, TEMPLATE, INHERIT, DISTRIBUTE or PROCESSORS. As things stand, I
believe
the following is valid (though not well-defined):
subroutine sub(a)
!hpf$ inherit a
!hpf$ inherit :: a
!hpf$ template, distribute (block) :: t
!hpf$ template t
!hpf$ distribute t(cyclic)
end subroutine sub
----------------------------------------
*#7.12 Question: Can constants be sequential (for use as arguments)?
Submitted by: Henry Zongaro , 4 Aug 94
Answer: Text change needed.
Rationale:
(reference to document change:)
Status: G1 - this needs a text change - no action name. And send reply.
2) I should have followed up CCI request 6.1 with the following question:
May a named constant be declared to be sequential? As the grammar on p. 145,
lines 44-45 stands, only variable-names and common-block-names may be
explicitly specified to be sequential or nonsequential.
According to the response to 6.1, a named constant may be aligned or
distributed. It would seem to be desirable to be able to declare it to be
sequential or nonsequential as well. For example,
program p
integer, parameter :: a(100) = (/(i, i = 1, 100)/)
call sub(a) ! Invalid - "a" must be sequential
end program p
subroutine sub(d)
integer :: d(*) ! Dummy "d" is sequential
end subroutine sub
could only be made valid if the user declared a sequential array temporary to
which "a" was copied, and passed the temporary instead of "a". Admittedly,
page 149, lines 18-24 discusses the necessity of copying into temporary
variables when passing expressions to sequential dummy arguments, but since "a"
above has a name and it can be aligned or distributed, it makes sense that it
should be allowed to be declared to be sequential as well.
----------------------------------------
#7.13 Question: Explicit mapping, sequential, and dynamic
Submitted by: Henry Zongaro , 4 Aug 94
Answer:
Rationale:
(reference to document change:)
Status: G1: Answers are:
3 - no 3a not applicable 3b y,y,y. First reading on a text change:
Change p 144 line 31 (definition of explicitly mapped ) to add DYNAMIC and
INHERIT to the ways to make something explicitly mapped.
3) The definition of explicitly mapped on page 144, line 31-32, states that
"A variable is explicitly mapped if it appears in an HPF alignment or
distribution directive within the scoping unit in which it is declared." I
assume that means, "if it appears as an alignee in an ALIGN directive or as
a distributee in a DISTRIBUTE directive," and that it wasn't the intent that it
would be considered to be mapped if it appeared as an align-target. Is that
correct?
3a) Assuming that the answer to 3) is "Yes", may a sequential variable appear
as an align-target in an ALIGN directive? Or perhaps only sequential variables
which are aggregate covers and are scalars or rank-one arrays?
3b) May a sequential variable have the DYNAMIC attribute, and does appearance
as an alignee or a distributee in a REALIGN or REDISTRIBUTE directive qualify a
variable as having been explicitly mapped? In the following example, is "i"
considered to be explicitly mapped? According to page 146, lines 5-8, "A
sequence-directive with an empty association-name-list is treated as if it
contained the names of all implicitly mapped variables. . . which cannot
otherwise be determined to be sequential or nonsequential. . . ." If "i" is
considered to be explicitly mapped, it is nonsequential; otherwise it is
sequential (and if DYNAMIC is not allowed, the example is invalid.)
program p
integer i(100)
!hpf$ sequential
!hpf$ dynamic i
.
.
.
!hpf$ redistribute i(block)
end program p
Thanks,
Henry
----------------------------------------
*#7.14 Question: Distribution in a contained subroutine.
Submitted by: nunohiro@hisoft.soft.hitachi.co.jp (Eiji_Nunohiro) 10 Aug 94
Answer: The code is erroneous because A1 is declared more than once .
Rationale:
(reference to document change:)
Status: G1 Closed. Send reply.
1. Can the host associated array be distributed in an internal
procedure? If possible, does it mean the array will be remapped
at the beginning and end of an internal procedure just same as
the dummy arguments of an external procedure will be ?
example:
REAL A1(100)
!HPF$ DISTRIBUTE A1(CYCLIC)
:
CONTAINS
SUBROUTINE SUB
!HPF$ DISTRIBUTE A1(BLOCK)
:
----------------------------------------
*#7.15 Question: Array alignment in internal procedures
Submitted by: nunohiro@hisoft.soft.hitachi.co.jp (Eiji_Nunohiro) 10 Aug 94
Answer: The align of B is illegal, the align of C is legal. No changes are
necessary.
Rationale:
(reference to document change:)
Status: G1 Closed. Send reply.
2. Is it possible to align the array in an internal procedure with
the host array ? Is it possible to align two host associated arrays
in an internal procedure ?
example:
REAL A(100),B(100)
!HPF$ DISTRIBUTE A(BLOCK)
:
CONTAINS
SUBROUTINE SUB
REAL C(100)
!HPF$ ALIGN B(:) WITH A(:) !OK?
!HPF$ ALIGN C(:) WITH A(:) !OK?
----------------------------------------
*#7.16 Question: Library inquiry about template distribution
Submitted by: nunohiro@hisoft.soft.hitachi.co.jp (Eiji_Nunohiro) 10 Aug 94
Answer: No. Templates are not first-class objects. (First-class is F90
terminology.)
Rationale:
(reference to document change:)
Status: G1 Closed. Needs reply.
3. Can template name be specified as a DISTRIBUTEE argument of the
library procedure HPF_DISTRIBUTION ?
example:
!HPF$ TEMPLATE T(100,100)
!HPF$ DISTRIBUTE T(BLOCK,BLOCK)
:
____________________________________________________
*#8.1 Question: Asynchronous algorithms
Submitted by: Wilfried GANSTERER 22 Jun 1994
Answer: Referred to tasking requirements subgroup.
Rationale:
(reference to document change:)
Status: G2: Closed. Needs reply.
concerning high performance:
There are (as I far as I know) no ways to express asynchronous
algorithms (e.g. for LU-decomposition) in HPF. Should this
possibility for improved performance be provided by the compiler,
when creating the low-level code? (Maybe it's a little bit
exaggerated, but it seems to me, that HPF stresses compilers more
than programmers when trying to reach high performance.)
Or is the use of EXTRINSIC procedures the only way to control WHEN
some communication should be done?
________________________________________________
*#8.2 Question: Clarify processor declarations.
Submitted by: Wilfried GANSTERER 22 Jun 94
Answer: There is no difference. Document terminology will be changed.
Rationale:
(reference to document change:) Change all instances of processor-dependent to be
implementation dependent. Add text in chapter 1 or 2 so specify that by
implementation dependent, we mean the same as processor dependent in F90, but
didn't want to use that term.
Status: G2 - Closed. Reply needed.
In the following comments page and line numbers are from
HPF LANGUAGE SPECIFICATION Version 1.0 of May 3, 1993.
concerning physical - abstract processors:
1. The description of the procedures 5.6.4 NUMBER_OF_PROCESSORS
and 5.6.5 PROCESSORS_SHAPE seems misleading to me.
According to page 40, lines 24-28, both may be used to inquire about
the total number of actual PHYSICAL processors.
Why the distinction between
...processor-dependent hardware processor array... (page 102,
line 19) in the case of NUMBER_OF_PROCESSORS
and
...implementation-dependent processor array... (page 102, line
31) in the case of PROCESSORS_SHAPE?
What does ...processor-dependent... mean?
What does ...implementation-dependent... mean?
________________________________________________
*#8.3 Question: Load balancing
Submitted by: Wilfried GANSTERER 22 Jun 94
Answer: Requirement noted. Referred to tasking/irregular data requirements
groups.
Rationale:
(reference to document change:)
Status: G2: Closed. Reply needed.
In the following comments page and line numbers are from
HPF LANGUAGE SPECIFICATION Version 1.0 of May 3, 1993.
concerning high performance:
HPF provides no means to control task allocation to processors.
Nevertheless, load balancing can have a significant influence on
the performance of parallel computer systems.
Will this be considered in the concept of HPF or will it be left to
the compilers?
________________________________________________
*#8.4 Question: Is high performance a misname?
Submitted by: Wilfried GANSTERER 22 Jun 94
Answer: Point taken.
Rationale:
(reference to document change:)
Status: G2: Closed. Reply needed.
With high-level programming one often does not get the highest
possible performance. Besides, performance will be very sensitive to
changes in high-level code (the impacts of changes in low-level code
can probably be predicted more easily). In the moment I don't
believe that the first two parts of the name of HPF (HIGH
PERFORMANCE) can be taken for granted.
________________________________________________
*#8.5 Question: Library section misprints
Submitted by: Wilfried GANSTERER 22 Jun 94
Answer: Yes - these need to be corrected.
Rationale:
(reference to document change:)
misprints:
On the pages
119, line 3 ( IALL )
121, line 46 ( IANY )
124, line 36 ( IPARITY )
131, line 28 ( PARITY )
the expression should be replaced by (in order to be universally valid).
On page 129, line 45 ( MINVAL_SCATTER ) should be
replaced by .
On page 133, line 48 ( POPPAR ) the use of variables I and x for
denoting the same scalar is misleading. Preferably x should be replaced by I.
Status: G2: Closed. Document change needed. Reply needed.
------
________________________________________________>
*#8.6 Question: Scope of forall index
Submitted by: Eiji_Nunohiro nunohiro@hisoft.soft.hitachi.co.jp 5 Jul 94
Answer: As in CHK reply.
Rationale:
(reference to document change:)
Status: Repeat: G2 Closed. Reply already sent.
Dear HPFF members,
I have some questions about 'High Performance Fortran Language
Specification, Version 1.0'.
Indistinctness item of HPF specifications.
1. At page 58 line 9 in HPF Language Specification describes that
the scope of an index-name is the FORALL statement itself,
this can be thought the local variable of the FORALL statement inside?
Example:
i=5
FORALL(i=1:100) a(i)=b(i)
print*,i
As for this program, value 5 is printed.
------
response from Koelbel:
This question was discussed at the last HPFF meeting. In short, the answer
is "yes, the FORALL index can be thought of as a local variable". This is
identical to the "statement scope" used for implied DO indices in DATA
statements. (The same idea extends to multi-statement FORALLs.) In your
example, 5 is indeed the value printed.
________________________________________________>
*#8.7 Question: Clarification of inquiry functions on distributed arrays
Submitted by: Eiji_Nunohiro nunohiro@hisoft.soft.hitachi.co.jp 5 Jul 94
Answer: As answered by chk.
Rationale:
(reference to document change:)
Status: G2 Closed. Answer already sent.
If the LBOUND, UBOUND or SIZE function (array inquiry functions)
applies the distributed arrays, then it returns the value of original
arrays?
Example:
dimension a(100)
!HPF$ DISTRIBUTE a(block)
print*, ubound(a,1)
As for this program, value 100 is printed always.
-------
Koelbel reply:
DISTRIBUTE and ALIGN do not affect the values returned by Fortran 90
inquiries. (This is a consequence of HPF's single name-space model.) Your
example is correct, 100 is the value.
________________________________________________>
*#8.8 Question: Use of distribute in HPF_LOCAL
Submitted by: Eiji_Nunohiro nunohiro@hisoft.soft.hitachi.co.jp 5 Jul 94
Answer: Yes example is in error.
Rationale:
(reference to document change:) (fix examples noted)
Status: G2: Closed. Reply needed. Document change needed.
At page 158 line 46 in HPF Language Specification describes that
it can not use DISTRIBUTE directive in HPF_LOCAL routines,
but it uses in the example of page 167. Is this an error?
________________________________________________>
*#8.9 Question: Inquiry about a component structure
Submitted by: Eiji_Nunohiro nunohiro@hisoft.soft.hitachi.co.jp 5 Jul 94
Answer: Text will be clarified. Subcomponents cannot be mapped in HPF1, but
this has been referred as a requirement to HPF2. The text on page 146 refers to
an F90 requirment that means that some subcomponents will never be able to be
mapped.
Rationale:
(reference to document change:) Clarify text on page 146.
Status: G2 - Closed. Document change needed. Reply needed.
Is it true that a component of a derived type without SEQUENCE
attribute can explicit mapping, and it can not inquire its mapping?
At page 146 line 14, "No explicit mapping may be given for a component
of a derived type having the Fortran 90 SEQUENCE attribute".
At page 112 line 12, "It must not be a structure component".
Example:
type d
real::a(100)
endtype
type(d)::x
!HPF$ DISTRIBUTE x%a(BLOCK) ...OK
call HPF_ALIGNMENT(x%a, LB=i) ...NG
________________________________________________>
*#8.10 Question: Must call inside independent loop be PURE?
Submitted by: Eiji_Nunohiro nunohiro@hisoft.soft.hitachi.co.jp 5 Jul 94
Answer: CHK answer correct.
Rationale:
(reference to document change:)
Status: G2 - Closed.
If a procedure calls in INDEPENDENT loops,
must it be a PURE procedure?
-----
Koelbel replies:
No. INDEPENDENT is a statement about the behavior of the loop as it is
written. It does not restrict the syntax in the loop.
________________________________________________>
*#8.11 Question:
Submitted by: Eiji_Nunohiro nunohiro@hisoft.soft.hitachi.co.jp 5 Jul 94
Answer: Already answered by chk.
Rationale:
(reference to document change:)
Status: Closed.
Is it correctly that the case scalar variable assignment in
FORALL statement executed only one time?
At page 58 line 19, "A forall-stmt is not HPF-conforming if
it causes any atomic data object to be assigned more than one value".
Example:
FORALL(i=1:100,i==n) s=a(i) !s is assigned a(n)
-------
Koelbel replies:
I believe this is legal.
A brief history: originally, the left-hand side of the FORALL assignment
had to be an array element. That syntax restriction was removed, and
replaced with the sematic restriction that no atomic data object to be
assigned more than one value. An unintended consequence of this decision
was that assignments to scalars in FORALLs were allowed so long as the loop
only had only one active iteration.
________________________________________________>
*#8.12 Question: Incorrect independent assertion
Submitted by: Eiji_Nunohiro nunohiro@hisoft.soft.hitachi.co.jp 5 Jul 94
Answer: Already answered by chk
Rationale:
(reference to document change:)
Status: G2 - Closed.
In the case that the INDEPENDENT directive of loop has error,
is it correctly that the compiler interprets INDEPENDENT loop?
At page 85 line 41, "The compiler is justified in producing a warning
if it can prove that one of these assertions is incorrect."
Example:
!HPF$ INDEPENDENT
DO I=2,n
a(i)=a(i-1) !a(i) has undefined but it is user miss?
ENDDO
Sincerely, Dr. Eiji Nunohiro.
---------
Koelbel replies:
I'm not sure what you intend to say in this comment, but the loop is indeed
not INDEPENDENT. As with any incorrect program, what happens next is up to
the compiler. (Similarly, if a subscript is outside the array bounds there
is no telling what will happen.) Any one of the following is possible:
1. At compile time, the compiler issues a warning.
2. At run time, the program stops with a warning.
3. The program runs, producing nondeterminate results
but no warning.
4. The compiler concludes that n<=2, and uses this assumption
to translate all loops in the program.
Which one actually happens will depend on the quality of the compiler,
runtime system, and possibly on the hardware.
Chuck Koelbel
________________________________________________
*#8.13 Question: HPF 2.0, mathematical functions
Submitted by: Jens Bloch Helmers jenhel@marin.unit.no 8 Jul 94
(submitted to hpff-comment)
Answer: This issue should be taken to X3J3. It might form a good activity for a
collateral Fortran standard. It is too big in scope for HPFF to take on.
Rationale:
(reference to document change:)
Status: G2 - Closed. Reply needed.
EFFICIENT EVALUATION OF MATHEMATICAL FUNCTIONS.
------------------------------------------------
Fortran (FORmula TRANslation) is primarally designed for efficient numerical
calculations. Using fortran intrinsic functions the programmer knows that
the routines are:
1) extremely well tested.
2) easy to implement.
3) portable between hardware platforms.
4) highly optimized for each platforms.
5) the interpretation is well known for all fortran programmers.
Very often engineers need to evaluate mathematical functions that are not
included in standard HPF. In case of such calculations the programmer can not
fulfil the requirements 1)...5). May HPF 2.0 help the programmer to fulfil these
requirements?
Possible solutions:
I) Extend the number of intrinsic mathematical functions.
II) Define a standard interface for library functions.
III) New constructions.
Discussions:
I) This is the most convenient solution for the programmer, but increase
the effort of building compilers. However, many of the functions are
calculated using power serie expansions. The compiler technique
for such calculations are already well developed. (SIN, COS, ...)
Therefore very important engineering functions, e.g. the Bessel
functions,
should be included as elemental intrinsic functions.
II) Define a standard HPF interface module: HPF_MATH_FUNCTIONS.
This module should define explicit interface for a huge number of
mathematical functions. (See e.g. "Handbook of mathematical functions",
Abramowitz & Stegun) The actual implementation of the functions should
not be a part of the HPF compiler.
A module like this will have the following effects:
a) New markets for building a standard function library.
b) Does not complicate the effort of building compilers.
c) The programmer fulfills the requirements 1)...5).
d) Easy to include the most recent numerical techniques.
(In my opinion there should also be defined a standard HPF module
HPF_LINEAR_ALGEBRA. This module should define the interface of
typically operations/operators on dense and sparse matrices.
(e.g. solving systems of linear equations.) )
Modules like HPF_MATH_FUNCTIONS and HPF_LINEAR_ALGEBRA will
reduce the effort of building professional state-of-the-art software!!!
(POWER TO THE PEOPLE.)
III) As mentioned before many of the intrinsic mathematical functions
are calculated using some kind of serie expansion. In case of
power series we may write:
Y = A(0) + A(1)*X + A(2)*X**2 + A(3)*X**3 + ... + A(N)*X**N
In case of intrinsic functions such calculations are highly
optimized. These efficient algorithms should be available to the
fortran programmer using a new intrinsic elemental function:
Y = POLYNOM( A, X ) !Y and X are scalars or conform arrays.
This function should produce the same result as the above assignment.
If the array A is defined with the attribute PARAMETER, the compiler
should invent a seperate procedure in order to achieve maximum
optimization.
The function POLYNOM may be extremly important in some critical
parts of the code. E.g. the statement:
Y = X*SIN(X) + COS(X)
may be replaced with the more efficeinet:
REAL, DIMENSION(0:5), PARAMETER :: &
SINCOS = (/ 1., 1./2., -1./8., 1./144., -1./5760., 1./403200. /)
....
Y = POLYNOM( SINCOS, X*X )
Many functions are evaluated extremly efficient using "General Fourier
Series":
Y = A(0)*F(0,X) + A(1)*F(1,X) + A(2)*F(2,X) +... + A(N)*F(N,X)
where F(i,X) are orthogonal functions of X with some recursive relation:
F(i,X) = G(i,X)*F(i-1,X) + H(i,X)*F(i-2,X)
For many series the functions G(i,X) and H(i,X) are simple.
E.g. the very popular Chebyshev serie of first kind:
G(i,X) = 2.*X ; H(i,X) = -1.
F(0,X) = 1. ; F(1,X) = X
There should be intrinsic elemental mechanisms to evaluate such
series in an efficient way. E.g.:
Y = CHEBYSHEV( A, X ) ! Y and X are scalars or conform
! arrays.
Y = GFOURIER( A, G, H, F0, F1, X ) ! F0, F1 and Y should be
conformable
! with X. The first dimension of G
! and H should be conformable
with A.
! The other dimensions are
conformable
! with X.
***********************************************************
* *
* Jens Bloch Helmers *
* Department of Marine Hydrodynamics *
* Norwegian Institute of Technology *
* N-7034 Trondheim-NTH, NORWAY *
* *
* Phone : +47 73 59 59 96 *
* Fax : +47 73 59 55 28 *
* Email : jenhel@marin.unit.no *
* *
***********************************************************
________________________________________________
*#8.14 Question: I/O in HPF_LOCAL
Submitted by: Henry Zongaro 10 Jul 94
Answer: Everything is implementation-dependent, and the user should beware of
non-portability if there is a mix of I/O between global HPF and HPF_LOCAL. This
item was noted as one to refer to HPF 2.
Rationale:
(reference to document change:)
Status: G2: Closed. Send reply. Should some warning go in the document?
Hello,
I was wondering whether there should be some restrictions/statements on
I/O in HPF_LOCAL procedures.
When an HPF_LOCAL procedure is called by a global HPF program or
subprogram, should all units and files be required to still have the same
connection status on return to the global HPF procedure? Should an HPF_LOCAL
procedure be prohibited from executing an I/O statement on an external unit or
file which was connected when control first transferred from the global HPF
procedure? (Such prohibitions would be analogous to the prohibition in A.2.1
of the HPF Language Spec. against accessing global HPF data, since Section 14.3
of the Fortran 90 standard states that, "An external input/output unit is a
global entity.") Perhaps this should go even further, by stating that any I/O
statement in an HPF_LOCAL procedure must not refer to a file which is referred
to in a global HPF procedure which is part of the same program.
Or is all of this implementation-dependent? Or are HPF_LOCAL external
units and files considered to be completely different from global HPF units and
files, so that their interaction is impossible, rendering restrictions
unnecessary? Or is there some existing restriction that I'm missing?
I noticed that Fred Webb submitted similar questions in comments to
Chapter 7 of the HPF draft, but I couldn't find a response. Sorry if these
issues have already been addressed.
Thanks,
Henry
________________________________________________
#8.15 Question: HPF_LOCAL interfaces
Submitted by: Henry Zongaro 12 Jul 94
Answer: New extrinsic interface proposed.
Rationale:
(reference to document change:)
Status: G2 ( 2.3, 6.16, 6.17, 8.15 - see 6.16 for proposal)
__________
Hello,
I have a couple of nit-picking questions about HPF_LOCAL.
(i) According to page 140 of the HPF Language Spec, lines 31-32, "writing
EXTRINSIC(HPF) in an HPF program has exactly the same effect as not using an
EXTRINSIC specifier at all." Does this apply within an HPF_LOCAL program unit?
For example,
extrinsic(hpf_local) subroutine local_sub
interface
subroutine ext_sub
end subroutine ext_sub
end interface
call ext_sub
call int_sub
contains
subroutine int_sub
end subroutine int_sub
end subroutine local_sub
Is the call to ext_sub invalid because it is EXTRINSIC(HPF) by default?
Similarly, is the definition of int_sub invalid because it has EXTRINSIC(HPF)
by default? Or should an extrinsic-kind-keyword of HPF_LOCAL be assumed for
any procedure defined within an HPF_LOCAL program unit?
(ii) According to lines 13-14 of the same page, "An explicit interface must be
provided for each extrinsic procedure entry in the scope where it is
called. . . ." Consider the following:
extrinsic(hpf_local) subroutine sub
call sub2
end subroutine sub
Does sub2 (which is presumably another HPF_LOCAL procedure) require an explicit
interface in sub? Should the compiler assume that sub2 is an HPF extrinsic,
which would make the reference invalid?
Since HPF_LOCAL routines are written in HPF, I would expect that the two
rules mentioned above should still be in effect, and that the examples given
would be invalid. If at some point in the future, HPF_LOCAL program units are
allowed to call HPF procedures, these examples would/could then have
well-defined meanings.
What do others think?
Thanks,
Henry
________________________________________________
*#8.16 Question: functions in parameter statements
Submitted by: Jens Bloch Helmers jenhel@marin.unit.no 27 Jul 94
Answer: this is strictly an F90 issue. Reshape is allowed. The F90 document
7.1.6.1 gives the rules about initialization expressions.
Rationale:
(reference to document change:)
Status: G2 Closed. Reply needed.
Is it legal to use the function RESHAPE in a parameter statement ?
real, parameter, dimension(2,2) :: a = reshape( (/1., 2., 3., 4./), (/2,2/) )
Why is the following statement illegal ?
real, parameter :: pi = acos(-1.0)
and this one okey ?
real, parameter :: div3 = 1.0/3.0
Why not allow all kind of intrinsic functions in initialisation expressions ?
***********************************************************
* Jens Bloch Helmers *
* Department of Marine Hydrodynamics *
* Norwegian Institute of Technology *
* N-7034 Trondheim-NTH, NORWAY *
* Phone : +47 73 59 59 96 *
* Fax : +47 73 59 55 28 *
* Email : jenhel@marin.unit.no *
***********************************************************
----------------------------------------
#8.17 Question: How to find bounds of global array from local argument?
Submitted by: Henry Zongaro 12 Jul 94
Answer:
Rationale:
(reference to document change:)
Status: Second reading needed. First reading proposals (28,0,2) accepted for
GLOBAL_LBOUND
GLOBAL_UBOUND
GLOBAL_SHAPE
GLOBAL_SIZE
all with text adapted directly from F90, except that ARRAY has to be
HPF_LOCAL dummy associated with an HPF_GLOBAL argument.
This is more a how-to question than a CCI request:
In an EXTRINSIC(HPF_LOCAL) subprogram, is there any way in
which to determine the bounds of the global array which is argument
associated with the local array? A couple of us here have puzzled over
this, and there doesn't appear to be an obvious, easy way to do it.
program prog
interface
extrinsic(hpf_local) subroutine sub(a)
integer :: a(:)
!hpf$ inherit a
end subroutine sub
end interface
integer i(1000), j(991:1990)
!hpf$ processors p(100)
!hpf$ distribute j(block) onto p
!hpf$ align i(:) with j(1990:991:-1)
call sub(i)
call sub(j)
end program prog
extrinsic(hpf_local) subroutine sub(a)
use hpf_local_library
integer :: a(:), g_index(1)
call local_to_global(a, (/1/), g_index)
end subroutine sub
If i and j are mapped so that i(991:1000) and j(991:1000) are both on the
same processor, on that processor g_index above will acquire the value (/991/)
in both calls to sub. But that doesn't say much about the relative positions
of those global indices in the arrays i and j.
I imagine it might be possible, through calls to GLOBAL_ALIGNMENT,
GLOBAL_TEMPLATE and GLOBAL_DISTRIBUTION, to determine the bounds of the
actual
arguments, but that seems like a lot of trouble to go through for what seems to
be some useful information.
It might be nice to have new HPF_LOCAL_LIBRARY routines in HPF 2.0 which
will give this information. Say, GLOBAL_LBOUND, GLOBAL_UBOUND,
GLOBAL_SIZE
and GLOBAL_SHAPE, with the "obvious" definitions.
Thanks,
Henry
CALL HPF_DISTRIBUTION (T,...) !OK?
----
note also the discussion from 8.7 ... What do intrinsics like LBOUND return for
distributed arrays. This has already been correctly answered (info about the
full array). There was some discussion about whether this is different in the
context of HPF_LOCAL?
----------------------------------------
*#8.18 Question: Difference between (JOD) NODE and PROCESSOR directives
Submitted by: nunohiro@hisoft.soft.hitachi.co.jp (Eiji_Nunohiro) 10 Aug 94
Answer: Referred to I/O requirements group. JOD is not part of HPF document.
Rationale:
(reference to document change:)
Status: G2. Closed. Send reply.
About JOD Parallel I/O Proposal:
Is there any different meaning ( ex physical node arrangement ) between
Node Directive and Processor Directive.
!HPF$ NODE (J :: D2(2,2)
!HPF$ PROCESSORS :: D2(2,2)
example Node directive Define IO processing only
Processor directive : Define computation processing only
----------------------------------------
*#8.19 Question: (JOD) Relation between I/O nodes and Processor arrangements.
Submitted by: nunohiro@hisoft.soft.hitachi.co.jp (Eiji_Nunohiro) 10 Aug 94
Answer:Referred to I/O requirements group. JOD is not part of HPF document.
Rationale:
(reference to document change:)
Status: G2. Closed. Send reply.
Are there any directives for definition of that I/O node is one part of
the Processor arrangement.
----------------------------------------
*#8.20 Question: Input data and distribution.
Submitted by: nunohiro@hisoft.soft.hitachi.co.jp (Eiji_Nunohiro) 10 Aug 94
Answer:Referred to I/O requirements group. JOD is not part of HPF document.
Rationale:
(reference to document change:)
Status: G2. Closed. Send reply.
(note - message that came with this item had a bunch of extra control
character-related garbage in the examples --- the examples below
came from an attempt to delete the garbage, but may have resulted in
mixed-up spacing. -mz-)
To reduce the overhead of Parallel IO (ex message passing) , some methods are
needed for the relation between the distribution of FILEMAP to
map arrays to disks/files and the distribution of data , because input data
for each node depend on the distribution of data.
I think IO process need next directives and next steps.
DIMENSION a(1000),b(1000),c(1000)
!HPF$ PROCESSOR P(10)
!HPF$ DISTRUBUTE (block) ONTO P :: a,b,c
!HPF$ NODE D(10) onto P
/* define processor node equale IO node in the physical node arrangement */
!HPF$ FILEMAP F1(100)
!HPF$ ALIGN WITH F1 :: a,b
!HPF$ DISTRUBUTE F1(block) ONTO D
/* FILEMAP F1 define one file format that include data a,b that are content
of a(1000),b(1000) and distribute a,b with block distribution */
!HPF$ FILEMAP F2(100)
!HPF$ ALIGN WITH F2 :: c
!HPF$ DISTRUBUTE F2(block) ONTO D
OPEN(UNIT= 1,FILEMAP=F1,FILE='indata' ,nodefile='intmp' )
OPEN(UNIT=20,FILE='outtmp')
!HPF$ PREAD(1) a,b
/* input data a and b from the original file 'indata' to temporary file on
each node */
:
read(10) a,b
/* input data a and b from the temporary file on each node */
:
write(20) a,b
/* output data a and b to the temporary file on each node */
!HPF$ PWRITE(2) a,b
/* output data a and b from temporary file on each node to the original
file 'outdata' */
indata
a(1,..,1000) , b(1,..,1000)
PREAD process
node D(1) D(2) ...... D(10)
FILEMAP F1(1,..,10) F1(11,..,20) F1(91,..,100)
intmp a(1,..,100) a(101,..,200) a(901,..,1000)
b(1,..,100) b(101,..,200) b(901,..,1000)
node D(1) D(2) ...... D(10)
FILEMAP F2(1,..,10) F2(11,..,20) F2(91,..,100)
outtmp c(1,..,100) c(101,..,200) c(901,..,1000)
PWRITE process
outdata
c(1,..,1000)
----------------------------------------
* #8.21 Question: Suggested extension for indexed lists.
Submitted by: nunohiro@hisoft.soft.hitachi.co.jp (Eiji_Nunohiro) 10 Aug 94
Answer: Refer to the irregular data requirements group.
Rationale:
(reference to document change:)
Status: G2. Closed. Send reply.
Extensions of HPF specification
Are there any directives to indicate or assist for uncertain reference
(ex. list vector)?
ex.
do 10 i=1,n
a(I)=b(L(I))
10 continue
|
