> 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
> to
> 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.
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.
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.
Now, converting everything to C++ - now that is another point entirely...
;-)
All the best
Ross
/\
\/
|\oss Walker
| Assistant Research Professor |
| San Diego Supercomputer Center |
| Tel: +1 858 822 0854 | EMail:- ross.rosswalker.co.uk |
|
http://www.rosswalker.co.uk | PGP Key available on request |
Note: Electronic Mail is not secure, has no guarantee of delivery, may not
be read every day, and should not be used for urgent or sensitive issues.
Received on Fri Dec 05 2008 - 16:30:22 PST
