Internal procs 
Author Message
 Internal procs


Quote:
>re: reasons for writing internal procedures..

>Assuming you are referring to:
>CONTAINS
>Here are just 2 of my main reasons...
>1.  Allow procedure to have access to caller's variables without
>     using module, common, or calling sequence...
>2.  Speed up calling the procedure if its important to get a little bit
>     of extra performance..

To amplify the second point, the compiler is free to do all kinds
of optimizations on internal procedures.  It can inline them before
it does its normal optimizations on the code (so, constant propagation,
strength reduction, common expression handling, etc. are all done
across the procedure boundary).  This means that, at least with a
good compiler, using an internal procedure is no slower than
writing the equivalent code explicitly at each reference.

So, things that make reading the code easier, but you don't want
to pay the procedure call penalty are now possible (something like
SWAP(X,Y) - it replaces three statements with a mnemonic single
call).  Also, sophisticated things that you need to do several times,
but all inside the innermost loop of your code, can be written once
and called - without a procedure call penalty in speed.

There are a number of things of this kind that I find useful.  The
use of a separate file containing definitions of internal procedures
which I can INCLUDE wherever I might need them is a good
deal.

--
J. Giles



Wed, 18 Jun 1902 08:00:00 GMT  
 Internal procs


Wed, 18 Jun 1902 08:00:00 GMT  
 Internal procs

Related to the issue of internal procedures is MODULE
procedures.  Though MODULEs use the same CONTAINS
syntax, MODULE procdedures are not necessarily treated
as efficiently.  In fact they usually are not.  Even very good
compilers don't necessarily inline MODULE procedures.
That's why the use of INCLUDE is usually better.

In fact, I've written on this subject before.  I don't believe that
the compiler should be allowed to inline (or do any other
aggressive interprocedural analysis) on MODULE procedures.
This is because I believe that the actual code in the definition
of a MODULE procedure should be PRIVATE to that procedure.
That is, it should not be required to be available at the compile-time
of any USE of the MODULE.  This would permit you to write
changes to the way a MODULE's code worked, and as long
as you haven't changed any of the procedures' interfaces you
don't need to recompile USEs - only relink them.  Unfortunately,
the way the standard is presently interpreted, this would be
considered an incompatible change - so it can't be done
easily.

There is an alternative which is less palatable, but at least give
the same capability to the programmer: allow separately compiler
procedures to USE MODULEs that contain INTERFACE
specifications for the procedure itself.  For example:

MODULE A
  INTERFACE
      FUNCTION X(I)
      ...
   END INTERFACE
END MODULE A

---

In a separately compiled source file:
FUNCTION X(I)
  USE A
  ...
END FUNCTION X

The meaning of this would be that any interface to itself that a
procedure USEd would just be checked against the actual
declaration of the procedure and its arguments.  The code
for the procedure is still independently compiled, so changes
to the code can be made without recompiling all the procedures
that call the procedure - just relinking them.  This is an
important consideration for many programmers - particularly
vendors.

--
J. Giles



Wed, 18 Jun 1902 08:00:00 GMT  
 Internal procs


]Related to the issue of internal procedures is MODULE
]procedures.  Though MODULEs use the same CONTAINS
]syntax, MODULE procdedures are not necessarily treated
]as efficiently.  In fact they usually are not.  Even very good
]compilers don't necessarily inline MODULE procedures.
]That's why the use of INCLUDE is usually better.

 Why Sun f90 v. 1.2 does not allow internal procedure to be passed
 as an argument to a subroutine, while allowing module procedure
 to be passed ? Is it a bug ?



Wed, 18 Jun 1902 08:00:00 GMT  
 Internal procs


Quote:
>]Related to the issue of internal procedures is MODULE
>]procedures.  Though MODULEs use the same CONTAINS
>]syntax, MODULE procdedures are not necessarily treated
>]as efficiently.  In fact they usually are not.  Even very good
>]compilers don't necessarily inline MODULE procedures.
>]That's why the use of INCLUDE is usually better.

> Why Sun f90 v. 1.2 does not allow internal procedure to be passed
> as an argument to a subroutine, while allowing module procedure
> to be passed ? Is it a bug ?

Perhaps the internal procedure is always inlined while the
module procedure is never inlined.  That would mean that
the module procedure has an address which could be passed
as the argument.  Meanwhile, there would be no such
address for the internal procedure - all instances of it
having been inlined and then optimized.  I don't use the
Sun compiler, so I can't tell what it actually does.

The standard itself allows module procedures to be used
as arguments, it does not allow internal procedures to be
used that way.  Even if your compiler does not inline the
internal procedures, maybe it is just enforcing the standard.

--
J. Giles



Wed, 18 Jun 1902 08:00:00 GMT  
 Internal procs


Wed, 18 Jun 1902 08:00:00 GMT  
 Internal procs

An example of a situtation is in the coding of a tree sort
(or heap sort...).  Here there is a bit of code - the
siftup operation - that is used at two places in the
sort.  It is such a peculiar and unique bit of code that
it is unlikely to be of any use elsewhere, and so there
is no point in having it known outside the sort routine.
An internal procedure is ideal because no explicit linkage
is needed, all variables can be taken from the environment.
Internla procedures allow a generalization of the statement
function.  One often finds short bits of repeated code, that
can't quite be squeezed into a single line but don't
merit a full subroutine - e.g. exchange x and y
          temp=x
          x=y
          y=temp

