forums.silverfrost.com

[davidb]

In FORALL assignment, using a forall statement, or a forall construct, the index variable or variables should retain the defined/undefined status (and value if defined) they have at the start of the statement when the forall assignment is completed.

So in the following code, if i is undefined at the start it is undefined at the end, and if i = 4 (say) at the start then i = 4 at the end.

[LitusSaxonicum]

David,

Where do you go to learn these things? I've been reading books on post-Fortran77 all the way since Metcalf & Reid's 'Fortran 8x Explained' (which was what it was called until the 80s decade was well and truly over) - and never understood the half of it. Mind you, I struggled for a long time with FORMATs when converting from Algol-60 back in 1969, so wrestling with things written in Klingon is nothing new!

The error message you refer to is near to what a Fortran oldie would expect - so perhaps it merits a Warning at least.

It always seemed to me that the standards in Fortran 90 et seq were specified by people who hated Fortran as it was. A huge amount of effort was expended in doing things a different way, rather than (say) providing a standard method of accessing graphics, or for interacting with users - things that are done well by Clearwin, and which are far more useful than multiple ways of defining the precision of a variable, or of doing DO loops.

Eddie

[davidb]

Hi Eddie.

Well I'm one of those people who like to study the different standards and then try things out on different compilers. For a good translation of the standard I use "The Fortran 2003 Handbook" but I also use one of Metcalf and Reids books plus the different documentation with the compilers. It helps that I have a good understanding of C++ as well, which helps to make a lot of the "concepts" a bit less alien. (I started out writing Fortran IV then Fortran 77 and Pascal in the 80s).

Forall was added to Fortran 95 to provide opportunities for a programmer to hint at vectorisation on a compiler/processor that supports it (using SSE3 for example). Silverfrost FTN95 processes a Forall sequentially as far as I know, so it looks like a loop. However, technically it isn't a loop, but a fancy assignment.

A lot of the new things added from Fortran 90 can seem a bit unecessary for the Fortran 77 programmer. However, generally, the features provide ways of doing things that are essential for writing correct Fortran programs of any complexity (e.g. Explicit interfaces and Modules).

To give a specific example, the introduction of Derived Types (and Classes in Fortran 2003) makes coding much easier. But it also means that array elements of larger types can be made to "persist" on multiple, different cache lines (avoiding "false sharing"), which can provide a boost to efficiency when processes which act on them are made to run on multiple processors (using OpenMP for example, or Fortran 2008 coarrays).
_________________
Programmer in: Fortran 77/95/2003/2008, C, C++ (& OpenMP), java, Python, Perl

[PaulLaidler]

David

Thanks for the bug report. I have logged it for investigation.

[LitusSaxonicum]

David,

Thanks for the explanation - most helpful. So it is a type of assignment statement, not a loop. A pity it looks a lot like a loop then. I've spent a bit of time trying to find out about it, and what I discover is that it doesn't seem to be any sort of improvement on a DO loop.

One answer at least to my general ignorance: FORALL isn't in Metcalf and Reid's 'Fortran 8X Explained'.

My last remark in the previous posting stands. Do you think that you are the first person to discover the bug because you are the first person to use FORALL in FTN95? (Or the first person to reuse the 'i' variable in that particular way?).

Eddie

[davidb]

Eddie,

FORALL was only introduced in Fortran 95, so it wouldn't be in "Fortran 8x explained" or any book about Fortran 90. It was originally introduced in High Performance Fortran (HPF) and was then included in Fortran 95.

The FORALL construct looks like a loop, but the FORALL statement does not.

The following code to extract the diagonal of a matrix is an example of the FORALL statement (meaning: assign the diagonal elements of A to the DIAG array):

[LitusSaxonicum]

David,

An interesting and helpful exposition. Thank you for going to the trouble of explaining it. The two DO loops are the way I would have tackled this problem.

Eddie

[JohnCampbell]

David,

I note your confidence with FORALL, but I would be more cautious.

FORALL(i=1:10)
DIAG(i) = A(i,i)
B(i) = DIAG(11-i)
END FORALL

With this construct, can you be sure that all compilers would process the first line completely before B(i) =... ?

Also, your statement: "I know a lot of Fortran programmers who use FORALL a lot. "
Unfortunately, I know few Fortran programmers and fewer of them know FORALL !

Best wishes for the new year and look forward to your comments in 2013.

John

[davidb]

[LitusSaxonicum]

David and John,

