From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,99ab4bb580fc34cd X-Google-Attributes: gid103376,public From: dewar@cs.nyu.edu (Robert Dewar) Subject: Re: Q: access to subprogram Date: 1996/07/09 Message-ID: #1/1 X-Deja-AN: 167579155 references: <4rb9dp$qe6@news1.delphi.com> <4re2ng$t7u@wdl1.wdl.loral.com> organization: Courant Institute of Mathematical Sciences newsgroups: comp.lang.ada Date: 1996-07-09T00:00:00+00:00 List-Id: 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.