On 02/24/2010 07:30 PM, Greenberg, Naomi wrote:
> I am looking for books or articles that discuss machine efficiency issues with respect to the more OO-oriented Fortran features.
>   

Not a book nor another reference, but my limited understanding from
playing around with OOP and following the OOP development in gfortran:
As long as the compiler knows the type at run time, there should be no
more overhead than with standard Fortran 90. As soon as the compiler
does not know the type - e.g. you have CLASS somewhere - it needs to
check the effective type using - typically - a vtable and you will see
some slowdown. Whether this slowdown is negligible or not depends on the
details.

Having only one, two extension levels of a type also helps to reduce the
vtable size and the traveling through the partent types to call the
finalization subroutine. (Additionally, a very deep inheritance
hierarchy is often a sign of bad design.)

Maybe a more relevant change in Fortran 2003: If "A" is allocatable then
doing
  A = some_expression
will reallocate "A" if the shape of A does not match the right-hand
side. That's a nice feature, but has some overhead. If you do not want
to have the reallocation, you can do:
  A(:,:) = some_expression
which prevents the reallocation (and all compilers should be smart
enough to figure out that this is effectively a whole-array reference).

Tobias

PS: Writing clean, simple, and understandable code is usually better
than trying to blindly optimize it - which even might lead to slower
code. If one optimizes, one should do a benchmark first to find the
relevant parts and confirming that the code really runs significantly
faster with the optimization. On the other hand, it helps if one tries -
while writing/designing code - to keep the memory access local and work
mostly with access to contiguous memory (e.g.  A(:, n) is better than
A(n, :)).

PPS: Talking about efficiency in Fortran 95+: I really like the
CONTIGUOUS attribute of Fortran 2008 - it finally combines the advantage
of assumed-shape arrays (no copy in, copy out needed, having an array
descriptor) with the advantages of assumed size/explicit size arrays,
namely: having a stride of 1 which simplifies the code (in terms of
machine instructions) and allows for vectorization. Hopefully, it will
get soon implemented in the compilers.