(j3.2006) (SC22WG5.4943) Thoughts on Reinhold's thoughts

Van Snyder Van.Snyder
Fri Mar 29 16:36:17 EDT 2013


(B.1, B.4) CHANGE TEAM synchronization and ancestor-team addressing

Reinhold gave an example where image 1 cannot do things asynchronously
while the remaining images, decomposed into two teams, do something
else, because of the synchronization requirements of CHANGE TEAM.  If it
were possible to use ancestor-team coindexing (I haven't given much
thought to the syntax) one could decompose first into two teams, image 1
and the rest of them, then decompose the remaining teams:

  type(team_type) top
  integer :: id_1, id_2
  id_1 = min(2,this_image())
  form subteam ( id_1, top )
1 change team ( top )
    select case ( id_1 )
    case ( 1 )
      ! work asynchronously from the remaining teams, accessing
      ! their data using ancestor-team indexing
    case ( 2 )
      block
        type(team_type) bottom
        id_2 = 2+mod(this_image,2)
        form subteam ( id_2, bottom )
2       change team ( bottom )
        select case ( id_2 )
          case ( 2 )
            ...
          case ( 3 )
        end select
      end block
    end select
  end team

The first change team synchornizes all images (maybe this is the problem
Reinhold wanted to avoid), while the second one only synchronizes images
other than image 1.

(D.1) CO_MULT: for distributed linear algebra, it is likely that a
collective multiply-add would be more useful.

(D.2) Asynchronous execution:  I previously argued that EVENT WAIT ought
to be WAIT, that the WAIT statement ought to be moved to somewhere in
Clause 8, and that the I/O and WAIT statements ought to admit a variable
of LOCAL_EVENT_TYPE for synchronization.  The objection appeared to be
to the concept of conflating I/O with anything else.  If we use the
ASYNCHRONOUS attribute for the purpose Reinhold suggests, perhaps we can
re-visit the question of WAIT.

Reinhold's and Nick's concerns tell me that we must tread very
carefully, lest we make an irrevocable mistake.  We risk things that
even interps cannot repair.  Getting it right must take a much higher
priority than getting it out on schedule.





More information about the J3 mailing list