Newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.object
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!howland.reston.ans.net!news.starnet.net!wupost!news.utdallas.edu!corpgate!bcarh189.bnr.ca!nott!cunews!dbuck
From: dbuck@superior.carleton.ca (Dave Buck)
Subject: Re: c++, smalltalk, and real-time
X-Nntp-Posting-Host: superior.carleton.ca
Message-ID: <D72CCr.K9y@cunews.carleton.ca>
Sender: news@cunews.carleton.ca (News Administrator)
Organization: Carleton University, Ottawa, Canada
References: <3mjk4m$ijf@news.belgium.eu.net>
Date: Sat, 15 Apr 1995 06:22:03 GMT
Lines: 111
Xref: glinda.oz.cs.cmu.edu comp.lang.c++:123314 comp.lang.smalltalk:22789 comp.object:29619

In article <3mjk4m$ijf@news.belgium.eu.net>,
Filip Vandamme <bigtime@phil.eunet.be> wrote:
>Hi everybody,
>
>I read somewhere, in sunexpert if I'm not mistaken, that smalltalk wouldn't 
>be as suitable as C++ for real-time OOP. The argument that was put forward 
>mentioned that message-resolution was done at run-time in smalltalk, while 
>in C++ this is actually done at compile time. Hence, this dynamic resolution 
>in smalltalk could potentially deteriorate responsiveness, which could be un-
>acceptable for hard real-time applications (Any experience or solid ground 
>for this?) In that context, I would like to ask the following:
>
>  1) Since I haven't got the foggiest idea how polymorphism is implemented in
>     C++ nor how it is done in Smalltalk, I was wondering if somebody could 
>     explain (or provide refs to) what mechanisms are in place to deal with 
>     it, how they differ, and how they could affect real time applications.

Polymorphism in C++ is done by "virtual tables".  These are basically
arrays of pointers to functions.  The compiler knows which index
corresponds to which method name.

>  2) If C++ also resolves polymorphism at compile time, how can it cope with 
>     e.g. the following situation:
> <clipped>

In your example, the base class must declare the method to be
virtual.  This allocates a fixed index in the virtual table for this
method. In the subclasses, this method pointer is replaced with a
pointer to the subclasses' method.

>     Does the number of derivations down the inheritance hierarchy play a
>  role in eventually finding the method?

The depth of the inheritance hierarchy is irrelavent in C++.  The
method lookup just looks at a fixed offset in the virtual table.

By contrast, the method lookup in Smalltalk searches the method
dictionaries of the object's class followed by those of the
superclasses.  Optimizations called method caching can reduce the
depth of the search.  For each method call, the full method lookup is
performed the first time.  The class and method found are then cached.
On subsequent calls from this call point, the class is compared to the
receiver's class and if it matches, the cached method is used
directly.  Smalltalk also implements many common methods using
bytecodes which speeds them up.  Finally, some Smalltalks are
dynamically compiled which means that when the bytecodes are
interpreted for the first time, the corresponding native code is
cached.  Thereafter, the native code is run directly.

>  3) Does smalltalk's interpretive nature inhibits its use for hard real-time 
>     applications? 

To some extent, yes, Smalltalk's nature inhibits its use for hard
real-time applications.  What I mean by this is that if you have hard
realtime applications, you must be careful about the code you write.
Hard real-time applications have been developed in Smalltalk.  The
developers are simply more careful.

Hard realtime is a nebulous term.  If you need responses in
nano-seconds or less, you will probably have to resort to hardware.
Responses in the low microseconds will typically require assembly
programming.  At the other end of the scale, responses in the order of
seconds can be achieve with virtually any language depending on the
complexity of the task of course.

Often times, the proper solution to a Smalltalk performance problem is
to perform a high level optimization.  This is often much more
effective than switching to another language.

>  4) I also heard that it performs automatic garbage collection. Does this im-
>     plies that while cleaning up the heap, responsiveness could be further 
>     delayed; since at any point in time the application is blocking everything
>     (e.g. signals to signal handlers) to clean up the heap consistently?

Smalltalk garbage collection is pretty efficient.  In many cases, it's
more efficient than schemes required by C++ to manually manage the
memory management.  Smalltalk can, however, block for short periods of
time while performing a GC.  (If you're not careful, C++ can do this
as well).  If you have hard realtime limits, you are normally much
more careful about when you create objects and how long those objects
survive.  The Smalltalk generation scavenger can handle garbage much
faster when the object are created and discarded quickly.  The longer
an object stays in memory, the longer Smalltalk takes to garbage
collect it on average.

>  5) Are there any other constraints that OOP in general, or C++/Smalltalk in 
>     particular impose that are detrimental to solve real time problems, com-
>     pared to C?

Compared to C, Smalltalk is poor at handling massive floating point
calculations.  Most Smalltalks, however, have many optimizations in
them to make them fairly fast in general.  Smalltalk, though, will
typically run more slowly than C++ applications which are coded with
the same algorithms.  Keep in mind that C++ allows you to do many
things to speed up the programs at the expense of the maintance costs
(static vs. dynamic binding, inlining, lack of array bounds checking).
It's very hard to compare Smalltalk to C++ in terms of performance.

A common technique is to code critical parts of an application in C
and call them from Smalltalk.

Hope this helps.

David Buck
dbuck@ccs.carleton.ca

_________________________________
| David K. Buck                 |
| dbuck@ccs.carleton.ca         |
| The Object People             |
|_______________________________|