--
"In spite of his name he's a real Quebecker"
(One of Rene Levesque's all too frequent
tribal xenphobic remarks.



Wed, 18 Jun 1902 08:00:00 GMT  
 Internal procs

What are some reasons for using internal procedures? The only one
I can
think of at the moment is when a team writes bits of a large
program
and some members write routines with names they suspect others
might
pick. This probably happens very rarely (?).

    One reason is to have an automatic explicit interface for
    a procedure that is required in only one other program unit.
    Note that an internal procedure has access to all its hosts
    entities, including any other internal procedures it might
    contain.

    Otherwise, a module procedure is more useful and more
    general.

              Mike Metcalf  

--



Wed, 18 Jun 1902 08:00:00 GMT  
 Internal procs


Wed, 18 Jun 1902 08:00:00 GMT  
 Internal procs


Quote:

> Why Sun f90 v. 1.2 does not allow internal procedure to be passed
> as an argument to a subroutine, while allowing module procedure
> to be passed ? Is it a bug ?

Section 12.4.1.2 of the fortran 90 standard states

      If a dummy argument is a dummy procedure, the associated actual
      argument must be the specific name of an external, module, or
      intrinsic procedure.

Section C.12.10 of the Fortran 90 standard states

      This standard does not allow internal procedures to be
      used as actual arguments, in part to simplify the problem
      of ensuring that internal procedures with recursive hosts
      access entities from the correct instance of the host.

                                        Sincerely,
                                        Bob Corbett



Wed, 18 Jun 1902 08:00:00 GMT  
 Internal procs


Wed, 18 Jun 1902 08:00:00 GMT  
 Internal procs

Quote:



> >re: reasons for writing internal procedures..

> >Assuming you are referring to:
> >CONTAINS
> >Here are just 2 of my main reasons...
> >1.  Allow procedure to have access to caller's variables without
> >     using module, common, or calling sequence...
> >2.  Speed up calling the procedure if its important to get a little bit
> >     of extra performance..

> To amplify the second point, the compiler is free to do all kinds
> of optimizations on internal procedures.  It can inline them before
> it does its normal optimizations on the code (so, constant propagation,
> strength reduction, common expression handling, etc. are all done
> across the procedure boundary).  This means that, at least with a
> good compiler, using an internal procedure is no slower than
> writing the equivalent code explicitly at each reference.

[...]

I find this preoccupation with performance a little strange. Maybe that's
because I work with a lovely fast Alpha. I thought that the days of
tweaking your programs were over. I have been telling my students that I
don't care if something runs for 3 or 4 msec; it's much more important to
write clear code, that I myself can understand 6 months later, than optimal
code. Is this not more or less the accepted view nowadays?

I do understand that there are people who write longer programs than my
"toy programs" (as a friend of mine called them once) and maybe 3h instead
of 4h would be interesting. I also understand the points made by some other
respondents about explicit automatic interfacing etc. Thanks, everybody.

-- Dieter Britz.    Visit me at http://www.kemi.aau.dk/~db



Wed, 18 Jun 1902 08:00:00 GMT  
 Internal procs

Quote:
>I find this preoccupation with performance a little strange. Maybe that's
>because I work with a lovely fast Alpha. I thought that the days of
>tweaking your programs were over. I have been telling my students that I
>don't care if something runs for 3 or 4 msec; it's much more important to
>write clear code, that I myself can understand 6 months later, than optimal
>code. Is this not more or less the accepted view nowadays?

It seems to be accepted view at schools that speed doesn't matter.
Yet, I can't think of any development in the computing industry that
isn't speed driven.  If no one cared for speed, then no one would
ever buy a new computer - not until their existing one broke and even
then they'd buy the cheapest replacement with the same performance
of the one that broke.  But, that's not the case.  People buy faster
machines long before their old ones break.  Mostly for the speed.

If changing which compiler you use, or altering the location of your
procedures from MODULEs to internal will eliminate a need to move
to faster hardware, or even delay such an expensive step, won't it
often be worth it?

Quote:
>I do understand that there are people who write longer programs than my
>"toy programs" (as a friend of mine called them once) and maybe 3h instead
>of 4h would be interesting. I also understand the points made by some other
>respondents about explicit automatic interfacing etc. Thanks, everybody.

Well, I have long worked with people for whom the difference might
be three weeks instead of four.  With this kind of time, and the cost
of the most expensive hardware only justifying itself if it is fully
utilized,
improvements in efficiency are still the driving force behind many
programming efforts.  Yet there's still a desire for the advantages
in legibility and correctness of using well modularized code.  Internal
procedures fill a useful role in this respect.

So, yes it is important to write clear code that you can understand
6 months later - or 6 years.  Is is more important than optimized
code?  Why make the tradeoff unless it's necessary?  Use the
language features that give you both.

--
J. Giles



Wed, 18 Jun 1902 08:00:00 GMT  
 
 [ 21 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Internal BUG, or internal OPTIMIZATION?

2. Returning result sets from db2 stored procs to vast 4.2

3. Little endian problem with Dual Procs

4. Deleted procs not deleted???

5. Invoice Procs

6. SQL server stored procs questions

7. Sharing a handcoded Q with several Procs

8. Needed: recipe for using Oracle stored procs from IBM ST

9. Those Persistent Phantom TODO Procs!

10. Store procs in SQL

11. Dynamic calls to DLL Procs CW2.0

12. LOGO-L> PROCS in MSWLogo

 

 
Powered by phpBB® Forum Software