(j3.2006) Integration of co-arrays with the intrinsic shift functions
Thu Jul 12 17:52:05 EDT 2007
Sorry, if I understand you correctly, the mention of heterogeneity
was a bit of a red herring with respect to the proposal (the
heterogeneous part is a problem we have to deal with at LANL and is
outside the standard). The proposal should be thought of only in
terms of separate program images executing on identical processors.
On Jul 12, 2007, at 3:14 PM, Andy Vaught wrote:
> nOn Thu, 12 Jul 2007, Craig Rasmussen wrote:
>> I've been talking to code developers and examining codes at Los
>> Alamos and I've come across an area that we forgot to integrate with
>> co-arrays. I've written a paper describing the issue but I'm unsure
>> of how to submit it since this is a WG5 meeting.
>> I have identified at least one code at Los Alamos that implements
>> global shift functions (nearly identical to the co_cshift and
>> co_eoshift intrinsics proposed in the paper) in MPI. This issue is
>> very important to LANL as we are investing heavily in heterogeneous
>> processor architectures and the data parallel programming model has
>> been identified as one way to manage the complexity of the hardware.
>> In summary, after thinking about how co-arrays can be used with
>> Fortran's array notation, it seems to me that Fortran with the co-
>> array additions can provide an ideal platform for a data-parallel
>> style of programming.
> Interesting. I got a mail from a guy the other day who was having
> difficulties getting consistent results on an MPI calculation on a
> homogeneous cluster.
> This proposal takes that to a new level: If you are running a
> calculation on a heterogeneous cluster it would be extremely easy
> to have
> floating point numbers change slightly as they are shifted around
> on nodes
> and this effect would be exacerbated by network and disk
> latencies. Of
> course, the basic co-array spec implicitly allows this a little bit
> as it
> is, but this is opening the door to many more unexpected
> perturbations of
> intermediate results.
> I'm not saying that your proposal is without merit or shouldn't be
> adopted, but you're moving into an area in which calculations will be
> irreproducible from run to run.
> J3 mailing list
> J3 at j3-fortran.org
More information about the J3