(j3.2006) for all comments in c.l.f

[Dan Nagle]

Hi,

The (clumsily) attached news posting from c.l.f expresses some concerns
about obsoleting FORALL.

No comment from me, just FYI.

Path: eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Ian Harvey <ian_harvey at bigpond.com>
Newsgroups: comp.lang.fortran
Subject: Re: FORALL's proposed obsolescence
Date: Mon, 30 Sep 2013 23:00:49 +1000
Organization: A noiseless patient Spider
Lines: 87
Message-ID: <l2bsm6$vtt$1 at dont-email.me>
References: <cdec9e23-37e3-4889-9317-ba71a6d6494d at googlegroups.com> <b8rveiFu92gU1 at mid.individual.net> <l0avb5$13l$1 at dont-email.me> <l0b4qu$os8$1 at dont-email.me> <l0b87r$7gm$1 at dont-email.me> <l0dcfu$r27$1 at dont-email.me> <l0joo8$lia$1 at dont-email.me> <l0r2nn$3p5$1 at dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 30 Sep 2013 13:00:55 +0000 (UTC)
Injection-Info: mx05.eternal-september.org; posting-host="b59a2c4bbb2b0a5e016302e0e1abd7d5";
	logging-data="32701"; mail-complaints-to="abuse at eternal-september.org";	posting-account="U2FsdGVkX18kjaPY6B/NY9VJPRPW69avQAzTRY+LOGo="
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
In-Reply-To: <l0r2nn$3p5$1 at dont-email.me>
Cancel-Lock: sha1:OSyIIc9GUsDo9s2ekbaxSGxPKtQ=
Xref: news.eternal-september.org comp.lang.fortran:48379

On 2013-09-12 10:43 AM, Dan Nagle wrote:
> Hi,
>
> On 2013-09-09 06:10:13 +0000, Ian Harvey said:
>
>> On 2013-09-07 6:04 AM, Dan Nagle wrote:
>>> Hi,
>>>
>>> On 2013-09-06 00:39:21 +0000, Ian Harvey said:
>>>
>>>> I agree - completely independent of its suitability (or lack thereof)
>>>> for parallel execution or vectorisation or whatever, it is concise and
>>>> clear way of writing certain array-like assignments.
>>>
>>> Do concurrent uses a forall header to express the iteration space,
>>> including the mask expression.
>>
>> The issue, as I see it (and perhaps I'm looking the wrong way!), is
>> more around the constraints and requirements of what is permitted in
>> between the FORALL statement and END FORALL, and similarly DO
>> CONCURRENT and END DO, and not the syntax per-se.
>
> If you can show enough actual use cases, I'll take the discussion
> to J3, who are now considering what to do with f1x.
>
> But show me cases that can't be done with intrinsics (yes, I know
> some are not well-optimized) or pointers, including pointer rank-
> and bounds- remapping.
>
> If you can build a good set of cases, there's a good chance
> of changing the work list for f1x.  In any case, if I think it's
> a good set of use-cases, I'll try.  :-)
>
> The next J3 meeting http://www.j3-fortran.org is in October, in Las Vegas.

I've been thinking about this in the intervening weeks and had a look 
through my actual uses of FORALL.  They fell into two overlapping 
categories:

- simple assignment that could have been done using 
lower_exp:upper_exp:stride_exp array notation, but the ability to factor 
out the range into the forall header made for clearer, less repetitive code

- more complicated assignment that couldn't be expressed using array 
assignment, generally because two subscripts needed to vary at the same 
time (e.g. operations on a diagonal or some operation on a 2D array to 
give a 1D array).

In both categories there were examples where the variable appeared in 
the expression, but in all cases there was a straight-forward one-to-one 
mapping.

My understanding is that these would be easily transferred across to DO 
CONCURRENT (nuisance levels of effort, mostly around the differences 
between a single statement forall-stmt and the multiple statement 
do-construct).

However, my understanding is also that these particular use cases don't 
trigger the "real" issues associated with FORALL (apart from the need 
for the compiler to identify that those issues don't exist) - should a 
vendor have decided it was worthwhile to implement the necessary 
analysis in their compiler, the assignment could be carried out by a 
simple loop without the need for any temporaries.

 From my point of view as a Fortran programmer, I don't then really see 
this impending obsolescence as improving my lot.  The move to DO 
CONCURRENT is a relatively mild nuisance in terms of the necessary 
source change, but doesn't offer any code robustness or clarity benefits 
and isn't likely to offer any performance improvement (assuming that 
vendors have already put the required analysis work into FORALL).

So... "actual" use cases in my code that trigger my concern?  No.

But this proposal still makes me a bit twitchy - there are potential 
uses of FORALL that don't map across.  Here's one I found in "someone 
else's" code - in appendix C.4.6 of Fortran 2008:

     J = (/ 1, 2, 3, 4, 5 /)
     FORALL (K = 1:5) J(K) = SUM(J(1:K) )

Blindly change that to a DO CONCURRENT (K = 1:5); J(K)=...; END DO and 
you are in a world of hurt, without the help of any numbered constraints 
to tell you that things are going to go bad.

(Make the first sentence of the first dot point in 8.1.6.7 (and perhaps 
the first sentence of the second dot point) a constraint, and my 
concerns evaporate, but the vendors might not like that much... ).

--

Cheers!
Dan Nagle