Subject: hpff: March 96 HPFF minutes

From: owner-hpff
Date: Fri, 5 Apr 1996 18:50:05 -0600 (CST)

---------------------------------------------------------------------------
[email-masked] is a mailing list for announcements related to High
Performance Fortran.  Instructions for adding or deleting yourself
from this list appear at the bottom of this message.
---------------------------------------------------------------------------

High Performance Fortran Forum Meeting
March 13-15  Arlington, Texas
Record of Action:  Mary Zosel

Executive Summary
There were 21 people from 17 institutions present at the 
March 96 HPFF meeting.

The group processed the first or second reading of a number 
of language proposals.  Following summarizes the status. 
Details of the proposals are included in the full minutes below.

Proposals passing second reading:
Language naming and content.
Elimination of explicit mapping of sequential data
Amended derived type mapping.
Amended commutative intrinsic reduction.
Processor sections as distribution targets.
Specification of distribution ranges.

Proposals still in progress of second reading:
On proposal. (15-4-1)
Update of inquiry functions.

Proposals passing in first reading: 
Tasking.
Policy for extrinsics.
SPMD_HPF extrinsic summary (new policy).
Update on pointer rules.
Elimination of GLOBAL_LB and GLOBAL_UP
SORT_UP/SORT_DOWN library functions

Invitation for a proposal:  Fortran77_Local
---

