Re: Q: access to subprogram

[dewar@cs.nyu.edu (Robert Dewar)]

Jon Anthony says

"I don't see how, as most programs will not have _any_ nesting.
Period.  So displays or static links are irrelevant for nearly all
cases.  So, the issue is irrelevant to [probably not even hyperbole
here] 99+% of subprogram calls.  Which means that there really is no
distributed overhead (at least not as I understand the term)."

This is wildly overstated. I would say that any large program that has
no nested procedures at all is poorly written, and I have seen very
few large program (actually none in Ada) that had no nesting at all.

On the other hand, I have *quite* often seen programs using nesting
*very* extensively, where the program was divided into large procedures,
containing many nested procedures, where the majority of calls are to
procedures contained within other procedures.

I don't believe Jon's figure of 99+% of subprogram calls being to library
level subprograms is anywhere near right, and I would guess it is just
a rhetorical guess rather than any kind of measurement. Across an
admitedly small sample of large programs that I was involved in measuring,
we saw over 80% of the calls being to procedures that were nested inside
other procedures.

Probably the big picture is that some programs use very little nesting,
and therefore are insensitive to the display mechanism, and other programs
nest heavily, and are potentially sensitive to the mechanism.

I will get some statistics on our Ada 95 database when I have chance to
find out what we see there.

For GNAT itself, there are sections in both styles. For a style where
calls to nested procedures are heavy in frequency, see sem_prag.adb
for example.

Remember that nesting of procedures becomes much more critical in
tasking programs, because it is the cheap way of making task local
data. One of the problems in making C library routines threadsafe
is that they tend to use global variables heavily, which in 
corresponding Ada programs would typically be local uplevel references.

For example, printf is presumably a big nest of functions, and it would
not be surprising if there are some global variables around that make
it thread unsafe. In Ada, one would nest these subsidiary functions inside
the equivalent of printf, and the global variables would become local
variables of printf itself, and therefore task specific.

In any case, I agree it is probably not a critical point. gcc uses static
links for all implementations (and a good thing too, because it is what
made pointers to inner procedures possible, something we depend on quite
a bit). Most of the Alsys implementations used displays, and to our
satisfaction (our = Alsys, I used to work for them :-) our measurements
showed that this was clearly more efficient, but in the big picture
of things, I doubt the difference was very significant.