Newsgroups: comp.parallel From: zosel@phoenix.ocf.llnl.gov (Mary E Zosel) Subject: HPFF94 April Meeting Minutes Organization: Lawrence Livermore National Laboratory Date: 29 Apr 94 18:40:46 GMT HPFF Minutes Chicago April 6-8, 1994 Prepared by Mary E. Zosel Executive Summary Thirty four people attended the first HPFF94 meeting (see list at end). Activity at the meeting is summarized here very briefly. The full minutes can be consulted for details. Formal voting requirements were discussed. An HPFF MOSAIC home page was proposed (and implemented). See http://www.erc.msstate.edu/hpff/home.html The formal vendor survey was updated. Changes are that Digital now has an announced product and Convex has an announced effort. Issues submitted to the hpff-interp email list over the past year were addressed. A number of minor corrections were adopted without further review. A few of the more complex issues remain for formal proposals or further consideration at future meetings. Reports were given on the initial discussions about new requirements for support of irregular data, parallel I/O, and tasking. Each of these groups has been invited to see if there are some simple issues/fixes that can be addressed during the HPFF94 meetings. Additional working groups were formed to address collection of mini-applications for testing and the creation of an implementor's advice document. As a wrap-up, the following responsibilities have been assumed, along with email reflectors for communications. Full committee communications continue on the hpff-core@cs.rice.edu list and general meeting announcements, minutes, documentation releases are posted to hpff@cs.rice.edu. -Send any changes to the implementation survey to ken@rice.edu and zosel@llnl.gov. -Donna Reese (dreese@erc.msstate.edu) will be responsible for the HPFF Mosaic homepage. -David Loveman will continue as document editor. -Richard Shapiro and Mary Zosel will lead work on CCI issues. New issues should be sent to hpff-interp@cs.rice.edu. A formal CCI report should be created. -For Requirements, the subgroup chairs are: Chuck Koelbel (irregular data) hpff-irreg@cs.rice.edu Alok Choudhary (parallel I/O) hpff-io@cs.rice.edu Joel WIlliamson (tasking) hpff-task@cs.rice.edu The charter for these groups is to collect application requirements, look for simple fixes to propose to the committee, and to create a requirements report. -For work to "Encourage Implementations" to subgroups are identified: Joel Saltz will lead a group to collect mini-apps. hpff-bench@cs.rice.edu Rob Schreiber will collect information for an implementor's advice document. hpff-impl@cs.rice.edu. ____________ APRIL HPFF94 MEETING RECORD OF ACTIONS ____________ April 6 Working subgroup sessions were held to discuss requirements and initial review of the requests for document correction/clarification. April 7 Ken Kennedy formally initiated the second round of High Performance Fortran Forum meetings and led the discussion of initial administrative issues. There have been two voting mechanisms - straw votes and formal votes. We had continuity in HPFF I meetings and hope that continues. Formal votes are one per organization. Anyone can vote at this meeting. New organization at the second meeting cannot vote - must have attended the previous meetings. We propose to modify the first/second reading voting procedure for these meetings: some issues will be identified as minor and will be adopted in one meeting. If anyone questions an issue, it will be moved to more formal consideration. The program chair of ICPP has proposed that we coordinate our August meeting since the dates coincide. ICPP has already determined their meeting site and there was some objection to moving the HPFF meeting to that hotel. No overlap was identified in people present at the HPFF meeting who were planning to attend ICPP. The resolution was that if the ICPP organizers wish to propose a joint activity, weUll consider it. An HPFF Mosaic homepage was discussed. Mary was looking for volunteers to complete a language overview, as well as a volunteer for setting up the home page document. For the overview, most of the current document section editors agreed to help. Donna Reese, volunteered to take on the maintenance of the HPFF home page. There was a brief discussion of the possibility of getting the full document on-line. [NB as of the time the minutes are being prepared, the initial home page is available: http://www.erc.msstate.edu/hpff/home.html] Documents for this round of HPFF meetings were discussed. David Loveman will continue as the main language document editor. Various possibilities for additional documents were discussed, such as a CCI document, implementation experience, limitations (whey we decided not to do something), requirements. The interpretations list might be formalized so it can be on-line. A requirements document would be a form of charge for HPFF II. Funding for test and validation suites were discussed briefly. Ken contacted NIST about funding, but no program there has this kind of a charter. Mary outlined the proposal that was submitted to SC94 for a (workshop) roundtable. We propose about 1 hour of report from the HPFF94 meetings - probably in the form of reports from the working group leaders - followed by about 2 hours of implementation and user experience. David Loveman volunteered additional help for the workshop. There will be more discussion of this at a later meeting. Ken commented on federal research budgeting. Last year HPCC took a beating in the congress. HPCC funding has promoted a lot of good things such as HPFF, purchase of products, and good research. NSF got hit hard for a variety of reasons and steps have been taken. ARPA got hit by misinformation that was passed on to committee staff people (e.g. House Arms Services committee). There may be similar problems again this year. The people who can have the most impact are the HPC companies who should contact their congressmen. Lobbyists are trying to take the HPCC $$$ away. The mailing reflectors were reviewed. The hpff-comments reflector will be aliased to hpff-interpret. The older working group reflectors will be disabled and replaced by new ones, as the need is identified. It was verified that we will call this round of HPFF meetings HPFF94, to eliminated the confusion about correspondence between the version of the language and the series of the meetings. The vendor/implementation survey was updated with the following results: __________________________________________ Survey of Vendor HPF Implementation Status April 94 ANNOUNCED PRODUCTS Applied Parallel Research Digital Intel Kuck and Associates Meiko Portland Group ANNOUNCED EFFORTS ACE, Archipel, Convex, IBM, Lahey, Maspar, NA Software, nCUBE, NEC, PSR, Thinking Machines INTERESTED ACSET, CRI, Fujitsu, HP, Hatachi, SGI, Sun ____________________________________ Changes to this list should be sent to both ken@rice.edu and zosel@llnl.gov. It is useful to keep this list up to date, because it is used in various talks about HPCC developments and proposals. This concluded the initial round of administrative discussion. --- Mary Zosel next presented the CCI Initial report from the subgroup meeting. Three document handouts for the initial interpret list were considered: the 3/28 list circulated via email (and handout), an addendum from Hank Sips and an second addendum from David Loveman. A numbering correction to the index for items #3.10, 3.11, 3.12 was noted. In the CCI subgroup, recommendations for the following minor corrections, were made. #1.1 Adopt the correction to LB/UB in the example. #1.2 A number of editorial problems with the document were addressed. (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 #1.3 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. #1.4 (a) agree - strike ALIGN or (b) agree - dist-target-clause should be dist- onto-clause. #2.1 Add sentence to page 20 line 7 to verify that the entire directive is case insensitive. #2.2 Change the instance of IARRAY to ARRAY. #2.4 Strike "and hence delivers a known shape at compile time" in the subset. These recommendations for minor corrections were accepted by the committee with a vote of 25-0-2. Two additional items were recommended as "first reading" issues: #2.3 - Add text to item 4 on page 142 to make it explicit that in general Extrinsics may access and modify HPF global data even though HPF_LOCAL routines cannot (A.2.1 page 158). Straw poll 25-0-5. Clarify in A.2.1 that global MODULE data may not be accessed by HPF_LOCAL. Straw poll 10-0-21. Straw poll - should it be more restrictive? 8-0-21. Action Guy Steel to provide specific text. #2.5 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. The remaining CCI items were broken into two groups with a recommendation that the full group break into two subgroups later in the meeting to consider it issues. Meeting break. Following the break, there were reports from three requirements groups. Each group met on Wednesday afternoon to discuss the process and select someone to lead further work. Irregular computations requirements - reported by Chuck Koelbel Methodology: HPF is widely believed to be inadequate for irregular computations (irregular means complex data structures). We want to base new extensions (if any) on user needs. WeUre heavy on compiler experience, light on applications people. So our general approach will be to survey applications we do have, survey established implementations and abstract feasible language and / or library features. Target Applications: The important areas currently identified are - rapid n- body solvers e.g. multipole (octree), multigrid and adaptive grids, unstructured meshes, (irregularly) coupled regular meshes, mixed problems with substantial regular components, and monte carlo. Collecting a suite of example programs would be an important contribution. (These might also be useful for applications people to have models.) Application Needs: The following were identified - more general data mapping, nested data structures, arrays of arrays, derived types, mapping to processor subsets, several mechanisms (map arrays, irregular blocks, etc.). Better control of parallelism: In addition to mapping control, the following kinds of operations can contribute to support of irregular computations - nested and loosely coupled data structures, computational partitioning for loop iterations and array operations, schedule of loop iterations such as ON clause or self-scheduling, precomputing communications. Other Issues Mapping to processor subsets is also needed for regular problems. Removing the existing specifications that equal-size processors arrangements coincide and size equal NUM_PROCESSORS rules is an important enabling change. General cleanup of HPF is also important. Some suggested features specific to heterogeneous systems, although others commented that this is exactly the sort of thing we want to avoid in HPF after a variety of somewhat non-portable suggestions were made. There is concern that fully general methods may have excessive overhead. Action identified: Chuck will circulate a draft outline. In general discussion following the report, Ken asked what expect to produce after these meetings. Chuck suggested each subgroup produce a report documenting what the issues are and some high-level descriptions of what possible approaches are - e.g. survey of literature, and maybe some recommendations. Important to focus on requirements of the users and not the requirements for solutions. It was noted that HPF includes F77 so in some sense, it already solves the problem, but also commented that we want to advances the state of the art. Existing program kernels can be quite useful, but there is also a danger in concentrating on existing programs instead of maybe new approaches. Ken asked about any consensus on some simple things. Some of the suggestions were: the proposal by Chapman at the January meeting that mapping directives by allowed inside of derived data types; processor subsets; reduced restrictions on what is allowed in FORALL. Ken proposed that the irregular group prepare a formal proposal for minor adjustments to HPF that would enable some solutions. We would like to have such a proposal at the next meeting for straw votes. Terry asked if vendors are adding things? Do they see some easy things? Levesque volunteers to tell about the APR extensions that they are considering. ------------ Parallel I/O requirements - reported by Alok Choudhary The first issue was a survey of what the vendors are doing. Intel - (CFS/PFS) To get parallelism explicitly, special routines provide various was to access the data. There is file striping on a file system basis. Thinking Machines found the need for 64 bit file pointers. They have made an effort to get parallelism from Fortran I/O. Meiko - Like INTEL has striping controlled on files system basis with read/write distributed arrays. IBM - Vesta -> File distributions may be specified. Guy Steele described the extensions for 64 bit integers as the most difficult thing they experienced at Thinking Machines. Fortran provides most needs, depending on the file location. If one Fortran program writes and another program reads, there may be a mismatch between the number of processors, and the number of disks. Then there are some implications requiring some unscrambling but Fortran I/O spells this out. Part of the reason this works is that the disks are not node attached, they are all are equally distant from the processing nodes. At this point, the report was interrupted with some informal discussion that went approximately as outlined here. Rob Schreiber asked if implementations can just add keywords. Alok: - adding file layout directives doesnUt harm portability because they can be ignored. Guy: Thinking Machines has another set of primitives that are accessed from message passing where all processors are dealing with the same file, but in an asynchronous fashion - also routines to control what happens when all processors are trying to write. These are low level things not visible to Fortran. Jerry Wagener: you need to write things out to be read back in other programs / different configurations. Is there a way to aid the system getting this right? Should we have something like a specification of the number of streams on the reads / writes? Alok: you should always maintain a specific global view of the data - and map in various applications. Returning to the Parallel I/O report: Summary of Types of I/O identified are: out-of-core (persistent), checkpointing and restart, real-time output, I/O for very high bandwidth (massive amount of I/O) . Some additional issues are: Is the language sufficient or some additions needed? Can a runtime library do the job? What is the model for parallel I/O? Are there special issues for I/O over high-performance networks? Bob Knighten noted that users aren't interested in parallel I/O, they want high performance. Mary raised the question of the need for standardization of buffered I/O for overlap of computations with I/O. Bob: Posix has standards for this. Ken: it might be useful to adopt these as part of HPF. Ken asked if there are simple changes that should be considered such as 64 bit integers, posix I/O, or an out-of-core directive. He invited a simple proposals. Terry Pratt: overlap of I/O and computations may be a key issue. Guy: we are not necessarily promoting 64 integers. Chuck: F90 already has a KIND mechanism. lunch break Tasking group requirements - reported by Joel Williamson Support for multiple tasks requires creation, invocation, terminations, coordinations, communication, resource management and scoping. The question of determinism is a major concern. There is no consensus on mechanism. Sample implementations are - Fortran M, SVM, X3H5, Fx Fortran, U. Vienna extensions. There is no unanimous opinion that tasking is needed. A paper that has been written by Zima, Chapman, Mehrotra , and Rosendale describes something that looks pretty natural. There is possible overlap with irregular computation. Example applications are needed. A report is expected from a workshop on tasking that was held recently in Pasadena. There should be an ftp address with pointers to electronic copies of various projects/implementations that have proposed language extensions. The X3H5 documents says that a user must be able to run codes on a single process. Maybe there should be specification of minimum number of tasks and resource? [Some discussion about the distinction between single process, single processor, and serial code.] Chuck: what about non-determinism? Joel: if there are any place in the language where it can happen, users will fall into the trap. Mary: would like to see a focus on real application requirements. Robert Babb: Is a simple bridge between different tasks on different subsets of processors sufficient? Ian Foster: a virtual file mechanism helps this. An email list will be established. Questions and suggestions are welcome. Mary asked about nested WHERE - which subgroup does this belong to? Guy: the current semantics say that the ELSEWHERE can depend on WHERE so it is not really for parallelism, but that could change. This question is delegated to the irregular data requirements group. [Note X3J3 is also addressing this issue.] This ended the requirements reports. ---- At this time Jerry Wagener have an explanation of one of the questions that came up about the addition of the DIM argument to MAXLOC and MINLOC. HPF proposed this addition and made it an optional second argument - extending the number of arguments of the Fortran 90 intrinsic to three instead of two. It was noted that this has the appearance of nonportability in the case that the user has specified a non-keyword form of the call with two arguments: is it the original Fortran 90 version with array and mask as arguments, or the HPF version with array and dim as arguments. Since Fortran 95 is intending to adopt this HPF extension, they have already studies the problem closely. They note that the types of the two arguments are different so there is a way to tell which call it is by examining the data types. While it isn't elegant, F95 will propose that both maxloc(array,mask,dim) and maxloc(array,dim,mask) be allowed and let the overload rules take care of it. When asked if HPF had made a mistake in making this the second argument, Jerry replied that X3J3 considers it to be a Fortran 90 mistake and the HPF way is correct. David Loveman reported that the Digital implementors spent more time complaining about the problem than it took to implement the solution. Ken conducted a straw poll about whether we should consider changing the HPF version. Straw Poll: 5-10-14. -------------- At this point there was a break followed by a split into two working subgroups to continue processing the CCI input. Rick Shapiro and Mary led the two groups. ------------ April 8 CCI group 1 report - presented by Rob Schreiber for Rick Shapiro. This group worked on issues related to mapping, sequential, and inherit/processor arrangements. The subgroup recommendations were presented. #D7 - does m have to be positive in block and cyclic directives? - Yes, The document should be modified to clarify. #4.2 questioner made a mistake #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 As advice to implementors - just replicate s over all the processors and be done with it. But this issue needs further consideration. Guy will prepare a proposal. #2.7 REAL A(20); !HPF$ Distribute A(Block(30)) - is this legal? Yes - add an example to the document. #3.9 Part 1 What about overload of names such as REAL X(10), template x, processors x? This is illegal. There should be just one namespace. The document should be fixed to reflect this. #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. David asked about the existing document phrase "non-terminal symbols that are not defined". This needs further action. #3.13 ALIGN WITH B::A REAL ALLOCATABLE DIMENSION (:) :: A,B This is clearly covered and illegal. #4.1 - Illegal in HPF I. (The example shows a two dimensional array mapped to a single dimensional processors arrangement.) #3.7 - 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. #3.5/3.6 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. #3.10 - 3.12 INHERIT A DISTRIBUTE A *(BLOCK) ONTO *P is in the subset DISTRIBUTE * ONTO * is not By a vote of 13-0-2 we recommended that INHERIT be removed. Straw poll on removing inherit from subset 25 - 0 - 6 Vote to adopt the minor items above where resolution is clear: 27 - 0 - 0. CCI group 2 report - presented by Mary Zosel. This group worked on the extrinsic/external interface, pointer, inquiries, and pure/forall issues. The subgroup recommendations were presented. #2.8 GLOBAL_ALIGN/HPF_ALIGN "Furtney test". The answer is 2 in both cases. 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. #3.3 Eliminate alternate return in PURE subroutines. Yes, Fortran 95 will propose removal of alternate return altogether. We don't want to encourage any new use of the feature. #3.4 (a) What is the scope of the forall index? Fortran 90 has the concept of statement-scope which applies nicely. This is what F95 is proposing for the scope of the forall index. We should propose the same. Statement scope means that the index gets it type from the surrounding scope, but does not change value of the surrounding scope. #3.4 (b) Eliminate the constraints about use of globals as indexes. Agree - with the statement scope definition, the text in these constraints is not needed. #4.4 Ragged array pointer example. This example is a good irregular data requirement - and the general question is referred to that group for further consideration. The answer to the "true?" question is yes-true. #D1. Don't allow explicit shape in interface-spec for HPF_LOCALS. 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. #D2 Explicit mapping of the DO-index should be limited. No - this is a machine-dependent advice to user issue. Individual vendors can address this in documentation. These items were approved by a vote of 26-0-2. The following items were either not done or action was postponed as noted. #3.1 HPF external interfaces. Invite comments for consideration. #3.2 Forbid prescriptive distributions in PURE. We agree, but the issues are sufficiently complex not to finalize at this meeting. Think about it before a final vote. #3.8 Function forms of inquiry. Action: invite John Merlin to make a specific proposal. #D3 Restrict use of cyclic(n) in HPF_LOCALS. The example given does illustrate a problem, but the suggested fix may be overkill. Action - Guy and David to prepare a new proposal. #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. #D8 (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. #D8 (b) Define HPF_MY_PROCESSOR() for use in HPF_LOCALS. 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. This completed the reports from the CCI working groups. The next issue for discussion was the charter item about encouraging robust implementations, with discussion of implementation help, tests, etc. Ken (speak-up or sing) Kennedy asked if we should have an "Advice to implementors document" Ira Baxter: ADA has such a document. There was more on this topic following a discussion of organizing test codes. Applications subgroup (proposed) - reported by Joel Saltz Joel reported on an effort being formed to gather a set of small practical kernels and mini-apps of the order 100-30000 lines of code in F77, F90. These would have several data sets, both small and realistic. There would optionally be HPF versions and parallel message passing versions, and possibly some versions from other languages such as Vienna Fortran. Two Gigabytes of a storage repository will be allocated for this purpose. Several codes have already been identified, along with a volunteer to take responsibility for the code: #1 EUL3D (irregular reductions) - John Levesque #2 Hartree Fock matrix construction (regular structure, irregular load balance, good for course-grained approaches) - Ian Foster #3 Irregularly coupled regular mesh code (Liebrock's code) - David Loveman #4 Direct simulation Monte Carlo (particles migrate from cell to cell, shifting patterns of work make load balancing {remapping} useful) - Joel Saltz #5 Structure multigrid - Scott Baden #6 Additional code (linear algebra) - John Levesque The goal is to provide F77 code by next meeting to provide input for the working groups. In the next phase, more codes will be collected: #1 Particle - particle / particle mesh Pcubed-M vortex dynamic application (LPAR) - Scott Baden #2 Adaptive multigrid (LPAR) - Scott Baden #3 Image processing/pipelined FFT (Fortran-M) Ian Foster #4 Particle in cell (Fortran-M) - Ian Foster / David Walker #5 Flame code (Chaos) - Joel Saltz The purpose of these codes will be to test the limits of HPF and give direction for requirements. For HPF validation suites, Ken repeated a statement made in January, that funding needs to be identified, and a commercial company given the assignment to produce a validation. This isn't volunteer labor or a student project. A tutorial was proposed for how to do HPF for irregular problems and where it breaks down. So far the collecting mini-apps is addressing HPF related to irregular data - but also need general HPF versions. Chuck volunteered to do another regular code. Alok volunteered an unnamed code and Jerry has a finite difference acoustic model. Jerry described the CSEP (Computer Science Education Project) which is working on an online text book. He suggested that maybe some of those authors would produce versions. Jerry will provide a mosaic address for more information. John Levesque also has a suite of benchmarks - that are available over ftp Joel: sponsorship of codes is important. We hope that over time, that the application will be rewritten in different versions so people can understand the trade-offs between different ways of writing the codes. Chuck: We also need descriptions of what the codes are doing. An email list hpff-bench will be created for discussion of gathering codes. Morning break. Rob Schreiber has volunteered to be the collector of any information related to implementation experience to form a new document. The format and contents of such a document has yet to be determined. Ken asked if vendors would like to give any implementations experience reports. John Levesque (APR): We are ignoring restrictions in some case- e.g. on distributing equivalenced variables, or on entries to the routines. We allow for passing work arrays down a call chain and distributing subsections. David Loveman (Digital): Implementation is very hard. We are targeting an ambitions compiler - full F90 and most of HPF (all except dynamic mappings and few other things). We also have a lot of Digital extensions. We are concentrating on doing well on loops and not paying a lot of attention to COMMON/EQUIVALENCE. We find that the F90 array syntax is just syntactic sugar for FORALL. If you do FORALL right then the array syntax falls out. Andy Meltzer (CRI) presented a slide about feathers in CRAFT that users have commented most about. They are removing the power of two restriction. Almost everything feature is useful, but most important is for things to run fast. The users prefer high performance over new features. There have been lots of requests for eccentric distributions, even things that will never be available in LPF {actually canUt do them in LPF - because LPF doesnUt want users!!} [Readers new to HPFF minutes should look to the end of the report and note that LPF is Andy's private project - in no way reflecting on CRI products.] ---- There was general discussion about what an HPFF implementors document should look like. One suggestion is a collection of mini-articles on various topics. Some kind of procedure for getting people to write would be needed. Chuck: would a literature survey be useful? Ken: even more - produce some real papers. BabbUs journal could do a special issue. Ken is willing to get releases for any copyright restrictions. Might be useful to assemble into a book. Start with a bibliography, but aim for new papers. Chuck: can we put these out for mosaic access (modulo copyright agreements)? --- LPF developments during the last year - excepts from report by Andy the LPF guru. While HPF has been sitting around, LPF has been hard at work. LPF MDCII is the current version. Voting procedures for LPF are that anyone can vote, but since no one cares, there is no need to count. About a Mosaic home page - yeah right! Additional LPF working subgroups are planned - with a charter to find out what is working well and remove it. For the irregular problem group, a high fiber diet is recommended along with 8 glasses of water a day. Parallel I/O will be easy - there is no I/O. About task parallelism, LPF is taking a defensive position - since HPF is considering everything everyone wants, LPF will not consider anything anyone wants - in other words lots of syntax and satisfy no one. For LPF CCI work - the mistake was in distributing the document in the first place. :-) --- As wrap-up the following were reviewed: 1. Send any changes to the implementation survey to Ken or Mary. 2. Donna Reese will be responsible for the HPFF Mosaic homepage. Anyone with related research projects is invited to send her http pointers - also any commercial products can be sited from the implementation survey page. Send pointers. The document editors should send text for the language overview. 3. David Loveman will continue as document editor and the current section editors will be responsible for their parts. Drafts will be made available to the committee on FTP in a new directory. (We don't want to confuse people looking for the HPF document with draft versions.) Change bars will be investigated for the macros. 4. For continued CCI work, Rick Shapiro and Mary Zosel will work on issues identified. Each issue should be resolved, document changes verified, and a CCI report should be generated. It is suggested that a formal format be established with the form Question: Submitted by: Answer: Rationale: (reference to document change:) Status: New communications for CCI should be addressed to hpff- interp@cs.rice.edu 5. For Requirements, the subgroup chairs are Chuck Koelbel (irregular data), Alok Choudhary (parallel I/O), and Joel WIlliamson (tasking). The charter for these groups is to collect application requirements, look for simple fixes to propose to the committee, and to create a requirements report. Chuck will assemble this report. New reflectors will be established: hpff-irreg, hpff-io, hpff-task - all at cs.rice.edu. 6. For the "Encourage Implementations" work, Rob Schreiber will act as a group leader. A goal is an implementor advice document. In addition Joel Saltz will lead a group to collect mini-apps. The reflector addresses for these two groups are hpff-impl and hpff-bench, both at cs.rice.edu. The following people attended the April HPFF meeting. Robert Babb University of Denver babb@cs.du.edu Scott Baden UCSD baden@cs.ucsd.edu Ira Baxter Schlumberger Austin Rsch baxter@austin.sar.slb.com Alok Choudhary Syracuse U. choudhar@cat.syr.edu Jim Cowie Cooperating Systems cowie-james@cs.yale.edu Ian Foster Argonne Lab. foster@mcs.anl.gov Don Heller Ames Laboratory heller@cs.rice.edu Andrew Ingalls ACSET (Belgium) ingalls@acset.be Satoshi Itoh Hitachi CRL sitoh@crl.hitachi.co.jp Andrew Johnson OSF Research Institute andyj@osf.org 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 lovemann@hpcgrp.enet.dec.com Larry Meadows PGI lfm@pgroup.com Andy Meltzer Cray Research meltzer@cray.com Nicole Nemer-Preece U. Missouri-Rolla nnemer@cs.umr.edu Bruce Olsen Hewlett Packard bruce@apollo.hp.com Terry Pratt CESDIS/NASA Goddard pratt@ceddis1.gsfc.nasa.gov J. Ramanujam Lousiana State U. jxn@max.ee.lsu.edu Donna Reese Mississippi State U. dreese@erc.msstate.edu Shoichi Sakon NEC sakon@lang1.bs1.fc.nec.co.jp 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 Jon Steidel Cray Research jls@cray.com Jeff Vanderlip Pacific-Sierra Research jeff@psrv.com Jerry Wagener Amoco jwagener@amoco.com Joel Williamson Convex Computer joelw@convex.com Hans Zima U. of Vienna zima@par.univie.ac.at Henry Zongaro IBM Canada zongaro@vnet.ibm.com Mary Zosel LLNL zosel@llnl.gov