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: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,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 From: piercarl@sabi.demon.co.uk (Piercarlo Grandi) Subject: Re: What is wrong with OO ? Date: 1997/01/14 Message-ID: #1/1 X-Deja-AN: 209790753 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 organization: Home's where my rucksack's 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-14T00:00:00+00:00 List-Id: >>> "goubier" == Thierry Goubier writes: goubier> On 11 Jan 1997, Piercarlo Grandi wrote: goubier> [On the subject of inlining by the compiler, with B. Meyer] piercarl> Ideally a compiler would use profiling feedback to evaluate piercarl> whether it is worth inlining a procedure at a given call site, piercarl> by running the program with an without (this check ought to be piercarl> done for each procedure at each call site for which is is piercarl> possible, and every combination thereof :->). goubier> I believe this technology already exists, for example in the goubier> Self 3.0 and 4.0 inlining compilers. Things like polymorphic goubier> inline caches may be used as a tool to record profiling goubier> information for the compiler. >From what I have read I haven't the impression that the Self compiler actually decides _whether_ to inline an implementation using the profiles/inference used to decide _which_ implementation *can* be inlined. In other words, my impression is that Self implementations use profiles/inference to find out whetherit is _possible_ to inline at some cal site and which implementatin(s) may be inlined, not whether it is _useful_ to inline them, and as the latter they use heuristics not dissimilar from those used in ``Eiffel'' or ``C++'' compilers, such as the size of the implementation. Perhaps somebody more familiar with the innards of the Self implementation can throw some light on this. BTW, the point I was making above is that one of the great worths of inlining is that it allows merging the code of the callee in the caller, and those provides significantly greater/easier opportunities for optimization. However if there are several call sites of several different potentially inlinable callees in a given caller procedure, *which* of these calles at which call sites are worth inlining is not so obvious for not only merging in the code at each call site with that of the caller produces _different_ opportunities for optimization, it also results in merging the codes of the callees as well. *Which* combination of inlinings is optimal is thus an intricate problem. Consider the following example (in something like C, so we have that each implementation has exactly one interface and overload resolution, offline and inline, does not complicate the picture) p(a,b,c) { .... q1(a); .... .... q2(b); .... .... q3(c); .... .... q1(42); .... } Now each of the four calls to the three implementations might or might now be worth inlining seaprately; for example 'q1(a)' may not be worth inlining, but 'q1(42)' later on may well be, because it is passed a statically know argument. Inlining each of these call sites may produce positive interactions with the code of their caller. But it may well happen that inling 'q2(b)' merges in code that then makes the merged in code of 'q3(c)' significantly more optimizable, but neither call is worth merging into 'p' on its own. This effect actually _might_ well be important; after all if there are several call sites of several procedures in a block it is because they supposedly cooperate in establishing some result and are thus related, and this perhaps could well provide good optimizations. Thus in theory one should verify the possibility for optimization for every possibly combination of call site inlinings... :-) What I really think should be done, and this is not a new idea, but one that is rarely considered, is to do compilers as symbolic reduction engines, which operate in the domain of instances (that is operate as intepreters) when such are known and in the domain of abstractions (that is operate as compilers) when they are not; then inlining would become a mere byproduct of symbolic reduction between dependent modules. goubier> But I should let interested people look the Cecil/Vortex goubier> project to see how this may be used in static compilation. [ goubier> ... ] That's very interesting work. I also hope that Sun be deploying their Self technology towards the Java compiler, for it is claimed rather convincingly that the Self compiler technology can result in Self or ``Smalltalk'' code that runs only twice as slow as C code. Given that Java is a more constrained sort of language than Self or ``Smalltalk'', the same technology should get it to deliver much the same performance as statically compiled C, while instead being dynamically compiled.