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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public X-Google-Thread: f43e6,b87849933931bc93 X-Google-Attributes: gidf43e6,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public From: piercarl@sabi.demon.co.uk (Piercarlo Grandi) Subject: Re: What is wrong with OO ? Date: 1997/01/11 Message-ID: X-Deja-AN: 209185612 x-nntp-posting-host: sabi.demon.co.uk x-disclaimer: Contents reflect my personal views only references: <5acjtn$5uj@news3.digex.net> <32D11FD3.41C6@wi.leidenuniv.nl> <32D53473.4DAA423A@eiffel.com> content-type: text/plain; charset=US-ASCII mime-version: 1.0 (generated by tm-edit 7.94) newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object,comp.software-eng Date: 1997-01-11T00:00:00+00:00 List-Id: >>> "bertrand" == Bertrand Meyer writes: bertrand> The ISE Eiffel compiler performs inlining completely bertrand> automatically. There is no "pragma inline" or comparable bertrand> programmer intervention, since it is not the programmer's job bertrand> to worry about whether a routine is inlinable or not. This is bertrand> a job for a compiler. It seems contrary to reasonabless: there are many contexts where inlining is not necessary and others in which it is important, *even for the same procedure*. Thus there is (usually) a space/time tradeoff, but *at each call site*. It sounds astonishing to me an argument that the compiler should try to second guess or infer space/time tradeoffs (except perhaps in the simplest cases), in addition to doing its job of compiling valid translations of a source. bertrand> (In addition, for an object-oriented language, inlining is bertrand> only possible for a routine that is never subject to dynamic bertrand> binding. This is not quite the whole story. It all depends on call sites: at some call sites a procedure can well be inlined, if at those call sites the procedure implementation invoked can be identified statically. If it is *also* invoked at call sites where this cannot be done, then an out-of-line version must also be generated. A lot of people forget that overloading resolution *and* procedure implementation call/inlining are crucially dependent, both as to validity and desirability, on specific call sites. Call sites that are part of inner loops tend to make inlining more desirable (there are often opportunity for code reorganizations of various sorts), for example. Static resolution and perhaps inlining can also be possible at some call sites but not others. bertrand> This requires extensive analysis of the software. If the bertrand> programmer requests inlining but it is semantically wrong, the bertrand> compiler should ignore the request. But then if the compiler bertrand> is capable of doing this analysis it should take care of the bertrand> inlining too, without bothering the programmer!) Here is a confusion two very different concepts: whether inlining is *useful* and whether it is *possible* (valid). It may be a job for the compiler to check whether inlining a procedure at a given call site is *possible*, as claimed here; but it may require a lot harder work for the compiler to determine whether that inlining is also *useful*. A programmer's suggestion as to the *usefulness* of inlining a procedure at a given call site (or all call sites, much more coarsely and rather less desirably) is not replaceable by the a compiler check on the *possibility* of inlining it. Ideally a compiler would use profiling feedback to evaluate whether it is worth inlining a procedure at a given call site, by running the program with an without (this check ought to be done for each procedure at each call site for which is is possible, and every combination thereof :->). Cruder hints may be used: bertrand> ISE Eiffel does give the user a degree of parameterization: a bertrand> compilation option specifies the size threshold beyond which a bertrand> routine will not be inlined. This is measured in internal bertrand> units (number of bytecode words), but easy to relate to number bertrand> of instructions. This option provides a way to control bertrand> space-time tradeoffs. but, just like the 'inline' keyword of ``C++'', it does not quite recognize that hinting for inlining a procedure at *all* call sites is not quite as useful as hinting for it to be inlined at particular call sites. However probably simple compiler heuristics can be useful, like: bertrand> In practice, however, most users are happy with the default, bertrand> which inlines small, frequently called routines. As to this some Ada compilers do allow selective inlining at call site, or at least at call sites thru a region of code only (if I remember well). bertrand> This automatic optimization is crucial because the bertrand> object-oriented style of development, with its emphasis on bertrand> abstraction, naturally tends to yield many small bertrand> routines. Where have I heard some of those word already? Ah, yes, those are the words used by Ken Thomson and Dennis Ritchie about the C procedure calling conventions. Then people instead started using '#define'. :-) bertrand> With ISE Eiffel, you can write the software as it should be, bertrand> not asking yourself all the time "should I violate abstraction bertrand> here and avoid writing a small routine because of the effect bertrand> on performance?". You just leave this kind of concern to the bertrand> compiler. ("Inline" pragmas would be almost worse here, bertrand> because you would have to perform yourself the analysis of bertrand> what is inlinable and what is not. The incrementality problem bertrand> is particularly nasty: change a single line somewhere in a bertrand> large system, and a routine that was inlinable, far away in bertrand> the software text, now becomes non-inlinable! This kind of bertrand> systematic, exhaustive work, error-prone when done by humans, bertrand> is what computers are for.) Exactly! As to the *possibility* of inlining. On the other hand complexity analysis to determine where it is *useful* to inline is not quite what programs are very good at. [ ... ]