I agree with everything Richard said, but I'm sure that avoiding copy
in/out is always a good idea. The exception is related to execution
speed. If you have "lots" of arrays and have "many" references to
them in a "whole bunch" of DO loops, then it might be better to
swallow a copy in/out to gain the "advantages" of both contiguous
memory references and simplicity of index computations.
If the passed-in stride is "large" (especally a large power of 2)
you're likely to make "inefficient" use of the memory/cache without
the copy in.
In general, if you have "lots" of arrays, "almost all" of them have
the same set of dimensions. So in an expression like
a(i,j,k) = b(i,j,k) + c(i,j,k)
the compiler only needs to compute (i,j,k) once and can use it
for all three array references, provided that it can see at compile
time that all three arrays have the same dimension set (and No, (:,:,:)
doesn't count as being the same ;> ). In "big" loops with "lots"
of array references this can speed up computation and also reduce the
possibility of running out of registers and swapping to/from
memory/cache to do subscripting.
There's a lot of uncertainity about where trade-offs occur when
you deal with assumed shape dummies. Most of the time, easy
of writing, clarity, and error checking are more important than
mere raw speed: but not always. If you have large subroutines
you might want to experiment a little.
Dick Hendrickson
Richard Maine wrote:
>
> Tony Keating writes:
> > On Sat, 2002-11-30 at 04:15, Richard Maine wrote:
> > > Be aware that it will probably cause a copy-in/copy-out because the
> > > actual argument slice is discontiguous, while the subroutine has
> > > an explicit-shape array (which generally requires contiguity).
> > > That *IS* supposed to work per the standard, but be aware of
> > > the possible performance penalty from the copy.
> >
> > Is there a way to get around this copy-in/copy-out?
> > Would using an assumed-shape array in the subroutine be a better idea?
> > I guess I'd have to be careful with lower-bounds in more complex cases.
>
> Yes, using assumed-shape dummies will almost always avoid
> copy-in/copy-out.
>
> I usually prefer assumed-shape dummies, partly because it avoids
> copy-in/copy-out, but mostly because is simplifies interfaces (because
> the array dimensions are passed for you instead of needing you to pass
> them separately) and because it improves error checking possibilities.
>
> In a case like yours, where you are passing a non-contiguous
> slice as an actual argument, I think assumed shape dummies are
> usually the best choice because they can deal with non-contiguous
> arrays without needing copy-in/copy-out.
>
> However, I hesitate to make such a broad generalization as that "using
> assumed shape is always a better idea" (not your exact words, I
> realize). Situations do vary. I tend to recommend assumed shape as
> the "default" in that I'd use it if you don't have reason otherwise,
> but I'll acknowledge that reasons otherwise occasionally exist. I do
> have a few cases of assumed size (which is not the same thing as
> assumed shape) in my own code. Its not my norm, but I do have a few
> places where it gets noticably better performance or otherwise fits a
> specific need (such as interfacing with C or with I/O systems that
> need contiguous storage).
>
> --
> Richard Maine | Good judgment comes from experience;
> [log in to unmask] | experience comes from bad judgment.
> | -- Mark Twain
|