assignment of coarray objects with allocatable components
in [Fortran]
|
From: Reinhold Bader on 23 Apr 2010 03:28 Jim Xia schrieb: > >> type :: mytype >> integer, allocatable :: a(:) >> end type >> >> I believe your code to be legal, since a non-coindexed entity is >> treated as if it were a "normal" Fortran entity. It should auto-allocate >> the component to the right size and transfer the remote component >> values into it. > > > > Not that simple. Or is it? > > > " > IF (THIS_IMAGE()==2) obj=obj[1] > " > > > I recall we have debated intensely on the supports for coindexed > objects with allocatable components during WG5 meetings. As I can > remember as the final outcome, the quoted line is legal by the > standard. However there are many hairy details exposed if you're > going further. The intrinsic assignment being the easiest case, even > so the implementations may not be nearly as easy as it seems. In your > example, you have integer types as the component and it seems feasible > to copy data from remote image. If your components are of polymorphic > allocatables, or parameterized derived types, then how do you expect > the compiler to figure out what data type and type parameters to copy > over from image 1? This would not appear fundamentally different - even in the simplest case above some metadata (i.e. descriptor information) needs to be transferred from the remote image before the actual data can be copied; I wouldn't consider type tags or type parameters to be much different (although I agree the implementation effort is not negligible, especially if you consider nested types). The compiler, I agree, will typically not be able to figure out things at all (at compile time). > How much information can you think the compiler > has to figure out? Imagine you're on the distributed system and your > local libraies may not even be the same as the remote machine, and you > have no clue as to the dynamic type of the component of the coindexed > object on a remote image. I'm not sure what you mean by "local libraries" - the implementation's run time? I agree having different versions of an implementation on different execution hosts invites catastrophe (vendors do occasionally change their descriptors). > > > The next trouble will be the function calls. "call foo (obj[1])". If > foo() modifies its dummy arguments, how would you expect the modified > value being passed back to image 1? And what state of "obj on image 1" > would be in during the execution of foo? If this is allowed, then > you're essentially doing a remote allocation and remote operation, > which is against the coarray operation principle. So the final > decision is to allow "call foo(obj[1])" ONLY IF foo() does not modify > its dummy. But again, finding out the all the relevant information on > the data being fetched from image 1 will pose challenges to compilers > on a distributed system. > > > One may be excited about coarrays in F08, but if you use allocatable > components in your coarrays, I'd love to know how robust your compiler > is in supporting them :-) I'm sure initial implementations will generally have limitations in this area. > > > Cheers, > > Jim Regards Reinhold
From: Jim Xia on 23 Apr 2010 23:01 On Apr 23, 10:48 am, Jared Ahern <jared.ah...(a)gmail.com> wrote: > > So this is actually a question that I had when reading N1824. Of > > late, I have been starting to use the polymorphic features of F03, now > > that more implementations are closer to completely supporting that > > standard. But Reid states: > > > "So that the implementation does not need to access the dynamic type > > of an object on another image, no references are permitted to a > > polymorphic subobject of a coindexed object or to a coindexed object > > that has a polymorphic allocatable subcomponent" > > I think that C617 in N1826 is the constraint in question, fyi. Yes. For coindexed objects with polymorphic subobjects, the implementation will be nightmare. It's better to put the limit for now so we can set the ball rolling on coarrays. It's always possible to relax the restrictions later. Not the other way around. There are two issues to be considered. One is how many Fortran programmers will use polymorphism in next 10 years. If the answer is a lot, then there is a valid reason to look at this issue seriously and try to find a solution. The technical issue is the heterogeneous system. For people familiar with polymorphism in other languages, finding the rtti on remote nodes on such a system is nearly impossible. Consider a type bound procedure foo(), (which can be built within a library and distributed to all nodes), the actual function may be located at address 0x100000000 on one machine, and 0xfffffff on another, depending on the load sequence when the program starts. When you fetch polymorphic data from a remote machine, would you trust the function pointer addresses fetched from a remote image? You might have to rely on a string-based procedure name look-up scheme to find the correct function pointer locally and invoke it. I'm sure no vendor would ever want to consider these cases during implementation even if they have to. With such a risk that it may not be implented by anyone, we're better off to leave without this feature. Cheers, Jim
From: Jared Ahern on 26 Apr 2010 15:42
> Yes. For coindexed objects with polymorphic subobjects, the > implementation will be nightmare. It's better to put the limit for > now so we can set the ball rolling on coarrays. It's always possible > to relax the restrictions later. Not the other way around. Fair enough. Hopefully it won't take as long a time to get coarrays in free compilers as it has to get F03 OOP! > There are two issues to be considered. One is how many Fortran > programmers will use polymorphism in next 10 years. If the answer > is a lot, then there is a valid reason to look at this issue > seriously and try to find a solution. I do hope that with it's new features Fortran can attract some new people, perhaps with C++, Java, or Obj-C backgrounds, who already have experience with polymorphism. To me Fortran provides a number of advantages, and it would be nice if it didn't fade away! I suppose it's partly a matter of perception though. > The technical issue is the heterogeneous system. For > people familiar with polymorphism in other languages, finding the rtti > on remote nodes on such a system is nearly impossible. Consider a > type bound procedure foo(), (which can be built within a library and > distributed to all nodes), the actual function may be located at > address 0x100000000 on one machine, and 0xfffffff on another, > depending on the load sequence when the program starts. When you > fetch polymorphic data from a remote machine, would you trust the > function pointer addresses fetched from a remote image? You might > have to rely on a string-based procedure name look-up scheme to find > the correct function pointer locally and invoke it. I'm sure no > vendor would ever want to consider these cases during implementation > even if they have to. Interesting. I only have a rough working knowledge of the OOP and coarray features behind the scenes, and have no knowledge of how rtti is actually stored, so I could be far off-base. But it would seem to me though that for your example, the calling machine would have no interest in the actual remote function address: it already knows where all of the TBPs are located on the local machine. It just needs to know the dynamic type of the object on the remote image, and the relative location of the TBP in a lookup table. There could be a static lookup table of type information stored on each machine, and the pointers could just give the offset to the object's type, no? The lookup tables would need to have the same structure on both machines, but they could point to different locations for the actual functions. Then it can find the function locally however it normally would at runtime, and also use any type information needed to copy the object to the local image. Any architecture differences could be handled in a coherent manner by the compiler - I would think that the same compiler would have to be used on both machines, and it could be made aware of all the current targets. Again, I may be missing something you consider obvious. For a procedure pointer component, yes, I can see that being a problem. But if that's the biggest problem, I would think that the restriction could be narrowed to that case. |