Challanges of Implementing the ISO Standard...
nobat
website(http://www.fortran.bcs.org/), I've noticed an interesting talk
by Malcom Cohen from NAG about the challenges of writing a Fortran
compiler:
On page:
http://www.fortran.bcs.org/2007/jubileeprog.php
file:
http://www.fortran.bcs.org/2007/jubilee/f50.pdf
Several interesting points, among others:
1- The timeframe/roadmap for full implementation of Fortran 2003 by
NAG,
2- The challenges related to the implementation of FORALL statement,
3- Comments regarding to the Fortran 2003 implementation and Fortran
2008 ...
One point regarding to the FORALL statement:
My understanding is that in the ISO steering committee, there are
representatives from compiler companies. If this the case and If
implementation of FORALL is so awkward why it is in the standard? (not
pretending to know how ISO committee works)
Is there anybody who actually uses the FORALL statement for the
production quality applications?
Nobat
Beliavsky
> While surfing the British Computer Society Fortran Specialist Group
> website(http://www.fortran.bcs.org/), I've noticed an interesting talk
> by Malcom Cohen from NAG about the challenges of writing a Fortran
> compiler:
>
> On page:http://www.fortran.bcs.org/2007/jubileeprog.php
>
> file:http://www.fortran.bcs.org/2007/jubilee/f50.pdf
>
> Several interesting points, among others:
> 1- The timeframe/roadmap for full implementation of Fortran 2003 by
> NAG,
> 2- The challenges related to the implementation of FORALL statement,
> 3- Comments regarding to the Fortran 2003 implementation and Fortran
> 2008 ...
>
> One point regarding to the FORALL statement:
>
> My understanding is that in the ISO steering committee, there are
> representatives from compiler companies. If this the case and If
> implementation of FORALL is so awkward why it is in the standard? (not
> pretending to know how ISO committee works)
FORALL was in High Performance Fortran (HPF), and Fortran 95 added
several features from HPF. I guess it was thought at the time that
compilers would be better able to parallelize FORALL than the
equivalent DO loops.
> Is there anybody who actually uses the FORALL statement for the
> production quality applications?
I use it in my production programs, for brevity and expressiveness.
forall (iret=1:nret,ijob=1:njobs,isys=1:nsys)
xsig_matrix(iret,ijob,isys) =
dot_product(xpos(iret,:,isys),raw_sig(iret,:,ijob)) ,
a line which appears in my code, would otherwise take 7 lines with a
triply nested loop. It's more expressive than a loop, because it does
not needlessly specify an order for the calculations to be done.
Speed is not a problem for my programs at present. The problem is that
the stocks it says will go up often go down :(. If it were I could
examine whether removing FORALLs could speed up the code.
Fortran 2008 will have DO CONCURRENT, which vaguely resembles FORALL.
Clive Page
nobat <sk.n...@gmail.com> writes
>One point regarding to the FORALL statement:
>
>My understanding is that in the ISO steering committee, there are
>representatives from compiler companies. If this the case and If
>implementation of FORALL is so awkward why it is in the standard? (not
>pretending to know how ISO committee works)
I went to Malcolm Cohen's talk which was full of interesting stuff, and
in the meal-break asked him about the problems of implementing FORALL. I
think, basically, nobody realised how hard it would be to implement
efficiently, until they actually tried to do it. His suggestion was
that programmers should avoid using FORALL. I don't recall seeing any
code that uses it, except for examples in tutorials etc.
--
Clive Page
Richard Maine
> Fortran 2008 will have DO CONCURRENT, which vaguely resembles FORALL.
No.
Well... ok... To avoid being too negative, I'll allow that how there is
some resemblance, perhaps enough to justify the above statement insomuch
as it does include the qualifier "vaguely". However, people so often
misunderstand FORALL that I hate to let anything by that could
contribute to the misunderstanding.
I'd say that there were two things that people often misunderstand about
FORALL. One is the performance issue - that FORALL more often results in
performance loss instead of gain. I'll let others speak to that, and it
is a side matter for my current purpose.
But the misunderstanding that I want to address here is that people
often think of FORALL as a looping construct. It isn't; it is an
assignment construct. I regularly see people asking why they can't put
something in a FORALL. It is clear to me that they are thinking of it as
a parallel loop construct. I might even say that DO CONCURRENT does what
many people incorrectly think FORALL does. I suppose that counts as a
vague resemblance, but I wanted to take the opportunity to make the
distinction. I think that the differences between DO CONCURRENT and
FORALL are more important than the simillarities.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
highegg
> In message <1175708907.262275.289...@p77g2000hsh.googlegroups.com>,
> nobat <sk.no...@gmail.com> writes
>
> >One point regarding to the FORALL statement:
>
> >My understanding is that in the ISO steering committee, there are
> >representatives from compiler companies. If this the case and If
> >implementation of FORALL is so awkward why it is in the standard? (not
> >pretending to know how ISO committee works)
>
> I went to Malcolm Cohen's talk which was full of interesting stuff, and
> in the meal-break asked him about the problems of implementing FORALL. I
> think, basically, nobody realised how hard it would be to implement
> efficiently, until they actually tried to do it. His suggestion was
> that programmers should avoid using FORALL. I don't recall seeing any
> code that uses it, except for examples in tutorials etc.
To be relatively happy with FORALL, one must not think about it as a
parallel DO but rather an extended array assignment. Although most
FORALLs can be replaced by using array constructors with implied-do
loops, the FORALL version is often not just more readable, but also
faster (less temporary arrays).
Array expressions, just like scalar expressions, need to use
temporaries when necessary to store intermediate results that might.
It may create an unnecessary overhead, which, however, can be only
avoided by further analysis, either by the programmer or the compiler,
to realize that there are no dependencies.
For a true (Matlab-like) array arithmetics that allows to treat arrays
quite like scalars, the ability to create temporary arrays on demand
is essential.
It is up to the compiler to eliminate them by automatic dependency
analysis and/or provide directives allowing the user to give hints
about whether temporaries are necessary. For example, I would like
Intel extend the IVDEP also to FORALLs and array expressions to
specify that the lhs and rhs are independent and thus no temporary is
needed for rhs.
I think that an experienced C or F77 programmer might be disappointed
by F95 array facilities creating more often slowdowns than speedups.
The price is high, but the reward is IMHO good,
one can write things like
! scale and normalize
y = D*x / maxval(abs(D*x))
without thinking too much about it. The best way to implement this
statement depends on several circumstances - and the compiler may even
do a better job than the programmer.
Tim Prince
> Beliavsky <beli...@aol.com> wrote:
>
>> Fortran 2008 will have DO CONCURRENT, which vaguely resembles FORALL.
>
> No.
>
> Well... ok... To avoid being too negative, I'll allow that how there is
> some resemblance, perhaps enough to justify the above statement insomuch
> as it does include the qualifier "vaguely". However, people so often
> misunderstand FORALL that I hate to let anything by that could
> contribute to the misunderstanding.
>
> I'd say that there were two things that people often misunderstand about
> FORALL. One is the performance issue - that FORALL more often results in
> performance loss instead of gain. I'll let others speak to that, and it
> is a side matter for my current purpose.
>
> But the misunderstanding that I want to address here is that people
> often think of FORALL as a looping construct. It isn't; it is an
> assignment construct. I regularly see people asking why they can't put
> something in a FORALL. It is clear to me that they are thinking of it as
> a parallel loop construct. I might even say that DO CONCURRENT does what
> many people incorrectly think FORALL does. I suppose that counts as a
> vague resemblance, but I wanted to take the opportunity to make the
> distinction. I think that the differences between DO CONCURRENT and
> FORALL are more important than the simillarities.
>
"a do construct .... is required to perform each successive iteration in
order and one after the other. This represents a potentially severe
impediment to optimization on a parallel processor so, for this purpose,
Fortran has the forall...." Soon after, they give an example where
"forall is more readable [than array assignments]."
I remember also that it took about 15 years before all compilers
implemented DO in accordance with f77. I was perhaps misled into
thinking it would be easier to implement an iterative construct which
didn't require making the index variable state match pre- and post- loop
state.
I still have not got my head around all the ways in which actual C and
C++ compilers handle for index variable after the loop, disregarding
standards and sanity. At my age, it may be doubted that I ever will.
So, I think the time some of us have spent attempting to use FORALL in
place of f90, f77, and f66 syntax should be forgiven, if only we can
come eventually to a correct conclusion.
In practice, I have noted:
1) Early partial f95 implementations converted FORALL immediately to a
DO loop, if such was easily accomplished. Then, nothing was lost,
although one might argue that only the functionality common to DO and
FORALL was implemented.
2) I find it impossible to guess whether FORALL or DO will wind up more
efficient, if both work, but the down side remains greater with FORALL.
3) All OpenMP implementations work well with the DO loop, under
appropriate conditions; few handle FORALL well.
4) My customers reject FORALL (along with many other features of the
last 15 years).
glen herrmannsfeldt
(snip)
> But the misunderstanding that I want to address here is that people
> often think of FORALL as a looping construct. It isn't; it is an
> assignment construct. I regularly see people asking why they can't put
> something in a FORALL. It is clear to me that they are thinking of it as
> a parallel loop construct. I might even say that DO CONCURRENT does what
> many people incorrectly think FORALL does. I suppose that counts as a
> vague resemblance, but I wanted to take the opportunity to make the
> distinction. I think that the differences between DO CONCURRENT and
> FORALL are more important than the simillarities.
I think I agree, though I am not sure why. FORALL seems to have
the restrictions one might expect for a parallel loop construct,
though I do agree that the word loop should not be there.
It does seem like it was designed to allow parallel implementations.
Specifically, the restriction against many to one assignment
would seem convenient for implementing assignment on machines
with vector registers. But if one did want to implement vector
registers one would want to allow them to be used between
statements in the same FORALL construct, though there is no restriction
on that. Given that real vector processors, such as the CRAY series,
are out of fashion, it does seem not to be so useful.
-- glen