Re: Global array operations: a performance hit?
- From: nospam@xxxxxxxxxxxxx (Richard Maine)
- Date: Tue, 17 Jun 2008 11:31:06 -0700
deltaquattro <deltaquattro@xxxxxxxxx> wrote:
I was wondering whether global array operations, introduced in f90,[elided initialization with DO loops and whole array operations]
can have a negative impact on performance. Compare:
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
.
- Follow-Ups:
- Re: Global array operations: a performance hit?
- From: Dennis Wassel
- Re: Global array operations: a performance hit?
- References:
- Global array operations: a performance hit?
- From: deltaquattro
- Global array operations: a performance hit?
- Prev by Date: Re: Fortran 'read' statement question
- Next by Date: Re: Fortran 'read' statement question
- Previous by thread: Re: Global array operations: a performance hit?
- Next by thread: Re: Global array operations: a performance hit?
- Index(es):
Relevant Pages
|
|