For a few years from early 1970 to about early 1974, if called upon to write code for this, I would probably have done the 2 do loops. After reading a slim tome by Kreitzberg & Schneiderman, I would have used just one loop to save the loop overhead:

[davidb]

Interesting points Eddie and John.

It's only worth it if you want or need the speed-up that vectorisation can bring and you are using a compiler that supports it. (4X double precision or 8X single precision, on the new processors which support AVX instructions.)

In the following code for in place LU factorisation, the FORALL version is about 8 times faster for moderate values of n (using the Intel compiler). Notice how most of the loops and overhead have disappeared from the FORALL version.

I doubt you would see much difference with FTN95 though.

[JohnCampbell]

David and Eddie,

An interesting twist to the tale of FORALL is that Salford FTN95 had some bugs with it's implementation of FORALL for a number of years. As a consequence I have been slow to use it's syntax.
My impression is that FORALL was implemented in Fortran 95 as a pseudo "parallel" code syntax, but few compilers provided any efficiency gains from it. Even today, other optimising compilers do not automatically parallelise FORALL structures, or show any performance benefits over DO codings for the same compiler options.

FORALL has the important restriction in that the code must be "pure" and the order of calculation can not be assumed, which the compiler is to use when optimising.

Most FORALL can be easily replaced by a 1-line DO loop, such as:
DO I=1,10 ; DIAG (I) = A (I, I) ; END DO

It can be an elegent syntax, but provides little practical benefit over DO.

John

[davidb]

Sometimes FORALL is clearer code.

Look at these ways of shuffling the contents of an array. The FORALL is much clearer and closer to the mathematical syntax; the DO loop needs to work sequentially in reverse order.

[LitusSaxonicum]

Several points from this discussion, firstly that a compiler ought to conform to the standard, even if it seems to anyone that the particular facility in a standard is pointless. David's findings are therefore of great use.

Secondly, the standard doesn't say anything about 'warnings', and these can be as helpful as possible to the majority of users (FTN95 scores well here). But, the 'errors' should be 'standard conforming'.

Thirdly, FORALL doesn't actually do anything that you can't do in a DO loop - all these discussions end up by showing how the DO loop would look like. Sometimes, the DO loop(s) are a bit contrived. A useful comment that the loop needs to be 'PURE'. I always believed that FUNCTIONs should be 'pure', but some programming styles lead to 'impure' functions, and I suspect that the changes in scoping rules with MODULEs makes it more likely that routines will not be 'PURE'. I would concede that there will be cases where 90 and 95 constructs might be more elegant than 77 constructs, but I have yet to encounter a situation in my own programming that needs them.

As well as missing the opportunity to add graphics and GUI facilities to Fortran, the Standard Committee could have made in incumbent on compiler writers to generate the most efficient code ...

Eddie

[JohnCampbell]

Eddie,

Your points are well made.
However F77 had its problems. F90 standard was a significant improvement, although I regret that I did not provide input into the standard committee when it was being developed.
The standard committee has lacked the input from Fortran users, being more dominated by compiler developers and computer scientists who use other languages.
F77 had a number of poor compromises and lack of definition, due to operating system limitations of (a) major hardware manufacturer.
There was discussion in 1980's that a significant source of coding errors could be addressed by improving the linking process, but like GUI, none of this became included in the standard. The complexity of KIND is typical of how to make something simple more complex. It implies you can "adjust" the precision, when there are very few hardware options available. REAL*8 is much more effective for a programmer, but never got to the main table.
Post F95, Fortran has been taken over by C programmers, with most of the effort to turn Fortran into C, but little attention to improving the needs of numerical calculations.
Improved functionality for ALLOCATE has not happened, nor has addressing GUI's or the linking process.
We now have inter-operability and more obscure allocated derived types, few of which are needed for FORmula TRANslation computations. I wrote indexed list structures back in 70's and do not see any great leap forward with F2008. All I see is a standard that is so complex, that few compiler developers would be able to pay for developing a stable conforming compiler.
While I might dismiss your holding on to F77, I am exactly the same as you as I hold onto F95.

Unfortunately, the code committee has long dismissed us programmers and our comments and persists with a new Fortran version of C that fewer require. Any improvements are coming from compiler developers and hardware, such as Checkmate from FTN95 and OpenMP for parallel computation, outside the standard. F90 was developed with the intention of improving portability, which is an aim that is being forgotten.

My apologies David, if these old views differ from your experience, but we must all embrace the diversity.

Thanks for your discussions in 2012 and I look forward to your comments and assistance in 2013,

John