Hi,
This thread is spiraling and missing one of my main points:
the advantages of get/set for the initial conversion
plus bypassing the need for compiler inlining are easily obtained:
> > However, consistently chosen get/set names
> > could be easily globally replaced into array references.
> > (And globally re-replaced if the debugging need arised.)
I.e., replace all those ene(your_favorite_integer)
with call xet_energy_readable_name( an_argument ),
where x is an element of {g,s}, then run the special test cases,
debug as necessary, and finally execute e.g.,
sed 's/call get_energy_readable_name( an_arg )/an_arg=ene( readable_name )/'
similarly for set.
On Sun, 23 Nov 2008, Ross Walker wrote:
> > though :-) I do think that get()/set() routines here would be overkill,
> > though, and I am not aware of an inlining standard for f90/95 (maybe I
> > missed something, but I did just drag down the iso/ansi reference). For
> > c++, this is a no-brainer, given that you have a situation where you want
> > limit the modification scope.
>
> Yes, I was thinking the same thing, given that there is no prototyping in
> Fortran and all optimization is generally done at the object build stage the
> only way this would work is if the get/set routines were in the same file as
> where they are used - which obviously wouldn't work. I don't know if the
> situation with modules is different but I suspect these, in reality, just
> allow for namespacing and not for actual inline optimizations.
No, there are many many compilers that have an IPA that
works across files; some store details in object files and have the
linker "paste" in the code. See the sgi man page for ipa:
By contrast, IPA algorithms analyze more than a single procedure
(preferably the entire program) at once. The optimizations performed
by the MIPSpro compilers' IPA utility include:
* Inlining: Calls to a procedure are replaced by a suitably modified
copy of the called procedure's body inline, even if the callee is in
a different source file.
...
IPA works by postponing much of the compilation process until the link
step, when all of the program components can be analyzed together.
Specifically, the following occurs:
* The compile step does initial processing of the source file, placing
an intermediate representation of the procedures it contains into
the output .o file instead of normal relocatable code. Such object
files are called WHIRL objects to distinguish them from normal
relocatable object files.
> Compilers such as ifort support Interprocedural optimizations with the -ipo
> flag which I think will do the sort of inlining you are referring to but at
> present we only use -ip with sander (Bob uses ipo for pmemd I believe). I
> tried turning on -ipo for sander and it ran fine until the link stage where
> the memory requirements exploded and my machine ran out of swap space. Thus
> I'm not sure we can rely on the compiler to inline things in order to not
> impact performance.
Yes, ifort does inlining; it use to put intermediate code in files during
compilation and use that during linking. And yes sometimes this leads to
slow builds, but by restricting the size of inlinable routines one can
work around this issue.
> Note I believe there are a number of other C++ like approaches to coding
> which make sense from a code standpoint but are not dealt with efficiently
> in Fortran so we have to be careful getting too c++ like in the code.
"...premature optimization is the root of all evil." Knuth, Donald.
Read this
.article{knuth71,
author = "{Donald E. Knuth}",
title = "Empirical Study of {Fortran} Programs",
journal = spe,
volume = 1,
pages = {105--133},
year = 1971 }
.string{spe = "Software --- Practice and Experience"}
Scott
Received on Fri Dec 05 2008 - 16:30:57 PST
