Re: MODULEand USE versus Argument Passing

Herman D. Knoble wrote:

Given a Subprogram that gets called millions of times,
we know that there is (CPU) overhead for subprogram linkage.


My question is, independent of compilers, which is more efficient
in practice:

passing a list of (say 3 to 10) arguments to a subprogram's corresponding parameters, OR using a Module and companion USE statement,
OR use named COMMON? 

It depends much on the processor architecture, (and linkage
convention), and not so much on the compiler.

On most systems arguments are passed by reference (address) requiring
an indirect reference.   Assumed size arrays are also passed similarly,
requiring an offset (into the array) from the passed address.

COMMON might be statically addressed, and so not require the indirect
addressing, or it might be about the same.  Though COMMON only works
if you pass the same parameters every time you call the routine.

For assumed shape arrays, a descriptor must be passed including the dimensions and even more indirect access to the data.

I don't know so well the implementation of module and USE, I will
guess it is similar to COMMON with one more level of indirection.

All the above should be fast enough for most normal uses.

There are conditions where the compiler must pass a copy of an
array, and copy it back on return. If you don't access much of
the array, the overhead can be large. If you access it a few times,
you might not notice so much. If you access each array element a large number of times, the copy might be faster as it is in contiguous storage and the cache works better that way.

In all cases, it makes a big difference to access an array in the order elements are in storage, normally with the leftmost subscript varying fastest.

Otherwise, you will need to supply more details to get a better answer.

-- glen

.

Relevant Pages

  • Re: MODULEand USE versus Argument Passing
    ... and COMMON) ... If the subroutine does anything significant, then the call overhead is likely to be small either way, and if the subroutine is small ), turn on inlining and let the compiler figure it out. ... The one related to arguments is when an array copy needs to ...
    (comp.lang.fortran)
  • Re: Largest Common Factor
    ... 4.1 is the largest common factor of ... get an integer array but feel there must be a better way. ... Euclid's algorithm would still work for non-integer elements like 12.3, ... would have to have a tolerance that allows for round-off errors. ...
    (comp.soft-sys.matlab)
  • Re: When will this ng come to accept that Fortran needs to go "back to the future" ?
    ... I fully agree with your comments about COMMON - used without tricks ... dependencies during compilation" too... ... and if it isn't a nightmare for the compiler writer, array sections. ... Again, it is there, well-proven, and easy to use in Fortran-95. ...
    (comp.lang.fortran)
  • Re: How to decide using COMMON block variables or function/subroutine parameters?
    ... common block variables. ... Different subroutines will need this array, ... Any subprogram that is generally useful, such as a root finder, ...
    (comp.lang.fortran)
  • Re: (Yet another) EQUIVALENCE problem in modules and common blocks
    ... for which I am converting arrays in common blocks to dynamically ... implicit double precision (a-z) ... array work from the module (note: the array has to be allocatable in ...
    (comp.lang.fortran)