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.sprintlink.net!news.wwa.com!rcm!rmartin
From: rmartin@rcmcon.com (Robert Martin)
Subject: Re: c++, smalltalk, and real-time
References: <3mjk4m$ijf@news.belgium.eu.net> <D72CCr.K9y@cunews.carleton.ca>
Organization: R. C. M. Consulting Inc. 708-918-1004
Date: Sun, 16 Apr 1995 16:05:21 GMT
Message-ID: <1995Apr16.160521.4238@rcmcon.com>
Lines: 63
Xref: glinda.oz.cs.cmu.edu comp.lang.c++:123387 comp.lang.smalltalk:22810 comp.object:29643


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

dbuck@superior.carleton.ca (Dave Buck) writes:

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

I agree with what Dave has said here, I would only add that in the low
'millisecond' domain, C++ is much more likely to behave acceptably.
In C++, message dispatch (virtual function calls) always take the same
amount of time, and that time is always very small. (one or two
pointer dereferences). 

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

This is true.  Certain GC schemes will have more *overall* efficiency
than manual memory management.   However, this is only true in
environments that have large sums of memory to expend.  In memory
limited environments, the frequency of collections must increase which
*may* force the GC method to cross the line and become less efficient
than manual memory management.

Moreover, manual memory management can be made very efficient, and
perfectly predictable.  Again, in the 'millisecond' domain, the
precision of manual memory management is probably more important than
the overall efficiency of GC.  

>Smalltalk can, however, block for short periods of
>time while performing a GC.  (If you're not careful, C++ can do this
>as well).  

Quite right, although probably for shorter periods.  Some manual
memory managers hunt through the heap when you call 'free'.  Others do
not.  If these dropout times are important to you, and you are using
manual memory management, then you must be careful to use a memory
manager that does not do significant hunting through the heap.

(C++ allows you to write your own memory management, either globaly,
or on a class by class basis.)

-- 
Robert Martin       | Design Consulting   | Training courses offered:
Object Mentor Assoc.| rmartin@rcmcon.com  |   Object Oriented Analysis
2080 Cranbrook Rd.  | Tel: (708) 918-1004 |   Object Oriented Design
Green Oaks IL 60048 | Fax: (708) 918-1023 |   C++
