Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!usc!wuarchive!uunet!abvax!iccgcc!klimas
From: klimas@iccgcc.decnet.ab.com
Newsgroups: comp.lang.smalltalk
Subject: Re: Stand-Alone .exe's & C libraries
Message-ID: <4385.28186286@iccgcc.decnet.ab.com>
Date: 26 Apr 91 22:25:26 GMT
References: <91104.114417U09762@uicvm.uic.edu> <4321.280dd75f@iccgcc.decnet.ab.com> <2268@media03.UUCP>
Lines: 57

In article <2268@media03.UUCP>, pkr@media03.UUCP (Peter Kriens) writes:
>  klimas@iccgcc.decnet.ab.com writes:
>         be <64kb in size.  Another reality that drives C fanatics crazy
>         is that there is not much to be gained by using C based functions
>         in terms of speed or memory.  We have actually seen a reduction
>         in total program size when we rewrote some C based libraries in
>         Smalltalk/V-286 and the performance was just the same if not faster.
> 
> I happen to be a Smalltalk fanatic but I am having problems with this
> statement. I love Smalltalk for its expressiveness and power, but I hate it
> for it's speed. And writing some heavily used parts in C can speed it up. Try
	That's the correct approach!  There is a misunderstanding in what
	I said and a word of clarification may help.  The point is that 
	optimization of the underlying algorithms should be done before 
	one resorts to rewritting Smalltalk into C based primitives because
	that's where your greatest gain will come most quickly.  Then if you
	still have a performance problem (especially for something in a tight
	loop) recode it in C, however don't be surprised if you don't get
	much more than a factor of 2 improvement in speed.  For many generic
	speed problems this is not satisfactory and the users I know have 
	had to rewrite the appropriate functionality into primitives written in 
	assembly code to get a 5-10x speed increase.  Hence my advice about
	considering assembly code rather than C for recoding primitives
	if speed is a problem.  Again, these are comments relative to a generic
	object-oriented program.  Most people don't write many tight loops
	in their code, in fact the old addage about 20% of the code consumes
	80% of the time, is the type of program that I'm talking about.

	With respect to the issue of existing C libraries, the advice was and
	is "if you got em reuse em".  If it's an existing C library, chances 
	are that it will be much more efficient to use that rather than 
	trying to roll your own!
	
	... stuff deleted...

> By the way, I am very interested in an example of coupling C code to Smalltalk
> and than loosing speed. Could you elaborate a little bit more on that?
	The situation with most dialects of Smalltalk is
	such that when you interface into existing C libraries, often times, 
	the C libraries contain functionality that exists in the Smalltalk
	class hierarchy somewhere already.  Unfortunately, when you replicate
	this functionality in a primitive, you have to give up memory.  This
	phenomena, coupled with the code associated with "flattening" objects
	so that they can go in and out of primitives also can increase code
	bulk and add more overhead.  Hence my comment, when these existing
	C based libraries are rewritten in Smalltalk, the overall program size
	can go down and performance can sometimes improve.  This is not 
	hypothesis but actual experiences from product developments which
	I would like to get the principals involved to publicize more to the
	community.

	My bottom line is that Smalltalk, C and assembly code each have their
	place and tradeoffs.  If one is going to use primitives to supplement
	some piece of a Smalltalk based program, then ponder some of these
	suggestions before blindly concluding that writing a primitive in 
	C will give the best results.