HPF August Minutes

August 17-19, 1994
Prepared by Mary E. Zosel

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.


August 17 Working subgroup sessions were held to discuss requirements and requests for document correction/clarification.

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

Applied Parallel Research, Digital, Intel, KAI, Meiko, Portland Group
Formally Announced Efforts
ACE, Archipel, Convex, Cray Computer, Fujitsu, Hitachi, IBM, Lahey, Maspar, NAG, NA Software, nCUBE, NEC, Pacific Sierra Research, Thinking Machines



Guy Steele made a statement to clarify the recent news from Thinking Machines. The company filed chapter 11, as reported in the media. About one third of the employees were laid off, but the company is continues to function. The purpose of the filing was to restructure debt and reorganize the business focus. They will continue with CM5 customer service support and with CM5 upgrades. The company plans to focus on government and petroleum markets, and they will be more aggressive about software work. HPF is more important now - they will port to other platforms, including other mpps and clusters. They will be licensing software technology, even down to complicated emacs macros if there is interest. The general new focus is on open systems and portability.

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

all with text adapted directly from F90, except that ARRAY has to be HPF_LOCAL dummy associated with an HPF_GLOBAL argument. There was a slight confusion over passing array sections, quickly explained. A straw poll about including these (first reading) in HPF 1+ passed with a vote of 28 yes, 0 no, 2 abstain.


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:

On page 82, line 39, change "More formally" to "moreover".
On page 81, line 16, add "; nor" at the end of the second bullet, and add a third bullet: Be host associated, or accessed via host association during execution of the loop in which it is a NEW variable.

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:

      DO I
      call Bar()
      SUB Bar
      COMMON/foo/ A
      ...= A

Further work on this was postponed until Friday.

Item 6.14: The following text change was accepted by a vote of 20-0-3.There was a question about whether "local variables" is a well defined term. If there are further concerns about this text, they should be submitted as a CCI for the next meeting.

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

Items 2.3, 6.16, 6.17, 8.15: HPF defines an extrinsic interface mechanism, and includes a specific definition of HPF_LOCAL. But it has been noted that there are numerous constructs that can be used by both HPF_GLOBAL and HPF_LOCAL. Common blocks were previously discussed, but MODULES, BLOCK DATA, and contained subroutine interfaces are also an issue. The question in these CCI items ask how a MODULE or BLOCK DATA can be tagged as EXTRINSIC HPF_LOCAL, and also ask about what mix mixes of local and global definitions are allowed. Guy presented a long proposal to clarify the interaction of the kinds of extrinsics. The basic flavor of the proposal is that if module id of one kind uses module of another extrinsic kind, then data objects cannot be made available across the USE , only subprograms. A proposed exception is HPF_LOCAL which does USE of hpf-global,: if the HPF_LOCAL accesses global data , then it is as if it were passed in by dummy association. HPF extrinsic common blocks cannot be intermixed - e.g. HPF_LOCAL can have local common and HPF can have global commons, but these may not be mixed. In discussion David Loveman added the issue of compiler defaults. Rob Schreiber added a question about an exception for PARAMETER, and wondered if a better exception was for parameter values rather than for variable data. A further question asked about whether something about mix and match of block-data is needed or if it falls out of the treatment of common. Some straw polls were taken:
Should paramemters be a special case? 0 - 7 - 23
Which version of the proposed exception: can the local get at anything from a global module? 5 - 8 - 18
Are we going in the right direction? 17 - 0 - 13

Guy took this guidance to prepare for further discussion on Friday.

There was a break for lunch.

The afternoon began with the CCI group 1 report, Rich Shapiro presenting.

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.

Next the "simple" old items for Group 1 were addressed:

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.

Next the "not so simple" items were addressed.

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.

Group 1 new items, not so simple.

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

David Loveman next presented some follow-on material to CCI item 5.8(a). In the proposals that were made and accepted, the new routines provide a way to find out exactly what part of an array is on a given processor, but they only provide half of the needed functionality. In a local routine, what one actually needs is 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. He presented a proposal for such routines. 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.
Next Alok Choudhary presented the second reading on the proposal to modify the KIND parameter in Fortran 90 I/O. The specific proposal is to change the arguments of the I/O statement to be of general integer type rather than default integer type in NEXTREC, RECL, and INQUIRE. This will allow file size to exceed the 32 bits that are common supported as default integer. This was accepted 24-0-1. As a minor complication, this statement needs to live somewhere in the HPF document and it remains to figure out where.
The last item for Thursday's meeting was a report from Ian Foster from the tasking working group meeting. Identification of the requirements for additional tasking seems to be merging with the benchmark activity. Several kinds of algorithms (adaptive grid, pic, sparse Cholesky, etc.) have been identified. The benchmark codes will provide input for the tasking requirements.
At this point, the group broke for working subgroup meetings. One group reviewed new X3J3 proposals for incorporating HPF syntax in Fortran 95, while the other group talked about tasking benchmarks.
Friday Morning, Aug 20.

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.

In a second round of the CCI discussion started on Thursday, Guy Steele presented amended versions of his proposals.

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:

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 programunit has no extrinsic prefix, then an HPF compiler assumes EXTRINSIC(HPF).

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_".)

In discussion of the proposal, there was a query about whether this proposal fits with the proposed "scalar" extrinsic kind. David Loveman believes that it does.

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.

First reading vote on the overall proposal: 29 - 0 - 0
Item 2.3: This item requires and additional statement: 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. This item was accepted in a straw poll Thursday.

The next topic of discussion was the generation of documents and reports from the HPFF94 activity.

For the actual language document specification update:

Aug 22 doc sent out by David Loveman.
Sept 15 section editors have changes back to DL
Goal Oct 1 new doc out to core and sent to tlc for duplicating.

The CCI document will go to web and full document (all issues, both open and closed) to be sent out as soon as updated - action Mary Zosel.
A requirements document:
Send input to Piyush by Sept. 15 who will assemble a version and cycle back by Sept. 24.
Goal of draft to core by Oct 1. Action Alok Chuck Piyush - Rob - Ian - Paul to generate sections for irregular, work load, task, critical sections, par I/O, general requirements.

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.

Friday Morning Break:

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:

Description of problems and references
favored parallel algs
HPF/HPF-2 ideas
code details
pseudo code
data structures
HPF2 pseudo code

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

Andy Meltzer presented a proposal for a new variation of the HPF subset: one that is explicitly aimed at the part of HPF that is most efficient. This would be useful guidance for both users and implementors. In discussion, it was noted that the existing HPF subset was designed with the idea of what could be implemented most quickly, which is a different goal than the subset Andy is proposing. But the notion of two subsets is confusing. It was suggested that this subset might be called the HPF kernel. It has also be suggested that the existing subset should disappear with time, as vendors have time to do the full language. No one should be targeting the subset alone. Andy will put together a specific proposal, starting with a minimal subset that he expects people to expand.
Ken led a short discussion about ambitions for HPFF meetings in 1995. This will be discussed again in October.
The meeting closed with a short LPF report from Andy Meltzer. An excerpt is included here.

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.

Attending the August HPFF Meeting:
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