From: ac690@cleveland.Freenet.Edu (Edward Klimas)
Newsgroups: comp.lang.smalltalk
Subject: Re: comparing object-oriented platforms
Date: 7 Oct 1992 04:05:16 GMT
Organization: Linea Engineering Inc.
Reply-To: ac690@cleveland.Freenet.Edu (Edward Klimas)
NNTP-Posting-Host: slc4.ins.cwru.edu


In a previous article, nadja@jetsun.weitek.COM (Nadja Adolf) says:
a lot of blatantly misinformed opinion including

>In article <718144987snx@feki.toppoint.de> marten@feki.toppoint.de (Marten Feldtmann) writes:
>>nadja@jetsun.weitek.COM writes in article <1992Oct1.013812.2130@jetsun.weitek.COM>:
>>
>>> Admittedly, the caching does make it faster than complete interpretation,
>>> but it is still significantly slower than a compiled language. The more
>>> complex the program, the greater the difference.
	This is not the case if one can fit the virtual machine into the 
	cache of a processor's architecture (e.g. 88000) in which case 
	the interpreted virtual machine based Smalltalk system executes
	faster than native code executing out of standard memory.  This is
	from a real world existing real time Smalltalk system.
>
>> Is this true? The more complex the program is, the greater the difference?
>>I've been told, that the more complex the program is, the more less is
>>the difference of the speed between compiled C++ and ST code.
	Yes!  In the proceedings of the 1990 OOPSLA workshop on real-time
	OOP one of the participants from a French defense contractor
	recounted their experience where an ST-80 simulation was recoded
	in C++ for speed and ended up running only 10% faster.  I just
	completed a real time ST based video processing application where the
	off the shelf C routines ended up being only 14% faster!  These
	kinds of performance "improvements" are hardly worth the 3-5x
	increase in development time when coding in C/C++ vs ST.
	If one must optimize a routine in Smalltalk, most experienced
	developers revert to native assembly code primitives because C
	typically does not give the 10x performance improvement that
	a developer will desire.

>> With ST one has drawbacks doing stuff like bit-shifting or complex
>>arithmetic functions. But if your application consists of a lot of
>>functions like this you can mix both ST-dialects with C procedures. Most
>>of the daily applications do not use these things ...
>
>What applications don't use complex arithmetic functions? I have yet to
>find a business app that didn't do a lot of calculations...
>
>> In my view the most significant problem with C++ is, that now most of
>>the C programmers think too fast, that they managed or understand the
>>OOP principles. They use procedural concepts and mix them with
>>OOP-concepts and I think, these guys will get lost in big projects.
>
>My experience has been the reverse. C++ people get the project done since
>they design before they code; smalltalk people 'design on the fly', get
>a demo up, and then have to redo everything several times to get a project.
	Please read the literature (e.g. "Experiences with Smalltalk
	on a Large Development Project" by Bran Selic The Smalltalk Report
	Sept 92 ) where seasoned developers consistently report large project
	experiences (18 people for 18 months) similiar to 2-3x C++ and 5x C 
	productivity using Smalltalk.  This upcomming OOPSLA will have another
	experience report on another large ST based real-time process control
	system at Texas Instruments with >25 developers for over 20 months
	with similiar documented results!  (Note: T.I. chose ST over its own
	in-house COOL C Obj. Oriented Libraries because of a direct
	comparison with what could be done with C++)

>There seems to be a big myth out there that C++==C. :-) A myth heavily
>believed in by people who don't use C++. How many big projects written
>in smalltalk have actually 'gone out the door?' How many in C++?
	With the major sales of C++ one would expect that to be the case
	but as reported in "Smalltalk Looming Larger" by David Taylor
	Object Magazine May/June 1992; 8 out of a sample of 18 applications
	were built in Smalltalk, 3 were done in C++ and the rest were done 
	in C++.

	As Meiler Page Jones notes in "Object Orientation: the importance
	of being earnest" Object Magazine July-August 92.  A lot of people
	are using C++ because they perceive it to be the politically 
	correct thing to do and continue to write C code in the same old way!

>> After all, speed considerations will more and more vanish in the future
>>and getting the solution will be the problem ...
>
>It depends on what sort of speed considerations you are speaking of. :-)
	There are some exceptionally financially successfull companies
	providing Smalltalk based solutions that cost a lot less, perform
	faster, and are much more reliable than alternate technologies.

	I bet some of them will also be at OOPSLA with more concrete
	examples!

	Ed Klimas
>
>-- 
>The Earth Pig Bourne....
>
>nadja@node.com (prefered email address)
>nadja@weitek.com
>
Newsgroups: comp.lang.smalltalk