Re: Eiffel and Efficiency Issues

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
--

Return to the comp.compilers page.
Search the comp.compilers archives again.