Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!uwm.edu!bionet!agate!stanford.edu!leland.Stanford.EDU!leland.Stanford.EDU!craig
From: craig@leland.Stanford.EDU (Craig Chambers)
Newsgroups: comp.object
Subject: Re: Run-time checks, Compile time Checks, and reliability
Keywords: type checking, high reliability, fault tolerance
Message-ID: <1991Apr12.190418.13128@leland.Stanford.EDU>
Date: 12 Apr 91 19:04:18 GMT
References: <1991Mar28.161307.6071@cbnewsh.att.com> <27F780E2.1872@tct.com> <1991Apr7.013813.23513@leland.Stanford.EDU> <524@eiffel.UUCP>
Sender: news@leland.Stanford.EDU (Mr News)
Organization: Stanford University
Lines: 65

In article <524@eiffel.UUCP>, bertrand@eiffel.UUCP (Bertrand Meyer) writes:
|> From <1991Apr7.013813.23513@leland.Stanford.EDU> by craig@leland.Stanford.EDU
|> (Craig Chambers):
|> 
|> > In a non-object-oriented language (at least one with a good type system)
|> > types specify interfaces (plus possibly some behavioral specifications)
|> > to objects, but specifically attempt to abstract away from specifying
|> > anything about implementations/representations of the objects of
|> > particular types (to support more reusability of code).
|> > This means that such interface-level types provide little information
|> > for a compiler to use to optimize messages sent to such objects.
|> > So the standard argument that static type information speeds execution
|> > of programs does not apply to object-oriented languages
|> > (or at least does not apply to anything near the degree it does
|> > in non-object-oriented languages).
|> 
|> This runs contrary to our experience. To handle a routine
|> call
|> 
|>     x.f
|> 
|> with polymorphism on x and dynamic binding on f, it helps the
|> compiler considerably to have the type information resulting
|> from the declaration
|> 
|>     x: SOME_TYPE
|> 
|> which indicates that the objects to which x may be
|> attached at the time of the call are not arbitrary,
|> but must be instances of SOME_TYPE (that is to say,
|> direct instances of SOME_TYPE itself or of one of its
|> descendants).
|> 
|> By restricting the scope of possible types (classes), this
|> information enables the compiler to handle calls in a much
|> more efficient way than otherwise.
|> 
|> -- Bertrand Meyer
|> Interactive Software Engineering Inc., Santa Barbara
|> bertrand@eiffel.uucp

What does your compiler generate to handle message sends?  It is certainly
possible to have a relatively inefficient scheme that gets faster as more
information is provided.  However, the efficient message passing schemes
such as in-line caching or a polymorphic form of in-line caching we've
recently developed (and will publish in ECOOP'91) are basically just as
fast as the virtual function calls in C++ 2.0, for the case in which the
in-line cache hits.  I was under the impression that Eiffel uses a slower 
implementation of message passing than either in-line caching or indirect
function calls, which (depending on how it's implemented) could get faster
with more precise type information.  Please correct my impression if I'm
wrong; I've tried before to get someone at ISE to tell me how Eiffel
implements things.

Knowing that some code type checks provides the information to the compiler
that no message-not-understoods could arise at some message send.  In most
situations there still will be several possible legal methods that could be
invoked by a particular call site, and so some sort of run-time dispatch is
required even in the statically-typed case.  It can be a little faster with
this knowledge, allowing implementations like C++'s, but not significantly
faster.  In a non-object-oriented language, such type information supports
inlining away the function calls and data accessors, which is what I meant
by significant performance improvement.

-- Craig Chambers