graham@maths.su.oz.au (Graham Matthews) (06/08/90)
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.
Can anyone tell me why this is? Is it just poor quality C code produced from
the front end that is the cause of the problem?
graham
[My impression is that it is partly due to the time spend looking up methods
and partly due to making things garbage collectable. Someone who is more
familiar with the innards of Eiffel will, I hope, comment. -John]
--
Send compilers articles to compilers@esegue.segue.boston.ma.us
{spdcc | ima | lotus}!esegue. Meta-mail to compilers-request@esegue.
Please send responses to the author of the message, not the poster.burtonl@cognos.uucp (Burton Leathers) (06/14/90)
It was asked what contributes to the ~25% performance disadvantage of
Eiffel relative to C.
It should first be noted what is directly comparable: flow control within
functions and expressions evaluation.
It is true that garbage collection imposes an overhead. I have not
had an opportunity to compare the Eiffel automatic garbage collection
with manual methods but suspect that by virtue of the n-square algorithm
employed that it is some part of the Eiffel cost.
It is true that feature selection is not free - although it is no worse
than C++. There is a startup cost associated with feature selection which
can be irritating and could probably be eliminated. (Look at the INIT
and DIVE routines in a C package.) Some tests I have conducted using a
SUN 3/60 measure the selection cost at about 5 microseconds. It is possible
that an entirely different approach could reduce this cost to a single
indexed indirection (less than a microsecond).
The killer in the tests I have done point to function invocation. On a
SUN 3/60, every feature call - not attribute reference - imposes an
overhead in excess of 200 microseconds. This is very painful but, as
was pointed out in Meyer's recent posting on the shortcomings of the
current implementation of Eiffel, is being addressed. Send a croissant
to ISE to fuel the developers in this effort.
As an incurable fan of the Eiffel language I cannot help being
disappointed that the current implementation is not faster than it
is. At least we have seen evidence of improvement and can expect more.
It is comforting to know that Eiffel is likely to get fast sooner
than another language is likely to get good.
Burton
--
Burton Leathers 3755 Riverside Dr. decvax!utzoo!dciem!
Cognos Incorporated P.O. Box 9707 nrcaer!cognos!burtonl
(613) 738-1440 Ottawa, Ontario
CANADA K1G 3N3
--
Send compilers articles to compilers@esegue.segue.boston.ma.us
{spdcc | ima | lotus| world}!esegue. Meta-mail to compilers-request@esegue.eiffel@eiffel.com (Kim Rochat) (07/07/90)
In article <1990Jun20.041632.15547@esegue.segue.boston.ma.us>, jimp@cognos.uucp (Jim Patterson) writes: > In article <graham.644716278@bizet> 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.