(j3.2006) for all comments in c.l.f
Tue Oct 1 18:11:40 EDT 2013
The (clumsily) attached news posting from c.l.f expresses some concerns
about obsoleting FORALL.
No comment from me, just FYI.
From: Ian Harvey <ian_harvey at bigpond.com>
Subject: Re: FORALL's proposed obsolescence
Date: Mon, 30 Sep 2013 23:00:49 +1000
Organization: A noiseless patient Spider
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>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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>
Xref: news.eternal-september.org comp.lang.fortran:48379
On 2013-09-12 10:43 AM, Dan Nagle wrote:
> On 2013-09-09 06:10:13 +0000, Ian Harvey said:
>> On 2013-09-07 6:04 AM, Dan Nagle wrote:
>>> 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
- 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
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
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 22.214.171.124 (and perhaps
the first sentence of the second dot point) a constraint, and my
concerns evaporate, but the vendors might not like that much... ).
More information about the J3