From owner-hpff Tue Apr 2 05:00:04 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id FAA15989 for hpff-out; Tue, 2 Apr 1996 05:00:04 -0600 (CST) Received: from chenas.inria.fr (chenas.inria.fr [192.134.192.136]) by cs.rice.edu (8.7.1/8.7.1) with SMTP id EAA15960 for ; Tue, 2 Apr 1996 04:59:54 -0600 (CST) Received: from esi.fr (esisun.esi.fr) by chenas.inria.fr (5.65c8d/92.02.29) via EUnet-France id AA27850; Tue, 2 Apr 1996 12:59:47 +0200 (MET) Received: from indy8.esi.fr by esi.fr; Tue, 2 Apr 1996 12:59:20 +0200 From: sm@esi.fr (Serge Meliciani) Received: (from sm@localhost) by indy8.esi.fr (8.7.3/8.7.3) id MAA26704 for hpff@cs.rice.edu; Tue, 2 Apr 1996 12:59:29 +0200 (MDT) Date: Tue, 2 Apr 1996 12:59:29 +0200 (MDT) Message-Id: <199604021059.MAA26704@indy8.esi.fr> To: hpff@cs.rice.edu Reply-To: sm@esi.fr 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. --------------------------------------------------------------------------- add hpff /////////////////////////////////////////////////////////////////////////// Serge MELICIANI Tel: +33 (1) 49 78 28 55 ESI Groupe ESI Fax: +33 (1) 46 87 72 02 Engineering Systems International 20 Rue Saarinen Silic 270 E-mail : sm@esi.fr 94578 Rungis-cedex FRANCE \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ --------------------------------------------------------------------------- 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 Tue Apr 2 10:13:48 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id KAA23997 for hpff-out; Tue, 2 Apr 1996 10:13:48 -0600 (CST) Received: from relay2.eunet.fr (rel2.EUnet.fr [192.134.192.149]) by cs.rice.edu (8.7.1/8.7.1) with SMTP id KAA23988 for ; Tue, 2 Apr 1996 10:13:38 -0600 (CST) From: hl@esi.fr Received: from esi.fr (esisun.esi.fr) by relay2.eunet.fr (5.65c8d/92.02.29) via EUnet-France id AA06136; Tue, 2 Apr 1996 18:13:24 +0200 (MET) Received: from semcapsun2.esi.fr by esi.fr; Tue, 2 Apr 1996 18:12:59 +0200 Received: by semcapsun2.esi.fr; Tue, 2 Apr 96 18:14:32 +0200 Date: Tue, 2 Apr 96 18:14:32 +0200 Message-Id: <9604021614.AA24969@semcapsun2.esi.fr> To: hpff@cs.rice.edu 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. --------------------------------------------------------------------------- add hpff --------------------------------------------------------------------------- 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 Apr 5 18:50:05 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id SAA01666 for hpff-out; Fri, 5 Apr 1996 18:50:05 -0600 (CST) Date: Fri, 5 Apr 1996 18:50:05 -0600 (CST) From: owner-hpff Message-Id: <199604060050.SAA01666@cs.rice.edu> >From: Mary E Zosel Subject: hpff: March 96 HPFF minutes 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. --------------------------------------------------------------------------- High Performance Fortran Forum Meeting March 13-15 Arlington, Texas Record of Action: Mary Zosel Executive Summary There were 21 people from 17 institutions present at the March 96 HPFF meeting. The group 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: Language naming and content. Elimination of explicit mapping of sequential data Amended derived type mapping. Amended commutative intrinsic reduction. Processor sections as distribution targets. Specification of distribution ranges. Proposals still in progress of second reading: On proposal. (15-4-1) Update of inquiry functions. Proposals passing in first reading: Tasking. Policy for extrinsics. SPMD_HPF extrinsic summary (new policy). Update on pointer rules. Elimination of GLOBAL_LB and GLOBAL_UP SORT_UP/SORT_DOWN library functions Invitation for a proposal: Fortran77_Local --- Other items of special note: The question of language name and content was again reviewed by the group of vendors. The new proposal which was adopted by HPFF is that there is one language HPF (version 2.0). There will be a chapter addressing portable/efficient features - which will outline those features previously called the kernel. Most of the new features, and a few of the existing HPF 1.1 features that have not yet been implemented (most notably explicit remapping via REDISTRIBUTE and REALIGN) will be in an Annex of Approved Language Extensions. The hope is that it is practical for all vendors to have a full implementation of HPF (2.0) within 18 months of approval. The definition of the original HPF subset will remain in an annex. A policy will be defined for proposing extrinsic interfaces which HPFF recognizes, and certifies as conforming to HPF expectations for extrinsics. The HPF_SPMD extrinsic being developed by PGI/CRI is expected to fall in this category. These will be distinct from the HPF_LOCAL and HPF_SERIAL extrinsics, in that HPFF takes responsibility of the definition (and cci's) for these two extrinsics. There is an HPF Workshop planned in conjunction with HPCN 96 in April. The next HPFF meeting is scheduled for May 1-3 (Arlington). An additional HPF meeting has been added for San Francisco June 26-28. The final HPFF meeting is September 18-20 (again San Francisco), with the expectation that there will be a public comment period between July and September. End of Executive Summary ____________________________ Detailed Record of Action Wednesday afternoon Mar. 13, 96 - HPFF Subgroup Meetings The HPFF Meeting convened Thursday AM, March 14 chaired by Ken Kennedy of Rice University. The status of proposals expected for processing at the meeting was reviewed: 1st 2nd group E format Jan Mar SPMD-HPF-ext. Jan Mar am group D dist ranges Jan Mar hz seq. nonmap Jan Mar cm subsets Jan Mar group C on Jan Mar reduc - simple partly done Mar rs reduct - user def. Jan Mar task Mar May inq updates Jan Mar rs whoami needed DONE - (C) async lm (C) gen transpose rs (D) derived typ gls (D) shadow width co (D) irreg map (E) kernel am (E) interop am (E) local_global func cm (E) explicit interf ~ Technical work began with the second reading of the Distributed Range proposal by Henry Zongaro. (details of this proposal were on a 1-page written proposal which is unfortunately not available here) There are some details to sort out: - RANGE only has effect where object to which it applies is accessible. So remapping of an actual for a call does not have to match to another subprogram. - If pointer changes are approved, RANGE is no longer needed for pointers that are not DYNAMIC. - Need to integrate with 3.10 to clearly describe when a user is justified in giving RANGE assertion. ... There were questions about why processor arrangement isn't allowed in the list of RANGE? Similarly maybe ALIGN. Carl Offner commented that distribution information is key information for the compiler while stride, etc. is not. ---- Proposal: (1) For generalized BLOCK distribution, use the GEN_BLOCK -- - it is required for the RANGE proposal even if it was not needed for the original GEN_BLOCK proposal. - Friendly spelling amendment to Generalized Block - strawpoll 21 - 0 -0 Back to Range Proposal... Proposal Passes - 11 - 1 - 4 This proposal is for HPF approved extensions ================= Carol Munroe - Second reading: Eliminating explicit mapping of sequential variables from HPF 2. Currently defined for sequential 1D covers - hard to explain - complications in compiler - and probably minimal benefit for users who are porting their code. Second reading vote: 15 - 0 - 1 ============== Larry Meadows - Vendor Language Organization Proposal - Second Reading Naming - HPF (V 2.0) is the only language Content of language - - HPF 1.2 with changes - hope is 12-18 month timeframe for full implementations Document - HPF 1.2 + Annexes + Approved Extensions - minus a few features. HPF subset will remain as an annex in 2.0. It won't be called a language - just a set of features on record. HPF kernel becomes a chapter on portably efficient HPF programming. New Features proposed for inclusion in HPF 2. - Interfaces required if remapping. - Intrinsic, commutative reductions. - Pointers cannot be mapped or point to mapped objects. - No aggregate covers. Approved Extensions from HPF 1.2 - Dynamic and friends from HPF 1.1 - HPF_SERIAL, HPF_LOCAL - Pointer Mapping - All other new features passed in second reading. The motivation is that this is the language everyone (vendors) agrees on. Mary objected to removing mapping of pointer objects from the base HPF because this removes the only remaining support for irregular data structures. This should be proposed as a subject for public comment. If there is a large comment that says some feature in the approved extensions list is important it should be considered for including in v. 2.0. Discussion of why continuing the subset. (Primarily to document what has been a target of several implementations.) Clarification - the existing document makes reference in other chapters to what is in the subset. That explicit text should be dropped. Separated to two proposals ---- (with some voting vendor members leaving the room to avoid being on record for the vote). Document organization - naming, annexes and approved extensions - Vote on structure - 14 - 0 - 1. Vote on the content of the parts - 13 - 1 - 0. BREAK The vendor slide was reviewed. Despite a recent announcement of a joint project with PGI, CRI still doesn't want to be listed as Announced Product. SofTech was removed.. Ken will contact Motorola. HP/Convex changed to be just HP. Question about MasPar --- and Lahey what about Transtech? - using the PGI product (Larry will check.) ------------ Second Reading of the Processor Subsets, presented by Henry. dist-target is proc-name [(section-subscript- list)] or * proc-name [(section-subscript-triplet-list)] or * Constraint: In a section-subscript-triplet-list, the number of section-subscript-triplets must equal the rank of the processor-name - subscript - subscript-triplet - no vector-subscript Allows distribution to a subset of processors. !HPF$ PROCESSORS P(10,10) REAL A(100,100) !HPF$ Distribute A(BLOCK,BLOCK) ONTO P(2:6,3:7) vote - 12 - 0 - 4 passed for inclusion in the approved extensions. ================================= Derived Type component distribution clarification presented by Piyush Mehrotra. Consider the following example: type dt integer f(1000) !HPF$ distribute (block), dynamic:: f end dt type(dt), target :: s(1000( integer, pointer :: p(:) do I= 1,1000,2 !HPF$ redistribute (s(i)% f(cyclic)) end do p => s(1:1000)% f(6) Problem: the redistribute of f causes elements of s to have varying sizes. - the pointer p points to an array with an irregular mapping. Proposal: A component of a derived type can have the dynamic attribute only if it also has the pointer attribute. (The above pointer assignment is illegal in F90). Question - should this be first or second reading? 2nd reading amendment to derived type - 15 - 0 1 ===== Group D cci 11, 29, 47 - pointers. HPF 1.1. has contradictory statements about pointers. Proposal: 1st reading .... - Retain text in section 3.6 page 38 line 33 which states that pointers may appear as an alignee or a distributee - takes effect on allocation - delete constraints 3 page 27 line 5 - distribute cannot have pointer attribute (also page 186 line 48) - Add text: If a pointer (target) is explicitly mapped and is associated with a target using a pointer assignment, the mapping of the target object must MATCH the declared mapping of the pointer. (Where MATCH needs to be defined.) Override - then this applies only on allocation If a pointer is declared to be DYNAMIC, it can point to any non-sequential object. The RANGE directive can be used to restrict the mappings of the target object or the allocated array. A pointer declared sequential using the SEQUENCE attribute can point to sequential objects only. A pointer which is not explicitly mapped or declared sequential can point to a target which is not explicitly mapped or declared sequential. Discussion of DYNAMIC - is this an appropriate overloading of DYNAMIC? Can a dynamic pointer point to a static objects? PM - saying this is illegal is too restrictive --- but user might think that because pointer is dynamic it can be redistributed ... but other text should restrict this. example A(100), B(100) !HPF$ distribute (cyclic):: A,B pointer, dynamic :: p(;) p => A p=> B Straw poll on this for a first reading - clearly not ready for second reading 19 - 0 - 0. CCI 50: Legal F90! program p integer a(100), b(10,10) !HPF$ DISTRIBUTE a(block), b((block,block) call sub1 (a,b,b) contains subroutine sub1(x1,x2,x3) integer x1(100), x2(10,10), x3(10,10) !HPF$ DISTRIBUTE x1 *(cyclic) !HPF$ DISTRIBUTE x2 *(block,cyclic) !HPF$ DISTRIBUTE x3 *(cyclic,block) print *, x2, x3 .... .... = a(i) call sub2(a) end subroutine sub2 (x) integer x(100) !HPF$ DISTRIBUTE x *(*) end sub2 end Not HPF conforming. page 46 line 17 - actual arg will be remapped to conform to the interface _ page 54 line 14 - if array accessible through 2 or more paths cannot be remapped. Proposal: (to make the above example legal) Change text page 46 line 17 to delete reference to remapping of actual arguments; [need better words] ... and a remapping of the actual argument is necessary, the call should proceed as if the data was copied to a temporary variable mapped to match the mapping of the dummy argument. Rational (to be added): sometime actual is accessible through say host association, so cannot remap actual. ===== Discussion - is a better solution just to say it illegal. Ken - points out that the places to worry are where a program is legal in F90 and one changes to HPF it is illegal - with no fix ... that doesn't apply here. straw poll on fix (vs saying illegal) - aliasing 0 - 14 - 6 ==== second part of the same problem (aliasing involving pointers) program p integer, pointer :: a(;) !HPF$ DISTRIBUTE a(block) allocate a(100) call sub(a) contains subroutine sub(x) integer, pointer :: x(:) !HPF$ DISTRIBUTE x *(cyclic) x(i) = ... a(i) = ... end sub end p problem: legal F90 => a and x point to same data with different distribution: Proposal: add restriction [better words] to the pointer proposal discussed earlier The mapping of a dummy argument with a pointer attribute has to match the mapping of the actual argument if the latter is accessible inside the procedure through another path. strawpoll : 18 - 0 - 3 ================= Rob Schreiber presented group C proposals Reductions (simple) - summary of written text. Syntax: !hpf$ independent, new(y), reduction (x) do I = 1,n y = f(i) x = x + y end do Full list of constraints is in the written version of the proposal, but they include specification that: whole object is the reduction variable reduction must appear on outermost independent with no new clause for reduction variable. The change (to the original proposal) is putting reduction on the independent directive associated with the loop. Note - this has been voted for inclusion in the 2.0 language. vote - 14 - 1 - 1 passed modified simple reduction. ========= More general reductions 1. Intrinsics; (two flavors) - commutative only - concatenation and MATMUL concatenate isn't interesting in Fortran because of the fixed length. but MATMUL is interesting. 2. Defined ops and derived types (BIGNUMS, SPARSE MATRICES). !hpf$ independent, reduction (a = expr1) do I = 1,n a = a .op. expr2 a(2:4) = a(2:4) .op. expr3 enddo Rules: - expr1 and expr2 conformable with a. expr3 conformable with a(2:4) - (a .op. b) .op. c == a.op. (b.op.c) - .op. PURE; may not reference a global whose value changes in the loop. FIRST vote: Add MATMUL to approved things for reduction - (in the approved extensions). Vote - 10 - 1 - 5 fails. Second vote: Add defined ops and derived types for reductions - not powerful enough for matmul - doesn't allow the shape issues involved in matmul. Vote - 10 - 2 - 4 motion fails (after some vote changing). Chuck doesn't want to lose the text ... proposal is to make this a Rice CRPC tech report. .... Out of core I/O is another similar proposal where we might want to preserve the text. ========== Break for lunch Group started again at 1:10 Rob Task Proposal !hpf$ tasking, new(i) do I = 1,n !hpf$ on home (proc(1:i)) ... !hpf$ on home (proc (9:16) ... enddo !hpf$ end tasking processor disjoint execution tasks - - there must be no interference .... e.g. no I/O, no stepping on same variable - NEW variables cannot cause interference of synchronization This form of tasking is like an independent assertion for a group of statements. The example gives 2xn tasks --- n trips through the loop that has 2 tasks .... Discussion of whether the loop in the example could be labeled independent. This proposal says that if you use !tasking ... then whenever you find !HPF ON home, you can potentially do it in parallel. Possible model - in simple send receive world with owner computes - with no shared memory and no active messages .... could ignore these directives. Every processor can execute - and since there is no "interference" there just won't be anything to do. For shared memory or one-sided communications model - barriers are needed at the beginning and end of task regions for any tasks that have possible interference. What about the DO statement itself? It does not (and cannot ) appear in an ON that doesn't also enclose the end do. No barrier is needed. But there are additional issues involving control flow, subroutine calls, etc. This is subtle way to do tasking --- but it is nice in that it provides information that would be useful to the compiler. Andy asks if people would vote for some form of tasking 12 - 3 - 6 First reading 10 - 3 - 8.... Jaspal: think we can't finish by the next meeting. Will we need another meeting? Subgroup C to meet to talk about the issues associated with tasking. ========== Mary presented group E cci. cci 45/46 still in progress. cci 48 ok as answered. cci 51/54/new-lfm ... all variants on questions about global_lb/ub proposal: first reading remove global_ub/lb from HPF2 Motivation: global_shape etc. do the same thing. Henry believes he asked for these functions and no longer needs them. As a formal 1st reading, we will have time to reconsider. Vote: 17 - 0 - 1 cci 53 - Whaley F77_local The workaround is to call HPF_LOCAL and it can call F77 The feature proposed isn't sufficient. An F77_LOCAL definition makes practical sense .... ( Invitation For Proposal --- but timing problem.) discussion of the need for F77 local vendors think 4-1 that F77 interface would be important. Ken thinks such a proposal would be good PR for us. ------------- What do we do about interoperability? Nothing new from WG5. X3J3 may be going in another direction. For direction - can ask for specific guidance in the public comment For current guidance - how many think we should go ahead even if X3J3 goes somewhere else: 8 - 3 - 5 ------------ Document outline Propose we have two syntax annexes - one for HPF and one for HPF with approved extensions. Document formatting tool .... Ken (Chuck) will buy copies of FRAME for editors that don't have one. Check versions. ------------ The group split up for continued subgroup meetings. =================== FRIDAY - MORNING Discussion of meetings and the need for an additional meeting was discussed. May 1-3 - Arlington End of June for 26-28 --- San Francisco for a new meeting Sept 18-20 also San Francisco ------------- Piyush presented Pointers revisited ... Static explicit declaration take effect on allocations on assignment target mapping has to match - current one for dynamic target (note a definition for match is still needed) sequential pointer can only point to sequential object not explicitly mapped and not sequential can point to target which is not explicitly mapped and not sequential For dynamic pointer - 2 options: OPTION 1 !HPF$ dynamic :: p,q can point to anything - can be used to redistribute allocate (p) range can be used to limit target !HPF$ redistribute p(block) p => a case 1: A is not a pointer or not a dynamic pointer - not allowed !HPF$ redistribute (p(block)) case 2: A is a dynamic ptr, p point to new object; A loses association OPTION 2 !HPF$ DISTRIBUTE *::P,Q transcriptive distribution for p,q - can point to anything-can't be used in redistribute !HPF$ DYNAMIC :: R,S can point to anything dynamic ALLOCATE (P) has no dist - use range with one choice q => A q inherits dist of A allocate (r) - or use a range one choice !HPF$ redistribute (r(block)) s=> A case 1 A is not a pointer - not allowed - case 2 A is ptr - a looses assoc ! HPF$ redistribute (s(block) Rob points out a third option dynamic can only point to dynamic not explicitly mapped pointer can point to anything not but dynamic whatever you say about the pointer must be true about the target mapping of pointer has to be less specific than the target option 0 - no remap in pointers 7 - 6 - 5 option 1 - dynamic point to anything option 2 - use transcriptive syntax (creative new use of old syntax) option 3 - not explicitly mapped can pt to anything but dyn/seq 11 - 1 - 7 bottom line - group D - will go away and think more about option 3 =========== Andy Meltzer presented a proposal for an extrinsic called HPF_SPMD. (we just finished LPF ... now something high performance :-) Predicted Objections: 1. There are too many new directives / intriniscs for one proposal In its stripped down form - the only new directives are PE_PRIVATE and SERIAL/END SERIAL . 2. There are too many details to nail down and many new concepts Yes there are many new details and concepts, but there is a 4 year old implementation of this that has been successful 3. Opens another can of CCI worms See above - but yes there will be more CCI 4. It is a big chunk to add stripped down it isn't so big - but a standard spelling for sync primitives would be nice 5. Can users understand yet another model? yes - also this will bring a set of new users to HPF and provide a natural task model 6. Cray is doing it anyway, why adopt it useful to have a standard way of doing this in approved extensions. Also without something for its higher performance customers Cray will have difficulty supporting HPF at all. ---------- Introduction SPMD_HPF is an extrinsic environment based upon HPF_LOCAL with all of the HPF 2.0 built on top. SPMD_HPF is a multi-threaded language like HPF_LOCAL. Allows seamless use of low-level paradigms - message passing, get/put, explicit syn. Additional rules redefining rules defined relationship between HPF_LOCAL and HPF 2.0 things have been added. WHY SPMD_HPF? Not applicable to all platforms, but for platforms that can support it - allows greater flexibility and higher performance Multi-threaded model allows easier migration path for MP users - HPF is no longer all or nothing Extrinsic environment allows will defined interface to standard HPF. Many of these features are currently successfully in use. NEW IN SPMD_HPF Data default is that of HPF_LOCAL, called private. The interaction between private and explicitly mapped data is defined. Possibly Parallel inquiry intrinsics added (IN_PARRALLEL, IN_INDEPENDENT). Serial regions are added (SERIAL/END SERIAL). Explicitly synchronization primitives are define for addition. Assorted other features are suggested: parallelonly, serial_only, parallel_and_serial pe_resident, pe_private, symetric, geometry Data Mapping No changes from HPF 2.0 features all data distribution formats are available. Data defaults to private (the default behavior of HPF_LOCAL). Input and Output I/O behaves like HPF_LOCAL I/O HPF calling HPF_SPMD can't pass functions question about pointers if dummy is explicitly mapped data - same as hpf if dummy is private - same as hpf_local Subprogram Interface Subprogram interface behave exactly like hpf2 for explicitly mapped data. Subprogram interface behave exactly HPF_LOCAL for private data. The interaction between private and explicitly mapped data is defined. Array Syntax Array syntax with all private data acts like it does in HPF_LOCAL. Array syntax with explicitly mapped data acts like it does in HPF 2 all processors must cooperate. Mixed private and explicitly mapped data is defined HPF_SPMD - with a list of rules given in the document.. Serial Regions In a multi-threaded environment it is useful to be able to start single-threaded section, operating on one processor. Serial / End Serial are used for this. Synchronization Primitives: Locks (set, wait, clear) critical sections events (test, set,wait, clear) barriers (test, set,wait) To cover some issues that are not spelled out or not clear in the documents: Cooperative subprograms are subprograms that require all tasks to participate in. A subprogram is cooperative if: it calls the HPF_library it contains a serial directive it contains a symmetric directive or barrier it contains an independent loop it contains an array assignment to explicitly mapped data it declares mapped data or remaps data it makes a subprogram that does any of the above All of these conditions may result in the insertion of barriers that all tasks must encounter. All processors must participate in the execution of cooperative subprograms (exactly like HPF) or they may be invoked from a SERIAL region or from with in an independent loop so if (my_proc() .eq.5) call func() ! not cooperative endif Explicitly Mapped Data Explicitly mapped data should not be modified unless it is in an INDEPENDENT, SERIAL, array syntax expression, or it is explicitly protected by a user mechanisms. This is the same as HPF FORALL restriction - It is illegal for two tasks to update the same storage location for the same statement. REAL A(10000) !HPF$ DISTRIBUTE A(BLOCK) ... A(3) = 6 ! illegal A (my_proc()) = 5 ! ok if (my_proc().eq. 0) A(3) = 6 ! ok DO I = 1,10 A(I) - 5 ! illegal, ok if independent ENDDO -------- INDEPENDENT and DO With no independent, a do loop executes individually on every processor DO I=1,n executes n iterations per processor. This is intended for PRIVATE data. (like HPF_LOCAL) with INDEPENDENT, a do loop distributes its iterations among the processors DO I-1,n executes n iterations total (like HPF) REAL A(10000) DIST A(BLOCK) INDEPENDENT DO I=1,n A(I) = I*2 !ok j = j+1 !ok private or explicitly mapped END do Loop index must be private Discussion ---- should there be some other term rather than INDEPENDENT for this? The subcommittee considered the following questions: - should HPF_SPMD accept all of HPF since the kernel is gone? 4 - 0 - 0 - should the restrictions on calling HPF_SPMD form HPF be relaxed for pointers to allow association with INOUT or OUT, but no dummies of type pointer 1 - 0 - 3 - allow all synchronization flavors - yes - geometry accepted? 1 - 2- 1 - parallel-only, serial_only, parallel-and-serial 3 - 0 - 1 - symmetric 3 - 0 - 1 - change independent name ======== Ken began the discussion of the SPMD proposal with procedural comments: we want to encourage extrinsics and we could endorse ones that we think conform to the rules for HPF extrinsics. Chuck suggested that proposed extrinisics that we reference should come from an organization of some kind (rather than one person's pet). HPF should certify the interface and can include a summary - that has a responsibility on both sides (e.g. extrinsic maintainer doesn't change the details we advertise). But this summary must be approved by us, and it would be HPFF right to decide who meets criteria. The general idea is: "Here's a set of rules ---- you can submit ---- and we will look at it." Subgroup E will formalize a set of the rules. This discussion is considered the first reading of this proposed new extrinsic policy. Some possible criteria are Significant new functionality Some existing practice Straw Poll ... 17 - 0 - 1 about the approach for extrinsics. Straw poll - How many believe the SPMD proposal generally meets this: 13 -1 - 3. We will try for 2nd reading of this policy at the May meeting. BREAK Carol Munroe presented the first reading of a proposal for new Sort Library functions. Motivation: Grade_up/down are flexible routines that produce index arrays for arbitrary sorts. The problem is that the simplest sorts are slowed down by this. It requires extra storage for the permutation and maybe copy of the data etc. Some sorts can be done in place much faster. Propose two direct sort functions for the library: SORT_UP SORT_DOWN result1 = SORT_UP(Array1) result2 = SORT_UP(array2, DIM=1) where result1 might be the same as array1 alternate version with the key sort_up (ARRAY [,KEY] [,DIM]) If no Key is supplied, data in Array would be sorted directly. The need for explicit interfaces for HPF_LIBRARY prohibits arrays of arbitrary user-defined types. pros (for Key) - somewhat greater generality - possibly speed-up of a single sort-by-key - Avoiding need for an extra user array cons - sort-by-key can be done effectively using grade_up/down - single sort by key is probably less common Overall proposal - straw poll ---- sort/up/down in library 14 - 0 - 2 (first reading vote) straw poll - optional dim argument 13 - 2 - 2 straw poll - optional key argument 0 - 11 - 6 ---------------------------- TASK PROPOSAL ---- One more time! Presented by Chuck. Goals _ sequential model of semantics, simple, powerful, efficiently implementable; cures bad breath, tastes as good as apple pie ... !HPF$ TASKING region Tasks delimited as ON blocks Key properties ON regions are all RESIDENT (i.e. all reference local to the processor set) If processor sets are disjoint, then the ON blocks do not interfere (i.e. are INDEPENDENT) Standard semantics everywhere else (i.e. dependencies may serialize overlapping tasks All processors must follow same control flow outside of ON blocks (this may be redundant) Strong advice to implements - replicate scalars outside ON regions! e.g. if you have a do-loop index - replicate it ... Example (with a fancy diagram to indicate calculations with time) !HPF TASKING DO I - 1,N !HPF ON HOME (PROC(1:2)) BEGIN CALL READ_IMAGE(A) !HPF$ END B=A !HPF$ ON HOME (PROC(3:6)) BEGIN CALL ROW_FFT(B) !HPF$ END C=B !HPF$ ON HOME(PROC(7:8)) BEGIN CALL WRITE_IMAGE(C) !HPF$ END END DO !HPF$ END TASKING Implementation Mechanism 1 (Message Passing) Insight: You don't need one-sided communication between tasks So: All processors have their own copy of scalars All processors execute the same code outside ON blocks Scalar = Scalar : Replicate the computation Scalar = Dist_array(i) : Broadcast the value Dist_array(i) = Dist_array(j) : Send/recv pair between owners Conditionals, loops, etc. : Evaluate conditions as scalars Processors enter ON blocks if and only if they are part of the processors set RESIDENT ensures that send/recv suffices to implement each ON block Implementation Mechanism II (Shared Memory) Insight: You can use the ON clauses for synchronization So All processors have their own copy of scalars All processors execute the same code outside of ON blocks Replicate computations on replicated scalars Assigning from or to mapped data requires sync of RHS and LHS owners On clauses synchronize processor in the HOME clause Barrier on entry ensures that data written by other ON blocks is up-to-date Barrier on exit ensures that this ON block's data gets written before it is read We speculate that compilers can optimize a lot in this area After the discussion on Thursday - the subgroup had been asked to list issues associated with tasking. Following are a number of things that the subgroup considered. Questions What does TASKING tell us? Resident and restricted interference Is NEW necessary? We don't think so, but may be needed to avoid blocking. Can the number of processors in and ON block change at runtime? Yes, needed for multi-block. Can ON blocks do I/O? Yes but 2 non-overlapping ON's can't access the same file. Are there dark corners in procedure calls and nested TASKING regions? Probably but we ran out of time Other Suggestions Message Passing - HPF binding for MPI - too big for now. Message Passing - parallel sections have REMOTE reference. A-> B to send A <-B to receive But how do you know which sends and receives match? HPF_SPMD VOTE -- 15 - 0 - 2 first reading of a TASK proposal is finally on the books! ============= The LPF report was submitted by Andy Meltzer - excerpts below ... LPF (a) LPF rules of order* 1. All proposals require a unanimous vote (0) to pass. B. All proposals require a unanimous vote (o) to reject. III. No proposals may be submitted. iv. Any inane comment is automatically considered a proposal. =>All proposals are simultaneously approved and rejected. =>LPF is all possible combinations of proposed features. =>LPF is still smaller than HPF. * thanks to PH. HPF has been trying to get TASKS completed. LPF has been working hard on getting CHORES done. !LPF$ TAKE_OUT_THE_TRASH !LPF$ GO_GROCERY_SHOPPING !LPF$ MOW_LAWN !LPF$ SHOVEL_DRIVEWAY and finally the odious !LPF$ GO_TO_HPF_MEETING The LPF committee has done a study of a couple of modern languages HPF LATIN Dead language? Dead language. Only religious fanatics use it. Only religious fanatics use it. Hasn't changed in hours. Hasn't changed in centuries. Has users? Many users all over the world. Derived from many unsuc. languages. Basis for many successful other langs. Getting rid of lang. is religious issue. ditto Can only learn lang. from an academic. ditto HPF 2.0 is almost ready. Latin has lasted thousands of years. Basis for a lot of romantic language. Basis for Romance languages. Many of you are wondering why there won't be an officially chaired LPF meeting next time: - SGI doesn't support LPF? Nah - LPF is alive and well at SGI, like everywhere else. - LPF is done? Can't finish it, someone may try to use it. - HPF is LPF? That's never stopped us before. - A new LPF designer is coming on board. His mother won't be happy if I'm not there. ---------------- end of LPF report for Mar. 96 ------------ ---------------- As of the end of the meeting - the new status of proposals is: 1st 2nd group E SPMD-HPF-ext. Mar May am/lfm Rules for extrinsics Mar May Elimination of GLOBAL_LB/UB Mar May m New Sort functions Mar May cm group D dark corners of ptr Mar. May group C on Jan May ck task Mar May inq updates Jan May rs F77_LOCAL needed DONE - (C) async ext lm (C) gen transpose ext rs (D) reduc - simple 2 rs (D) reduc - simple amended 2 rs (D) derived typ ext gls (D) derived type amended ext (D) shadow width ext co (D) irreg map ext ? (D)dist ranges ext hz (D) seq. nonmap 2 cm (D) subsets ext pm (E)name/etc. (E) kernel (chapter) am (E) interop ext am (E) local_global func ? cm (E) explicit interf 2 ~ ------------- The next HPFF meeting is scheduled for May 1-3 (Arlington). An additional HPF meeting has been added for San Francisco June 26-28. The final HPFF meeting is September 18-20 (again San Francisco), with the expectation that there will be a public comment period between July and September. ------------------------------------------------------------- March Attendance: Siegfried Benkner Univ. of Vienna sigi@par.univie.ac.at Jay Boisseau SDSC boisseau@sdsc.edu Bob Boland LANL wrb@lanl.gov Alok Choudhary Syracuse U. choudhar@cat.syr.edu Paul Havlak U. of Maryland havlak@cs.umd.edu 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 Meadow The Portland Group lfm@pgroup.com Piyush Mehrotra ICASE pm@icase.edu 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@ee.lsu.edu Guy Robinson University of Vienna robinson@vcpc.univie.ac.at P. Sadayappan Ohio State University saday@cis.ohio-state.edu Rob Schreiber HP schreibr@hplpp3.hpl.hp.com Jaspal Subhlok Carnegie Mellon jass@cs.cmu.edu Joel Williamson HP joelw@rsn.hp.com Hon W. Yau NPAC honyou@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 --------------------------------------------------------------------------- From owner-hpff Mon Apr 8 09:25:51 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id JAA22302 for hpff-out; Mon, 8 Apr 1996 09:25:51 -0500 (CDT) Received: from palisades.cs.dartmouth.edu (palisades.cs.dartmouth.edu [129.170.200.29]) by cs.rice.edu (8.7.1/8.7.1) with ESMTP id JAA22296 for ; Mon, 8 Apr 1996 09:25:47 -0500 (CDT) Received: by palisades.cs.dartmouth.edu (8.7.4/4.2) id KAA27396; Mon, 8 Apr 1996 10:25:45 -0400 (EDT) Date: Mon, 8 Apr 1996 10:25:45 -0400 (EDT) Message-Id: <199604081425.KAA27396@palisades.cs.dartmouth.edu> From: David Kotz To: hpff@cs.rice.edu Subject: hpff: IOPADS '96: I/O in Parallel and Distributed Systems 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. --------------------------------------------------------------------------- [Forgive me if you receive multiple copies -- multiple mailing lists] Reminder: ==> Hotel registration deadline is April 19! ==> Conference registration deadline is April 26! ==> Registration information at http://www.acm.org/conferences/fcrc/ 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. ==> Hotel registration deadline is April 19, ==> Conference registration deadline is April 29! ==> Registration information at http://www.acm.org/conferences/fcrc/ --------------------------------------------------------------------------- FINAL PROGRAM for May 26, 1996 7:00- 8:00 Breakfast 8:00- 9:00 FCRC Plenary Speaker: Randy Katz, UC Berkeley "The Case for Wireless Overlay Networks" FINAL 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 Sivan Toledo and Fred G. Gustavson, 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 Scalable Message Passing in Panda Y. Chen, M. Winslett, K. E. 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 Mon Apr 22 02:22:30 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id CAA01264 for hpff-out; Mon, 22 Apr 1996 02:22:30 -0500 (CDT) Received: from CERNVM.CERN.CH (crnvmb.cern.ch [137.138.26.60]) by cs.rice.edu (8.7.1/8.7.1) with SMTP id CAA01259 for ; Mon, 22 Apr 1996 02:22:26 -0500 (CDT) Message-Id: <199604220722.CAA01259@cs.rice.edu> Received: from CERNVM.CERN.CH by CERNVM.CERN.CH (IBM VM SMTP V2R2) with BSMTP id 9705; Mon, 22 Apr 96 09:21:19 SET Received: from CERNVM.CERN.CH (NJE origin METCALF@CERNVM) by CERNVM.CERN.CH (LMail V1.2a/1.8a) with BSMTP id 4189; Mon, 22 Apr 1996 09:21:19 +0200 Date: Mon, 22 Apr 96 09:21:09 SET From: Michael Metcalf Subject: hpff: First book on Fortran 95 To: hpff@cs.rice.edu 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. --------------------------------------------------------------------------- Announcing the first book on Fortran 95. ---------------------------------------- "Fortran 90/95 Explained" by Michael Metcalf and John Reid, Oxford University Press, Oxford and New York, 1996, ISBN 0 19 851888 9 (about $US33 or 16.95 pounds sterling). Fortran 95 is a revision of the ISO Fortran 90 standard based on the interpretations that have been requested following its implementation and use. In addition, new features to keep ISO Fortran aligned with High Performance Fortran have been added, along with a small number of other improvements. It is now in its final stages of formal approval. This volume represents a thorough revision of "Fortran 90 Explained". It includes more detailed explanations of many features with more examples (giving about 18 additional pages), as well as new appendices (on avoiding Fortran 77 extensions and an extended pointer example, a further 12 pages). Also, it incorporates all the interpretations, and has a completely new chapter on Fortran 95 (18 pages). It is a complete and authoritive description of Fortran 90/95. Table of Contents: 1. Whither Fortran? . . . . . . . . . . 1 2. Language elements . . . . . . . . . 13 3. Expressions and assignments . . . . 41 4. Control statements . . . . . . . . 65 5. Program units and procedures . . . 81 6. Array features . . . . . . . . . . 117 7. Specification statements . . . . . 143 8. Intrinsic procedures . . . . . . . 173 9. Data transfer . . . . . . . . . . . 197 10. Operations on external files . . . 229 11. Fortran 95 . . . . . . . . . . . . 241 12. Other features . . . . . . . . . . 259 Appendix A. Intrinsic procedures . . . 283 Appendix B. Fortran 90/95 statements 289 Appendix C. Obsolescent features . . . 293 Appendix D. Avoiding Fortran 77 extensions 299 Appendix E. Pointer example . . . . . 303 Appendix F. Fortran terms . . . . . . 311 Appendix G. Solutions to exercises . . 323 Index . . . . . . . . . . . . . . . . . 343 Michael Metcalf works at CERN, Geneva. He is the author of a range of publications, including the books Effective Fortran 77 (Oxford University Press) and Fortran Optimization (Academic Press). He was Editor of the Fortran 90 standard. John Reid works for the Rutherford Appleton Laboratory and is well known as a numerical analyst; he is a co-author of Direct Methods for Sparse Matrices (Oxford University Press). He served as Secretary of X3J3 and played a leading role in the development of Fortran 90 and 95. Ordering information (publication in the US is delayed until June): 1) N. America: Order Department, Monday-Friday, 8:15am-5:00pm (EST) Phone: 1-800-451-7556 Fax: 1-919-677-1303 Post: Order Department Oxford University Press 2001 Evans Road Cary, NC 27513 E-mail: orders@oup-usa.org WWW: http://www.oup-usa.org/ 2) UK: send order and payment to: CWO Department, OUP, FREEPOST NH 4051, Corby, Northants NN18 9BR - no stamp required phone: with a credit card, the 24-hour credit card hotline is +44 (0)1536 454534 Postage and packing for UK orders: - under #20 - add #2.06, over #20 - add #3.53, over #50 - add #4.70. WWW: http://www.oup.co.uk/ 3) Eire, Europe, and the rest of the world, send order and payment to: CWO Dept, OUP, Saxon Way West, Corby, Northants NN18 9ES, UK fax: credit card sales: +44 1536 746337 Postage and packing for non-UK orders: add 10% of the total price of the books. --------------------------------------------------------------------------- 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 Tue Apr 23 07:27:50 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id HAA18247 for hpff-out; Tue, 23 Apr 1996 07:27:50 -0500 (CDT) Date: Tue, 23 Apr 1996 07:27:50 -0500 (CDT) Message-Id: <199604231227.HAA18247@cs.rice.edu> From: Michael Metcalf Subject: hpff: Fortran 90 Information (April) 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. --------------------------------------------------------------------------- ******************************************************************** * Still time: the Fortran Futures Conference near London Heathrow * * airport on 25/26 April: * * http://www.nag.co.uk/other/ff96.html * ******************************************************************** FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF F F F Is F the language that will be the true stepping stone to HPF and F F at the same time replace Basic, Pascal and C for teaching purposes? F F See http://www.imagine1.com/imagine1, and watch this space! F F F FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF ********************************************************************* * Information file, on compilers, tools, books, courses, tutorials * * and the standard for the Fortran languge. * ********************************************************************* Note: additional information on Fortran products is availble on WWW with the URL http://www.fortran.com/fortran. WHERE CAN I OBTAIN A FORTRAN 90 COMPILER? Absoft is about to beta-test a version of Cray's CF90 for the Power Macintosh. Windows NT and 95 versions will follow (fortran@absoft.com or http://www.absoft.com/). ACE of Holland provides f90 and HPF for Parsytec PowerPC-based machines (marco@ace.nl, http://www.ace.nl/). Apogee's compiler is highly optimized for SPARC architectures (info@apogee.com). Used on the Meiko CS-2HA. Cray Research has a fully-optimizing, native compiler, CF90, that is being marketed by them, and by Visual Numerics for workstations, starting with Suns (craysoft@cray.com or http://www.cray.com/PUBLIC/product-info/craysoft/Fortran_90.html). Digital has DEC Fortran 90, a native, optimizing compiler for Digital UNIX on Alpha systems (with HPF), and for OpenVMS Alpha (without HPF). A Windows NT (Alpha) version is likely to follow (fortran90@digital.com or http://www.digital.com/info/hpc/f90). EPC has optimizing, native compilers for x86, Sun, RS/6000, SGI and MIPS (info@epc.com or support@epc.co.uk). HPF is also available. FORTNER Research (formerly Laguage Systems Corp) expects to deliver f90 for Macintoshes at some unspecified date. Fujitsu is marketing a native Fortran 90 Workbench for Solaris 1.1 and 2.x. Contact Unicomp (walt@fortran.com) or Fujitsu (info@ossi.com). HP has stated its intention to collaborate with EPC to produce a compiler for HP and Convex platforms, timescale not yet announced. IBM has been shipping its optimizing, native compiler for the RS/6000, xlf Version 3, as of 31 December, 1993. HPF will be available in April. See http://www.software.ibm.com/ap/fortran. Lahey has been shipping a native LF90 compiler for DOS since 29 August, 1994 (sales@lahey.com or http://www.lahey.com). It is particularly well optimized on the Pentium. Also on offer is elf90, a subset language that does not allow storage association and is very cheap. Microsoft has released its Fortran Powerstation V4.0 that includes f90 for Windows NT 3.5 and Windows 95 (fortran@microsoft.com or http://www.microsoft.com/fortran). It is a 32-bit compiler with optimizations for Pentium and 486. Microway NDP Fortran 90 for 386/486 and Pentium is available (nina@microway.com). NAG provides a compiler for most unix platforms, VMS and PCs (including Linux). This was the first f90 compiler, in 1991. An optimizing version produced in collaboration with ACE (see above) will be released in the first quarter of 1996. FORESYS 90, to convert from F77 source to f90, is available too (infodesk@nag.com, infodesk@nag.co.uk or http://www.nag.co.uk/). NA Software supplies Fortran 90 Plus on PCs (including Windows 95 and Linux) and T800 and T9000 transputers (marketing@nasoftwr.demon.co.uk). There is a cheap student version available. They also supply a F77 to f90 syntax convertor, LOFT90, as well as HPF. PSR's VAST/f90 compiler for unix, VMS and Convex includes a vectorizer. PSR also supplies VAST/77to90, to convert FORTRAN 77 programs into Fortran 90 syntax, as well as HPF (info@psrv.com or http://www.psrv.com/) ParaSoft has a compiler (f90-info@parasoft.com, or http://www.parasoft.com/f90.html). PGI has released a subset Fortran 90/HPF compiler for SGI and IBM SP2. (sales@pgroup.com or http://www.pgroup.com/). It supplies HPF to Cray. Salford Software markets a PC version of the NAG compiler, also for Windows 95 and NT (sales@salford-software.com or http://www.salford.ac.uk/ssl/ss.html). A very cheap student version is available (EuroSoft@fc.net). SGI released the MIPSpro Fortran 90 64-bit compiler in June 1995. It can be configured with an optional MIPSpro Power Fortran 90 Accelerator (PFA90) to optimize Fortran 90 code for SGI's multiprocessor systems. SofTech has a licence to sell its own versions of DEC's HPF/f90 compiler. Sun has released an f90 compiler based on Cray's CF90, initially for Solaris 2 (tel. 1-800-SUNSOFT or URL http://www.sun.com/sunsoft/Products/Developer-products). OTHER USEFUL PRODUCTS FORGE90 and an HPF processor from APR (support@apri.com or http://www.infomall.org/apri/) are available. HPF is apparently available not only as listed above, but also from Hitachi, Intel, Motorola, Meiko, and NEC. I have no details. A source form convertor, convert.f90, is obtainable by ftp from jkr.cc.rl.ac.uk in the directory /pub/MandR. Latest version is 1.4. NAG (see above) and IMSL (now Visual Numerics, mktg@houston.vni.com) offer f90 versions of their maths libraries that take full advantage of the language's library building capabilities. An f90 mode is included in the official Emacs distribution (GNU Emacs-19.28/XEmacs-19.13 or later). For make files, a perl5 script, which behaves like an X11 makedepend program (it edits an existing Makefile) and recursively searches include files for more dependencies, is available from Kate Hedstrom: ftp://ahab.rutgers.edu/pub/perl/sfmakedepend http://marine.rutgers.edu/po/perl.html WHAT BOOKS ARE AVAILABLE? English: Fortran 90 - Meissner, PWS Kent, Boston, 1995, ISBN 0-534-93372-6. Fortran 90 - Counihan, Pitman, 1991, ISBN 0-273-03073-6. Fortran 90 and Engineering Computation - Schick and Silverman, John Wiley, 1994, ISBN 0-471-58512-2. Fortran 90, A Reference Guide - Chamberland, Prentice Hall PTR, 1995, ISBN 0-13-397332-8. Fortran 90/95 Explained - Metcalf and Reid, Oxford University Press, 1996, ISBN 0-19-851888-9, about $33. This book is a complete, audited description of the Fortran 90 and Fortran 95 languages in a more readable style than the standards themselves. It incorporates all X3J3 and WG5's interpretations and has a complete chapter on Fortran 95. It has seven Appendices, including an extended example program that is available by ftp and solutions to exercises, as well as an Index. US e-mail orders may be sent to: orders@oup-usa.org. The Fortran 90 version is also available in French, Japanese and Russian (see below). Fortran 90 for Scientists and Engineers - Brian D. Hahn, Edward Arnold, 1994, ISBN 0-340-60034-9. Fortran 90 Handbook - Adams, Brainerd, Martin, Smith and Wagener, McGraw-Hill, 1992, ISBN 0-07-000406-4. Fortran 90 Language Guide - Gehrke, Springer, London, 1995, ISBN 3-540-19926-8. Fortran 90 Programming - Ellis, Philips, Lahey, Addison Wesley, Wokingham, 1994, ISBN 0-201-54446-6. Fortran Top 90-Ninety Key Features of Fortran 90 - Adams, Brainerd, Martin and Smith, Unicomp, 1994, ISBN 0-9640135-0-9. Introducing Fortran 90 - Chivers and Sleightholme, Springer-Verlag London, 1995, ISBN 3-540-19940-3. Introduction to Fortran 90, Algorithms, and Structured Programming, Vol. 1, R. Vowels: 93 Park Drive, Parkville 3052, Victoria, AUSTRALIA, (rav@goanna.cs.rmit.edu.au). $20 Aust, $15 US, ISBN 0-9596384-8-2. Introduction to Fortran 90 for Scientific Computing - Ortega, Saunders College Publishing, 1994, ISBN 0-030010198-0. Migrating to Fortran 90 - James F. Kerrigan, O'Reilly Associates, 1993, ISBN 1-56592-049-X. Programmer's Guide to Fortran 90, third edition - Brainerd, Goldberg and Adams, Springer, 1996, ISBN 0-387-94570-9. Programming in Fortran 90 - Morgan and Schonfelder, Alfred Waller/ McGraw-Hill, Oxfordshire, 1993, ISBN 1-872474-06-3. Programming in Fortran 90 - I.M. Smith, Wiley, ISBN 0471-94185-9. Schaum's Outline of Theory and Praxis -- Programming in Fortran 90 - Mayo and Cwiakala, Mc Graw Hill, 1996. ISBN 0-07-041156-5. Upgrading to Fortran 90 - Redwine, Springer-Verlag, New York, 1995, ISBN 0-387-97995-6. Chinese: Programming Language Fortran 90 - He Xingui, Xu Zuyuan, Wu Qingbao and Chen Mingyuan, China Railway Publishing House, Beijing, ISBN 7-113-01788-6/TP.187, 1994. Dutch: Fortran 90 - W.S. Brainerd, Ch.H. Goldberg, and J.C. Adams, translated by J.M. den Haan, Academic Service, 1991, ISBN 90 6233 722 8. French: Fortran 90; Approche par la Pratique - Lignelet, Se'rie Informatique E'ditions, Menton, 1993, ISBN 2-090615-01-4. Fortran 90. Les concepts fondamentaux, the translation of "Fortran 90 Explained" M. Metcalf, J. Reid, translated by M. Caillet and B. Pichon, AFNOR, Paris, ISBN 2-12-486513-7. Fortran 90; Initiation a` partir du Fortran 77 - Aberti, Se'rie Informatique E'ditions, Menton, 1992, ISBN 2-090615-00-6. Les specificites du Fortran 90, DUBESSET, M. et VIGNES, J., editions Technip, 1993. ISBN 2-7108-0652-5 Manuel complet du langage Fortran 90, et guide d'application, LIGNELET, P., S.I. editions, Jan. 1995. ISBN 2-909615-02-2 Programmer en Fortran 90, DELANNOY, C., Eyrolles, 1992. ISBN 2-212-08723-3 Savez-vous parler Fortran, AIN, M., Bibliotheque des universites (de Boeck), 1994. ISBN 2-8041-1755-3 German: Fortran 90 - B.Wojcieszynski and R.Wojcieszynski, Addison-Wesley, 1993, ISBN 3-89319-600-5. Fortran 90: eine informelle Einfu"hrung - Heisterkamp, BI-Wissenschaftsverlag, 1991, ISBN 3-411153-21-0. Fortran 90, Lehr- und Arbeitsbuch fuer das erfolgreiche Programmieren - W.S. Brainerd, C.H. Goldberg, and J.C. Adams, translated by Peter Thomas and Klaus G. Paul, R. Olbenbourg Verlag, Muenchen, 1994, ISBN 3-486-22102-7. Fortran 90 Lehr- und Handbuch - T. Michel, BI-Wissenschaftsverlag, 1994. Fortran 90 Referenz-Handbuch: der neue Fortran-Standard - Gehrke, Carl Hansen Verlag, 1991, ISBN 3-446163-21-2. Programmierung in Fortran 90 - Schobert, Oldenburg, 1991. Programmieren in Fortran - Erasmus Langer, Springer-Verlag, Wien New York, 1993. ISBN 3-211-82446-4, 0-387-82446-4. Software Entwicklung in Fortran 90 - U"berhuber and Meditz, Springer Verlag, 1993, ISBN 0-387-82450-2. Japanese: Fortran 90 Explained - Metcalf and Reid, translated by H. Nisimura, H. Wada, K. Nishimura, M. Takata, Kyoritsu Shuppan Co., Ltd., 1993, ISSN 0385-6984. Russian An Explanation of the Fortran 90 Programming Language (translation of Fortran 90 Explained - Metcalf and Reid), translated P. Gorbounov, Mir, Moscow, 1995, ISBN 5-03-001426-8. Available also from Petr.Gorbounov@cern.ch. Swedish Fortran 90 - en introduktion - Blom, Studentlitteratur, Lund, 1994, ISBN 91-44-47881-X. WHERE CAN I OBTAIN COURSES, COURSE MATERIAL OR CONSULTANCY? Copyright but freely available course material is available on the World Wide Web from the URLs: Manchester Computer Centre: http://www.hpctec.mcc.ac.uk/hpctec/courses/Fortran90/F90course.html or via ftp: ftp.mcc.ac.uk, in the directory /pub/mantec/Fortran90. The University of Liverpool: http://www.liv.ac.uk/HPC/HPCpage.html. CERN: http://wwwcn.cern.ch/asdoc/f90.html or via anonymous ftp from asisftp.cern.ch in the directory cnl as the file f90tutor.ps. An ASCII copy of this material as a set of slides for a six-hour course is available from metcalf@cern.ch. In French: Support de cours Fortran 90 IDRIS - Corde & Delouis (from ftp.ifremer.fr, file pub/ifremer/fortran90/f90_cours_4.ps.gz). A course on HPF is freely available from Edinburgh: http:// www.epcc.ed.ac.uk/epcc-tec/course-packages/HPF-Package-form.html Courses are available from: Walt Brainerd, a member of X3J3, also on HPF (walt@fortran.com); PSR (see above); CETech, Inc. (also on HPF) 8196 SW Hall Blvd., Ste. 304, Beaverton, Oregon 97008, USA. Phone: (503)644-6106 Fax: (503)643-8425 (cetech@teleport.com). European companies offering courses and conversion consultancy are: IT Independent Training Limited, 2 Windlebrook Green, Bracknell, Berkshire, UK tel. +44 1344 860172 fax. +44 1344 867992 Salford Software (see above); Simulog, attn. Mr. E. Plestan, 1 rue James Joule, F-78286 Guyancourt Cedex, France tel: +33 1 30 12 27 00 fax: +33 1 30 12 27 27 Allgemeiner Software Service Prinz-Otto Str.7c, D-85521 Ottobrunn, Germany tel: +49-89-6083758 Fax: +49-89-6083758 e-mail: 100722.746@compuserve.com URL: http://www.wp.com/AllSoftServe WHERE CAN I FIND THE STANDARD? Fortran 90 was adopted as an International Standard by ISO in July, 1991, as ISO/IEC 1539:1991, and is obtainable for 185 Swiss francs from ISO Publications, 1 rue de Varembe, Case postale 56 CH-1211 Geneva 20, Switzerland Fax. + 41 22 734 10 79 It may also be obtained from national member bodies such as ANSI, 1430 Broadway, New York, N.Y. 10018 (where it is also known as ANSI X3.198-1992), or in electronic PostScript or ASCII form from Unicomp (walt@fortran.com) at a cost and under conditions agreed by ISO. Corrigenda 1 and 2 were published by ISO in 1993 and 1995, respectively, and are available from them (cost about 30 Swiss francs). A Russian translation of the standard (translator S.G.Drobyshevich) is available from the editor, Alla Gorelik (gorelik@applmat.msk.su). ***** This information is compiled on a 'best-effort' basis and without prejudice. It may be freely copied and disseminated. Corrections and additions are solicited. Mike Metcalf (metcalf@cern.ch) Version of 22 April, 1996. --------------------------------------------------------------------------- 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 ---------------------------------------------------------------------------