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

[Bader, Reinhold]

Hello Van, 

> -----Urspr?ngliche Nachricht-----
> Von: j3-bounces at mailman.j3-fortran.org [mailto:j3-bounces at mailman.j3-
> fortran.org] Im Auftrag von Van Snyder
> Gesendet: Freitag, 29. M?rz 2013 21:37
> An: sc22wg5
> Betreff: (j3.2006) (SC22WG5.4943) Thoughts on Reinhold's thoughts
> 
> (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:

Unfortunately, item T2 of N1930 prohibits going outside the current team via coindexing, 
and I think with good reason: It would violate composability of the programming model. 
Of course, there still should be some way of efficiently exchanging data between subteams, 
motivating my desire to remove the big barrier around CHANGE TEAM (effectively saying: 
If we can't pull data into a team from its inside, lets push them in from the outside). 

> 
>   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.

I'd go along with this idea.

> 
> (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.

Agreed. With respect to the big barrier in CHANGE TEAM let me note that there are
risks to any path we take:  

* if it is retained and no other way is found to *efficiently* exchange data between
   teams, the teams feature will be regarded as a half-baked solution by programmers
* if it is removed and we fail to nail down the possible inconsistencies that might result,
   implementors will start a head-hunt ...

For this reason I'd like to see *concrete examples* that show how things can go badly 
wrong if the synchronization requirements are relaxed.

Regards
Reinhold
> 
> 
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3