U09762@uicvm.uic.edu (Steve Oster) (04/14/91)
Is it possible to create stand-alone programs with Smalltalk/V or Smalltalk/V 286? Also, is it possible to write Smalltalk programs that can use 3rd party libraries (that are primarily meant for use with C compilers)? Thank you, Steve
klimas@iccgcc.decnet.ab.com (04/19/91)
In article <91104.114417U09762@uicvm.uic.edu>, U09762@uicvm.uic.edu (Steve Oster) writes: > Is it possible to create stand-alone programs with Smalltalk/V or > Smalltalk/V 286? Yes, Digitalk gives you a tool with their runtime license to create an EXE program. Object Technology Intl. also has some tools for this with their ENVY toolkit. > Also, is it possible to write Smalltalk programs > that can use 3rd party libraries (that are primarily meant for use > with C compilers)? Yes, The Floating Point library in the goodies package is just such an example of how to interface ST/V286 into an external C program. ST/V286 does have one limitation that ST/V-PM doesn't WRT interfacing into external libraries. The functions are accessed via what are called primitives (desribed in detail in the manual) and although you can have a fair sized number of user defined primitives, the code associated with a particular primitive must 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. Hence the rule of thumb is, 1.)If C libraries already exist, partiton into <64kb modules and interface into them via the Smalltalk primitives. 2.)Don't necessarily expect to gain performance or more memory by developing new code in C and interfacing into ST. 3.)If you have a speed problem with your ST code consider optimizing the algorithms first and then rewriting the remaining time critical code in assembler. BTW Digitalk includes examples of this with the product.
pkr@media03.UUCP (Peter Kriens) (04/19/91)
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
writing he V286 floating point package in Smalltalk. I think that you should
differentiate between different problems. Smalltalk handles C code as
primitives and I think we should regard them as such. Pieces of code that
do one thing very good and very fast. In hypercard on the macintosh there is
a very similair very populait facility to extend hypercard (ver, very necessary)
called XCMD's. There is a lot of public domain code out there so there is
a good insight in how people are coding them. What you usually see that they
handle much too much in their primitives. This will force duplication of
code in the primary and the secondary environment and usually also in loss
of speed.
But if you make primitives in the right way, they can speed up you application
and make things possible which are impossibale in Smalltalk, like controlling
or monitoring external devices, fast fourier transform (try that in Smalltalk).
As said earlier, I love Smalltalk, but I think we must remain honest about
it's major drawback: speed.
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?
Peter Kriens
pkr@media01.uucpmoorebj@odin.icd.ab.com (Bruce J. Moore) (04/20/91)
In article <4321.280dd75f@iccgcc.decnet.ab.com> klimas@iccgcc.decnet.ab.com writes: ...Some reasonable stuff about standalone .exes deleted. > Yes, The Floating Point library in the goodies package is > just such an example of how to interface ST/V286 into an external > C program. ST/V286 does have one limitation that ST/V-PM doesn't > WRT interfacing into external libraries. The functions are accessed > via what are called primitives (desribed in detail in the manual) > and although you can have a fair sized number of user defined > primitives, the code associated with a particular primitive must > 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. A reality that drives *some* Smalltalk fanatics crazy is that Smalltalk is based on primitives written in C and other languages. If it were slower to write them in C or assembler it wouldn't be done. Digitalk says that their primitives are used (among other things) for "higher-level but performance-critical methods such as stream access and block transfers". In short, C is not a four letter word. I appreciate some of the gains to be realized by OO (so no language flames please), but it seems to me that the original poster was interested either in optimizing a specific performance problem area or reusing already written and tested code.
tma@m5.COM (Tim Atkins) (04/25/91)
It is pretty obvious to me that using a piece of C code from Smalltalk will be slower than staying in Smalltalk if certain conditions are met. Accessing the C function has a certain amount of set up and return overhead that varies depending on the flavor of Smalltalk (dll vs. setjmp/longjmp for instance) and the cost of doing the needed interface setup on the particular machine. Obviously, if the relative speed advantage of the C vs. Smalltalk code is less than the cost of warping out of Smalltalk to execute the code plus the cost of any needed Smalltalk/C conversion routines, then the functionality *should be* written in Smalltalk. This is only a simple quantitative test however. Factors such as the maintainibility and extensibility of the resultant code sets must also be considered in relation to the problem domain requirements. Occassionally it may also make sense to code a functionality in a "foreign" language simply because useful information is thereby made available to the foreign interface layer that will be needed in subsequent calls. - Tim Atkins
klimas@iccgcc.decnet.ab.com (04/27/91)
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.