one-line function declarations & f90 
Author Message
 one-line function declarations & f90

I'm not sure that I have the right name, but I mean the simple,
one line functions like

    real f = a + b

I understand that modules were supposed to make these obsolete,
but they seem to be designed for more complicated issues.

I have a handful of relatively simple things that I'd like to keep
in a single location that are used in different modules.  These
lines are called regularly, and I want to avoid the overhead of
function calls.  I know that the optimizer *might* inline these,
but is there any way of insuring this?

Naturally, these occur in som of the performance-critical areas . . .

rick

--
These opinions will not be those of ISU until it pays my retainer.



Wed, 18 Jun 1902 08:00:00 GMT  
 one-line function declarations & f90


Quote:
>I'm not sure that I have the right name, but I mean the simple,
>one line functions like

>    real f = a + b

>I understand that modules were supposed to make these obsolete,
>but they seem to be designed for more complicated issues.

>I have a handful of relatively simple things that I'd like to keep
>in a single location that are used in different modules.  These
>lines are called regularly, and I want to avoid the overhead of
>function calls.  I know that the optimizer *might* inline these,
>but is there any way of insuring this?

Well, you can still use statement functions in the present standard.
It will be obsolescent and then deleted in the next couple of revisions
(10-15 years?).  So you can still write:

   f(a,b) = a + b

before any of your executable statements to declare these functions.

But, the actual replacement for statement functions is not MODULEs,
but internal procedures.  Since these are part of the source code for
the procedure which calls them, they should be inlined and/or otherwise
aggressively optimized at all times.   They aren't as succinct.  At the end
of you code you write:

Contains
  function f(a,b)
   some_type :: f, a, b
   f = a + b
  return
  end function f

Internal procedures can call each other, and they inherit all the local
variables of the procedure they're contained within.

--
J. Giles



Wed, 18 Jun 1902 08:00:00 GMT  
 one-line function declarations & f90

Quote:
> I'm not sure that I have the right name, but I mean the simple,
> one line functions like

>     real f = a + b

> I understand that modules were supposed to make these obsolete,
> but they seem to be designed for more complicated issues.

The name you are looking for is probably "statement functions".
The name presumably derives from the fact that the whole function
is defined in a single statement (ignoring the somewhat subtle
interactions with other declarations in the host scope).

Modules don't have too much direct relationship to statement functions.
Yes, you can write a function as a module procedure, and yes,
you could presumably use it where you used a statement function before,
but this doesn't have much bearing on the particular features of
statement functions.

The more direct replacement for statement functions is internal
procedures.  An internal procedure shares one of the fundamental
properties of a statement function.  It is available only in the
procedure where it was defined.  This has 2 results.

  1. You don't need to worry about name conflicts outside of
     the procedure in question.  You can have zillions of procedures,
     each with a statement function or internal procedure named fred,
     and the various fred's don't interfere with each other.

  2. Because code for the statement function or internal procedure is
     physically within the code for the host procedure, the compiler
     will always have it available when compiling the host, and the
     odds of the compiler doing something "smart" like inlining
     are improved.  Separate compilation is never an issue with
     statement functions or internal procedures.  Inlining is
     certainly not guaranteed, but the odds are probably better.

And, of course, although statement functions are on the obsolescent
list, they are still part of the standard.  Every full language
f90 or f95 compiler supports them by definition (ELF and F are
not full language).  So you can still use them.  I don't personally
"like" them, but that doesn't have to be an influence.

My dislike relates mostly to the quirky way that statement function
argument characteristics interact with the host.  The declaration of
a statement function isn't really as self-contained as it looks.  If
you have an f(x) and want the x to be double precision (or whatever),
you put a declaration of x in the host.  This single declaration
might then declare 2 different things, both named x.  One is the statement
function dummy argument.  The other is an unrelated variable in the
host.  I find this confusing and strange.

Quote:
> I have a handful of relatively simple things that I'd like to keep
> in a single location that are used in different modules.  These
> lines are called regularly, and I want to avoid the overhead of
> function calls.  I know that the optimizer *might* inline these,
> but is there any way of insuring this?

Um.  Oh.  If you want to be able to call them from different modules,
then neither statement functions nor internal procedures will do that.
One of the fundamental things about both is that they are internal
to a single procedure.  If you want something called from several
diffferent places, the only "natural" options are external or
module procedures.

Inlining is completely compiler-dependent.  About the only "portable"
way I know to "insure" it is to not give the compiler any other
options.  Otherwise, its time to check the compiler manuals.

The idea of not giving the compiler any options might, in fact, be
practical.  If your functions are really simple enough to work as
statement functions, then they might also be simple enough to work as
macros.  If the compiler never sees a function call, but just sees the
result of the macro expansion, then its pretty much guaranteed to
"inline" it.  (Well, one can imagine processors that generate function
calls for pretty much everything - but then you presumably wouldn't be
using compilers like that in an application that cared about
performance). Yes, I know that fortran doesn't have macros.  But there
are several macro processors readily available.  Portability can be an
issue, but not necessarily an intractable one.

Not sure whether I'd recommend using macros for the purpose.  It does
add on a lot of "baggage" to have to worry about the complications in
your compilation procedures and the extra portability issues.  But I
like to make sure that all possibly reasonable options are at least known.
Depending on the situation, this could be one of them.

Another possibility is to go with the statement functions or internal
procedures and use an include to bring them into everywhere that needs
them.  Of course, an include takes about the same amount of code as a
statement function (unless its an awfully long statement), but I suppose
there could still be arguments for it in terms of centralizing the
stuff for maintenance purposes.  Unlike the macro approach, using an
include for a statement function or internal function does not portably
guarantee that it will be inlined, but it probably makes your odds better.

P.S. Using "include" with statement functions probably increases the
odds of screwing up interactions between the dummy argument names and
local host names.  Caveat emptor.

--
Richard Maine



Wed, 18 Jun 1902 08:00:00 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. F90 function declarations

2. How to replace one or two words with one word with one line of awk code

3. Trouble using variables for function names in function declarations

4. Trouble using variables for function names in function declarations

5. Two lines to one line

6. dimension declaration in F90

7. declarations in MIPSpro f90 7.3 and 7.4

8. F90 Name conflicts with common block declaration

9. Multiple declaration in MIPSPro 7.2 f90

10. dimension declaration in F90

11. Type declarations in F90

12. All file declarations in one file

 

 
Powered by phpBB® Forum Software