From owner-hpff Tue Dec 19 23:06:49 1995 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id XAA14574 for hpff-out; Tue, 19 Dec 1995 23:06:49 -0600 (CST) Received: from wildcat.cs.dartmouth.edu (wildcat.cs.dartmouth.edu [129.170.200.34]) by cs.rice.edu (8.7.1/8.7.1) with ESMTP id XAA14568 for ; Tue, 19 Dec 1995 23:06:44 -0600 (CST) Received: by wildcat.cs.dartmouth.edu (8.7.2/4.2) id AAA18820; Wed, 20 Dec 1995 00:05:19 -0500 Date: Wed, 20 Dec 1995 00:05:19 -0500 From: dfk@wildcat.cs.dartmouth.edu (David Kotz) Message-Id: <199512200505.AAA18820@wildcat.cs.dartmouth.edu> To: hpff@cs.rice.edu Subject: hpff: IOPADS '96 Advance Program Reply-to: David Kotz Sender: owner-hpff Precedence: bulk --------------------------------------------------------------------------- hpff@cs.rice.edu is a mailing list for announcements related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- CALL FOR PARTICIPATION http://www.cs.dartmouth.edu/iopads/ Fourth Annual Workshop on I/O in Parallel and Distributed Systems (IOPADS) in conjunction with the ACM 1996 Federated Computing Research Conference May 27, 1996 Philadelphia, PA Co-sponsored by: ACM SIGACT ACM SIGARCH ACM SIGOPS IEEE TCOS In cooperation with: ACM SIGMETRICS In 1996, its fourth year, IOPADS graduates from an informal workshop held in conjunction with IPPS, to a format more like a symposium to be co-located with many others at FCRC '96. The thrust of IOPADS has always been to bring together researchers in all aspects of parallel I/O, which we broadly place into five categories: architecture, algorithms, applications, file and operating systems, and compilers and runtime systems. It is our opinion that the problems of parallel I/O are most effectively addressed by investigating all these areas rather than working in each area in isolation. Although I/O-related papers appear in many other conferences, the value of IOPADS is in gathering interested researchers from all these areas of computer science, encouraging cross-disciplinary interaction, rather than working in each area in isolation. Through ACM Press, IOPADS will publish a formal proceedings, which will be provided to all registrants and will be available for sale at FCRC and afterwards. FCRC is the Federated Computing Research Conference, which was last held in 1993. In 1996, FCRC will include many exciting conferences and workshops under one roof: ICS, IOPADS, ISCA, PADS, PLDI, PODC, SIGMETRICS, STOC, WOPA, Workshop on Academic Careers for Women, Symposium on Computational Geometry, Conference on Computational Complexity, Symposium on Networks and Information Management, Symposium on Parallel and Distributed Tools, and Conference on Functional Programming. --------------------------------------------------------------------------- TENTATIVE PROGRAM for May 27, 1996 8:00- 8:45 Breakfast 8:45- 9:00 Opening remarks 9:00-10:30 Session 1: Applications and Language Support Chair: Charles Koelbel, Rice University Efficient Data-Parallel Files via Automatic Mode Detection Jason A. Moore, Oregon State University Philip J. Hatcher, University of New Hampshire Michael J. Quinn, Oregon State University Tuning the Performance of I/O Intensive Parallel Applications Anurag Acharya, Mustafa Uysal, Robert Bennett, Assaf Mendelson, Michael Beynon, Jeffrey K. Hollingsworth, Joel Saltz, and Alan Sussman, University of Maryland The Design and Implementation of SOLAR, a Portable Library for Scalable Out-of-Core Linear Algebra Computations Fred G. Gustavson and Sivan Toledo, IBM T. J. Watson 10:30-11:00 Break 11:00-12:30 Session 2: Caching and Architectural Issues Chair: John Wilkes, Hewlett-Packard Laboratories Evaluating Approximately Balanced Parity-Declustered Data Layouts for Disk Arrays Eric J. Schwabe, Ian M. Sutherland, and Bruce K. Holmer, Northwestern University ENWRICH: A Compute-Processor Write Caching Scheme for Parallel File Systems Apratim Purakayastha and Carla Schlatter Ellis, Duke University David Kotz, Dartmouth College Prefetching in Segmented Disk Cache for Multi-Disk Systems Valery V. Soloviev, North Dakota State University 12:30- 2:00 Lunch 2:00- 3:30 Session 3: File Systems Chair: David Womble, Sandia National Laboratories Performance of the Galley Parallel File System Nils Nieuwejaar and David Kotz, Dartmouth College HFS: A Performance-Oriented Flexible File System Based on Building-Block Compositions Orran Krieger and Michael Stumm, University of Toronto Client-Server-Directed Collective I/O in Panda Y. Chen, M. Winslett, K. Seamons, S. Kuo, Y. Cho, and M. Subramaniam, University of Illinois 3:30- 4:00 Break 4:00- 5:00 Session 4: Theory and Algorithms Chair: Jeffrey Vitter, Duke University Bounds on the Separation of Two Parallel Disk Models Chris Armen, University of Hartford Structured Permuting in Place on Parallel Disk Systems Leonard F. Wisniewski, Dartmouth College --------------------------------------------------------------------------- General Chairs David Kotz Thomas H. Cormen Ravi Jain Department of Department of Bellcore Computer Science Computer Science 445 South Street Dartmouth College Dartmouth College Morristown, NJ 07962 Hanover, NH 03755-3510 Hanover, NH 03755-3510 (201) 829-4756 (603) 646-1439 (603) 646-2417 rjain@thumper.bellcore.com dfk@cs.dartmouth.edu thc@cs.dartmouth.edu Program Chair Alok Choudhary ECE Dept., 121 Link Hall Syracuse University Syracuse, NY 13244 (315) 443-4280 choudhar@cat.syr.edu Program Committee Sandra Johnson Baylor, IBM T. J. Watson Alok Choudhary, Syracuse University Tom Cormen, Dartmouth College Denise Ecklund, Intel SSD Garth Gibson, Carnegie Mellon University Charles Koelbel, Rice University David Kotz, Dartmouth College Ethan Miller, University of Maryland, Baltimore County Richard Muntz, UCLA Dan Reed, University of Illinois at Urbana-Champaign Jeffrey Vitter, Duke University John Wilkes, Hewlett-Packard Laboratories David Womble, Sandia National Laboratories For updates and more information, see http://www.cs.dartmouth.edu/iopads/. For general inquiries, send electronic mail to iopads@cs.dartmouth.edu. --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff Fri Dec 29 18:04:55 1995 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id SAA24411 for hpff-out; Fri, 29 Dec 1995 18:04:55 -0600 (CST) Date: Fri, 29 Dec 1995 18:04:55 -0600 (CST) From: owner-hpff Message-Id: <199512300004.SAA24411@cs.rice.edu> >From: Mary E Zosel Subject: hpff: HPFF Minutes High Performance Fortran Forum Meeting November 1-3, Arlington, Texas Record of Action: Mary Zosel Sender: owner-hpff Precedence: bulk --------------------------------------------------------------------------- hpff@cs.rice.edu is a mailing list for announcements related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- Executive Summary A major decision was made at this meeting to split the language document into two parts - the first, substantially smaller that the existing HPF 1.1, called HPF 2.0; and the remaining features of the language are contained in a larger section with a working designation of HPF2000. The primary distinction between subset HPF and HPF 2.0 is that HPF 2.0 contains all of Fortran 90 (95) {the subset does not}, and HPF 2.0 limits the kinds of distributions and alignments supported. More complex distributions, including CYCLIC (n) are part of HPF2000. Also, HPF 2.0 does not have sequence/storage association which limits common block flexibility. New language features accepted will become part of HPF2000, and the group may selectively chose to move the features to HPF 2.0. The group also processed the first or second reading of a number of language proposals. Following summarizes the status. Details of the proposals are included in the full minutes below. Proposals passing second reading: Indirect mapping of array elements (HPF 2000) C interoperability proposal Explicit interfaces required in many cases (HPF 2.0) Generalized Transpose (extension of Fortran transpose routine) (HPF 2.0) Specification of shadow widths (HPF 2000) Derived type component mapping (HPF 2000) Simple reduction directive in loops (HPF 2.0) ASYNC I/O (HPF2000) Proposals still in progress of second reading: Mapping to subsets of processors Proposals in the process of first reading: Task regions. Proposals discussed in a preliminary review: External bindings such as MPI integration with HPF. Another item of special note: there was a change of voting rules requiring 2/3 majority of all votes (with abstain counting as no) to pass major issues and all second readings. The next HPFF meeting is schedule for Houston January 9-12. It will replace the annual HPF conference this year - and the longer time will allow more time for review of issues that require special discussion, as well as document reorganization. End of Executive Summary (apology for delay in minutes - the last 6 weeks haven't existed) ____________________________ Detailed Record of Action Nov 1: Subgroup meetings chaired by Rob Schreiber, David Loveman, and Guy Steele were held from 1:30 through the evening. Nov 2: Ken Kennedy called the meeting to order at 8:40. Introductions and the initial count of installations were made. 26 people from 23 (22 voting) institutions were present. =================== In the review of the vendor list, Announced Products Applied Parallel Research, Digital, Hitachi, Intel, Meiko, Motorola, NA Software, NEC, Pacific Sierra Research, The Portland Group, Inc. (PGI), SofTech Announced Efforts ACE, Fujitsu, IBM , Lahey, MasPar, NAG, nCube, Thinking Machines Interested Cray Research , EPC, Convex, HP, Silicon Graphics, Sun ============ First topic was a presentation by David Loveman addressing the definition of success or failure for HPF. Following are excerpts from his talk. This question can be addressed from several perspectives: user (application ISV, role-your-own end users), vendors (system,, performance, desktop), and researchers. The requirements for success are different. Some requirements for HPF success: are vendor independence and acceptance providing application portability across vendor's platforms; performance of application; ease of use by application developers; standardization and stability; sizzle. What is the order of importance of these requirements? ISV order (1 2 3 4 5); End user order (3 2 1 4 5), Vendor order (1 2 3 4 5). So what language for technical applications development? Fortran? designed for technical computing, standard, widely available, efficient implementations, well understood, low level, dull. Fortran 90? designed for technical computing, standard becoming available, implementations becoming efficient, not understood, high level, dull (perceptions). HPF? designed for technical computing, evolving, not available, not (yet) efficient implementations, not understood, low level. C++ designed to support abstraction, standard (??), widely available, not (yet) efficient implementation, not easy to understand, sexy. Something else? Ada? Don't laugh. Ada is standard available, efficient, supports abstraction, explicit tasking, etc. etc. Is Fortran the RrightS language? If we really believe that Fortran is the RrightS language for technical computing, we need to sell it. We need to stop saying: Ryou can't solve problem X without new feature YS and RWithout feature Y users won't use HPFS and concentrate on what can be done with HPF as it is now. How is problem X being solved right now? Neither Fortran, nor C nor C++ has feature Y now and problem X can always be solved in HPF as it currently is in Fortran, C or C++, plus HPF has modules, private data, explicit interfaces. The problem is not missing language features in HPF. There is a lack of F90 experience - its benefits need to be sold. C is better than Fortran, if you mean standard Fortran 77. Fortran 90 is better than C or C++ unless you need C++ inheritance (which causes all the problems ...). David asserted the HPF process is broken. HPF 1.0 was based on consensus and agreement on what we agreed on, rather than simple majority. The typical vote was often something like 24-1-2 The HPF 2.0 is assumption seems to be "let's add this neat feature" without clear majority. (There was some question if actual votes taken bear this out.) We need to spend much less effort on new language features, spend much more effort on sales and marketing, promotion and teaching ( in a successful product, less than 20% of the investment is in engineering), avoid over promising, and be proud of what HPF can do, rather than stressing what it can't do. HPF must be the consensus intersection of HPF features that can be readily implemented, i.e. the HPF kernel. Other features must be HPF extended for features not formally in HPF but for which there is agreement on syntax, or HPF Journal of Development for proposals not yet accepted but worth preserving. There must be an effort toward illustrative examples of how to use HPF well. ------------ At this point there was a discussion about the name of the language and the implications for document organization. A variety of opinions were expressed: there are parts of HPF1.1 that we shouldn't deal with; what problem do we solve when features won't be implemented for years? one reason for definition now is so that eventual implementations will spell things the same way; it's important for marketing that "full" HPF be something small that vendors cat get out now; but we need the future language definition in place; architectures are changing faster than languages - features we discuss might not be needed in 2000. Guy Steele provided a procedural suggestion - that in ANSI work, substantive changes require 2/3 votes and abstains are not allowed. This was made into a formal proposal for a change of our rules: all 2nd reading institutional votes require 2/3's with no abstains. Since this was a rule change vote it also required a 2/3 vote. A friendly amendment was made that abstains would be allowed, for recording purposes, but they would count a s a "no" vote. This proposal passed. 21-1- 0. So HPFF has new voting rules. Now on to discuss the language split. Jerry Wagoner point out that X3J3 started out with the idea of core + satellites, but the idea didn't fly (for a variety of reasons). Ken: we should take our previous document vote as a 1st reading. Proposal: "HPF 2.0" is "a kernel" and some-other-name is the full thing. There was a discussion of where the voting was required - to take things out of the language? to put things in? to put in full language - and then to move to kernel? Ken proposed that we start with an empty kernel and move things in. VOTE: (yes= split the language with base part that is HPF2) At the end of this vote - HPF2 will be defined to be an empty language (runs very fast everywhere) :-) 20 - 2 - 0 (with some pain) Guy proposed that we move all of 1.1 into HPF 2.0 (with the understanding that we move things out later). Is it harder to get things in or to get things out? This failed: 6 - 16 So we start with empty language for HPF2. ====== At this time there was a break - followed by an intentional switch to technical issues. Guy Steele presented some Group D items: CCI 11: In September the subgroup said pointers cannot point to sequential, but the full group vote said try again. So the new recommendation is: (a) Pointers with the HPF SEQUENCE attribute may point only to targets with the SEQUENCE attribute. (b) POINTERS without the SEQUENCE attribute may point only to targets without the SEQUENCE attribute. When a pointer is invoked you know ahead whether it is sequence or not ... institutional vote ... 22 - 0 - 0 ----- Indirect mapping of array elements second reading: The proposal: Add to H309 dist-format is ... or INDIRECT (int-array) The int-array must be of rank 1 and its extent must equal the extent of array or template dimension being distributed. If int-array is an array variable, changing its value later does NOT change the mapping. Elements must be valid indexes of the processors arrangement. In last line of example, change DISTRIBUTE => REDISTRIBUTE *Does it mean an ONTO clause MUST appear? *Need change to inquiry intrinsic? For the future, subcommittee must address whether feature is into HPF2000 and second vote on into the kernel. Subcommittee vote was 3 - 0 - 2 Vote on into large language ... HPF2000 ... 17 - 3 - 2 (passes) Separate vote ... Is the ONTO required .... If there is no ONTO clause ... then it is impossible for the user to know that the values in the int array are legal. 20 - 0 - 2. ----- Mapping to subsets of processors: (Second Reading) dist-target is processor-name [(processors-subscript-list)] or * processor-name [(processors-subscript-list)] or * or subproc-name ? processors-subscript is subscript or subscript-triplet [must be specification-exprs] subgroup - directive is SUBGROUP SUBPROC-NAME [(EXPLICIT-SHAPE-SPEC-LIST)] OF PROC-NAME (PROCESSOR-SUBSCRIPT-LIST) {eliminate from the bottom of the written things First some examples were given of the various options: Part 1: Simple subgroups (1-1-3) !HPF$ Processors P(10) !HPF$ DISTRIBUTE A(BLOCK) ONTO P(2:5) !HPF$ SUBGROUP Q (4) of P (2:5) !HPF$ DISTRIBUTE B(CYCLIC) ONTO Q Question about whether the (4) is required? In simple case not needed, but is needed for the reshaping? Part 2: Reshaping 0 - 2 - 3 !HPF$ PROCS P(10,10) !HPF$ SUBGROUP Q(50) of P(6:10,1:10) ! HPF$ SUBGROUP R(5,10) OF P(1:5, 1:10) ! HPF$ SUBGROUP S(3,4,5) OF P(3:8m1:10) Are Processors are default base 1? {no}. There were some technical difficulties with the written proposal: needed to be able to use subscript OR subscript triplet list. Delete the rule processor- name is proc-name or subproc-name - this gets rid of allowing sub-groups of subgroups. Amendment: A subgroup may not have size zero. Part 1 Down to (excluding) the last paragraph on the written page. Can the onto be a subset of procs? Can there be a name for such a subset? Can we reshape subsets? The recommendation was to revert to straw polls and table until next meeting onto subsets .... straw poll - 20 - 1 - 5 onto named subsets .... straw poll - 14 - 5 - 7 reshaping .... straw poll - 9 - 11 - 6 ---------------- BREAK FOR LUNCH AT 12:15 HPF Kernel: Andy reviewed areas in the kernel where full committee guidance was required before the final presentation could be made. First a question about when variables are identically mapped: When they share identical alignment, distribution, and processors directives (e.g. mapping only syntactic; refers to directives) Whole objects may be identically mapped, but it is possible for two objects to be identically mapped, even though not all directives are specified. (e.g. identical mapping is synonymous with having identical memory layout) Subobjects (for example rows of an array) may be claimed to have identical mappings. And then a question of how restrictive the processors directive should be: Processors directive (7-0-1) - The product of the extents must exactly match the number of processors in the partition or must be a scalar. -only one processor arrangement declared for each rank -If an onto clause is not specified, a default arrangement is provided which is identical for distributees that have identical shape and identical dist-formats Item 3 above applies to HPF2000 as well as HPF kernel. Institutional vote for HPF 20000 20-2-0 (item 3 above) Straw poll for item 1 in the kernel proposal ... 24-0-1 Straw poll for item 2 in the kernel proposal ... 1 - 15 - 9 Pointers in the kernel: (5-0-2) A pointer may only point to identically mapped objects. (1-1-5) The object a pointer points to may be mapped, but the pointer may only point to a whole array or scalar object. Should we restrict the mapping of pointees? 13 - 1 - 9 Wording to be determined. Chuck noted that -much of the kernel write-up is Rthese features deleted from HPF 2000. This is going to be a challenge for documentation. ========= Andy presented the Interoperability proposal (2nd reading) with 2 issues for discussion - from the written proposal. Controversy over which is a better way to indicate that the RC-styleS address of a variable should be taken. Possible intrinsics are loc, or address_of, or symbol: @, * The recommendation is to (let X3J3 pick one for us). A strawpoll of the group about the address-of function was taken: loc - 4 ... address_of ... 2 @ - 13 * - 1 Another change proposed from the original: The NAME clause of the extrinsic some felt was a poor choice of keyword. Alternatives with subcommittee preference: CASE EXTERNAL_NAME (5-0-2) NAME There are two unresolved issues that the proposal doesn't address: Allowing user to provide a map function to convert user types and Requiring conversion intrinsic functions to convert data There is a ISO / IEC Technical Report available via: http://www.uni-karlsruhe.de/~SC22WG5/ Institutional vote on Interoperability proposal for HPF2000: 20-2 - 0 ============= Next was a second reading about explicit interface requirements - tabled at the last meeting. Rewrite 3.10 to include Required except when 1. Fortran 90 does not require one AND 2. No dummy arg is passed transcriptively or with the inherit attribute AND 3. Either of the following cases applies so each pair of corresponding actual and dummy arguments: (a) they are both implicitly mapped (b) they are both explicitly mapped and the mapping are the same. The intent is Rthe sameS means the old definition of when we can call the subroutine descriptively (assert it is coming in here). 4. Either of the following cases applies so each pair of corresponding actual and dummy arguments: both are sequential both are nonsequential. This proposal also eliminates the distinction between prescriptive and descriptive. Institutional vote about when explicit interfaces are required: passed - 17 - 2 - 3 This was followed by a discussion of pros and cons of eliminating the distinction between prescriptive and descriptive arguments. The argument in favor is that it simplifies examples, syntax, understanding, etc. One argument against is that there still may be meaning - in that the user is asserting that "I believe you don't have to change this", so a warning message about redistributions might be appropriate in the case where the user uses the descriptive form and data motion is required. Rewrite section 3.10 to eliminate descriptive directive syntax , and in addition make the appropriate changes to proceedings sections (examples etc.) : institutional vote( 11 - 3 - 8). The distinction will remain. ========= Rob presented a second reading of generalized transpose Extend Transpose (array,order) optional order integer order(rank(a)) array- any type, shape, rank > 0 If order isn't specified, it is as if order - (/n,n-1..., 1/) Result: Element j1, j2, ... jn of the result is element ARRAY [j(order(1)), j(order(2)), ..., j(order(n))) (Let's license this to X3J3 ... exchange for frame-maker licenses) Institutional vote. 18 - 0 - 1 This was treated as a second reading. ======== Carl Offner presented Shadow Widths Proposal: The problem motivating this is that arrays with shadows that are generated implicitly by the compiler are costly to move across subroutine boundaries. The concept of shadow widths is familiar to users - and they can help choose reasonable defaults, as well as give input about what is coming across boundaries. Proposal Replace H209 (page 26) with dist-format is BLOCK [(int-expr [, shadow-spec-or-int-expr])] or BLOCK (shadow-spec) or CYCLIC {(int-expr[,shadow-spec-or-int-expr])] or * shadow-spec-or-int-expr is shadow-spec or int-expr shadow- spec is SHADOW - int-expr or LOW_SHADOW - int-expr [,HIGH_SHADOW = int-expr] or HIGH_SHADOW - int-expr [,LOW_SHADOW - int-expr] Note - shadow=0 might be useful , e.g. for external interfaces. useful for external interfaces. Some possible syntax simplifications were proposed. Institutional vote : (syntax open) 18 - 2 - 2 ============= ASYNC I/O Proposal - Larry Meadows: Example READ (10, ID=I, REC=10) A READ (10, ID=J, REC=11) B ... WAIT (ID=I); WAIT (OD=J) Syntax: New I/O Specifier: ID - scalar - int-var New Statement: WAIT ([UNIT=n] [, ID=n] [,ERR=LABEL] [, IOSTAT=ivar] [, DONE=lvar]) Between READ/WRITE and WAIT No redistribution, undefinition, change in mapping or pointer association for any I/O variable. For READ, no access to any I/O variable. No other I/O operations on same unit. No WRITE to same record. All READs or all WRITES. READ/WRITE Preserves sequential semantics No function call in I/O list! read (99, ID=J, rec=s) I, A(F(I)) When is F(I) evaluated? Problem with doing it --- this will require several changes to the F95 chapter. Explicit text will be presented Friday. ============ Second reading of proposal for Derived type component mapping (subgroup vote 3-0-2). distributee is object-name or template-name or structure-component alignee is object-name or structure-component 1) Allow ALIGN, DISTRIBUTE, DYNAMIC within a derived-type-def to specify attributes of its components. 2) may map a component or variable only if it is pointer or its type is not a derived type having a mapped subcomponent. 2. Alignee or distributee may be a structure-component in REALIGN or REDISTRIBUTE only. in the subgroup ... this was amended: - An alignee or distributee that is a structure-component must have every part-ref, excepting possibly the rightmost, be scalar(rank zero). - A component in a derived type may be explicitly mapped only if the derived type is not a SEQUENCE derived type. partial example from handout DO I=1,n ALLOCATE (grid(i)%bl(grid(i)size)) !HPF$ REDISTRIBUTE grid(I)bl(BLOCK) ONTO P(grid(i)%lo: grid(i)%hi) end DO In the printed copy of the proposal, the first Definition paragraph should read: Definition: A derived type is said to be an "explicitly mapped type" if any of its non-pointer components is explicitly mapped or if any of its non-pointer components is of an explicitly mapped type. Institutional vote: passes - 16 - 3- 3. =========== Second reading on proposal for reductions: !hpf$ independent do i - 1,n !HPF$ REDUCE x = x+expr enddo Some points to consider are: 1. No reduction clause 2. Reduce directive might be optional when reduction var is a whole array name,scalar name. 3. Forms of reduction statement: x = x op expr x = expr op x x = fn (x, expr) x = fn (expr, x) 4. Combine fn is "same" (has same name as) reduction function. 5. Pure functions and operators only 6. Associatively is required of user reduction functions. 7. Only intrinsic assignment in reduction statements. 8. Operators may not be mixed. 9. If operator is - then it's treated as + A-B => A+(-B) If user defined, then unary - must also be defined. May also mix intrinsic * and /. Commutative attribute: !HPF$ commutative reduction-name !HPF$ NONCOMMUTATIVE RN- NAME ! THIS IS DEFAULT CASE Reduction will work better for commutative operations. User defined functions were also discussed, but not considered for the vote. Motion is to accept the intrinsic reduction. Amendment: - #2 REDUCE is optional. 7 - 11 - 4 So REDUCE is required. #9 ... can intrinsic plus and minus (and */) be used together as exception to no mixed reductions. 18 - 0 - 4. Institutional vote as amended with #9: simple proposal (no functions) 19 - 1 - 2 ============= Ian Foster presented an overview of the issue of an MPI binding for HPF. There are two different approaches when HPF is mixed with message passing. (1) SPMD calls HPF (complement of extrinsic) (2) coordination libraries - based on extrinsic HPF communicating with other HPF For an HPF binding with MPI - the primary issue is definition of the Fortran 90 binding for MPI. Examples were given where the code is a simple message passing source when HPF directives are ignored. The problematic F90 issues are array subsections, derived types, and sequence association - MPI assumes mostly linear memory model. In addition to F90 binding there are many implementation issues to consider such as gather to thread 0, sends to thread 0 of second HPF program, scatter; or parallel exchange , etc. Summary HPF binding for MPI is important - provides rapid access to new applications It is primarily an MPI problem but MPIF might not address it. There may be minor HPF issues such as startup, extrinsic/local library. It may also motivate MPI extensions such as full channels. Strawpoll about importance of a F90 binding for MPI ... 24 - 0 2 ========= Scott Baden spent a few minutes on 2 cases for SPMD to HPF interfaces. In the simple case there is a single HPF program. There is requirement initialize HPF - invocations are procedures ... there is no HPF main. Life gets interesting with multiple HPF invocations. Each invocation on a single node spmd calls local hpf program and do coordination. Motivating application - multi-block code each block identified with a single node - each node maybe an smp (or not). HPF execution appears serial from SPMD layer. Data motion between blocks handled at SPMD layer. Requirements are ability to return mapped hpf allocatable back to extrinsic spmd; query functions lb etc access to blocks of data; and mapped array section copy. Break at 6PM ========= Friday 8:15 Andy - Kernel Proposal - to put initial values into HPF 2.0 Summary of differences from HPF v 1.1. BLOCK(N) and CYCLIC(N) distribution formats are removed. DYNAMIC , REDISTRIBUTE, REALIGN, not in kernel. Processors: The product of extents must exactly match the number of processors or must be scalar. If an ONTO clause is not specified, a default arrangement is provided which is identical for distributees that have identical shapes and dist- formats. ALIGN Alignment must be direct, no offsets or strides Dimensions may not be permuted INHERIT: Not part of kernel HPF POINTERS: Pointers may point only to identically explicitly mapped objects. SUBROUTINE Interfaces Carl's explicit interface proposal Dummy args may not be mapped distribute * onto * Assumed size arrays are not allowed REDUCE: (add the intrinsic reduction proposal that passed yesterday) No sequence and storage association in HPF 2.0 HPF2.0 Proposal let's put a stake in the ground and make progress we can see future proposals to amend this but with this could take forever we will need amendments for ON and maybe REDUCE anyway. If you think for functionality needs to be added, vote for this then propose the new features Guy Steele raised a parliamentary point of order: amendment s can be passed by simple majority. Later changes will require 2/3 vote. MZ - add cyclic(n) - 2-15-2 RS - add transcriptively passed dummy say INHERIT (needed for libraries) Long discussion pro and con about goals of HPF 2.0 ... Ken, rather than max performance as the highest priority, we want to design for maximum acceptance. Institutional vote 11-6-2 passes by simple majority. Straw vote to include REDUCE 10 - 5 - 6 DL: remove the REDUCE directive - formal vote: 6 - 11 - 2 - failed. Move to add generalized transpose: 11 - 3 - 5 VOTE on full proposal: 16 - 3 - 0 (all NO votes were vendors) Extended discussion about the what the expectations are for HPF 2.0 - vs the other features that are HPF 2000. Group E --- committee will process changes to HPF 2.0. Work on all first readings for that at the January meeting in Houston. ======== There was discussion of a European Meeting. Based on current changes, the best thing is to have a 1-day workshop in conjunction with HPCN with presentations from the members of the group. Alok will be program chair. Chuck will get a list of people. Ken will write a letter - for a 1-day workshop at the HPCN - presentation from the members of the group. Summary of meetings coming up is: SC95 - document meeting and BOF. Jan 9-11 - Houston March 13-15 - Arlington European Meeting - one day HPCN Brussels 19 April May 1-3 - Arlington Straw poll favored staying in this hotel for March and May rather than Denver. =============== There was a spirited vote for name of the extended feature HPF language among candidates: HPF2000, HPF Extended, HPF 99, HPF 9x, HPF Pro, HPF 2.x. After some elimination. HPF2000 11 and HPF 9x tied at 11 - 11. And finally there was vote switch to make the official name HPF2000. ================ BREAK .... BOF Plan Ken: Refinement of Direction HPF 2.0/2000 and what is it. Implementations, booth pointers, platforms. Rob will summarize the new features. Ian will present HPF/MPI binding issues. We will try for user reports from John Prentice (Chuck contact) and someone from Ames (Rob will get name). An announcement is needed. ======= In a review of proposal status: 1st 2nd group E kernel done interop done format Jan Mar explicit interf done SPMD-HPF Jan Mar local_global func Jan Mar group D irreg map done dist exten dead dist ranges Jan Mar seq. nonmap Jan Mar subsets Jan derived type done shadow width done OOC Jan Mar group C async done on Jan Mar reduct Jan Mar task Jan Mar gen transpose done ============================= The LPF Report: Andy Meltzer LPF 2.0 LPF is very jealous It didn't think of deleting every single feature from the language It didn't think of carefully defining a complex syntax, explaining it in a lengthy discourse then finally telling users that it is meaningless and useless. No marketing organization in history has come up with as clever a way to position a product in the future as making its new product number 1000 times as big as the current product (2 vs 2000). BUT LPF does have a better relationship with its users --- there are none (none left alive anyway). The rational for adding a feature is not if a single user may want it like HPF, but only if no user would every want it. Yet more - LPF has never been so successful making it its committee unhappy. LPF2 New Directives - !LPF$ REDUCE This is directed at the overweight user. He or she must then restrict his or her code to the kernel's original recipe. - !LPF TRIBUTE This directive can only be used on the DISARRAY construct. Operations on a TRIBUTEed dissarry will always produce unknown, messy, and probably late results. An individual element of a DISARRAY is often called a MESS One can have a MESS without a DISARRAY if it is replicated it can only be accessed by the ?? PW, referred to as the SLOB - A user may DISINHERIT a SLOB LPF2 has found HPF2's naming conventions very appealing. LPF2.0 contains the entirety of all programming languages every defined. more will be added as needed LPF20000000 (obviously better than a mere 2000) everything not in LPF2.0 the kitchen sink In LPF2 all proposal reading are final, official readings until just before the vote, at which point they must be withdrawn. Next LPF Meeting January 12-15 , 1992 ====================== This was followed by a virtual LPF Bachelor's party presented by Guy Steele in honor of Andy's pending marriage shortly after the meeting. True to the LPF tradition, instead of actually implementing a party, we're just going to show you a list of party features. There was a long detailed vote, skillfully directed by Ken to determine the list of names to consider for the occasion, and we finally decided on a Multi- Block Parti. After looking at the program, we optimized a schedule .... DO: -Start with black and white home movies of old Fortran 2.0 programs. -{Fill-in-your-favorite-risqu-group-activity} involving all of the LPF users. -A basket ball game with YMSSA (young men's sequence-and-storage association). -A rehash of favorite times from the carefree days of HPF 1.0 such as recollections of discussions between Shapiro and Swift preceding votes of 2- 2-32. -A subset to go bowling (that's irrelevant, but LPF is too). -A raffle for a trip to the Bristol Suites with dinner out at the Chinese Buffet. -And good conversation ... such as advice (which can be ignored) about relative performance of inter-operability interfaces: receptive, deceptive, and contraceptive. -We rejected a CRAFT fair because we thought it would take too long. - Actually every activity was projected to take 10 times longer than expected, so we thought about trying them in parallel, but couldn't because they weren't all PURE. Mellifluous Parti music was provided by a (guy) steel band with performance of selections from a hit LPF record, including: music from the Pointer sisters and Johnnie Cache. Here we go Loop-de-lou Forall (we ) know; If (I_were_a_rich_man) do do do do do do do ... One is the loneliest number Sweet little 2**4 ... and I am 2**4, you are 2**4 + 2**0 IF ( I_were_a_programmer .AND. U_were_a_lady) This was interrupted by a dummy syntactic argument about relative merits of Would you marry me , anyway ? Would you have my baby? vs Would you marry me ? Anyway , would you have my baby? And (not) terminating with a hallelujah chorus of FOR (ever .and. ever) ... Every good Parti has lots of food and drink ... We start with 2**7 bottles of beer on the wall and card punch (which can't be spiked because we are not allowed to fold, spindle or mutilate). As appetizers: bytes will be distributed on temPlates for digital food (no forks allowed). First course: catchup with turtle soup and molasses. MAIN course: CALL take_out_from_the_kernel Dessert: 4 * atan (1.0) with Java and Tea for 2. SO ANDY: After you do double precision, life gets more complex, but you're a magnetic character and memories are made of this. FORALL (TIME = NOW:ETERNITY) WHERE (EVER_YOU_GO) OUR_SALUTE(TIME) = BEST_WISHES(TIME) END WHERE END FORALL Best wishes from HPFF! ============= And back to business in the remaining time: Larry Meadows presented proposal for ASYNC I/O specific list for how the document would be modified ... Changes are that WAIT should always have an ID Example READ(10,ID=I, REC-10) A READ(10,ID-J, REC=11) B .... WAIT(ID=n [ERR=LABEL] [,IOSTAT=ivar] [,DONE=lvar]) Syntax - see written proposal, Institutional vote for HPF2000 16 - 0 - 2 ----- Jaspal Subhlok started the first reading of the task region proposal. The following text is incomplete. Assume there is a way to divide processors into subgroups - such as the processor subgroup naming proposals that have been discussed earlier. A task region is a section of code with an ON clause used to direct execution on processor subgroups. Specific rules are needed if it is ok that only P1 processors execute on P1 region. Following Restrictions: (1) no restrictions on accessing Rread onlyS variables in the region. (2) For a variable mapped to P1 only ON regions including P1 can access it. (3) For "unrestricted" variables, all ON regions that access it must have at least one common subgroup. All processors involved in an ON section have a barrier at the beginning of the section. TASK REGION ON P1 ... ENDON ON P1, P2 ... ENDON ... implicitly on P1, P2, P3 .... ON P2 ... ENDON END REGION TASK REGION DO i=1,n ON P1 ... ENDON ON P1,P2 ... ENDON on everything if there are only P1, P2 ON P2 ... ENDON end do end region Need to work on what happens if the do and task region are reversed. to get the barriers worked out. Issue #1 - Should we support ON (p1,p2) or only ON P1 ... On P1, P2 is typically used to transmit data between P1 and P2. If that is almost always the case, simpler model is sufficient. Issue #2 subroutine CALL A subroutine call is an ON P1 region - uses only this subgroup of processors This needs to spelled out in conjunction with the ON proposal. Issue 3 Nesting Task Regions Dynamic nesting / subdivision can be done through subroutine calls. Straw poll .... 7 - 2 - 9 general direction ON P1, P2 in addition to P1 .... 6 - 2 - 10 This concluded what we had time for. Meeting adjourned ~12:00 Friday. --------------------------------------- Attending the Nov. 95 HPFF Meeting: Robert Babb U. of Denver babb@cs.du.edu Scott Baden UCSD baden@cs.ucsd.edu Bob Boland LANL wrb@lanl.gov Barbara Chapman University of Vienna barbara@vcpc.univie.ac.at Alok Choudhary Syracuse U. choudhar@cat.syr.edu James Cowie Cooperating Systems cowie@cooperate.com Ian Foster ANL foster@mcs.anl.gov Ken Kennedy Rice U./CRPC ken@rice.edu Charles Koelbel Rice U. chk@cs.rice.edu David Loveman Digital loveman@msbcs.enet.dec.com Larry Meadows The Portland Group lfm@pgroup.com Andy Meltzer Cray Research meltzer@cray.com Carol Munroe Thinking Machines munroe@think.com Carl Offner Digital offner@hpc.pko.dec.com J. Ramanujam Louisiana St. Univ. jxr@gate.ee.lsu.edu 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 Yosiki Seo NEC Guy Steele Sun Microsystems guy.steele@east.sun.com Jaspal Subhlok Carnegie Mellon jass@cs.emu.edu Jerry Wagener Oklahoma U.,X3J3 jwagener@cs.uoknor.edu Joel Williamson HP/Convex joelw@mozart.convex.com Hon W Yau NPAC Syracuse hwyay@npac.syr.edu Henry Zongaro IBM Canada zongaro@vnet.ibm.com Mary Zosel LLNL zosel@llnl.gov --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe ---------------------------------------------------------------------------