[J3] Effect of RESULT_IMAGE in CO_xyz intrinsics

[malcolm at nag-j.co.jp]

Hi Van,

 

It is not required for a processor to use A as workspace, so saying that would be misleading. But yes, the idea that A, especially when A is itself a coarray, could be used for intermediate stages of the reduction, is the idea behind this.

 

One might imagine that the computation could proceed in parallel, e.g. all the odd images add (for CO_SUM) their A to the next even image, then all the not-divisible by four even images add that result to the divisible-by-four images, etc. Some internal synchronisation is required to make such a scheme work, but rather less than a full sync.

 

I don’t see anything confusing here. You already came up with the justification for making A undefined everywhere else, so it hardly needs a note to explain why some on the committee thought it to be a good idea.

 

Without RESULT_IMAGE, A is set to the result, on all images. Is that always going to be the same value for CO_SUM? Well, if A is of type INTEGER, that is required (as long as the program is conforming i.e. no overflow). But if A is of type REAL, I don’t see any requirement for it to be the same value, and there are computational schemes that would not produce the same value.

 

If we want to ensure the same value, that could require additional operations or for the final sum to be broadcast to all images.

 

(Aside: the NAG compiler does make the value the same on all images, but that’s just because I felt that doing otherwise was a disservice to the user; others may reasonably differ.)

 

OTOH, the user could ensure the same value by doing CO_SUM with RESULT_IMAGE, then CO_BROADCAST from that image to everyone else. That would almost certainly be slower than having the processor ensure the same value itself… but it works!

 

Is the potential performance improvement from permitting the value to differ worth the inevitable user confusion (or even annoyance)? I would think not, but that’s just my opinion.

 

Cheers,

 

From: J3 <j3-bounces at mailman.j3-fortran.org> On Behalf Of van snyder via J3
Sent: Friday, September 19, 2025 10:52 AM
To: j3 at j3-fortran.org
Cc: van snyder <van.snyder at sbcglobal.net>
Subject: [J3] Effect of RESULT_IMAGE in CO_xyz intrinsics

 

CO_MAX, CO_MIN, CO_REDUCE, and CO_SUM have a RESULT_IMAGE argument. The description says that its value shall be an integer that is an image index in the current team. The effect of it being present is hiding in the description of the argument named A. That description says that the result of the operation appears in A, and appears also to say that if RESULT_IMAGE is present and its value is not the index of the executing image, the value of A on that image becomes undefined.

 

This is a bit confusing.

 

Does A really become undefined on all images other than the one indexed by RESULT_IMAGE? I naively would have expected it to remain unchanged. If it's used for work space, a note to that effect would be useful.

 

One might expect the value of A on all images to be the same if RESULT_IMAGE is not present.  The description of A seems to say that, but doesn't explicitly say so.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20250919/61725b89/attachment.htm>