Other items of special note:  The question of language name 
and content was again reviewed by the group of vendors.  The 
new proposal which was adopted by HPFF is that there is one 
language HPF  (version 2.0). There will be a chapter 
addressing portable/efficient features - which will outline 
those features previously called the kernel. Most of the new 
features, and a few of the existing HPF 1.1 features that 
have not yet been implemented (most notably explicit 
remapping via REDISTRIBUTE and REALIGN) will be in an Annex 
of Approved Language Extensions.  The hope is that it is 
practical for all vendors to have a full implementation of 
HPF (2.0) within 18 months of approval. The definition of the 
original HPF subset will remain in an annex.  A policy will 
be defined for  proposing extrinsic interfaces which HPFF 
recognizes, and certifies as conforming to HPF expectations 
for extrinsics.  The HPF_SPMD extrinsic being developed by 
PGI/CRI is expected to fall in this category.  These will be 
distinct from the HPF_LOCAL and HPF_SERIAL extrinsics, in 
that HPFF takes responsibility of the definition (and cci's) 
for these two extrinsics.

There is an HPF Workshop planned in conjunction with HPCN 96 in April.
The next HPFF meeting is scheduled  for May  1-3 (Arlington). 
An additional HPF meeting has been added for  San Francisco  
June 26-28.  The final  HPFF meeting is September 18-20 
(again San Francisco),  with the expectation that there will 
be a public comment period between July and September.

End of Executive Summary
____________________________

Detailed Record of Action
Wednesday afternoon  Mar. 13, 96 - HPFF Subgroup Meetings

The  HPFF Meeting convened Thursday AM, March 14 chaired by 
Ken Kennedy of Rice University.

The status of proposals expected for processing at the 
meeting was reviewed:

			1st		2nd
group E                                
	format		Jan		Mar	
	SPMD-HPF-ext.  	Jan		Mar		am	

group D                              

	dist ranges	Jan		Mar		hz
	seq. nonmap	Jan		Mar		cm	
	subsets		Jan		Mar

group C                          
	on		Jan		Mar	
	reduc - simple	partly done	Mar		rs
	reduct - user def.  Jan		Mar	
	task		Mar		May	
	inq updates	Jan		Mar		rs

	whoami	needed

DONE - 
	  (C) async			lm
	  (C) gen transpose		rs
	(D) derived typ			gls
	(D) shadow width		co
	(D) irreg map			
	(E) kernel			am
	(E) interop			am
	(E) local_global func		cm	
	(E) explicit interf			
	~

Technical work began with the second reading of  the 
Distributed Range proposal by  Henry Zongaro.
	(details of this proposal were on a 1-page written proposal which is
	unfortunately not available here)

There are some details to sort out:
 - RANGE only has effect where object to which it applies is 
accessible.  So remapping of an actual for a call does not 
have to match to another subprogram.

- If pointer changes are approved, RANGE is no longer needed 
for pointers that are not DYNAMIC.

- Need to integrate with 3.10 to clearly describe when a user 
is justified in giving RANGE assertion.   ... 

There were questions about why processor arrangement isn't 
allowed in the list of RANGE? Similarly maybe ALIGN.

Carl Offner commented that distribution information is key 
information for the compiler while stride, etc. is not.

----
Proposal:
(1)  For generalized BLOCK distribution, use the GEN_BLOCK --
- it is required for the RANGE proposal even if it was not 
needed for  the original GEN_BLOCK proposal.

 - Friendly spelling amendment to Generalized Block -   
strawpoll   21 - 0 -0

Back to Range Proposal...

Proposal Passes    - 11 - 1 - 4

This proposal  is for HPF approved extensions
=================

Carol Munroe - Second reading:  Eliminating explicit mapping 
of sequential variables from HPF 2.

Currently defined for sequential 1D covers - hard to explain 
- complications in compiler - and probably minimal benefit 
for users who are porting their code.

Second reading vote:  15 - 0 - 1

==============

Larry Meadows - Vendor Language Organization Proposal - 
Second Reading

Naming - HPF (V 2.0) is the only language

Content  of language -
 - HPF 1.2 with changes
 - hope is 12-18 month timeframe for full implementations

Document
 - HPF 1.2 + Annexes + Approved Extensions - minus a few 
features.

HPF subset will remain as an annex in 2.0. It won't be called 
a language - just a set of features on record.

HPF kernel becomes a chapter on  portably efficient  HPF 
programming.

New Features proposed for inclusion in HPF 2.
   - Interfaces required if remapping.
   - Intrinsic, commutative reductions.
   - Pointers cannot be mapped or point to mapped objects.
   - No aggregate covers.

Approved Extensions from HPF 1.2

   - Dynamic and friends from HPF 1.1
   - HPF_SERIAL, HPF_LOCAL
   - Pointer Mapping
    - All other new features passed in second reading.

The motivation is that this is the language everyone 
(vendors) agrees on.

Mary objected to removing mapping of pointer objects from the 
base HPF because this removes the only remaining support for 
irregular data structures. This should be proposed as a 
subject for public comment.  If there is a large comment that 
says some feature in the approved extensions list is 
important it should be considered for including in v. 2.0.

Discussion of why continuing the subset. (Primarily to 
document what has been a target of several implementations.)  
Clarification - the existing document makes reference in 
other chapters to  what is in the subset.  That explicit text 
should be dropped.

Separated to two proposals ----  (with some voting vendor 
members leaving the room to avoid being on record for the vote).
    Document organization - naming, annexes and approved extensions -
    Vote on structure -   14 - 0 - 1.
    Vote on the content of the parts  - 13 - 1 - 0.

BREAK

The vendor slide was reviewed.  Despite a recent announcement 
of a joint project with PGI, CRI still doesn't want to be 
listed as Announced Product.
SofTech was removed.. Ken will contact Motorola.  HP/Convex 
changed to be just HP.    Question about MasPar --- and Lahey 
what about Transtech? - using the PGI product (Larry will check.)

------------

Second Reading of the Processor Subsets, presented by Henry.

dist-target is proc-name [(section-subscript- list)]
     or * proc-name [(section-subscript-triplet-list)]
     or *

Constraint: In a section-subscript-triplet-list, the number 
of section-subscript-triplets must equal the rank of the 
processor-name
     - subscript
     - subscript-triplet
     - no vector-subscript

Allows distribution to a subset of processors.
!HPF$ PROCESSORS P(10,10)
               REAL A(100,100)
!HPF$  Distribute A(BLOCK,BLOCK) ONTO P(2:6,3:7)

vote - 12 - 0 - 4  passed for inclusion in the approved extensions.

=================================
Derived Type component distribution  clarification  presented 
by Piyush Mehrotra.

Consider the following example: 
type dt
    integer f(1000)
!HPF$ distribute (block), dynamic:: f
  end dt

type(dt), target :: s(1000(
 integer, pointer :: p(:)
do I= 1,1000,2
!HPF$ redistribute (s(i)% f(cyclic))
end do

p => s(1:1000)% f(6)

Problem: the redistribute of f causes elements of s to have varying sizes.
    - the pointer p points to an array with an irregular mapping.

Proposal:
  A component of a derived type can have the dynamic 
attribute only if it also has the pointer attribute.

(The above pointer assignment is illegal in F90).

Question - should this be first or second reading?

2nd reading amendment to derived type - 15 - 0 1

===== 

Group D cci

11, 29, 47 - pointers.
HPF 1.1. has contradictory statements about pointers.

Proposal:     1st reading .... 
 - Retain text in section 3.6 page 38 line 33 which states 
that pointers may appear as an alignee or a distributee - 
takes effect on allocation

 - delete constraints 3 page 27 line 5 - distribute cannot 
have pointer attribute (also page 186 line 48)

- Add text: If a pointer (target) is explicitly mapped and is 
associated with a target using a pointer assignment, the 
mapping of the target object must MATCH the declared mapping 
of the pointer.  (Where MATCH needs to be defined.)

     Override -   then this applies only on allocation

 If a pointer is declared to be DYNAMIC, it can point to any 
non-sequential object.  The RANGE directive can be used to 
restrict the mappings of the target object or the allocated array.

 A pointer declared sequential using the SEQUENCE attribute 
can point to sequential objects only.

 A pointer which is not explicitly mapped or declared 
sequential can point to a target which is not explicitly 
mapped or declared sequential.

Discussion of DYNAMIC - is this an appropriate overloading of 
DYNAMIC?  Can a dynamic pointer point to a static objects?  
PM  - saying this is illegal is too restrictive --- but user 
might think that because pointer is dynamic it can be 
redistributed ... but other text should restrict this.

example  
A(100), B(100)
!HPF$ distribute (cyclic):: A,B
pointer, dynamic :: p(;)
   p => A
   p=> B

Straw poll on this for a first reading - clearly not ready 
for second reading
  19 - 0 - 0.

CCI 50:  Legal F90!

program p
   integer a(100), b(10,10)
!HPF$ DISTRIBUTE a(block), b((block,block)
    call sub1 (a,b,b)

contains
   subroutine sub1(x1,x2,x3)
   integer x1(100), x2(10,10), x3(10,10)
!HPF$ DISTRIBUTE x1 *(cyclic)
!HPF$ DISTRIBUTE x2 *(block,cyclic)
!HPF$ DISTRIBUTE x3 *(cyclic,block)
    print *, x2, x3
   ....
   ....  = a(i)
   call sub2(a)
  end

subroutine sub2 (x)
   integer x(100)
!HPF$ DISTRIBUTE x *(*)
  end sub2

end 

Not HPF conforming.

page 46 line 17
  - actual arg will be remapped to conform to the interface

_ page 54 line 14
  - if array accessible through 2 or more paths cannot be remapped.

Proposal:  (to make the above example legal)
   Change text page 46 line 17 to delete reference to 
remapping of actual arguments;    [need better words]

... and a remapping of the actual argument is necessary, the 
call should proceed as if the data was copied to a temporary 
variable mapped to match the mapping of the dummy argument.

Rational (to be added): sometime actual is accessible through 
say host association, so cannot remap actual.

===== 
Discussion - is a better solution just to say it illegal. 

Ken - points out that the places to worry are where a program 
is legal in F90 and one changes to HPF it is illegal - with 
no fix ... that doesn't apply here.

straw poll on fix (vs saying illegal) - aliasing     0 - 14 - 6

====
second part of the same problem (aliasing involving pointers)
program p
   integer, pointer :: a(;)
!HPF$ DISTRIBUTE a(block)
    allocate a(100)
    call sub(a)
   
contains 
    subroutine sub(x)
       integer, pointer :: x(:)
!HPF$ DISTRIBUTE x  *(cyclic)
        x(i) = ...
        a(i)   = ... 
     end sub

  end p

problem:  legal F90 => a and x point to same data with 
different distribution:

Proposal: add restriction [better words]  to the pointer 
proposal discussed earlier
   The mapping of a dummy argument with a pointer attribute 
has to match the mapping of the actual argument if the latter 
is accessible inside the procedure through another path.

strawpoll :  18 - 0 - 3

=================

Rob Schreiber presented group C proposals

Reductions (simple) - summary of written text.

Syntax:
!hpf$ independent, new(y), reduction (x)
   do I = 1,n
     y = f(i)
     x = x + y
    end do

Full list of constraints is in the written version of the 
proposal, but they include specification that: 
	whole object is the reduction variable
	reduction must appear on outermost independent with no 
            new clause for reduction variable.

The change (to the original proposal) is putting reduction on 
the independent directive associated with the loop.  Note - 
this has been voted for inclusion in the 2.0 language.

vote - 14 - 1 - 1    passed modified simple reduction.

=========
More general reductions

1. Intrinsics;  (two flavors)
   - commutative only
   -  concatenation and MATMUL
                concatenate isn't interesting in Fortran 
                because of the fixed length.
                but MATMUL is interesting.

2. Defined ops and derived types
      (BIGNUMS, SPARSE MATRICES).
      !hpf$ independent, reduction (a = expr1)
           do I = 1,n
                a =  a  .op. expr2
                a(2:4) =  a(2:4) .op. expr3
            enddo

    Rules:
        - expr1 and expr2 conformable with a.  expr3 
conformable with a(2:4)

        - (a .op. b) .op. c == a.op. (b.op.c)
     
        -  .op.  PURE; may not reference a global whose value 
changes in the loop.

FIRST vote:  Add MATMUL to approved things for reduction - 
(in the approved extensions).   Vote - 10 - 1 - 5    fails.

Second vote:   Add defined ops and derived types for 
reductions  - not powerful enough for matmul - doesn't allow 
the shape issues involved in matmul.  Vote - 10 - 2 - 4     
motion fails (after some vote changing).

Chuck doesn't want to lose the text ... proposal is to make 
this a Rice  CRPC tech report. ....  Out of core I/O is 
another similar proposal where we might want to preserve the text.

==========
Break for lunch  Group started again at 1:10

Rob   Task Proposal

!hpf$ tasking, new(i)
   do I = 1,n
          !hpf$ on home (proc(1:i))
            ...
          !hpf$ on home (proc (9:16)
            ...
    enddo
!hpf$ end tasking

processor disjoint execution tasks -
    - there must be no interference .... e.g. no I/O, no 
stepping on same variable

    -  NEW variables cannot cause interference of 
synchronization

This form of tasking is like an independent assertion for a 
group of statements.

The example gives 2xn tasks --- n trips through the loop that 
has 2 tasks ....

Discussion of whether the loop in the example could be 
labeled independent.

This proposal says that if you use !tasking ... then whenever 
you find !HPF ON home, you can potentially do it in parallel.

Possible model - in simple send receive world with owner  
computes - with no shared memory and no active messages .... 
could ignore these directives.   Every processor can execute 
- and since there is no "interference" there just won't be 
anything to do.

For shared memory or one-sided communications model - 
barriers are needed at the beginning and end of task regions 
for any tasks that have possible interference.

What about the DO statement itself?  It does not (and cannot 
) appear in an ON that doesn't also enclose the end do.  No 
barrier is needed.  But there are additional issues involving 
control flow, subroutine calls, etc.  

This is subtle way to do tasking --- but it is nice in that 
it provides information that would be useful to the compiler.

Andy asks if people would vote for some form of tasking 12 - 3 - 6

First reading   10 - 3 - 8....   Jaspal:  think we can't 
finish by the next meeting.  Will we need another meeting?  

Subgroup C to meet to talk about the issues associated with 
tasking.

==========
Mary presented group E cci.
cci 45/46 still in progress.
cci 48 ok as answered.
cci 51/54/new-lfm  ... all variants on questions about 
global_lb/ub

      proposal:   first reading
      remove  global_ub/lb from HPF2  

     Motivation: global_shape etc. do the same thing.  Henry 
believes he asked for these functions and no longer needs 
them.  As a formal 1st reading, we will have time to 
reconsider.     Vote:   17 - 0 - 1

cci 53 - Whaley  F77_local
    The workaround is to call HPF_LOCAL and it can call F77
     The feature proposed isn't sufficient.
      An F77_LOCAL definition makes practical sense ....

       ( Invitation For Proposal --- but timing problem.)

discussion of the need for F77 local    vendors think 4-1 
that F77 interface would be important.

 Ken thinks such a proposal would be good PR for us.

-------------

What do we do about interoperability?  Nothing new from WG5. 
X3J3 may be going in another direction.
For direction - can ask for specific guidance in the public comment
For current guidance - how many think we should go ahead even 
if X3J3 goes somewhere else:     8 - 3 - 5

------------

Document outline

Propose we have two syntax annexes - one for HPF and one for 
HPF with approved extensions.

Document formatting tool .... Ken (Chuck) will buy copies of 
FRAME for editors that don't have one.     Check versions.
------------

The group split up for continued subgroup meetings.

===================

FRIDAY - MORNING

Discussion  of meetings and the need for an additional 
meeting was discussed.

May 1-3 - Arlington
End of June for   26-28  --- San Francisco   for a new 
meeting
Sept 18-20 also San Francisco

-------------
Piyush presented Pointers revisited ...

Static explicit declaration 
	take effect on allocations
	on assignment target mapping has to match - current one 
            for dynamic target
	(note a definition for match is still needed)
	sequential pointer can only point to sequential object
	not  explicitly mapped and not sequential can point to 
            target which is not explicitly mapped and not sequential

For dynamic pointer - 2 options:

OPTION 1
!HPF$ dynamic :: p,q 	can point to anything - can be used 
to redistribute

allocate (p)		range can be used to limit target
!HPF$ redistribute p(block)

p => a			      case 1: A is not a pointer or not a 
dynamic pointer - not allowed
!HPF$ redistribute (p(block))   case 2: A is a dynamic ptr, p point 
to new object;  A loses       
                                                     association

OPTION 2
!HPF$ DISTRIBUTE *::P,Q	transcriptive distribution for p,q - 
can point to 
                anything-can't be used in redistribute
!HPF$ DYNAMIC :: R,S	can point to anything dynamic

ALLOCATE (P)	has no dist - use range with one choice 
q => A		q inherits dist of A

allocate (r)		- or use a range one choice
!HPF$ redistribute (r(block))

s=> A		case 1 A is not a pointer - not allowed - case 2 A 
is ptr - a looses assoc
! HPF$ redistribute (s(block)

Rob points out a third option
  dynamic can only point to dynamic
  not explicitly mapped pointer  can point to anything not but dynamic
  whatever you say about the pointer must be true about the target

  mapping of pointer has to be less specific than the target

option 0 - no remap in pointers       7 - 6 - 5
option 1 - dynamic point to anything
option 2 - use transcriptive syntax   (creative new use of old syntax)
option 3 - not explicitly mapped can pt to anything but 
           dyn/seq  11 - 1 - 7

bottom line - group D - will go away and think more about 
option 3

===========
Andy Meltzer presented a proposal for an extrinsic called 
HPF_SPMD.
(we just finished LPF ... now something high performance  :-)

Predicted  Objections:
1. There are too many new directives / intriniscs for one 
proposal
	In its stripped down form - the only new directives are 
PE_PRIVATE and SERIAL/END SERIAL
	. 
2. There are too many details to nail down and many new 
concepts
	Yes there are many new details and concepts, but there 
is a 4 year old implementation of this that has been successful

3. Opens another can of CCI worms
	See above - but yes there will be more CCI

4.  It is a big chunk to add
	stripped down it isn't so big - but a standard spelling 
for sync primitives would be nice

5. Can users understand yet another model?
	yes - also this will bring a set of new users to HPF and 
provide a natural task model

6. Cray is doing it anyway, why adopt it
	useful to have a standard way of doing this in approved 
        extensions.  Also 
	without something for its higher performance customers 
        Cray will have difficulty supporting HPF at all.

----------

Introduction

SPMD_HPF is an extrinsic environment based upon HPF_LOCAL with 
all of the HPF 2.0 built on top.  SPMD_HPF is a multi-threaded 
language like HPF_LOCAL.  Allows seamless use of low-level 
paradigms - message passing, get/put, explicit syn.  Additional 
rules redefining rules defined relationship between HPF_LOCAL 
and HPF 2.0 things have been added.

WHY SPMD_HPF?
Not applicable to all platforms, but for platforms that can 
support it - allows greater flexibility and higher performance  
Multi-threaded model allows easier migration path for MP users - 
HPF is no longer all or nothing  Extrinsic environment allows 
will defined interface to standard HPF.  Many of these features 
are currently successfully in use.

NEW IN SPMD_HPF
Data default is that of HPF_LOCAL, called private.  The 
interaction between private and explicitly mapped data is 
defined.  Possibly Parallel inquiry intrinsics added 
(IN_PARRALLEL, IN_INDEPENDENT).  Serial regions are added 
(SERIAL/END SERIAL).  Explicitly synchronization primitives are 
define for addition.
Assorted other features are suggested:
	parallelonly, serial_only, parallel_and_serial
	pe_resident, pe_private, symetric, geometry

Data Mapping
No changes from HPF 2.0 features all data distribution formats 
are available.  Data defaults to private (the default behavior 
of HPF_LOCAL).

Input and Output
I/O behaves like HPF_LOCAL I/O

HPF calling HPF_SPMD 
	can't pass functions
	question about pointers
	if dummy is  explicitly mapped data - same as hpf
	if dummy is private - same as hpf_local

Subprogram Interface
Subprogram interface behave exactly like hpf2 for explicitly 
mapped data. Subprogram interface behave exactly HPF_LOCAL for 
private data. The interaction between private and explicitly 
mapped data is defined.

Array Syntax
Array syntax with all private data acts like it does in 
HPF_LOCAL.  Array syntax with explicitly mapped data acts like 
it does in HPF 2 all processors must cooperate. Mixed private 
and explicitly mapped data is defined HPF_SPMD - with a list of 
rules given in the document..

Serial Regions
In a multi-threaded environment it is useful to be able to start  
single-threaded section, operating on one processor.  Serial / 
End Serial are used for this.

Synchronization Primitives:
	Locks (set, wait, clear)
	critical sections
	events (test, set,wait, clear)
	barriers (test, set,wait)

To cover some issues that are not spelled out or not clear in 
the documents:

Cooperative subprograms are subprograms that require all tasks 
to participate in.
A subprogram is cooperative if:
	it calls the HPF_library
	it contains a serial directive
	it contains a symmetric directive or barrier
	it contains an independent loop
	it contains an array assignment to explicitly mapped data
	it declares mapped data or remaps data
	it makes a subprogram that does any of the above
All of these conditions may result in the insertion of barriers 
that all tasks must encounter.

All processors must participate in the execution of cooperative 
subprograms (exactly like HPF) or they may be invoked from a 
SERIAL region or from with in an independent loop  so 
             if (my_proc() .eq.5) call func() ! not cooperative  
             endif

Explicitly Mapped Data
Explicitly mapped data should not be modified unless it is in an 
INDEPENDENT, SERIAL, array syntax expression, or it is 
explicitly protected by a user mechanisms. This is the same as 
HPF FORALL restriction -  It is illegal for two tasks to  update 
the same storage location for the same statement.

	REAL A(10000)
!HPF$ DISTRIBUTE A(BLOCK)
	...
	A(3) = 6   ! illegal
	A (my_proc()) = 5 ! ok
	if (my_proc().eq. 0) A(3) = 6  ! ok

	DO I = 1,10
		A(I) - 5  ! illegal, ok if independent
	ENDDO

--------
INDEPENDENT and DO

With no independent, a do loop executes individually on every 
processor
 	DO I=1,n
executes n iterations per processor.  This is intended for 
PRIVATE data. (like HPF_LOCAL)

with INDEPENDENT, a do loop distributes its iterations among the 
processors
	DO I-1,n
executes n iterations total (like HPF)

REAL A(10000)
DIST A(BLOCK)
INDEPENDENT 
DO I=1,n
   A(I) =  I*2  !ok
   j = j+1	!ok private or explicitly mapped
END do

Loop index must be private

Discussion ---- should there be some other term rather than 
INDEPENDENT for this?

The subcommittee considered the following questions: 
	- should HPF_SPMD accept all of HPF since the kernel is 
          gone?  4 - 0 - 0
	- should the restrictions on calling HPF_SPMD form HPF be 
          relaxed for pointers to allow association with INOUT or OUT,
          but no dummies of type pointer   1 - 0 - 3
	- allow all synchronization flavors - yes
	- geometry accepted?  1 - 2- 1
	- parallel-only, serial_only, parallel-and-serial  3 - 0 - 1
	- symmetric  3 - 0 - 1
	- change independent name

========

Ken began the discussion of the SPMD proposal with procedural 
comments:  we want to encourage extrinsics and we  could endorse 
ones that we think conform to the rules for HPF extrinsics.   
Chuck suggested that proposed extrinisics that we reference 
should come from an  organization of some kind (rather than one 
person's pet).

HPF should certify the interface and can include a summary - 
that has a responsibility on both sides (e.g. extrinsic 
maintainer doesn't change the details we advertise).    But 
this summary must be approved by us,  and it would be HPFF 
right to decide who meets criteria.  The general idea is: 
"Here's a set of rules ---- you can submit ---- and we will 
look at it."

Subgroup E will formalize a set of the rules.   This 
discussion is considered the first reading of this proposed 
new extrinsic policy.  Some possible criteria are
    Significant new functionality
    Some existing practice

Straw Poll ...  17 - 0 - 1  about the approach for 
extrinsics.

Straw poll - How many believe the SPMD proposal generally 
meets this: 13 -1 - 3.      

We will try for 2nd reading of this policy at the May 
meeting.

BREAK

Carol  Munroe presented the first reading of a proposal for 
new  Sort Library functions.

Motivation:
Grade_up/down  are flexible routines that produce index 
arrays for arbitrary sorts.  The problem is that the simplest 
sorts are slowed down by this. It  requires extra storage for 
the permutation and maybe copy of the data etc. Some sorts 
can be done in place much faster.

Propose two direct sort functions for the library:

SORT_UP  SORT_DOWN
    result1 = SORT_UP(Array1)
    result2 = SORT_UP(array2, DIM=1)
          where result1 might be the same as array1
    alternate version with the key
     sort_up (ARRAY [,KEY] [,DIM])

If no Key is supplied, data in Array would be sorted directly.
The need for explicit interfaces for HPF_LIBRARY prohibits 
arrays of arbitrary user-defined types.

pros (for Key) - somewhat greater generality
	- possibly speed-up of a single sort-by-key
	- Avoiding need for an extra user array
cons
	- sort-by-key can be done effectively using 
              grade_up/down
	- single sort by key is probably less common

Overall proposal - straw poll ---- sort/up/down in library    
14 - 0 - 2  (first reading vote)

straw poll - optional dim argument   13 - 2 - 2
straw poll - optional key argument   0 - 11 - 6

----------------------------

TASK PROPOSAL ---- One more time!   Presented by Chuck.

Goals _ sequential model of semantics, simple, powerful, 
efficiently implementable; cures bad breath, tastes as good 
as apple pie ...

!HPF$ TASKING region
Tasks delimited as ON blocks
Key properties
	ON regions are all RESIDENT (i.e. all reference local to 
the processor set)
	If processor sets are disjoint, then the ON blocks do 
not interfere (i.e. are INDEPENDENT)
	Standard semantics everywhere else (i.e. dependencies 
may serialize overlapping tasks
	All processors must follow same control flow outside of 
ON blocks (this may be redundant)
	Strong advice to implements - replicate scalars outside 
ON regions!
	e.g. if you have a do-loop index - replicate it ...

Example   (with a fancy diagram to indicate calculations with 
time)

!HPF TASKING
	DO I - 1,N
		!HPF ON HOME (PROC(1:2)) BEGIN
			CALL READ_IMAGE(A)
		!HPF$ END
	B=A
	!HPF$ ON HOME (PROC(3:6)) BEGIN
		CALL ROW_FFT(B)
	!HPF$ END
	C=B
            !HPF$ ON HOME(PROC(7:8)) BEGIN
            CALL WRITE_IMAGE(C)
      !HPF$ END
      END DO
!HPF$ END TASKING

Implementation Mechanism 1   (Message Passing)

Insight: You don't need one-sided communication between tasks
So:
All processors have their own copy of scalars
All processors execute the same code outside ON blocks
Scalar = Scalar : Replicate the computation
Scalar = Dist_array(i) : Broadcast the value
Dist_array(i) = Dist_array(j) : Send/recv pair between owners
Conditionals, loops, etc. : Evaluate conditions as scalars
Processors enter ON blocks if and only if they are part of the processors set
RESIDENT ensures that send/recv suffices to implement each ON block

Implementation Mechanism II  (Shared Memory)
Insight:  You can use the ON clauses for synchronization
So
	All processors have their own copy of scalars
	All processors execute the same code outside of ON 
blocks
		Replicate computations on replicated scalars
		Assigning from or to mapped data requires sync of 
RHS and LHS owners
	On clauses synchronize processor in the HOME clause
	Barrier on entry ensures that data written by other ON blocks
           is up-to-date
Barrier on exit ensures that this ON block's data gets written before it is read
We speculate that compilers can optimize a lot in this area

After the discussion on Thursday - the subgroup had been 
asked to list issues associated with tasking.   Following are 
a number of things that the subgroup considered.

Questions
What does TASKING tell us?
	Resident and restricted interference

Is NEW necessary?
	We don't think so, but may be needed to avoid blocking.

Can the number of processors in and ON block change at 
runtime?
	Yes, needed for multi-block.

Can ON blocks do I/O?
	Yes but 2 non-overlapping ON's can't access the same file.

Are there dark corners in procedure calls and nested TASKING regions?
	Probably but we ran out of time
	
Other Suggestions
	Message Passing - HPF binding for MPI - too big for now.
	Message Passing - parallel sections have REMOTE reference.
		A-> B to send
		A <-B to receive
		But how do you know which sends and receives match?
	HPF_SPMD
		
VOTE -- 15 - 0 - 2   first reading of a TASK proposal is 
finally on the books!

=============
The LPF report was submitted by Andy Meltzer - excerpts below 
...

LPF (a)

LPF rules of order*
1. All proposals require a unanimous vote (0) to pass.
B. All proposals require a unanimous vote (o) to reject.
III. No proposals may be submitted.
iv. Any inane comment is automatically considered a proposal.
	=>All proposals are simultaneously approved and 
rejected.
	=>LPF is all possible combinations of proposed features.
	=>LPF is still smaller than HPF.

* thanks to PH.

HPF has been trying to get TASKS completed.
LPF  has been working hard on getting CHORES done.
		!LPF$ TAKE_OUT_THE_TRASH
		!LPF$ GO_GROCERY_SHOPPING
		!LPF$  MOW_LAWN
		!LPF$  SHOVEL_DRIVEWAY
			and finally the odious
		!LPF$  GO_TO_HPF_MEETING

The LPF committee has done a study of a couple of modern 
languages

HPF				LATIN
Dead language?			Dead language.
Only religious fanatics use it.	Only religious fanatics use it.
Hasn't changed in hours.	Hasn't changed in centuries.
Has users?			Many users all over the world.
Derived from many unsuc. languages.	Basis for many successful other langs.
Getting rid of lang. is religious issue.  ditto
Can only learn lang. from an academic.	  ditto
HPF 2.0 is almost ready.	Latin has lasted thousands of years.
Basis for a lot of romantic language.	Basis for Romance languages.

Many of you are wondering why there won't be an officially 
chaired LPF meeting next time:
	- SGI doesn't support LPF?
	Nah - LPF is alive and well at SGI, like everywhere else.
	- LPF is done?	
		Can't finish it, someone may try to use it.
	- HPF is LPF?
		That's never stopped us before.
	- A new LPF designer is coming on board.
		His mother won't be happy if I'm not there.

----------------   end of LPF report for Mar. 96 ------------
----------------

As of the end of the meeting - the new status of proposals 
is:

					1st	2nd
group E                                
	
	SPMD-HPF-ext.  			Mar	May		am/lfm
	Rules for extrinsics 		Mar	May
	Elimination of GLOBAL_LB/UB 	Mar	May		m
	New Sort functions 		Mar	May		cm

group D                              
	dark corners of ptr  		Mar.	May

group C                          
	on				Jan	May			ck	
	task				Mar	May	
	inq updates			Jan	May			rs

	F77_LOCAL	needed

DONE - 
	  (C) async				ext	lm
	  (C) gen transpose			ext 	rs
	  (D) reduc - simple			2	rs
	  (D) reduc - simple amended		2	rs
	(D) derived typ				ext	gls
	(D) derived type amended		ext
	(D) shadow width			ext	co
	(D) irreg map				ext	?
	(D)dist ranges				ext	hz
	(D) seq. nonmap				2	cm	
	(D) subsets				ext	pm
	(E)name/etc.			
	(E) kernel			(chapter)	am
	(E) interop				ext	am
	(E) local_global func			?	cm	
	(E) explicit interf			2
	~

-------------
The next HPFF meeting is scheduled  for May  1-3 (Arlington). 
An additional HPF meeting has been added for  San Francisco  
June 26-28.  The final  HPFF meeting is September 18-20 
(again San Francisco),  with the expectation that there will 
be a public comment period between July and September.

-------------------------------------------------------------
March Attendance:    
Siegfried Benkner	Univ. of Vienna	[email-masked]
Jay Boisseau		SDSC		[email-masked]
Bob Boland		LANL		[email-masked]
Alok Choudhary		Syracuse U.	[email-masked]
Paul Havlak		U. of Maryland	[email-masked]
Ken Kennedy		Rice U./CRPC	[email-masked]
Charles Koelbel		Rice U.		[email-masked]
David Loveman		Digital		[email-masked]
Larry Meadow		The Portland Group	[email-masked]
Piyush Mehrotra	ICASE	[email-masked]
Andy Meltzer		Cray Research	[email-masked]
Carol Munroe		Thinking Machines	[email-masked]
Carl Offner		Digital		[email-masked]
J. Ramanujam		Louisiana St. Univ.	[email-masked]
Guy Robinson		University of Vienna  [email-masked]
P. Sadayappan		Ohio State University [email-masked]
Rob Schreiber		HP		[email-masked]
Jaspal Subhlok		Carnegie Mellon	[email-masked]
Joel Williamson		HP 		[email-masked]
Hon W. Yau		NPAC		[email-masked]
Henry Zongaro		IBM Canada	[email-masked]
Mary Zosel		LLNL		[email-masked]	
---------------------------------------------------------------------------
To (un)subscribe to this list, send mail to [email-masked].  Leave
the subject line blank, and in the body put the line
(un)subscribe <email-address>
---------------------------------------------------------------------------