Re: Global array operations: a performance hit?



deltaquattro <deltaquattro@xxxxxxxxx> wrote:

I was wondering whether global array operations, introduced in f90,
can have a negative impact on performance. Compare:

[elided initialization with DO loops and whole array operations]

I found the execution time of the latter to be higher than the former,
as if many DO loops were executed instead than just one. Why use
global array operations then? Isn't better to stick to old plain DO
loops? Thanks,

Note that the usual terminology is something more like "whole array
operations" or even just an unmodified "array operations" instead of
"global".

The main reasons are clarity and conciseness. If it doesn't help clarity
and conciseness, don't do it. That is, no doubt, an oversimplification;
there are exceptions, etc. But its a good first approximation. Every
once in a while they might also get you faster execution, but if that is
your primary reason for using them, and you don't have specific
knowledge of exactly why to expect faster execution from your paticular
case, then your efforts are probably misplaced.

Execution time is actually not the sole measure of code "goodness". In
many cases, it isn't even particularly high on the list of important
things. Sometimes it isn't on the list at all. Other times it is at the
very top of the list. All generalizations are false, your mileage may
vary, etc.

In that regard, is execution time of an initialization such as this
actually significant in your code? While possible, that would be
unusual, and might suggest that the choice of algorithms is less than
ideal. There can be efficient algorithms like that, but they are rare.
As Dennis says, it can be tricky to even measure execution times
precisely enough to time initializations like this. I'm supposing that
perhaps you are just using this as an example of more "interesting"
cases.

In answer to Dennis, by the way, it is *VERY* common for whole array
operations to be slower than DO loops. No, it is not all all strange. It
is much closer to the usual state of afairs. There are a whole host of
reasons.

1. Compilers have had over 5 decades of time to develop techniques of
optimizing loops. Progress has been made in that time. There has only
been about a decade or two (some work preceeded the f90 standard; other
compilers didn't really start until later) of significant work on
optimizing array expressions. Things have improved and are still
improving, but it just is not at the level of experience of DO-loop
optimization.

2. Array temporaries are often a big deal in whole-array expressions. A
naive (aka straightforward) applicaion of the rules very often involves
such array temporaries, which are expensive in time. The compiler has to
do a fair amount of work to figure out whether they can be elided. See
point 1. That's probably not the case for your example, but it is a
common one.

3. Your example illustrates the problem of "loop fusion". The naive
(again aka straightforward) application of the rules for your code
example *DOES* imply separate loop for each array operation (complete
with all loop overhead). That's how the operations are defined. It is an
optimization for the compiler to recognize when it can usefully fuse
these multiple loops. See point 1.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
.



Relevant Pages

  • Re: Fortran memory management, error handling, and efficiency
    ... > f77 style codes, for example an array operation may be slower than an ... There is always a tradeoff between features and execution ... Simple array operations should be implemented exactly as they ... would with loops. ...
    (comp.lang.fortran)
  • Re: Fortran memory management, error handling, and efficiency
    ... >>There is always a tradeoff between features and execution ... Simple array operations should be implemented exactly as they ... >>would with loops. ... leaving details to the compiler. ...
    (comp.lang.fortran)
  • Re: Puppy Mastiff wants to Nip at Faces
    ... first couple of weeks of an introductory data structures ... it seems to me by my recollection that loops were... ... in my first college textbook on structured programming. ... they did was loop through an array to show how you could easily access ...
    (rec.pets.dogs.behavior)
  • Re: Postscript questions
    ... It looks as if you believe the curly braces are defining a scope. ... Curly braces are behaving much more like the square brackets, the array "delimiters". ... The difference is deferred execution, ... Evaluating an executable name means that the interpreter searchs the name through the dictionnary stack and when found, evaluate the value associated with the name. ...
    (comp.lang.postscript)
  • Re: Inefficient code?
    ... line is written to the output file. ... or read it into an array. ... # Backup File Field Positions ... Define 'my %found;' above the loops. ...
    (perl.beginners)