Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!sdd.hp.com!decwrl!ogicse!zephyr.ens.tek.com!tekcrl!brucec From: brucec@phoebus.phoebus.labs.tek.com (Bruce Cohen;;50-662;LP=A;) Newsgroups: comp.lang.c++ Subject: Re: Optimized virtual function invocation Message-ID: Date: 27 Aug 90 20:48:36 GMT References: Sender: news@tekcrl.LABS.TEK.COM Distribution: comp Organization: Tektronix Inc. Lines: 55 In-reply-to: dl@g.g.oswego.edu's message of 25 Aug 90 16:29:53 GMT In article dl@g.g.oswego.edu (Doug Lea) writes: ... a description of his proposal for "customization" ... > > Many people apparently believe that there might be a means to get > similar effects with less impact on the language and current > compilers. I remain unconvinced that this is possible. The fact that > both the SELF and TS (typed smalltalk) designers and implementers use > variations on customization extensively to obtain their impressive > performance improvements over standard OO compilation schemes lends > credence to the notion that customization can play an important > role in maintaining C++'s usual edge in efficiency compared to other > OO languages. > It seems to me there's another viable approach to the optimization of leaf object functions, etc: making the decisions in the linker rather than the compiler. The problem with doing this sort of thing in the compiler has always been the file granularity of compilation in the Unix(tm)/C model of development, which results in the compiler not being able to guarantee that it has all the global information it needs to make the decisions. On the other hand, the linker is in the right place in the pipeline; we just have to ensure that the information it needs is available. We also have to make sure that the linker is smart enough, and the object module format comprehensive enough, to be able to sew the functions and their calls together properly. It's theoretically possible that a smart enough linker could even be able to sew an inline version of a virtual function into a place where it could guarantee the class of object being invoked. The compiler and linker techniques are complementary, and could easily be made symbiotic. I'll have to read your paper to be able to comment on how other aspects of customization fit in, but I wouldn't be surprised if some of the work could be foisted off on the linker. > However, one viable alternative is to incorporate customization into a > metalanguage with associated tools comprising a C++ programmers > workbench, rather than into the language proper. I've been exploring > this too. > Are you proposing something like Demeter, which provides an object metalanguage that can be compiled into code skeletons for several different languages? Or a language for controlling the tools separately from specifying the program they'll transform? --------------------------------------------------------------------------- NOTE: USE THIS ADDRESS TO REPLY, REPLY-TO IN HEADER MAY BE BROKEN! Bruce Cohen, Computer Research Lab email: brucec@tekcrl.labs.tek.com Tektronix Laboratories, Tektronix, Inc. phone: (503)627-5241 M/S 50-662, P.O. Box 500, Beaverton, OR 97077 -- --------------------------------------------------------------------------- NOTE: USE THIS ADDRESS TO REPLY, REPLY-TO IN HEADER MAY BE BROKEN! Bruce Cohen, Computer Research Lab email: brucec@tekcrl.labs.tek.com Tektronix Laboratories, Tektronix, Inc. phone: (503)627-5241 M/S 50-662, P.O. Box 500, Beaverton, OR 97077