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.rick@tetrauk.UUCP (Rick Jones) (06/08/90)
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. > >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? > I spent some time profiling the performance of Eiffel 2.2 a few months ago. I didn't compare Eiffel with C directly, but I found the overheads of memory management - allocation and garbage collection - far higher than ISE suggested. In fairness, their figure of 20-25% against C is only claimed to be true if you have _no_ assertion checking, no garbage collection, and compile the C-package version of your program. Most of this overhead is due to the look-ups involved in making feature calls (have you ever looked at the generated C code? - it can give C compilers a hard time!). ISE say they are working on improving the efficiency of the generated code - I'm looking forward to seeing 2.3. In my test programs with garbage collection, where I was in fact creating and dropping objects quite liberally, I found that the various memory management functions (the C routines in _run_time.a) were taking about 70% of the total process time. I dived into this code in some detail, and it seemed that a large part of the overhead was concerned with the extra problems of looking for and dealing with expanded and bitfield objects. Since these were only introduced in 2.2, I presume 2.1 (which I never used) was in fact a lot more efficient. In order to see how much it could be improved, I took a lot of C library code apart and rearanged it, and got it down to about 30% of the process time, as well as fixing some definite bugs which can cause certain programs to crash when garbage collection is is use. ISE have copies of all these changes, so I'm expecting 2.3 to be a big improvement. In the end though, Eiffel is a high-level language and is unlikely ever to give the same absolute efficiency as a low-level language like C. This trade-off is as old as computers, and I think that in Eiffel's case what you get in language capability is pretty good compared to what you loose in efficiency. -- Rick Jones You gotta stand for something Tetra Ltd. Maidenhead, Berks Or you'll fall for anything rick@tetrauk.uucp (...!ukc!tetrauk.uucp!rick) - John Cougar Mellencamp
graham@maths.su.oz.au (Graham Matthews) (06/11/90)
In <489@tetrauk.UUCP> rick@tetrauk.UUCP (Rick Jones) 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. >> >>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? >> >have _no_ assertion checking, no garbage collection, and compile the C-package >version of your program. Most of this overhead is due to the look-ups involved >in making feature calls (have you ever looked at the generated C code? - it can >give C compilers a hard time!). ISE say they are working on improving the >efficiency of the generated code - I'm looking forward to seeing 2.3. Can these lookups not be performed at compile time? I have had a pretty close look at Eiffel over the last year, and it would seem to me that most of these lookups do not need to be at run-time, but can be worked out at compile time. After all the class lattice cannot change at run-time. graham
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.kimr@eiffel.UUCP (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