Newsgroups: comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!newsfeed.pitt.edu!news.duq.edu!newsgate.duke.edu!news.mathworks.com!fu-berlin.de!unlisys!news.maz.net!news.ppp.net!news.Hanse.DE!wavehh.hanse.de!cracauer
From: cracauer@wavehh.hanse.de (Martin Cracauer)
Subject: Re: ANSI CLISP: strengths vs. weaknesses?
Message-ID: <1996Oct20.112936.25643@wavehh.hanse.de>
Organization: BSD User Group Hamburg
References: <slrn55n3fg.5p.psci@teleport.com> 	<1996Oct10.100654.824@wavehh.hanse.de> <325E98A0.44CD@franz.com> 	<1996Oct18.115909.28857@wavehh.hanse.de> <TMB.96Oct19010039@best.best.com>
Date: Sun, 20 Oct 96 11:29:36 GMT
Lines: 56

tmb@intentionally.blank-see.headers writes:

>No runtime dispatch mechanism, not even the C++ mechanism, is fast
>enough to use for "everything".  The only way to be able to give the
>illusion of treating things like numbers just like other objects is
>via type inference, immediate representations, and other optimizations.

>In fact, in practice, the "efficient" C++ dispatch mechanism is not
>significantly faster than the much more dynamic mechanism found in
>Objective-C (or, I believe, IBM's SOM).  But the few extra cycles that
>C++ squeezes out cause lots of headaches when it comes to system
>integration, dynamic configuration, etc.  In particular, OLE and SOM
>are really just workarounds for the inflexible and cumbersome object
>model that C++ has built into it (btw, if you want to know all the
>unpleasant details, take a look at Lippman's "Inside the C++ Object
>Model").

This begins to be off-topic, but the lookup mechanism of ObjC requires
one pointer indirection more than the C++ virtual function
call. Pointer indirections can be very expensive given today's memory
bandwidth/CPU speed relation. 

Also, it was my point that C++ (and Dylan) enable static binding and
inlining. In a language that supports this, you can represent much
"smaller" things using the language's native Class
definition mechanism. Obviously, as I wrote in my former posting, such
languages will give people who jump on the OO wagon and try to
represent too much in true objects a much better performance. This
what happend to me.

To prevent misunderstanding: I don't think I have to represent as much
as possible as "true" objects anymore (and I didn't choose C++ for a
project for a long time). However, I still think this is an
explanation why people may get a positiv impression when they first
try C++ when they start using OO languages.

>I see little reason why CLOS should, in principle, be slower
>than Objective-C's mechanism.  In practice, of course, because
>CLOS is so feature rich, implementors may have less time to
>make it fast.

Also, as Jim Veitch of Franz wrote, there are actually CLOS versions
that can represent a CLOS object's slots as a flat array, so my former
claim that slot accesses (not functions calls) have to be slower in
CLOS was not right. 

I think we shouldn't dicuss things this way (theory only)
anymore. Obviously, my impressions need a reality-check against moderm
commercial CLOS systems (although I'd still prefer to write code that
runs on CMUCL or other free implementations fast as well, what can be
done with non-CLOS Common Lisp).

Martin
-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer@wavehh.hanse.de>  http://cracauer.cons.org
