Executive Summary
Thirty three people attended the August HPFF94 meeting (see list at end). Activity at the meeting is summarized here very briefly. The full minutes can be consulted for details. Fujitsu, Hitachi, and Cray Computer have newly announced HPF efforts. Many CCI issues were discussed - resolved. Discussion / proposals of special note include a proposal for an extrinsic interface that says code will run on a single node only. There was also a proposal about mix and match of different extrinsic kinds, including mechanisms for designating extrinsic kind for program objects like MODULE. Changes and additions to the extrinsic local functions, processor id were made.Plans were made for the set of HPFF94 documents, including an updated language specification, a requirements document, a CCI document, and a set of benchmarks. A proposal to generate an HPF kernel was discussed. If adopted, this would be a subset of HPF intended specifically for best performance. In time, this subset would be expected to replace the existing subset which was aimed instead at fastest implementation availability.
The next HPFF meeting will be October 12-14 in Chicago.
April 18 The meeting formally began at 8:50, chaired by Ken Kennedy. Ken announced changes in the implementation status list. Cray Computer, Fujitsu, and Hitachi now have formally announced efforts. Silicon Graphics is a new entry in the list of interested vendors. The current list now is:
Survey of Vendor HPF Implementation Status
Aug. 94
Announced Products
Interested
Group introductions were made, along with determination of alternate status.
The first business was a the reports from the CCI committees. For reader reference the complete CCI list will be available via the HPFF home page shortly after these minutes are distributed. Check at http://www.erc.msstate.edu/hpff/home.html.
CCI Group 2 notes - Mary Zosel presenting:
Several items are open, awaiting promised text or clarifications.
Item 5.5(b): The need for an interface to code that executes only on one processor has been identified. Henry Zongarro prepared a specific proposal for a SCALAR extrinsic interface. The proposal was discussed. 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. A straw poll was taken: should this go in HPF 1+? 13 yes, 14 no, 5 abstain. In further discussion, there was 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. A second straw poll was taken: Is SCALAR the wrong word? 23 yes, 1 no, 8 abstain. As an amusing alternative LPF was suggested. Other possible names noted were: SINGLE, UNI, UNIPROCESS.
Item 5.8(a) There was a second reading of a proposal for new local routines for determining in local routines. LOCAL_BLKCNT (returns the number of pieces of a given array that are allocated to the given processor), LOCAL_LINDEX (returns the low indexes associated with each block), LOCAL_UINDEX (returns the upper indexes associated with each block). Minor changes were identified to the handout prepared for the meeting. These are to be considered pure functions. The DIM argument will be optional, so that the routines return a vector-valued result describing all dimensions when DIM is not specified. The new local routines were approved by official vote: in favor - 22, against - 0, abstain - 3. Since these are associated with HPF_LOCAL, they will become part of the appendix for HPF 1+.
Item 5.8(b) There was a second reading of a proposal for local routines to obtain the processor identification. Based on directions from the first reading in June, two proposals were prepared:HPF_MY_PROCID (returning identification as a processor-id), HPF_MY_PROCESSOR (returning identification as an integer, range 1-n) Several amendments were made.
amendment: drop HPF_ - accepted by consensus.
amendment: MY_PROCESSOR should return integer in range 0...n-1 instead of 1...n. argument pro: that's how message-passing routines number processors argument con: this is FORTRAN, 1-based is (controllable) default, and one of the things this is used for is indexing arrays. This amendment was accepted by formal vote -14 yes, 5 no, 4 abstain.
amendment: drop MY_PROCID completely. query: should all HPF intrinsics that take PROCID also change to accept integer? yes. So, the effect of this amendment is to eliminate PROCID type completely from document. It was commented that PROCIDs were added in the first place "in an attack of ADAitis" (really, to skip 0-based/1-based controversy). This amendment was accepted by a formal vote - 21 yes, 0 no, 4 abstain.
There was clarification discussion to make it explicit that "n" is the value returned by NUMBER_OF_PROCESSORS(). Text should be clarified to reflect this. The modified proposal (now just for one routine MY_PROCESSOR, returning an integer value in the range 0 ... n-1 - and elimination of PROCID from the document) was accepted by a formal vote: 25 yes, 0 no, 0 abstain.
Item 6.10 - A second reading vote to drop the words "pointer or" from p.81 line 14 and allow a NEW variable to be a POINTER was postponed. Rob Schreiber has promised to think about implications of this issue.
Item 6.18 (Clarify that split key-words such as END FORALL and NO SEQUENCE do not require space.) This item should have been marked closed, it was accepted at the previous meeting.
Item 8.1 (commenting on the need for asynchronous algorithm support) was refer to tasking requirements subgroup).
Item 8.2 (terminology clarification about implementation-dependent vs processor-dependent) was discussed. Both phrases are used in the HPF document to mean the same thing. The formal Fortran terminology is processor-dependent, but this is somewhat confusing in the HPF context, and considered outdated terminology, even for F90. We will add a discussion of the terminology implementation-dependent to the first part of the HPF document (noting that it is the same as the formal F90 processor-dependent). To be consistent, all uses of processor-dependent will be removed. Our recommendation is that X3J3 reconsider this terminology for F95.
Item 8.3 Comment on load balancing functionality-referred to tasking/irregular data requirements groups.
Item 8.4 A comment questioning the use "High" in HPF. The formal reply, is point taken.. A more flip response is: The long tradition in advertising is that when something is capitalized it doesn't have to be true.
Item 8.5 Several new typos were identified.
Item 8.6 Query about FORALL index scope - The answer (statement scope) already sent was confirmed.
Item 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? See item 8.17.
Item 8.8 As noted, there is an error in an example. It will be corrected.
Item 8.9 Query about SEQUENCE & structure components. There are two different issues. The text on page 146 refers explicitly to a F90 requirement that components with the F90 sequence attribute will be sequential in HPF. This text will be clarified. The issue of whether general components can be distributed has been identified as an issue for HPF 2.
Item 8.10 Query about PURE calls in independent loops, already answered correctly.
Item 8.11 An amusing dark corner of FORALL semantics with scalar assignment, already answered correctly.
Item 8.12 What happens when INDEPENDENT directive is in error? This is implementation dependent.
Item 8.13 Mathematical library interfaces. The recommendation is that this issue be taken to X3J3. This is material for a possible collateral standard to Fortran, but outside the scope of what HPFF can take on.
A formal vote was taken on the recommendations for this group of recommendations except for 6.10- 24 yes, 0 no, 1 abstain.
Item 8.14 What is the relationship between HPF and HPF_LOCAL for file I/O? Are there restrictions on I/O in HPF_LOCAL? Can the same unit be used in both contexts? What if a local routine does a close on a unit? Does the HPF caller see this? These issues were discussed , but the agreement was that 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.
Item 8.15 About mixing locals & globals interface defaults was discussed and then postponed until later in the meeting for a Guy Steele proposal. This is related to items 6.16 and 6.17.
Item 8.16 Asking about restrictions on initialization expressions - this is strictly an F90 issue. Reshape is allowed. The F90 document 7.1.6.1 gives the rules about initialization expressions.
Item 8.17 Is there missing functionality for finding the global bounds of arrays from local routines? This was referred to Henry Zongaro for a proposal. (See next item following this CCI list in the minutes.
Items 8.18-8.20 These are questions about the JOD I/O proposals. They are referred to I/O subgroup.
Item 8.21 - Request for indexed lists. This needs clarification. The recommendation is to refer it to the irregular data requirements subgroup.
Formal vote on the remaining recommendations: 25 yes - 0 no - 0 abstain
Next Henry Zongarro presented a proposal related to 8.17 above. This was for routines:
Break.
Following the break, Guy Steele presented proposals / discussion for some of the CCI items that he had accepted as action items at previous meetings:
Item 6.12 Needing refined text for the definition of NEW. Proposed change:
It was noted that the question about common association seems to be missing in the proposed change. This is not a question of what the definition is after the loop ... a question of what the value is during the loop, say in a routine that is called from within the loop. There was extended discussion. Chuck provided an example:
COMMON/foo/a
!HPF$ INDEPENDENT, NEW A
DO I
call Bar()
----
SUB Bar
COMMON/foo/ A
A=...
...= A
Further work on this was postponed until Friday.
On page 83, insert this text at line 15: If a subprogram is called during execution of an INDEPENDENT loop, execution will behave as if all its local variables were declared NEW. Advice to implementors. An implementation that executes more than one call simultaneously must provide distinct storage for the locals variables of each invocation. (End of advice to implementors.)
Guy took this guidance to prepare for further discussion on Friday.
There was a break for lunch.
First the simple new questions were addressed.
Item 7.2 : Yes, scalar templates are ok, but we probably don't want to call attention to it.
Item 7.4 : No, no chronological order of directives is assumed.
Item 7.5: Yes, an alignee must be dynamic if align target is dynamic. A text change still needed : action Rich Shapiro.
Item 7.6: Comment on forcing communication with directives, including a query: how far do the directives provide a means for explicit communications? Answer is "pretty far" .
Item 7.7: An over sight, an align target must not be OPTIONAL . Text is needed: Action Rich.
Item 7.8 : Syntax goof, blank common can be sequential - Action Mary for syntax text change.
Item 7.9 : Regular array sections -what are they? This needs a definition. Rich will supply text.
Item 7.10 : Overlap between block and cyclic. The answer already sent by Chuck was ok.
Item 7.12 Can constants be sequential? - This needs a text change - no action name was noted.
Item 7.14: The code is erroneous because A is declared more than once .
Item 7.15 : The align of B is illegal, the align of C is legal. No changes are necessary.
Item 7.16: No - templates are not first class objects.
The items above were voted closed assuming the proper text changes would be made: 20 - 0 - 1.
Item 3.9.1: No text change is needed : Class one names takes care of it.
Item 3.9.2: Subobjects of derived types not mappable. This is an issue for future requirements.
Item 6.2: Text changes are proposed:Add text p 31 lines 23+ p 26 lines 35+ "A ... must be a simple name. It must not be a compound-name of a derived type." This is a 2nd reading.
Item 6.7 : No change is needed, let's not put in extra text about replication.
Vote on these items: 24 - 0 - 0 all closed.
Items 3.5/3.6: 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".
Items 3.10/3.11/6.9: Change text on p44, 27-29: Note that the rank of the dummy argument and the rank of the dummy argument's template need not match. The distribute applies to the template, not the array.
Defer vote on 3.11.
Item 6.3 Do mapping directives restrict pointer targets? Text change 2nd reading: 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
Item 2.6/6.8 Examples of undescribable alignments. You can't say it with a single align, but what it means is not ambiguous. This needs to go to HPF 2 . It was noted that we need a general issues section for the HPF2 charter.
Vote accepting all of these except 3.11 --- 22 - 0 - 3.
Item 7.1: Constraint about nonsequential array functions.. 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.
Item 7.3: Circular distribution directives. 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 ...."
Item 7.11: Repeated directives. Need text change. In the section on directives, disallow giving an object an attribute more than once. First reading: action Rich.
Item 7.13 : Explicit mapping, sequential, and dynamic. Answers are:3 - no 3a not applicable 3b y,y,y. Change p 144 line 31 (definition of explicitly mapped ) to add DYNAMIC and INHERIT to the ways to make something explicitly mapped.
Vote on all first readings: 27 - 0 - 1
This was the end of the Group 1 CCI report.
A report about the review of X3J3 proposals was made by Mary Zosel. Both PURE and FORALL are being proposed for inclusion in Fortran 95.
As a general issue, we recommend that HPF2 should be described as Fortran 95 plus extensions - just as HPF1 is Fortran 90 plus extensions. This automatically keeps us up to date with changes that they make, protects the vendors from slight differences between F95 FORALL constructs and HPF constructs, and also makes our document smaller.
The X3J3 proposal text mentions that the issue of copyright needs to be addressed. Rice University holds the HPF copyright on most of the text. Ken Kennedy sent a message to X3J3 addressing this problem. It is both of our best interests if the text be a similar as possible between the Fortran standard and HPF document. However, by releasing this text to the Fortran standard, we do not want to be caught in the position of not being able to use our own text.
Two technical issues were identified in the X3J3 proposals. The example below show the problem with a proposal to require all generic overloads of a PURE function to be PURE
program p
interface sin
function fun(L)
logical :: L
end function fun
end interface
end program P
The function fun not pure --- but generically overloaded. The second issue identified was the addition of PURE to the list of characteristics of a procedure. This has the danger of causing valid F90 programs to become invalid F95 programs. Both of these issues were forwarded to X3J3.
Item 6.12 The text has now been expanded to read: On page 82, line 39, change "More formally" to "moreover". On page 81, line 16, add these bullets:
Second reading vote: 23 - 0 - 1 Action Chuck to provide a rational related to this one.
Items 2.3, 6.16, 6.17, 8.15: A modified version of the extrinsic interface proposal addressing mixed extrinsics was presented and discussed. In the discussion, David Loveman requested a wording change to allow the possibility of compilers selecting default extrinsics kinds: every unit has an extrinsic kind - either you state the kind otherwise it will be a default. The full text of the proposal, as modified to recognize different compiler defaults is:
Extrinsic kind keywords whose names begin with "HPF" 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 "HPF" is said to be "of an HPF extrinsic kind".
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 "HPF_".)
The intent of this proposal is so that any HPF-extrinsic kind can call procedures of other kinds, but can't use their data directly.
A given named common may be used only with one kind of extrinsic ... within HPF> Everyone is asked to think about the broader expectations for this interface. A straw poll was taken: a given common may not be used in more than one HPF extrinsic kind - 27 - 0 - 3.
For the actual language document specification update:
An implementation document: There was an extended discussion about an implementation document. Robert Babb suggested a guest issue of his journal. Rob Schreiber would be willing to be a guest editor of such a journal. This is still an open question.
The benchmark report was presented by Paul Havlak. The following goals and assignments have been made.
By Sept. 1 get codes together.
John Levesque has a lot of kernels with indirect addressing. He will subdivide his codes into regular addressing vs irregular addressing.
Paul will be collecting miniapps and writeups describing mini apps. These descriptions should include the following:
Ian Foster will create a web page for the benchmarks. RICE is also about to do something for a national software exchange. By Sept. 15 the benchmark page should be linked up. Paul will send out instructions for the section texts ASAP. The document will contain proposed directions for HPF2 - things lacking in HPF1
In an update to LPF extrinsic interfaces, LPF_ADA has been dropped and LPF_APL added. This is just considered a small spelling change.
Since HPF has dropped the H, LPF will follow suit - now they are the same name and same performance.
According to HPCWIRE, the Thinking Machines news signals the death of supercomputing. HPF may be next, but LPF has a long life remaining. They are taking applications.
As a base language LPF will be moving from Bombara90 to Greek95. A few incompatibilities are considered a good thing.
LPFF members, like HPFF members, are concerned not only about erroneous issues, but also illegal ones. So an LPF crime bill is being proposed. It's time to get tough on bad programmers: 3 strikes - syntax errors, and the system crashes. There will be mandatory penalties for runtime errors. In programs for youth, there will be midnight chess. Fewer career and course counseling opportunities will be offered and a head-stop program initiated to keep at-risk kids from math-science..
The meeting was adjourned at ~11:45. The next HPFF meeting will be October 12-14 in Chicago.
Robert Babb U. of Denver babb@cs.du.edu
Scott Baden UCSD baden@cs.ucsd.edu
Ralph Brickner LANL rgb@lanl.gov
Alok Choudhary Syracuse U. choudhar@cat.syr.edu
Jim Cowie Cooperating Systems cowie-james@cs.yale.edu
Thomas Fahringer U. of Vienna tf@par.univie.ac.at
Ian Foster Argonne Lab. foster@mcs.anl.gov
Paul Havlak U. Maryland havlak@cs.umd.edu
Don Heller Ames Laboratory dheller@scl.ameslab.gov
Chua-Huang Huang Ohio State U. chh@cis.ohio-state.edu
Ken Kennedy Rice U./CRPC ken@rice.edu
Bob Knighten Intel SSD knighten@ssd.intel.com
Chuck Koelbel Rice U. chk@cs.rice.edu
John Levesque APR levesque@apri.com
David Loveman Digital Equipment loveman@hpcgrp_enet.dec.com
Piyush Mehrotra ICASE pm@icase.edu
Andy Meltzer Cray Research meltzer@cray.com
Nicole Nemer-Preece U. of Missouri-Rolla nnemer@cs.umr.edu
E. Nunohiro HITACHI nunohiro@hisoft.soft.hitachi.co.jp
Rex Page U. Oklahoma rlpage@uoknor.edu
(alternate for J Wagner)
Terry Pratt CESDIS/NASA Goddard pratt@cesdis1.gsfc.nasa.gov
J. Ramanujam Lousiana State University jxr@max.ee.lsu.edu
Chip Rodden PSR chip@psrv.com
P. Sadayappan Ohio State University saday@cis.ohio-state.edu
Joel Saltz U. of Maryland saltz@cs.umd.edu
Rob Schreiber RIACS schreiber@riacs.edu
Richard Shapiro Thinking Machines shapiro@think,com
Guy Steele Thinking Machines gls@think.com
Jaspal Subhlok CMU jass@cs.cmu.edu
Paula Vaughan Miss. St. / NSF ERC paula@erc.msstate.edu
Karen Warren LLNL kwarren@llnl.gov
Henry Zongaro IBM Canada zongaro@vnet.ibm.com
Mary Zosel LLNL zosel@llnl.gov