Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!usc!snorkelwacker!spdcc!esegue!compilers-sender From: eiffel@eiffel.com (Kim Rochat) Newsgroups: comp.compilers Subject: Re: Eiffel and Efficiency Issues Summary: Routine lookup costs Keywords: eiffel, code, optimize, OOP Message-ID: <1990Jul07.145543.9171@esegue.segue.boston.ma.us> Date: 7 Jul 90 14:55:43 GMT References: <1990Jun20.041632.15547@esegue.segue.boston.ma.us> Sender: compilers-sender@esegue.segue.boston.ma.us Reply-To: eiffel@eiffel.com (Kim Rochat) Organization: Interactive Software Engineering, Santa Barbara CA Lines: 85 Approved: compilers@esegue.segue.boston.ma.us In article <1990Jun20.041632.15547@esegue.segue.boston.ma.us>, jimp@cognos.uucp (Jim Patterson) writes: > In article graham@maths.su.oz.au (Graham Matthews) writes: > >In the Eiffel reference manual there are claims that Eiffel code (ie: C code > >generated by Eiffel) executes 20-25% (I think these figures are right?) > >slower than native C code. > > I spent a bit of time working with version 2.1c of the Eiffel compiler > (arouind 1988). The generated code appeared to spend a good deal of > time doing table lookups in order to implement multiple inheritence. ... omitted description of Eiffel 2.1 routine lookup mechanism ... The topic of Eiffel routine call costs is a little more complicated than it first appears. 1) By default, all routines are dynamically bound. This requires a constant-time lookup for each routine call. 2) When the Eiffel post-processor is used, calls to routines which do not have to be dynamically bound (that is, they always call the same routine) have their routine lookup optimized away by the post-processor and become normal C function calls. You can think of the post-processor as being the "system builder". Which routines can have their lookup optimized out is knowable only in the context of a complete system (set of classes). 3) Some procedures are inlined by the post-processor, completely eliminating routine call overhead. We plan to extend inlining to functions and apply it more extensively in subsequent compiler releases. 4) When routine lookup is required, turning on the C optimizer can provide dramatic improvements in speed, since the routine lookup expression is complex enough to provide several opportunities for optimization. 5) Running with precondition or assertion checking on greatly slows routine execution due to additional routine entry overhead, but this has nothing to do with the inherent costs of routine lookup. I made some measurements of these cases on a Sparcstation for invocation time of a function accepting one integer argument and returning it as the function result. The Sun C compiler was used in all cases. The alpha version of Eiffel 2.3 was used. Routine invocation times are normalized and approximate. The cost of a normal C routine call compiled with optimization on represents one. Description Normalized time --------------------------------------- --------------- C, optimized 1 Eiffel, C-optimized, no lookup 1 C, not optimized 3 Eiffel, C-optimized, with lookup 4 Eiffel, not C-optimized, with lookup 10 Eiffel, not C-optimized, with lookup, preconditions on 220 Note that these times are just the for the routine call and return. These figures should be weighted by the average time required to execute the routine body to reach any conclusions about relative speeds of complete programs. > Frankly, the 20-25% figure seems pretty low to me. It's not really > so much that the code is of poor quality (though there is some slop), > but that the computational model is at a higher level and quite a bit > more complex than C. Agreed. You can see that there are many variables governing Eiffel performance, even for a measure as simple as routine invocation costs. Under the proper conditions, it can meet or beat C. In the worst case, it is many times slower. ISE is actively working to reduce the costs incurred when precondition checking is enabled and do more optimization of lookups and inlining of routines. Using C compiler optimization is a big winner for Eiffel performance. Kim Rochat Interactive Software Engineering Responses to: eiffel@eiffel.com -- Send compilers articles to compilers@esegue.segue.boston.ma.us {spdcc | ima | lotus| world}!esegue. Meta-mail to compilers-request@esegue.