From owner-hpff Mon Jul 8 12:30:54 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id MAA05630 for hpff-out; Mon, 8 Jul 1996 12:30:54 -0500 (CDT) Received: from moe.rice.edu (moe.rice.edu [128.42.5.4]) by cs.rice.edu (8.7.1/8.7.1) with ESMTP id MAA05623 for ; Mon, 8 Jul 1996 12:30:51 -0500 (CDT) Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by moe.rice.edu (8.7.1/8.7.1) with ESMTP id MAA23600 for ; Mon, 8 Jul 1996 12:30:50 -0500 (CDT) Received: from [128.42.5.170] (pasyn-42.rice.edu [128.42.5.170]) by cs.rice.edu (8.7.1/8.7.1) with SMTP id MAA05614 for ; Mon, 8 Jul 1996 12:30:47 -0500 (CDT) X-Sender: chk@titan.cs.rice.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 8 Jul 1996 12:33:15 -0600 To: hpff@rice.edu From: chk@cs.rice.edu (Chuck Koelbel) Subject: hpff: Ptools DAQV Reference Implementation for pghpf 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. --------------------------------------------------------------------------- As the DAQV project essentially visualizes HPF array distributions, I thought this might be of interest to the HPF community... >Date: Tue, 2 Jul 1996 16:31:24 -0700 (PDT) >From: Steven Hackstadt >Reply-To: Steven Hackstadt >To: ptools@llnl.gov >Cc: ptools-dav@llnl.gov >Subject: Ptools DAQV Reference Implementation for pghpf >X-Url: http://www.cs.uoregon.edu/~hacks/ >Mime-Version: 1.0 >Precedence: bulk > > >We are pleased to announce the immediate availability of the first >publicly-available reference implementation for the Ptools Distributed >Array Query and Visualization (DAQV) project. > >It can be found at http://www.cs.uoregon.edu/~hacks/research/daqv/. > >The first reference implementation works with PGI's pghpf HPF compiler on >SGI Power Challenge/Onyx machines, SGI workstations, and Solaris >workstations. This reference implementation has also been successfully >ported to pghpf on the IBM SP-2 by collaborators at Cornell Theory Center. >The SP-2 implementation will also soon be available. Work is also >underway to port DAQV to a second HPF compiler platform, IBM's xlhpf. >Collectively, these separate implementations will eventually make up a >final reference implementation of DAQV, hopefully available in Fall 1996. > >For those of you that do not know about the DAQV project, I have attached >a quick abstract after my signature. The DAQV web site at the URL given >above also contains several pieces of documentation that describe various >aspects of the project, including its design and implementation. > >Thank you, >Steve Hackstadt, hacks@cs.uoregon.edu >Allen Malony, malony@cs.uoregon.edu > >[For those of you that received this message multiple times, I apologize.] >______________________________________________________________________ >Steven Hackstadt http://www.cs.uoregon.edu/~hacks >Computer & Information Science hacks@cs.uoregon.edu >1202 University of Oregon (tel) 541.346.1373, (fax) 541.346.5373 >Eugene, OR 97403-1202 Office 207B >******* Stop Internet Censorship ** Protect Free Speech Online ******* >*** http://www.eff.org/blueribbon.html ** http://www.cdt.org/ciec/ *** > >==== BEGIN ==== > >Abstract of DAQV >---------------- > >Distributed Array Query and Visualization (DAQV) system for High >Performance Fortran, a project sponsored by the Parallel Tools Consortium. > >DAQV's implementation leverages the HPF language, compiler, and runtime >system to address the general problem of providing high-level access to >distributed data structures. DAQV supports a framework in which >visualization and analysis clients connect to a distributed array server >(i.e., the HPF application with DAQV control) for program-level access to >array values. Implementing key components of DAQV in HPF itself has led >to a robust and portable solution in which clients do not need to know how >the data is distributed. > >==== END ==== --------------------------------------------------------------------------- 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 Jul 8 12:30:30 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id MAA05603 for hpff-out; Mon, 8 Jul 1996 12:30:30 -0500 (CDT) Received: from moe.rice.edu (moe.rice.edu [128.42.5.4]) by cs.rice.edu (8.7.1/8.7.1) with ESMTP id MAA05595 for ; Mon, 8 Jul 1996 12:30:23 -0500 (CDT) Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by moe.rice.edu (8.7.1/8.7.1) with ESMTP id MAA23576 for ; Mon, 8 Jul 1996 12:30:13 -0500 (CDT) Received: from [128.42.5.170] (pasyn-42.rice.edu [128.42.5.170]) by cs.rice.edu (8.7.1/8.7.1) with SMTP id MAA05583 for ; Mon, 8 Jul 1996 12:30:10 -0500 (CDT) X-Sender: chk@titan.cs.rice.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 8 Jul 1996 12:32:38 -0600 To: hpff@rice.edu From: Philippe Destree (by way of chk@cs.rice.edu (Chuck Koelbel)) Subject: hpff: New HPF Courseware 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. --------------------------------------------------------------------------- New HPF Courses +++++++++++++++ The Computing Services Department of the University of Liverpool has just finished updating their HPF Courses. These courses have been funded by JISC New Technologies Initiative and are available for downloading from URL: http://www.liv.ac.uk/HPC/HPFpage.html The previous incarnation of these courses received good reports - any feedback on the improved versions is strongly welcomed. The following text is taken from the above web page: -- There are two main Courses lasting 3 and 5 days and a shorter Seminar. The courses comprise OHP Slides, Course Notes, Student Exercises and Lecturers Guide. There is also a set of OHPs for a 40 minute Seminar explaining the conversion Fortran 77 codes into HPF. The 5 Day Course is a complete guide to to Fortran 90 / HPF. This course is for programmers who are familliar with a high level language such as C or Pascal. The 3 Day Course is designed for the those with programming experience in Fortran 90 and who whish to learn the basics of HPF. Each day is divided into two 3 hour sessions: 1 hour lecture, 2 hours practical. The course therefore is divided into 6 x 1 hour sessions: Data Parallelism (Introduction), Alignment and Distribution, Forall and Prallel Loops, Procedures, Extrinsic Procedures and Vectorisation and The HPF Library and HPF in the Future. The HPF Seminar will give a good introduction to HPF Programminmg. The Fortran 77 to HPF Conversion Seminar is designed for the those who whish to convert old Fortran 77 into a format suitable for submission to an HPF system. The slides explain some simple conversion productions and give simplistic examples as illustrations. -- These courses may be used for non-commercial gain. -- Dr AC Marshall | Cheese of the Week: CSD, University of Liverpool. L69 3BX | St Paulin. Tel: +44-151-794 3722 (Fax: 3759) | Mmmmm, St Paulin. http://www.liv.ac.uk/HPC/HPCpage.html http://www.liv.ac.uk/~adamm/HomePage.html --------------------------------------------------------------------------- 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 Wed Jul 24 18:40:08 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id SAA25022 for hpff-out; Wed, 24 Jul 1996 18:40:08 -0500 (CDT) Date: Wed, 24 Jul 1996 18:40:08 -0500 (CDT) From: owner-hpff Message-Id: <199607242340.SAA25022@cs.rice.edu> >From: Mary Zosel Subject: hpff: HPFF minutes - July 96 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 July 10-12, Burlingame, CA Record of Action: Mary Zosel Executive Summary There were 17 people from 15 institutions present at the July 96 HPFF meeting.. The group processed the second reading of a number of language proposalas listed below and also worked on document organization and writing. Proposals passing second reading: Inquiry Routines. Interprocedural ON Base language is Fortran. Additional Pointer clarifications. Reorg. of extrinsic interface. to incorporate the C interop and F77 interfaces. Limit inherit. The primary order of business now is producing a document for public review. The public review period has been postponed until after the September meeting (September 18-20San Francisco area). The review will take place during October and November, with a newly scheduled meeting - at Rice in Houston, tentatively December 9-11 to process public comment and finalize the document text. End of Executive Summary ____________________________ Detailed Record of Action Plenary session Wednesday The meeting began at 10:30 with Mary Zosel as temporary chair due to delay in the arrival of Ken Kennedy. The group reviewed the first/second reading proposal status. 1st 2nd group E SPMD-Craft-ext. Mar July am/lfm Base language Fortran (not F90) May July Amended C interface May July hz/jw F77_LOCAL ext interface May July cm group D dark corners of ptr Mar. July group C on - interproc May July ck task write-up Mar July inq additions Jan July rs -------- This was followed by a review of the status of the document chapters: -------- chapter status title - needs to inc version number credits - needs HPFF 95 participants overview - sad shape need area/chapter editor to go through & check outline Saday commented that it isnUt not useful for user, need less on history and hpf vs f90 vs hpf 2.0. Plant model of "what is data parallelism" - very short description. Some work is needed on the directives syntax. And in general the chapter needs a rewrite. Saday agreed to take on the task of proposing a reorganization of the material. mapping chapters - good shape, thanks to Piyush Mehrotra and Carl Offner. All the content is there, possibly details need discussion. Guy Robinson has volunteered for a lot of reading. These chapters are at the "proofreading stage" ... the dark corners of pointers are still with us. independent & reduce - Rob Schreiber will work on revisions. The content seems to be there. The syntax needs to be unified. hpf library - very good shape Carol has suggestions, new cci item should grade_up, grade_down return 1-based or array- based numbers? Also, we should remove maxloc & minloc, since our HPF extension is now part of standard Fortran. The features with dynamic need to be moved to approved extensions. extrinsics - old text, but no HPF 2.0 changes needs review for updates on, resident, tasking - lots to do needs interprocedural ON, more tasking new library - OK now, minor updates (see above) hpf_local - recheck, needs update (hpf_local calling hpf_local) hpf_serial - in proofreading stage f77-local - we note that Fortran_local disappeared and was replaced with F77_local in document draft. Fix this. Really the F77_local (which needs second reading) may belong in annex. c interoperability - shouldn't this be called extrinsic(c)? needs compiler functionality to work - but so do other extrinsics. Henry Zongaro is coming with revised proposal. bnf - needs to regenerate, need to resection extrinsic extrinsics - Needs new craft section and better chapter sections. subset - make sure there are no references to "subset" in rest of text. "this is an appendix in the true sense of the word - a vestigial organ" with no current function. ------- Following this, the group discussed conventions for syntax in the new document. The split format presents the challenge of syntax rules that change with the different extended features. First for extended features - add "extended-x" options with a statement at the beginning of extended section, overview that "extended-x replaces all occurances of x". Add "extended-declarative- directives" etc. ------ Finally, we reviewed ownership of chapters to make sure that there was someone present at the meeting associated with each chapter. assignments - ownership of chapters ch 1 - saday ch 2 - pm ch 3 - offner ch 4 - schreiber ch 5 - schreiber ch 6 - offner ch 7 - meltzer ch 8 - pm ch 9 - pm ch 10 - chk ch 11 - lfm ch 12 - offner ch 13 - offner ch 14 - munroe ch 15 - pm app a - offline app b - zosel, meltzer app c - zosel =========================================== After a break for lunch there were subgroup meetings for the afternoon. The HPFF Meeting reconvened Thursday AM, chaired by Ken Kennedy of Rice University. In the traditional review of the vendor slide, the decision was to move Lahey to interested and remove Ncube from the list altogether. There was a review of subgroup status: Group C reported that the CCIUs are finished, that gradeup/down and the processor lb/ub should all be 1-based - Also that the active number of processors and shape should be intrinsics; There is still a second reading of interprocedural ON; Group D reported that one or two of the CCIUs may need some text; There are new D proposals that are ready; Group E reported a new proposal to collapse several chapters into a broadened idea of Extrinsic. --------- GROUP C PROPOSAL PROCESSING Rob Schreiber presented the LIBRARY & Intrinsics NEWS July 11, 1196. This a play on KenUs complaint that the hotel didnUt carry the NY Times. Highlights are: GEN_TRANSPOSE NAME WILL COME BACK ... ALTERNATIVE IS GRNERALIZED intrinsics ... either it replaces the Fortran intrinsics or it is in the library with the generalized name . GRADE_UP, DOWN to go 1-BASED --- PROCS LB and UB RESULTS in distribution inquiries will also be 1-based. (This is the same as maxloc and minloc) New intrinsics: Active_num_procs and Active_procs_shape ... these are the same as num_procs and Proc_shape if they are outside all ON constructs ... otherwise they refer to the inner-most enclosing , ON region. grade-up/down will be 1-based official - 2nd reading vote: 12 - 0 - 3 gen_transpose and library ... or transpose and intrinsic .... overriding Fortran ... intrinsic? Adopt the latter: 14 0 1 NOTE: this is a difference from Fortran that should be noted in the early part of the document. HPF_NUMBER > HPF_NUMBER_MAPPED HPF_MAPPING > HPF_MAP_ARRAY Jaspal Subhlok: Task - Back on popoular demand. The write-up needs to be expanded - add another example and more advice to implementors and some wording changes There was a vote about which terminology to use: Instead of TASKREGION TASK_REGION ...END TASK_REGION - 7 TASK_SECTION or END TASK_SECTION - 4 TASKING END TASKING - 1 straw poll on name TASK_REGION wins Add the underscore to current proposal 14 - 1 - 0 ------ Chuck Koelbel --- review of interproceral ON Do i-1,n !HPF$ ON HOME (a(indx(i))) BEGIN a(indx(i)) = b(i) b(i) =c(indx(i)) !HPF$ END ON END DO ... Note This is now called END ON. For the proposal in the draft document will reorder text for better presentation. Now moving on to the principled of interprocedural ON: There is always an active set of processors specified by innermost ON directive. see also ACTIVE_NUM_PROCS() and ACTIVE_PROCS_SHAPE() ... the shape will come from the home ON clause ... irregular shapes have an answer but may not be able to map back to the global shape. Calling a subprogram does not (alone) change the active processors set Local variable are always stored on the active processors set. Dummy args are always on the active processors set. ACTUALS may not be resident. Global variables may be stored on passive processors. (so some one-sided communications are still required) About Classes of processors Arrangements: Universal arrangements - represent the set of all available processors including inactive ones. They are used to distribute global data.. These are what we had in HPF 1. The HPF compiler must support arrangements with Number_of _processor() elements. Two Universal processors arrangements with the same shape are identical. Active Processors Arrangements represet the set of active processors. They are used to distribute local data. HPF compiler must support arragements with ACTIVE_NUM_PROCS() elements. Two active processros arrangements with the same shape are identical if no ON directive is executed between their declaration. Discussion of status of RstackedS active sets ... there will be passive processor sets, but they are not needed for the definitions. Delarations of Local Variables: Distribute must be ONTO an active processors arrangement : Explicit ONTO has the obvious meaning An Implicit ONTO - uses the active processors set (or maybe subset) ALIGN must be to an ultimate align target that is distributed to an active procssors arrangemnt Active processors set is determined at the time that the DISTRUBTE or ALIGN becomes instantiated. explitic shape (non-allocatable) is determined at the time of declaration deferred shape(ALLOCATABLE) is determed at ALLOCATE statement Declarations of Dummy Arguments: Actual argument must be RESIDENT if the dummy argument is mapped transcriptively. This allows other locals to be ALIGNed to the dummy. Otherwise, actual argument may be non-RESIDENT and dummy must be declared as a local variable. Note: if a remapping takes place, the actual argument is moved to the active processors set. Note also, If no remapping takes place the dummy is on the active processors set (and thus the actual is also). Either way, the dummy is RESIDENT and other locals can be ALIGNED to it. Question ---- about what calling LOCAL means from within a restricted procs set ... what set of procs get activitated? Only the active set. But must have prescriptive mappings for any GLOBAL arrays that are passed. The question remaining is .... Imagine I have a subroutine called from within ON with a COMMON block containing a globally mapped array. ON ... CALL Foo SUBR Foo Common a(N) !HPF$ DISTRIBUTE A(BLOCK) ONTO P The questions comes up when N is passed in someway ... so the compiler doesnUt know for sure if P (N) is universal. There needs to be some way to indicate this. There was discussion of different options - ending up with a vote between Procs, Universal and Procs. Active. A straw poll favored active 13 - 0 - ? A suggestion to use restrictive instead of active was voted down. So the notation will be: PROCS, ACTIVE: P(N) Poll of opinions of vendors ... primary concern is access to non- resident which is not a new problem ... it also exists in PURE. Second reading - approved extension for interprocedural ON 10 - 4 - 1 (squeak). --------- BREAK ----------- Carol Munroe presented a problem involing Inherit + Distriubte. Example: subroutine sub (s,y,z) real, dimension (100,200) :: x,y,z,w !HPF$ INHERIT :: x,y,z !HPF$ DISTRIUBTE (BLOCK,BLOCK, CYCLIC) :: x !HPF$ DISTRIUBTE (CYCLIC) :: y !HPF$ DISTRIBUTE (BLOCK B(1:307:3) ! ok since template of RHS (and this of A) is clock distriuted. RANGE - clarificatiosn: !HPF$ DISTRIBUTE T(BLOCK) !HPF$ ALIGN A(I,J) WITH T(I) call sub(A) ---- sub(x) !HPF$ INHERIT x !HPF$ RANGE X (BLOCK, *) 2nd dimension of X has no corresponding dimension in the ultimate align target of the actual Text to be added: If there is not corresponding dimension, then a * or ALL mut be used as the range-attr. real A(100,100,100) !HPF$ dist A(block,*,cyclic) call sub(A(:,:,1)) ! illegal call sub (A(:,1,:)) ! ok call sub (A(1,:,:)) ! illegal where: sub(x) real x(:,:) !HPF$ inherit x !HPF$ range x(block, cyclic) second example - same caller - but different things are legal: real A(100,100,100) !HPF$ dist A(block,*,cyclic) call sub(A(:,:,1)) !ok in second example call sub (A(:,1,:)) ! ok in second example call sub (A(1,:,:)) ! ok in second example where: sub(x) real x(:,:) !HPF$ inherit x !HPF$ range x(block,*), (block, cyclic), (*,cyclic) vote on second clarification --- 14 - 0 - 1 vote on first clarification - 13 - 0 - 2 NOW POINTERS AGAIN If both actual and dummy pointes are dynamic what happens if dummy is redistriuted? Note - if dummy is (re) allocated new storage is visible in caller! Two options (with subgroup votes): Option 1 Redistrution of dynamic pointers not visible in caller - remapped to original - if new (re) allocation - new storage with original distribution (if possible) visible in caller 2-2-2 Option 2: If actual and dummy both dynamic - redistribution of dummy visible in caller - true for dynmic variables visible through use and host 3 -2 1 Committee talked about allowing this to work for pointers, but not variables - but decided that they should go together. This is a clarification - one of the two options (or maybe third or ...) Henry proposes variation - where couldnUt remap args but ok for things visible via modules, etc. ... Proposal is to adopt option 2 for approved extensions ... 11 - 0 - 3 ========== After break Saday presented a proposal for a new overview chapter. current contents - introduction of key HPF concepts - guide to HPF2 doc - document differences and trace evolution Proposal: Have Overview do the first two and move last to annex with appropirate pointers in the overview. New 1.1 goals and Scope of HPF 2.0 (old 1.2) 1.2 HPF Model (old 1.3, 1.9, 1.10) - philosophy of lang approach - f95 extension - data parallel model - data mapping directives - extrinsic interface for other lang/paradigm - new simple example such as LU 1.3 HPF language Features (old 1.4, 1.7) - philosopy of document organization - pointer to appendix - base 2.0 lanugage features - hpf approved extensions 1.4 Organization of Document (old 1.8) 1.5 Notation and Syntax (old 1.6 and 1.11) * Evolution of HPF (old 1.1, 1.5) move to annex --- changes and extensions Goals and Scope of HPF Primary Goals - Portability across different architectures - Data parallel programming (single threaded,global name space) - High performance on parallel computer with non-uniform memory access costs - Open interfaces and interoperability with other language (e.g. C) and programming paradigms (e.g. message passing with MPI) - Build on Fortran Subsidary Goals - Keep language understandable and implementable in short time span - Provide input to future standard standards activities for fortra and C - Provide evolutionary path for adding advanced features in a consistent manner to the base language ======== Mary presented the subgroup E proposed revision of the extrinsic mechanism. #1 EXTRINSIC ( HPF| HPF_SERIAL | HPF_LOCAL) or EXTRINSIC ([ [MODEL=] RstringS] [, [[LANGUAGE =] RstringS] [ , [EXTERNAL_NAME = ] RstringS ]] ) (or whatever the correct [] pairs are). The idea is that this mechanism will now follow the keyword conventions of other Fortran constructs. The strings for our oldnames are HPF MODEL = RglobalS, LANGUAGE = RhpfS HPF_LOCAL MODEL = RlocalS, LANGUAGE = RhpfS HPF_SERIAL MODEL = RserialS, LANGUAGE = RhpfS #2 As part of HPF 2.0, if extrinsics are supported - include MAP_TO - this is primarily to avoid explaining MAP_TO over and over for each extended extrinsic name. #3 MAP_TO generalized: MAP_TO (TYPE=RstringS, LAYOUT = RstringS, PASS_BY = RstringS) where again these follow the Fortran keyword notation. The strings are things like Rint:S, R(int,double)S for types; Rc_arrayS for layout; and RvalS, RrefS, RrrefS, RrrrefS. RrrrrefS for pass-by. A given extrinsic might extend MAP_TO. In approved extensions - the chapters for LOCAL, SERIAL, C, Fortran, and Fortran77 will be combined into one chapter with an outline of parallel models language interfaces libraries other {default} examples --- straw polled : consensus for the approach ... ======= Piyush presented more pointer discussion. - pointers with an explicit mapping using a distribute or align - can be used to allocate - can be used to point to whole array with dimension by dimension compatible mappings - cannot be used to point to sections - pointers can point to sections of distributed arrays via transcriptive mapping (distribute *) - range can be used to restrict the distribute * - rules of range apply - discussion of whether this is too restrictive - too much - or ??? committee decided yes. Remaining question about Distribute * ONTO ... for a dummy argument ... Andy Meltzer went over the HPF - CRAFT/DRAFT ... He described how he will rewrite the document to conform to outline. Questions for committee: 1. are the sections an appropriate length? - 1 page intro ~ 2 page examples ~2 pages of functional specs ~6 page functional spec 2. are these the sections what we want? Discussion about name - whether to change the name to CRAFT_HPF ... HPF_CRAFT 4 - CRAFT_HPF 3 - abstain 8 Second reading that this goes to the extrinsic extrinsic chapter - with the reorganization that Andy has outlined ... 9 - 1 - 3 external There was some additional discussion about the names of the chapter and annex for these extrinsics. The chapter will be Approved Extrinsic Extensions The annex will be Recognized Extrinsics Interfaces ------ Discussion of document plan Revised schedule - try to get it out very shortly after the October meeting. Ask for input about which of the approved extensions should the vendors give most priority to. The meeting to process comments will tentatively be Dec 9-11, probably at Rice. Starting at noon on the 9th to mid-day on the 11th. User Meeting Proposal - in Santa Fe in February - try for Feb 24-26 ; second choice 10-12; 12-14 third choice; 19-21 fourth choice. Bob Boland is organizing this with LANL and CRPC as joint hosts. On the agenda of the October meeting, we will plan the CCI process. Agenda for Friday: SC96, finish 2nd reading extrinsics; F77 as simplified; explicit interface clarified; interprocedural ON ; replan document; E cciUs. Adjourn Dinner ... Friday, July 12. Piyush: pointer recap to clarify the issue of compatibility mapping.. in HPF 2 if p is not explicitly mapped can be pointer associated with an object which has both been explicitly mapped compilers chooses mapping when allocated dummy - if and only if actual is also not explicitly mapped Approved extension if p is explicitly mapped with a non-starred mapping allocated using the specified mapping can point to whole objects with dimension - by - dimension compatible mappings p is dummy - actual must be explicitly mapped - must be whole array must have dim-by-dim compatible mapping if p is transcriptively mapped -compiler chooses mapping on allocation -can point to anything -range can be used to restrict mapping of the ultimate align target of the target -dummy - actuals maybe anything legal in F90 which is explicitly distributed - any reassociation must match the conditions of the actual on return - range can be used to restrict mappings of actuals if p has the dynamic attribute - can be pointer associated with a target iff it has the dynamic attribute - a target associated with p can be remapped through p iff - the object was allocated and - p points to the whole object Any other pointer associated with the target looses association (except see below) -range can be used to restrict what p can point to or redistributed to. For non* distribute must contain specified distribution - on allocation - transcriptive distributions - compiler chooses - non-* distribution - specified distribution In either case can be redistributed subject to the restrictions of range. If p is dynamic and is a dummy along with other restrictions, actual must also have the dynamic attribute on redistribution, actual does not loose association and new mapping is visible in caller any redistribution must match restrictions of the actual on return. For pointers - transcriptive means distribute * NOT distribute * onto * ==== Saday raises the question about the current (HPF 1.0 restriction) that if pointer target is redistributed through a pointer, then all the other pointers to that target become undefined. Saday moved that we remove this restriction. If we redistribute through pointer, other objects to not lose association - 9 - 2 - 2 passes .... Pointer compatibility recap .... 12 - 0 - 1 =============== Extensions --- Two clarifications related to the document rewrite. In consideration of how this would be used in a serial Fortran program, switch the EXTRINSIC args for model and name so that model is last - require keyword for model if it is used. In the HPF 2.0 chapter, it is ok to introduce HPF_SERIAL and HPF_LOCAL for discussion, even if these languages are in the extensions part of the chapter. There was some discussion of the idea of making such language names hidden parameter strings, but this was not accepted. ======== Henry Zongaro - when is explicit mapping required? Replace 3.5.1 p 66 line 35 through p. 68, line 10 of the draft 2.0 document with: The actual argument must be a named object. The shapes of the ultimate align targets must be the same. In addition, the ultimate align targets of the dummy and actual must not have been explicitly distributed, or the DISTRIBUTE directives specified for both the ultimate align targets must: have an onto-clause specifying processors arrangements having the same shape; and must specify dist-format-clasues with the same dist-formats in corresponding positions, except blocking factors need only have the same values. Each dimension of the actual and dummy must correspond to the same dimension of their respective ultimate align targets, and corresponding elements of the actual and dummy must be aligned with the same corresponding elements of their respective ultimate align targets. Section 3.5 will be modified to avoid describing these mappings as being the *the same*. Question about how this applies to the active processor set.? Summary: - to avoid requiring explicit interfaces, all arguments must have basically identical interfaces. Question ... about how this applies to pointers ... pointer actual - array dummy ... make sure it is ok ...that the terminology named-object is broad enough. 13 - 0 - 0 [trust Henry :-)] ---------- CHK will take responsibility for identifying all the context where Rprocessor setS should actually be RactiveS processors set. --------- F77_local interface changes to the proposal handout Extrinsic (LANG-SF77S, MODEL - RLOCALS) Rules for MODEL- RLOCALS described in RApproved ExtensionsS Argument passing via MAP_TO(LAYOUT-S...S, PASS_BY= R...S) Extrinsic kind F77_local determines defaults ( ...) Default for arrays: LAYOUT-SF77_ARRAYS - local data is packed/unpacked into sequence associate {missed something here - ed.} PASS_BY = RREFS - pass local assess of start of array Other supported MAP_TO options: LAYOUT = RNO_CHANGES - pass whole distributed HPF array as is. PASS_BY = RHPF_HANDLES - Pass address of a data structure to be used in local inquiry functions only. or should this be RDESCRIPTORS?) Question: Should we have a LAYOUT option to create automatically replicated SEQUENCE array? (must users remap these in advance) Should this go into Approved Extensions 11-0-2 -------- In the recognized extrinsic interface (library) F77 inquiry functions - unchanged in Annex as Rrecognized extrinsic interfaceS one global function HPF_SUBGRID_INDO to find actual local extens before call One local version of same F77_SUBGRID_INFO For the library recognized : straw poll ... 9 - 0 - 6 ============= August 7 Is the date for next HPF DOC. September 4th is the date for the distribution just before the meeting. ============== At the next meeting, we need an agenda item to talk about the longer term plan for HPFF. Create a FUTURE ROADMAP. For SC96, Mary will send in a BOF proposal. Preference is early in the week. This BOF will focus on presentation of HPF 2.0 and extensions - for public comment. ========= And LPF is back in action ... HPF2 slogan proposal for a tee-shirt ... If we canUt make it faster - at least we can make it more (complicated) crossed out ... feature rich. the tee-shirt only comes in xl and xxl velcro straps for approved extension LPF 3.1415i Goals of LPF: Opportunity to visit identical hotels all over the country to sit in a windowless conference room, spend long days with computer geeks, then to home - the entire low-performance community - Anger the entire language/compiler community Give HPF users a positive path forward. LPF new platform list: TRS-80 with 800 MB memory or more 500 megahertz apple Iie - Superscalal implementation for IBM Xt - Any abacus with a 2MB video card barefoot people with nine fingers and twelve toes and of course: any platform supporting full HPF New LPF Directives: Begin begin begin end begin end begin end end end Example usage: * begin begin if begin if end begin if begin begin block begin block end begin block (x/0 < 5) begin end block end block end end begin begin then begin then end begin then begin begin block begin block end begin block begin call call call() end call begin end block end block end end block begin end then end then end end then begin end if end if end end * of course LPF progs are not this nicely indented + No LPF user has ever written a program. (One prospective LPF user wonders if this example is best understood if one hums begin the begine (sp?) while reading it?? More new directives: (Building on HPF ACTIVE) - proACTIVE processors arrangements: - anticipte what the user will want to do and do it ahead of time. Their smug perfection annoys other processors. - retroACTIVE processors arrangements: - wait until too late, get into the correct position, then declare that they were there all the time. -hyperACTIVE processors arrangements: -continually change position, destructive, with a short attentions span. - also called Attention Deficit Disorder processors arrangements. Some thought s on HPF Directives: - HPF now has ON HOME and RANGE keywords - somehow HPF forgot the HOME ON the RANGE directive. parameter (from_dead_uncle=100) parameter(close=16) processors relatives(close) inherit lots_of_money(from_dead_uncle) distribute lots_of_money(cyclic) onto relatives or from a new father: distribute pee onto diaper distribute poo onto diaper align diaper with diaper_pail The meeting adjurned at 10:30 =============================================== The next HPFF meeting is September 18-20 (again San Francisco area), with the expectation that there will be a public comment period between during October and November. There will be a meeting Dec 9-11 , probably at Rice University. ------------------------------------------------------------- July 96 Attendance: Robert Babb U. of Denver babb@cs.du.edu Siegfried Benkner Univ. of Vienna sigi@par.univie.ac.at Bob Boland LANL wrb@lanl.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 Piyush Mehrotra ICASE pm@icase.edu Andy Meltzer CRI/SGI meltzer@cray.com Carol Munroe Thinking Machines munroe@think.com Carl Offner Digital offner@hpc.pko.dec.com P. Sadayappan Ohio State University saday@cis.ohio- state.edu Rob Schreiber HP schreiber@hplpp3.hpl.hp.com Jaspal Subhlok Carnegie Mellon jass@cs.cmu.edu Arun Venkatachar Louisiana St. Univ. arun@ee.lsu.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 ---------------------------------------------------------------------------