From owner-hpff Tue Feb 6 21:47:02 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id VAA25557 for hpff-out; Tue, 6 Feb 1996 21:47:02 -0600 (CST) 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 VAA25551 for ; Tue, 6 Feb 1996 21:46:54 -0600 (CST) From: dfk@palisades.cs.dartmouth.edu Received: by palisades.cs.dartmouth.edu (8.7.1/4.2) id WAA07934; Tue, 6 Feb 1996 22:46:52 -0500 (EST) Date: Tue, 6 Feb 1996 22:46:52 -0500 (EST) Message-Id: <199602070346.WAA07934@palisades.cs.dartmouth.edu> To: hpff@cs.rice.edu Subject: hpff: Program for IOPADS'96 Reply-to: 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. --------------------------------------------------------------------------- [apologies if you receive multiple copies] The full program, including abstracts, is available on the web page. CALL FOR PARTICIPATION http://www.cs.dartmouth.edu/iopads/ Fourth Annual Workshop on I/O in Parallel and Distributed Systems (IOPADS) in conjunction with the ACM 1996 Federated Computing Research Conference May 27, 1996 Philadelphia, PA Co-sponsored by: ACM SIGACT ACM SIGARCH ACM SIGOPS IEEE TCOS In cooperation with: ACM SIGMETRICS In 1996, its fourth year, IOPADS graduates from an informal workshop held in conjunction with IPPS, to a format more like a symposium to be co-located with many others at FCRC '96. The thrust of IOPADS has always been to bring together researchers in all aspects of parallel I/O, which we broadly place into five categories: architecture, algorithms, applications, file and operating systems, and compilers and runtime systems. It is our opinion that the problems of parallel I/O are most effectively addressed by investigating all these areas rather than working in each area in isolation. Although I/O-related papers appear in many other conferences, the value of IOPADS is in gathering interested researchers from all these areas of computer science, encouraging cross-disciplinary interaction, rather than working in each area in isolation. Through ACM Press, IOPADS will publish a formal proceedings, which will be provided to all registrants and will be available for sale at FCRC and afterwards. FCRC is the Federated Computing Research Conference, which was last held in 1993. In 1996, FCRC will include many exciting conferences and workshops under one roof: ICS, IOPADS, ISCA, PADS, PLDI, PODC, SIGMETRICS, STOC, WOPA, Workshop on Academic Careers for Women, Symposium on Computational Geometry, Conference on Computational Complexity, Symposium on Networks and Information Management, Symposium on Parallel and Distributed Tools, and Conference on Functional Programming. --------------------------------------------------------------------------- TENTATIVE PROGRAM for May 26, 1996 7:00- 8:00 Breakfast 8:00- 9:00 FCRC Plenary Speaker: Randy Katz, UC Berkeley "The Case for Wireless Overlay Networks" TENTATIVE PROGRAM for May 27, 1996 8:00- 8:45 Breakfast 8:45- 9:00 Opening remarks 9:00-10:30 Session 1: Applications and Language Support Chair: Charles Koelbel, Rice University Efficient Data-Parallel Files via Automatic Mode Detection Jason A. Moore, Oregon State University Philip J. Hatcher, University of New Hampshire Michael J. Quinn, Oregon State University Tuning the Performance of I/O Intensive Parallel Applications Anurag Acharya, Mustafa Uysal, Robert Bennett, Assaf Mendelson, Michael Beynon, Jeffrey K. Hollingsworth, Joel Saltz, and Alan Sussman, University of Maryland The Design and Implementation of SOLAR, a Portable Library for Scalable Out-of-Core Linear Algebra Computations 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 Wed Feb 21 09:02:46 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id JAA24642 for hpff-out; Wed, 21 Feb 1996 09:02:46 -0600 (CST) Received: from rising.irisa.fr (rising.irisa.fr [131.254.41.16]) by cs.rice.edu (8.7.1/8.7.1) with SMTP id JAA24633 for ; Wed, 21 Feb 1996 09:02:39 -0600 (CST) Received: from yapuka.irisa.fr (yapuka.irisa.fr [131.254.42.19]) by rising.irisa.fr (8.6.12/8.6.9) with ESMTP id PAA11213; Wed, 21 Feb 1996 15:58:11 +0100 Message-Id: <199602211458.PAA11213@rising.irisa.fr> To: ptools@llnl.gov, hpff@cs.rice.edu cc: pazat@irisa.fr Subject: hpff: HPF TOOLS SURVEY Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Wed, 21 Feb 1996 15:58:10 +0100 From: Jean Louis Pazat 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. --------------------------------------------------------------------------- Dear HPF tool developers, I am writing a survey about "Programming Environments for HPF". This survey will be available online (http://www.irisa.fr/pampa/HPF/survey,html) and It will also be published by Springer Verlag (LNCS series) in the proceeding of the "Spring School on Data Parallelism" (Les Ménuires (France),mars 1996). If you have developed an HPF programming environment or a tool related to HPF, ** I need your cooperation ! ** Note that this survey is NOT about compiling techniques, but about tools. It includes (but is not limited to): - restructuring tools for writing HPF programs - data distribution visualization tools - performance evaluation and measurement tools - debugging tools. If you are willing to contribute to this survey, could you send me a brief description of the tool (1/2 page max) or of the complete environment (4 pages max) you have developed. Please, also add pointers (bibliography references in Bibtex form + Web site address). Thanks for your cooperation. Dr. Jean-louis PAZAT. PAMPA Team IRISA Phone : +33-99-84-72-14 | Fax: +33-99-84-71-71 e-mail : pazat@irisa.fr | Web: http://www.irisa.fr/prive/pazat/ address: IRISA Campus Universitaire de Beaulieu 35042 RENNES 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 Mon Feb 26 17:04:40 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id RAA23939 for hpff-out; Mon, 26 Feb 1996 17:04:40 -0600 (CST) Date: Mon, 26 Feb 1996 17:04:40 -0600 (CST) From: owner-hpff Message-Id: <199602262304.RAA23939@cs.rice.edu> >From: Mary E Zosel Subject: hpff: January 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 January 9-12 Houston, Texas Record of Action: Mary Zosel Executive Summary There were 20 people from 17 institutions present. Attendance was impacted by severe storms on the east coast that delayed some and grounded others. 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: Query of function results in local library (11-0-5) Proposals still in progress of second reading: Clarification/ simplification to intrinsic reduction proposal (previously passed). Proposals passing in first reading: User-defined reduction (8-5-4) Elimination of explicit mapping of sequential data (11-0-6) SPMD_HPF extrinsic interface (11-0-7) Processor sections as distribution targets (14-1-3) Specification of distribution ranges (15-0-4) ON proposal (15-4-1) Proposals discussed in a preliminary review: Possible disjoint processor subsets. Out-of-core array specification (dropped 2-7-10). Task/end Task (8-2-8) --- Other items of special note: An update of the HPFF WWW pages is planned. A vendor group was chartered to address the issues of language split and what content and names should be from a marketing perspective. Their initial recommendation, which will be considered in more detail at the next meeting, is that there be a subset language, a full language that includes HPF1.1 with minor exceptions plus a few new features, and a set of approved extensions that include the other features discussed in the HPFF 2 meetings. This has not be formalized. The next HPFF meeting is schedule for Arlington (Dallas area) March 13-15. There is also an HPF Workshop planned in conjunction with HPCN 96 in April and two additional HPFF meetings planned for May 1-3 (Arlington) and September 18-20 (San Francisco), with the expectation that there will be a public comment period between May and September. End of Executive Summary ____________________________ Detailed Record of Action The meeting was called to order by Ken Kennedy Chair Tuesday Morning, Jan 9. Due to "Blizzard 96" a number of people planning to attend were stranded on the east coast. Most eventually arrived, to give an attendance of 20 people from 17 institutions. Because of the staggered arrival, issues requiring voting were deferred until Wednesday. 1st 2nd group E kernel done 2 am interop done 2000 am format Jan Mar explicit interf done 2 ~ SPMD-HPF Jan Mar local_global func Jan Mar group D irreg map done 2000 ? dist exten dead dist ranges Jan Mar seq. nonmap Jan Mar subsets Jan derived type done 2000 gls- pper shadow width done 2000 co OOC Jan Mar group C async done 2000 lm on Jan Mar reduc - simple partly done 2 rs reduct Jan Mar task Jan Mar gen transpose done 2 rs inq updates ? ~ rs whoami needed After a review of the status of proposals (above), the group broke into two subgroups - one to address the cci issues from group C, and the other to plan updates for the HPFF WWW page and work on the 1.2 document update. The group reconvened at 3:40 pm. with 4 additional people present. WWW update Ken will provide staff to work on a reorganization and update of the HPFF web pages. Two overall goals are to automate as much as possible, and give the people who generate the remaining information access so that they can do direct updates of the remaining pages. Barbara Chapman will establish a site at Vienna where the main pages can be regularly forwarded, so that a European mirror site is also up to date. There are three major kinds of information on the pages: implementation status, meeting/technical information, and information about related projects/efforts. These will each be handled separately. Implementation status: The goal is to get this information into a database - hopefully with automated updates, queries, and views. New proposed views are what platforms a given software company supports, and which implementations are available on a given platform. Software companies would have the responsibility of submitting a template to keep the information up to date about where a product runs. For HPF2 information: - keep this up to date by the person responsible. Desired information includes meeting information (dates, announcements, minutes), proposals (list, status, text), and document drafts as they evolve - especially as they are ready for public comment. For the related efforts: add new categories about education and workshops, and complete the automation. Currently forms are submitted, but it is up to human interaction to update the pages. We need to talk to Mississippi State about transition to the new pages and leaving a functional page at the original www address. Editing - subgroup has text for many of the cci's and a goal is to have a draft 1.2 document soon. Rob Schreiber presented the CCI items from Group C CCI 18 - X3 J3 has a resolution for a defined assignment in a forall. Propose we adopt the same solution. Decision taken by WG5 was to prohibit variable on left-hand side of defined assignment from being referenced elsewhere. Recommend we adopt the same: Section 4.1.1, page 59, line 29, add the following paragraph: "in a , a defined assignment subroutine must not reference any that becomes defined or that becomes associated by the statement." CCI 36 Can a call in independent cause an actual to remapped? Resolution - no - it is almost forbidden in 1.1 Enlarge the prohibition against remapping a dummy adding - "This forbidden remapping includes remapping due to a subprogram invocation in which an actual argument that is a variable name or a regular array section is argument associated with a dummy argument that has a different mapping." A similar sentence should go into the rational - CHK will do it. Some discussion about how this applies to the HPF library ... this is from page 85 of v1.1. third bullet ... CCI 37 - Locals of subprograms called in independent DO loop automatically - new? Was resolved in 1.1. - no change needed. CCI38 - Follow MINLOC example, use 1-based indices. Make a document change to clarify required. (does LB need to be added by user or library). In F90 you must added it yourself, but in GRADEUP, HPF does it the other way - library adds it for you. INTEGER A(5:10) CALL SUB(A) ... EXTRINSIC(HPF_LOCAL) SUBROUTINE SUB(D) USE HPF_LOCAL_LIBRARY INTEGER D(4:), L(1) CALL GLOBAL_TO_LOCAL (D, G_INDEX=(/5/), L_INDEX=L) END Does 5 mean A(5) or 5th element of A??? Decision was to go with the 1-based, since it is in harmony with Fortran assumed-shape, and in some situations, it is not possible to get at LBOUND, (e.g., for ABSTRACT_TO_PHYSICAL). --- in the above it is A(9). Henry will edit the source files for Rob. Rob / Henry will check how many this applies to. CCI Item BB (new item) PURE RECURSIVE FUNCTION LISTLEN (L) RESULT (R) TYPE LIST SEQUENCE TYPE (LIST), POINTER :: NEXT INTEGER :: VALUE END TYPE LIST TYPE (LIST), POINTER ::L IF (.NOT. ASSOCIATED(L)) THEN R=0 RETURN ENDIF R=LISTLEN(L%NEXT)+1 END Problem p.76, lines 10-11 prohibits pointer dummy argument of pure function from being associated with another pointer dummy argument on a procedure reference. This seems overly restrictive, so the proposal is that P.76 line 10- 11 change to: "· As an actual argument associated with a dummy argument of a pure subroutine with INTENT(OUT), INTENT(INOUT) or the POINTER attribute." And include this example in the document. There was a digression of discussing how this is different from F95 pure and also that F95 has a different solution to CCI #3 (allocate in pure). CCI new item (CC): Need to clarify text in HPF_LOCAL to make it clear that each instance of the HPF_LOCAL gets its own copy of HPF_LOCAL common blocks and HPF_LOCAL module data. (That *was* the intent, wasn't it??) Rob will do this. Mary notes that SAVE is necessary. CCI #40 - NEW(I) for DO loop index Resolution legal - guarantees that I is not used (value is not referenced) following the loop. CCI 41 / 42 and were OK as answered. CCI #29 EXTRINSIC in Independent Resolution - no change. (Yes, you can do it). Issues ready for discussion Wednesday were reviewed. ........... Wednesday AM - Meeting started at 9:00 with Ken as chair. Two more people from the east coast storm area were present. For the first agenda item Chuck Koelbel presented a possible HPF document outline. David Loveman noted that the ack. section is missing(should still be there). In some discussion about where technical items would go: INHERIT belongs in HPF 2. SEQUENCE probably goes, in chapter 4 with how to cope in chapter 8. Query about F95 intentions. There probably needs to be a new item in part I. Also there is a new item to add on Parallel I/O How to handle the syntax rules??? Put the complicated ones in Part II and handle the restrictions in the text??? Numbering is a problem. Other considerations are reader understanding and also what kind of errors we expect HPF2.0 compilers to produce. David has produced an MS word version of HPF 1.1. There was an extended discussion about document formatting. A subgroup will meet and discuss. Rob would prefer to stay with LATEX for the inquiry section. Ken said he would try to contact Adobe about licenses for FRAME. ------- Jerry Wagener gave an update about F2000 Content and Process ISO Technical Reports in preparation are: A. Floating-point - Exception Handling B. Interoperability with C C. Allocatable components, dummy arguments, function results D. Parameterized Derived Types (not yet approved by ISO as TR, but may be) Specialized development bodies will develop the report (quickly) and X3J3 will Review. then these will become a formal WG5/ISO Technical Report. This represents a new model for speeding up standardization. Other F2000 Requirements - to be handled by X3J3: 1. Derived Type I/O 2. Condition Handling 3. Pointers to Procedures 4. Asynchronous I/O 5. Command-line Arguments 6. Specifying Default Precision 7. Object-oriented Fortran (still ill-defined concept) 8. Remove limitation on statement length 9. Private and Shared Data in Parallel Processes (how to handle things like exceptions that only happen on one processes) - ill-defined. This is a problem that needs to be fixed, but not sure what, and how to fix. Ken pointed out that X3H5 did do careful work in this area. 10. Processor-dependent list These will he handled by X3J3 ... then the ISO TR's will be integrated. WG5 will take the approach of intrinsic functions for conditions handling, instead of the ENABLE proposals. Ken asked how a TR subject gets created. Jerry: go to WG5 meeting and convince them - WG5 then convinces ISO. Ken wondered about the possibilities of getting some of HPFF document into the status of a published TR. If we identified such subsets - we might work with some subgroup of X3J3. To get at WG5 information, one can look at: http://www.etrc.ox.ac.uk/WG5. ============== Next Rob Schreiber presented the reduction proposals First, clarifications to the simple reductions (we already had a 2nd reading): (1) Intrinsics - all associative (math, not infinite precision); two not commutative: //(concatenate), and MATMUL. (2) Use whole array, regular section, or single element in any reduction forces the whole array is a reduction variable (example) !hpf$ independent Do !hpf$ reduce x(i) - x(i) + 1 print *, x(2) ! bogus all of x is a reduction variable end do This is a different way of saying the simple reduction. It makes the previous proposal a little simpler and makes it clear that the whole array is involved and puts it just in one place instead of a number of directives. (3) External syntax !hpf$ independent, reduction (x,y,z) do i=1, ... n .... ! x only allowed in reduction statements enddo Since this is a change (potential simplification) to previously passed item - procedure will be .... if accepted, second reading ... but request to have Rob present the full revised proposal. 15 - 0 - 3 strawpoll. ------ VERY SIMPLE extension for User-Defined Reduction First reading !hpf$ independent reduction (x, A=MY_ID(-)) do i-1,n x = x+1 A = MY_OP (A,B) ... A= MY_OP(C,A) ... only allowed if MP_OP is commutative Propose a new keyword in the language that is used in the same place where PURE is ... COMMUTATIVE: PURE, COMMUTATIVE, TYPE(MY_TYPE) FUNCTION MY_OP(A,B) Chuck argues that COMMUTATIVE should stay as a directive instead of first class keyword --- since it just gives information for another directive Amendment - commutative should be directive rather than syntax ... strawpoll 8 - 2 - 8. More discussion the larger issue of user-defined operators in reductions. Jaspal asks about if these functions (pure) are functional enough? Others ask if this is too much - why should we have this even in HPF2000? Has there been some experience. Yes - Jaspal has some, but PURE is too restrictive. Should there be a second reading of a reductions for user-defined reductions: 8 - 5 - 4. Ken requests a development of a second reading. BREAK ... Carol Munroe: First Reading of a proposal to limit mapping sequential data. Proposal: A sequential array cannot be explicitly mapped. (i.e. remove exception for 1-D sequential aggregate covers.) Reasons: 1. Make the language simpler for users. (Eliminate painful definition of aggregate covers in 5.7.15 - 5.7.17.) 2. Simplify the compiler and the generated code. 3. The old rule may not help old codes anyway. And no vendors have implemented it or even plan to do so. Straw poll - 11 - 0 -6 ------------------- Andy Meltzer - overview of SPMD straw proposal: 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 multithreaded language like HPF_LOCAL. It allows seamless use of low-level paradigms, such as message passing, get/put, and explicit sync. All HPF 2.0 language and directives are features plus additional features for SPMD control and additional rules defining relationship between HPF_LOCAL and HPF2.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. A multi-threaded model allows easier migration path for MP users, so HPF is no longer "all or nothing". Extrinsic environment allows well defined interface to standard HPF. Many of these are currently successfully in use. New in SPMD_HPF Data defaults are those of HPF_LOCAL, called private. The interaction between private and explicitly mapped data is defined. Parallel inquiry intrinsics added (IN_PARALLEL, IN_INDEPENDENT). Serial regions are added (MASTER/END/MASTER). Explicit sync primitives are added. Assorted other features are suggested that have been useful in CRI's Craft. Data Mapping No changes from HPF 2.0. All data distributions formats are available. Data defaults to private (the default behavior of HPF_LOCAL). If explicitly mapped, the array is shared - if not explicitly distributed, it is private on each processor. Note that scalars are private by default ... would have to make some explicit distribution to force the value to be the same across the processors. Input and Output I/O behaves like HPF_LOCAL I/O. Subprogram Interfaces Subprogram interfaces behave exactly like HPF 2.0 for explicitly mapped data. Subprogram interfaces behave exactly like HPF_LOCAL for private data. The interaction between private and explicitly mapped data is defined in the written proposal. The INDEPENDENT Directive In one form, INDEPENDENT looks and behaves exactly like in HPF 2.0, except that private data is allowed to vary in value between processors. Because we don't yet have any ON_HOME, the ON_HOME version of Craft is put in as a place holder. At this point there was a long discussion to clarify the model, the difference between this and HPF and HPF_LOCAL and ??? Chuck posed this example: DO I=1,5 A(I) = 1 ! A private B(I) = 2 ! B distributed END Given 4 processors, and 20 elements for A and B, this will do 1-5 on each processor, hitting the first 5 elements of B multiple times. A motion to kill the whole presentation died for lack of a second. INDEPENDENT has an interesting difference .... do is more like a DO_PARALLEL in PCF ... when applied to a DO loop with or without independent. In the model above - with INDEPENDENT - there is worksharing - someone does B(i) - without INDEPENDENT, there is no worksharing ... every processor does the B(i) - and then ships it to the owner of B(i) in the case of a distributed B. 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.0. All processors must co-operate. Mixing private and explicitly mapped at is defined, specific rules are give in the written document. Serial Regions In a multi-threaded environment it is useful to start a single-threaded section, operating on one processor. MASTER/END MASTER are used for this. Synchronization Primitives - locks, critical section events, barriers are also defined. Other user possibilities from Craft are: no barrier - parallelism specification, resident, assertions, geometry. Ken: A way to think about this - these extrinsic environments we are looking at are something like the TR from F2000. There could be infinite extensions to the language, if we think about them as part of the language itself. Here is a model a number of people are using: we can either be concerned with a clean interface - or as part of the language. Straw poll about whether this should be proposed as a second reading for March: 11 - 0 - 7. Break for lunch .... 1:40 reconvene Larry Meadows (and Vince Shuster) Portland Group presented a proposal related to the naming of the language split - and the contents of the language split. The concept of a separate kernel HPF and enhanced HPF is valuable, but the HPF2000 and HPF 2.0 designations were arrived at without proper market considerations. Confusion and controversy exists. HPF acceptance, HPF process credibility and HPF vendors will be affected by the designations. The HPF 2000 name does not foster a notion of it being commercially viable, but rather sounds like a good idea that will never be implemented. A consideration: should be code that is HPF 1.1 compliant that will not be HPF 2.0 compliant? Ken summarized the concerns: HPF 2.0 never. Proposal: A task force be created to redesignate these language. The task force should be composed of HPF compiler vendors and MP system vendors. Charter: Determine designations that will advance HPF kernel acceptance and establish the enhanced HPF's commercial viability. Emphasize separate HPF Kernel as the choice for portability and performance. Address compliance issue for HPF1.1. programs that would not be HPF kernel compliant. Submit recommendations ------- At this point there were several cheerful asides about possible names: Cheerful aside about names: hpf_commercial vs hpf_academic hpf_real vs hpf_virtual hpf.com vs hpf.edu vs hpf.gov (for the users) Serious point - before the break, we just had a very positive vote to take the explicit mapping of sequential variables out of the language. What would this mean for HPF 2.0? Question about who would make up this task force? Parallel vendors who have some HPF on their system? The task force should report back like any of the subgroups do. E.g. report the votes. Proposal on the table by next time. ==================== The group adjourned for subgroup meetings, including a first meeting of the set of vendors about the Portland Group proposal. Thursday Morning January 18 Carl Offner raised the issue of a technicality in the shadow width proposal that we have accepted. Specification-expression should be constant- specification-expression. This modification was accepted. Barbara Chapman presented the first reading of mapping to subsets of processors. The proposal is split in 2 parts: (1) - Processor sections as distribution targets: Replace H311 by dist-target is proc-name [(proc-section-subscript-list)] or * proc-name [(proc-section-subscript-list)] or * proc section-subscript is subscript or subscript-triplet constraint: the number of items in the proc-section-subscript-list must equal the rank of proc-name. constraint: the subobject referred to by proc-name [(proc-section-subscript- list)] may not have size 0. constraint: Each subscript should be an integer specification expression. The subcommittee vote was 4-0-0. The full committee (straw) vote 14 - 1 - 3. Chuck asks if the constraint on the subscripts still applies to redistribute. (2) Second part of the proposal - We want to be able to have the possibility of having disjoint processor subsets - e.g. for a multi-grid distribution - we cannot define 2-d processor array so that disjoint sections of these shapes "fit in" - tasking also will require disjoint sections of available processors with high degree of flexibility. This functionality can be provided by definition of subgroups and reshaping of processor arrays - for example: !hpf$ processors p1(20,20) !hpf$ subgroup psub of P1( 2:6, 3:15:2) !hpf$ subgroup psub1(50) of p1(6:100,1:10) This gives a flexible means of obtaining, in particular, arbitrarily shaped disjoint subsets of processors. But there appear to be several ways to do this; it isn't clear that this is the right way to go. Subcommittee recommendation: This needs yet more work - but isn't ready for a vote - even a first reading. Chuck asks if the reshape intrinsic was considered. ======== Mapping intrinsics need to be reviewed with respect to subsets. ============== The first reading of a proposal for distribution range specification was presented by Henry Zongaro. Rationale: For transcriptive distributions, DYNAMIC and pointers, compiler may have to generate very inefficient code to ensure that it correctly handles all cases. Very often, a user will only need a small subset of the possibilities in a particular program. In order to permit the compiler to generate more efficient code in such situations, the user can specify distribution ranges for such objects. Two examples of possible syntax: subroutine sub(a) integer a(:,:,:,:) !hpf$ inherit a !hpf$ range a (block, * case(block,cyclic(), indirect),all) or !hpf$ range a(block,*,block,*),(cyclic*cyclic,*) or combine the two e.g. pull in the case Possibilities BLOCK - compatibility with BLOCK,BLOCK() CYCLIC(), ALL BLOCK(n) - comp. with BLOCK(), CYCLIC(), ALL CYCLIC - comp. with CYCLIC, CYCLIC(), ALL CYCLIC(n) comp with CYCLIC(),ALL * comp. with ALL or * GEN_BLOCK- comp. with GEN_BLOCK or ALL There may be a need to work out some details about pointers being passed. Carol asks about the case where just a part of an array is passed - e.g. A(2:n) Joel --- When would this actually be used? Barbara and Carl both provide examples. Straw poll about the overall proposal- 15 - 0 - 4 Some straw polls on the details: first syntax --- 6 - 4 - 9 second syntax --- 11 - 0 - 7 combination --- 4 - 6 - 9 There seems to be a preference for the second syntax. ============ Next Alok gave an over view of the Out-Of-Core proposal: !hpf$ template temp(100,100) !hpf$ distribute temp(block,block) !hpf$ align with temp:: A,B !hpf$ out-of-core: A() ... { user associates a metadata file by an open statement which opens the metadata file on unit number - if is old persistent}. !hpf$ out-of-core:B ... { compiler is free to choose a unit number and file name}. Persistence of an array "specified" using the open statement by extending STATUS field STATUS = OLDPERSISTENT ! already exists = NEW PERSISTENT ! create and store = OLDSCRATCH ! already exists, no need to save = NEWSCRATCH ! create , delete after using Other restrictions: - unformatted only - direct access only - read write only Metadata should: - contain names of files containing OOC, persistent array - processor arrangement that created persistent array distribution information - data type (record ...) - organization of data within files(s) This information should be accessible using inquiry functions. Chuck asks if these can properly be considered directives, or should they be first class statement? This was followed by various comments such as: "interesting, but too premature to talk about standardization", "might be a way to address new architecture directions", and questions about details of open, status, persistence options, etc. Straw poll about interest in pursuing: 2 - 7 - 10 OOC will be dropped. ============= Carol presented the proposal to fix a local-global issue that stemmed from an earlier CCI. Query functions for array-valued extrinsic HPF_LOCAL functions, specifically the following HPF_LOCAL_LIBRRY procedures: GLOBAL_ALIGNMENT(ARRAY, ...) GLOBAL_DISTRIBUTION GLOBAL_TEMPLATE GLOBAL_LBOUND GLOBAL_UBOUND GLOBAL_SIZE GLOBAL_SHAPE(SOURCE) ABSTRACT_TO_PHYSICAL PHYSICAL_TO_ABSTRACT LOCAL_TO_GLOBAL GLOBAL TO LOCAL LOCAL_BLKCNT LOCAL_LINDEX LOCAL_UINDEX(A Currently, each of these procedures accepts an argument ARRAY (or SOURCE), as an INTENT (IN) argument that is a dummy array argument to the extrinsic function. Proposal: Modify the description of each ARRAY argument to read "it must be either a dummy array that is associated with a global HPF actual array argument or the array-valued result of a HPF_LOCAL function called from HPF. 2nd reading vote --- 11 - 0 - 5. This goes where ever rest of local library goes HPF2/HPF2000. BREAK ---- SubGroup C proposal processing .... Chuck - 1st reading mostly for HPF2000 features. ON Proposal Motivation Some programmers want more control: which processor executes the operation makes a big difference whether data is moved makes a big difference ON HOME recommends where operations should be executed ... similar to the way DISTRIBUTE recommends where data should be placed RESIDENT asserts that data need not move similar to the way INDEPENDENT asserts that operations are parallel Changes to proposal document since September: local is spelled RESIDENT ALL is spelled EVERY BLOCK is spelled BEGIN Declarative ON clause applies to the whole procedure 2 Options - ON propagates through CALL, and it doesn't If ON propagates through CALL, the callee must also declare ON Changes last night: Clarify RESIDENT meaning for reads and writes RESIDENT may be separate from ON asserts locality relative to the surrounding ON RESIDENT(X) means what RESIDENT (EVERY(X)) used to ON propagates through CALL (with declaration) Resident propagates through CALL (no declaration needed) Add a NEW clause to ON HOME (analogous to INDEPENDENT) ON HOME Examples !HPF$ ON HOME(a(i)) a(i+1) = b(i) + a(i) ----- DO i - 1,n !HPF$ ON HOME (A(index(i))) BEGIN a(index(i)) = b(i) b(i) = c(index(i)) !hpf$ end ON END DO ---- !HPF$ ON HOME(x(i,:)) BEGIN DO j= 1,m !HPF$ ON HOME (x(i,j)) x(i,j) = foo (y(j,i)) END DO !HPF$ END ON ======== CALLS in ON HOME Blocks Consider: !HPF$ ON HOME (a(1)) CALL foo(a) --- SUBROUTINE foo(x) ! ON must be a subset of the caller !HPF$ ON HOME(x(1)) x(2) = ... The problems: Does the compiler know which processors should execute FOO? Yes. Can the compiler allocate and use local data? Yes. Local data in FOO must be mapped on HOME (x(1)). What about global data? It's tough. Ignore ON and set up 2-way communication. Constraints on declarations need work. Discussion - points out that may need some local processor arrangements declarations. Maybe relax the restriction that processor arrangements match the total processors - so that they match the current ON processor set. --- RESIDENT Examples: !HPF$ ON HOME(x(k)), RESIDENT (xindx(k)) x(k) = x(indx(k)) + y(indx(k)) --- !HPF$ ON HOME(indx1(i)) BEGIN n1 = indx1(i) n2 = indx2(i) !HPF$ RESIDENT (x(n1), y(n1)) BEGIN tmp = y(n1) - y(n2) x(n1) = x(n1) + tmp x(n2) = x(n2) - tmp !HPF$ END RESIDENT !HPF$ END ON Rob asks about if there should be some restrictions on the values of subscripts used in the RESIDENT clause? Is it an assertion about the lexical expression - or about a specific value? --- New and Old RESIDENT !HPF$ ALIGN y(i) WITH x(i) !HPF$ ON HOME (procs(1:2)), RESIDENT(x) ! "every element of x touched is local" x(i) = x(indx(i)) ! (i), x(indx1(i), x(indx1(i)) are local y(i) = y(indx2(i)) ! y(i) local, is y(indx2(i))? !HPF$ END ON ! THE OLD WAY - obsolete !HPF$ ON HOME (procs(1:2)), RESIDENT(x) x(i) = x(indx1(i)) ! every element of x is local y(i) = y(indx2(i)) ! every element of Y is local !HPF$ END ON --- Interprocedural RESIDENT !HPF$ ON HOME(procs(1:mp/2)) [, RESIDENT] CALL foo(a,b) --- SUBROUTINE foo(x,y) !HPF$ ON HOME(procs(1:np/s)) [, RESIDENT} Options: caller has RESIDENT, callee has RESIDENT Complete info, compiler has no problem caller has RESIDENT, callee doesn't have RESIDENT call can happen on half of processors, two-way comm will work caller doesn't have resident, callee has RESIDENT caller must compile for hard case, callee won't use half machine caller doesn't have RESIDENT, callee doesn't have RESIDENT Do it the hard way At this point the subgroup C members had an extended subgroup discussion about the correspondence between ON/RESIDENT and explicit interface requirements. In simple cases should calls require explicit interfaces? ---- On Directive in HPF 2.0 Restrict subscripts in HOME Only affine functions of DO loop indices. We also need variables that are invariant in the loop nest. HOME(x(i+1)) OK HOME(x(n-i+1)) OK HOME (x(indx(ii)) not OK Are other restrictions needed? Calls not allowed? Discussion of proposal as a whole - skipping details. Carl: problems of when functions enter into the picture - is this mostly for shared memory??? Otherwise, this is leading the user in a misleading direction that has performance impact. What assumptions that subroutines execute on all processors vs a subset? Larry points out FORALL already assumes separate calls. Discussion continues ... Straw poll on full proposal: 15 - 4 - 1 Should calls be precluded? yes = no calls ... 2 - 9 - 9 Should explicit interface (with explicit ON) be required? 8 - 1 - 10 Should any of this be in HPF 2.0??? 3 - 7 - 11 (Subgroup won't put lot of priority) Break at 12:15 for lunch -------------- Rob presented the latest version of a TASK proposal. Multiple HPF processes running in parallel each on a collection of processors - all in the same name-space. Most profitable if and only if data can be mapped in a way that data items are distributed to subsets of processors. Even the simple proposal about processor subsets before lunch facilitates some of this. --- Recall ON_HOME (PROCS(LO:HI)), RESIDENT BEGIN ... END ON ... this implies Every read in ... reads a variable with a copy on PROCS(LO:HI) and Every write in the block writes a variable with no copies outside of PROCS(LO:HI) --- Two new Intrinsics are proposed: ON_NUMBER_OF_PROCESSORS() ON_PROCESSORS_SHAPE() They will inquire about the state of processors in the inner-most enclosing ON HOME. -------- Strongly Parallel Tasks ... Proposal that doesn't require any additional mechanisms: ON HOME(PROCS(1:10)), RESIDENT, BEGIN CALL F(A) ENDON ON HOME (PROCS(11:20)), RESIDENT, BEGIN CALL G(B) ENDON Note these two ON blocks are disjoint ... no dependence no 1-sided communication needed other procs skip the ON barriers not needed (except for dependence from prior code, subsequent code.) Technical detail - there may be some additional issues related to I/O, etc. so there may be a needed assertion that says do it in parallel so that the compiler would know for sure that there were no side-effects. Or maybe that some outer hull is needed to group some things together ---- When RESIDENT is not available (SMP?) still need a way to assert independence: so might want something like TASK on_home(P1) f(A) on_home(P2) g(B) on_home(P1) END TASK Asserts that there is no dependence between two ON's in the regions if their HOMES are disjoint. Allows parallel execution by procs skip ON if not part of HOME Barrier at start of each --- NEW used for strong task parallel code: ON_HOME(A), RESIDENT f(A) ON_HOME(B), NEW(I), RESIDENT DO I=1,N .... END DO END ON Same assertion as INDEPENDENT ALLOWS privatization RESIDENT(I) implied. Straw poll 8 - 2 - 8 ... about developing more proposal for the TASK/END TASK Should there be some new intrinsics? Straw poll: 11 - 2- 5 --- SUBROUTINE SUB(x) REAL x(:) !HPF$ environment :: ON_HOME() !HPF$ distribute x(block) ONTO .... should there be something to say on the current ON set? !HPF$ processors procs Should the rules be changed to be able to talk about processor arrangements that are size and # of ON_HOME processors. Currently, we have no way to talk about the inherited set of procs. There are some difficulties that arise from not knowing the rank? Should they work on this? Strawpoll: 7 - 2 - 9 ====================== Rob presented a proposal for how the library changes with generalized distributions. HPF_DISTRIBUTION (A, ... PLB, PUB, PSTRIDE) !hpf$ distribute A onto PROCS(1:10,4:12:2) PLB = (/1,4/) PUB = (/10,12/) PSTRIDE - (/1,2/) HPF_DISTRIBUTION (A,AXIS_TYPE) Real a(10,10,10,10,10); INTEGER SIZES(4), map(10) !HPF$ DISTRIBUTE A(cyclic, block,*, BLOCK,*,BLOCK(SIZES), INDIRECT(map)) AXIS_TYPE = (/'cyclic',"block","collapsed","gen_block","indirect"/) MAP = MAP_ARRAY (A, DIM= 5) SIZES = BLOCK_SIZES (A,DIM=4) REAL A(10,10,10,10) PROCESSORS P(4,3,2,2) INTEGER sizes(2), MAP(10) SIZES = (/3,7/) MAP = (/1,1,1,1,1,1,1,1,1,2/) !hpf$ distribute A(BLOCK, CYCLIC(3), *, BLOCK(SIZES), INDIRECT(MAP)) !HPF$ [BLOCK_SIZES or NUMBER_MAPPED] (A,DIM) if DIM = 1, RESULTS = (/3,3,3,1/) DIM = 2, RESULT = (/4,3,3,1/) DIM = 3, RESULT = (/3,7/) DIM = 4, RESULT = (/9,1/) Votes on generalizing distribution: 14 - 0 - 4 New inquiry functions about sizes: 12 - 0 - 6 ============== The report from the vendor subgroup at this point was - no report - a lot of disagreement. Joel Williamson proposes that we call HPF2000 a JOD and freeze 2.0 where it is now. Ken rules this out of order - that a group has been chartered to address the issue of naming of the language. Break for subgroup meetings until 7pm plenary session. 7 pm evening session The vendor subgroup returned with a report of things that all of the vendors could agree about. The proposal is that the language features be in three sections. Note the names BIG and SMALL are just place holders. #1 HPF JOD HPF 2000 and most of the new features. #2 HPF BIG: (HPF 2.0, full HPF) HPF 1.2, plus Intrinsic Reductions (commutative only), explicit interface requirements minus pointers?, aggregate covers, REALIGN, REDISTRIBUTE, DYNAMIC - with different mechanism to handle ALIGN, DISTRIBUTE. HPF SMALL: (HPF 2.0 kernel) Has HPF 2.0 as defined last meeting , minus pointers. Suggestion Mention HPF and HPF www site regularly in comp.lang.fortran, comp.parallel, comp.system ---- Ken: The terminology JOD has a history of implying that features haven't been thought out. Find some other name. Sentiment that the name should not imply that it is a "language". Some suggestion that JOD should be called something more like Provisionally approved features. Question by Ken: with this approach, why not just publish the HPF1.2 document - drop the "JOD" features entirely, and say we are done. Discussion: (this was not the vendor intent). The features in "full HPF" are things that all the vendors except CRI are committed to implementation. Do we treat this as a first proposal, and vote on it the next time. Chuck: What does this say about the proposed document outline? Could make the kernel an appendix - or - maybe it would replace the subset chapters. straw poll - 13 - 2 - 1 as a first reading - develop a full proposal for next meeting. Another possibility is something in the appendix - that has the features - and are call endorsed extensions. Can talk about a document outline tomorrow morning. ========= Barbara: At HPCN Europe 96 (Brussels, April 15-19 1996 ) an HPFF workshop is scheduled. April 19 is workshop day. SPONSORS(LOCAL) : PPPE (Barbara Chapman) Prepare (Henk Sips) Program Chair: Alok Choudhary format: full-day workshop (6 hours) Suggested title: High Performance Fortran: Status and Development Suggested topics: Compiler(Tools?), User Experience, Motivation for language Extensions/overview Program draft Morning: current status Introduction & Overview 30 - 60 minutes: Ken Compilers 90 minutes: - Larry+? User Experience 60 minutes - European speaker, good experience, frustrated user - doesn't look like good possibility for US user. Afternoon: Language Development Motivation and User Requirements 60 minutes - European speaker Overview of Extensions 30 minutes Panel Discussion 90 minutes Who planning to go? Ken, Alok, Larry, Chuck, (Harvey Richardson), Barbara, Henk. Maybe Jaspal??? or Paul on motivating applications. Further discussion offline. Ken suggests maybe a pared down version of Chuck's tutorial Thursday evening. Henk will see if this is possibility. Ken would give a pitch for this in his talk on Thursday. ============= Henry Zongaro gave a report about the status of WG5 Interoperability with C. HPFF example Interface Extrinsic(c) function f(A,B,C,D) External_NAME("MyCFunction") Integer, MAP_TO (short, LAYOUT-C_ARRAY) :: A(100,100) REAL, MAP_TO (float) :: B(100) REAL, MAP_TO (double) ::C INTEGER, MAP_TO(int) :: D end Function F End Interface WG5/interop example from a pending proposal Interface Bind(Name="MyCFunction", LANG=C) FUNCTION F(A,B,C,D) USE ISO_C INTEGER (C_shrt_ki):: A(100,100) REAL (c_flt_kr):: B(100) REAL (C_dbl_kr)::C INTEGER (c_int_ki) :: D END FUNCTION F END INTERFACE TYPE DT CSTRUCT INTEGER (C_shrt_ki) ::A REAL (C_flt_ki):: B(100,100) ENDTYPE DT 1) Extrinsic mechanism is useful, should be used - explicit interfaces are not required for BIND, which seems like a bad idea. 2) Name binding should remain part of EXTRINSIC statement unfortunately, doesn't immediately do COMMON means LANG - isn't needed N.B. for both proposals, lower case letters are required for conformance. 3) extern is a problem for both proposals COMMON could be implemented on some platforms in a way that cannot map to extern might invent a different mechanism 4) Two mechanisms for type mapping KIND mechanism MAP_TO attribute Weaknesses: KIND MAP_TO - character - new machinery - array transposition - doesn't handle structure - can't handle types that are not representable - new machinery for structures - pointers - pointers - typedefs - typedefs difference - HPFF type doesn't require that the Fortran side have, for example, a specific type that maps to SHORT, while the WG5 draft would require a specific type Ken: Suppose I'm a Fortran programmer who needs to call C. With the KIND approach, I can take the new C kinds ... and use them through out the program ... or I can copy to a c-type when it is time to use them and then copy back ... this is not a user-friendly approach. The MAP_TO approach does this automatically. Should we work on a revised proposal to combine ideas at the March meeting. Andy and Henry to prepare proposal. ------------- Meeting: March 13-15 May 1-3 are the current dates for meetings. If we produce a document for comments in May. Could process in Sept. If everything is done in May we might have a June 15 document out to public on the net.. Deadline Friday Sept. 13 - meet 18-20 September. Public comment mid-June to mid September. The September meeting will be in the San Francisco area. Rob will locate a place. ======================== Excerpt from Andy Meltzer's LPF report: (We've done most of the work already) LPF III...I No LPF committee member need to return early due to bad weather - no one wants them ack - no one wants HPF members back either but they are pushier. Any vendor who wants may claim full LPF compliance - We're still waiting. LPF has demonstrated a successful implementation: The hotel elevator at the Windham Greenspoint New Proposal first reading: !LPF$ ADDRESS details will be filled in if it passes first reading Note the meeting adjourned after a late evening meeting Thursday to all some east coast people to catch earlier flights home on Friday because of another pending heavy snow storm. Small group discussions on Friday am talked about document outlines and updates. ======================================================== Draft Jan Attendance: Barbara Chapman University of Vienna barbara@vcpc.univie.ac.at Alok Choudhary Syracuse U. choudhar@cat.syr.edu Steve Fink UCSD sfink@cs.ucsd.edu Ken Kennedy Rice U./CRPC ken@rice.edu Charles Koelbel Rice U. chk@cs.rice.edu David Loveman Digitali loveman@msbcs.enet.dec.com Larry Meadow The Portland Group lfm@pgroup.com Andy Meltzer Cray Research meltzer@cray.com Carol Munroe Thinking Machines munroe@think.com Carl Offner Digital offner@hpc.pko.dec.com J. Ramanujam Louisiana St. Univ. jxr@gate.ee.lsu.edu P. Sadayappan Ohio State University saday@cis.ohio-state.edu Paul Havlak U. of Maryland havlak@cs.umd.edu Rob Schreiber HP hplpp3.hpl.hp.com Henk Sips TNO/Delft U of Tech. henk@cp.tn.tudelft.nl Jaspal Subhlok Carnegie Mellon jass@cs.emu.edu Jerry Wagener Oklahoma U.,X3J3 jwagener@cs.uoknor.edu Joel Williamson HP/Convex joelw@mozart.convex.com 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 Tue Feb 27 23:34:50 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id XAA17155 for hpff-out; Tue, 27 Feb 1996 23:34:50 -0600 (CST) 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 XAA17149; Tue, 27 Feb 1996 23:34:44 -0600 (CST) Received: from mcrc.mcd.mot.com (tornado.mcrc.mcd.mot.com [144.191.195.12]) by moe.rice.edu (8.7.1/8.7.1) with SMTP id XAA28304; Tue, 27 Feb 1996 23:34:35 -0600 (CST) Received: by mcrc.mcd.mot.com (8.6.8.2/1.34.tornado) id VAA15791; Tue, 27 Feb 1996 21:04:48 -0500 Date: Tue, 27 Feb 1996 21:04:48 -0500 From: atd@mcrc.mcd.mot.com (Anton Dahbura) Message-Id: <199602280204.VAA15791@mcrc.mcd.mot.com> To: tony-forward@mcrc.mcd.mot.com Subject: hpff: Tony Dahbura's new e-mail address Reply-to: atd@tornado.mcrc.mcd.mot.com Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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. --------------------------------------------------------------------------- [Please accept my apologies if: a) you receive this message more than once, or b) you don't care about its contents!] ************************************************** My new e-mail address, effective immediately, is: atd@abp.lcs.mit.edu ************************************************** Please make a note of the change. Thank you, Tony Dahbura --------------------------------------------------------------------------- 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 Feb 27 23:46:34 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id XAA17542 for hpff-out; Tue, 27 Feb 1996 23:46:34 -0600 (CST) 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 XAA17537; Tue, 27 Feb 1996 23:46:31 -0600 (CST) Received: from mcrc.mcd.mot.com (tornado.mcrc.mcd.mot.com [144.191.195.12]) by moe.rice.edu (8.7.1/8.7.1) with SMTP id XAA28575; Tue, 27 Feb 1996 23:46:24 -0600 (CST) Received: by mcrc.mcd.mot.com (8.6.8.2/1.34.tornado) id UAA15562; Tue, 27 Feb 1996 20:19:55 -0500 Date: Tue, 27 Feb 1996 20:19:55 -0500 From: atd@mcrc.mcd.mot.com (Anton Dahbura) Message-Id: <199602280119.UAA15562@mcrc.mcd.mot.com> To: tony-forward@mcrc.mcd.mot.com Subject: hpff: Tony Dahbura's new e-mail address Reply-to: atd@tornado.mcrc.mcd.mot.com Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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. --------------------------------------------------------------------------- [Please accept my apologies if: a) you receive this message more than once, or b) you don't care about its contents!] ************************************************** My new e-mail address, effective immediately, is: atd@abp.lcs.mit.edu ************************************************** Please make a note of the change. Thank you, Tony Dahbura --------------------------------------------------------------------------- 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 Feb 28 15:12:41 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id PAA13362 for hpff-out; Wed, 28 Feb 1996 15:12:41 -0600 (CST) 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 PAA13351; Wed, 28 Feb 1996 15:12:33 -0600 (CST) Received: from mcrc.mcd.mot.com (tornado.mcrc.mcd.mot.com [144.191.195.12]) by moe.rice.edu (8.7.1/8.7.1) with SMTP id PAA18688; Wed, 28 Feb 1996 15:12:26 -0600 (CST) Received: from mcghub.mcg.mot.com by mcrc.mcd.mot.com (8.6.8.2/1.34.tornado) id KAA20079; Wed, 28 Feb 1996 10:07:07 -0500 Received: from caipfs.rutgers.edu (caipfs.rutgers.edu [128.6.155.100]) by mcghub.mcg.mot.com (8.6.8.p4/8.6.3.mcghub) with ESMTP id IAA17448;Wed, 28 Feb 1996 08:01:00 -0700 Received: from acappella.rutgers.edu (acappella.rutgers.edu [128.6.111.22]) by caipfs.rutgers.edu (8.6.9+bestmx+oldruq+newsunq+grosshack/8.6.9) with ESMTP id KAA05705; Wed, 28 Feb 1996 10:05:06 -0500 Received: (porter@localhost) by acappella.rutgers.edu (8.6.12+CAIPFS_MAIL/8.6.9) id PAA21911; Wed, 28 Feb 1996 15:05:05 GMT Date: Wed, 28 Feb 1996 15:05:05 GMT Message-Id: <199602281505.PAA21911@acappella.rutgers.edu> From: Adam Porter To: atd@mcrc.mcd.mot.com CC: tony-forward@mcrc.mcd.mot.com, atd@au-bon-pain.lcs.mit.edu In-reply-to: <199602280119.UAA15562@mcrc.mcd.mot.com> (atd@mcrc.mcd.mot.com) Subject: hpff: Re: Tony Dahbura's new e-mail address 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. --------------------------------------------------------------------------- Please stop. I have no idea who you are and I've already received 2 copies of this. Why did you send to me??? -- -- Adam ============================================================================= Adam Porter (porter@caip.rutgers.edu) http://www-caip.rutgers.edu/~porter Systems Programmer:CAIP Center,Rutgers University,Piscataway,NJ: 908/445-0655 --------------------------------------------------------------------------- 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 ---------------------------------------------------------------------------