(j3.2006) (SC22WG5.4954) AW: AW: [ukfortran] AW: Thoughts on Reinhold's thoughts

[Bader, Reinhold]

> -----Urspr?ngliche Nachricht-----
> Von: j3-bounces at mailman.j3-fortran.org [mailto:j3-bounces at mailman.j3-
> fortran.org] Im Auftrag von N.M. Maclaren
> Gesendet: Samstag, 30. M?rz 2013 12:41
> An: Bader, Reinhold
> Cc: sc22wg5; Van.Snyder at jpl.nasa.gov; fortran standards email list for J3
> Betreff: (j3.2006) (SC22WG5.4954) AW: AW: [ukfortran] AW: Thoughts on
> Reinhold's thoughts
> 
> On Mar 30 2013, Bader, Reinhold wrote:
> >
> > Note that since your suggestion also involves relaxation of the CHANGE
> > TEAM synchronization semantics, you're under obligation of providing
> > proof of correctness as well ...
> 
> Accepted :-)
> 
> That suggestion (and it's most definitely inchoate) was because of all
> of the fundamental objections I had to the facility proposed in the
> draft TS.  That definitely won't work.
> 
> I can see three approaches, in various levels of severity:
> 
>     1) To forbid ALL communication from inside or outside a team to the
> other, even for coarrays that are used only in one place
> 
>     2) To forbid any synchronisation between inside and outside, though
> to permit the outside to access inside coarrays not used inside

This is what my suggestions would imply (and may also answer your issues with my version of the 
data feeder). The example does not completely get rid of overhead, but considerably reduces it. 
To reiterate: 

* computation and coindexed data transfers are overlapped with team execution (and this activity will usually involve 
   orders of magnitude more cycles than the one in the next bullet). 
* local memory operations and partial synchronization are not overlapped; further optimization potential
   compared to my example might be to use a local pointer assignment instead of a local memory copy, and
  to use events for synchronization instead of SYNC IMAGES.

> 
>     3) To allow limited synchronisation between inside and outside,
> whether by using atomics and SYNC MEMORY or otherwise
> 
> (1) is easy to validate, (2) doesn't introduce any consistency problems
> though it might introduce deadlock, and (3) is the one I get twitchy
> about.

I would also be in favor of disallowing (3). In fact, usage of atomics (as well as events) should also not be 
allowed across team boundaries if they are to be generally efficient, for just the reasons you give. 


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