jmaloney@june.cs.washington.edu (John Maloney) (09/22/88)
There has been some recent discussion of Smalltalk performance in
this forum recently. I would like to report on my experience using
both C and Smalltalk for experimental computer music work.
In order to do the experiments of interest, which had to do with
tools for the composer and musical accompaniment, it was necessary to
interface the computer with a music synthesizer and keyboard. In a
three month period in late 1986 and a three week period in late 1987
I implemented essentially the same underlying library of utilities,
the first time in Lightspeed C on a Mac+ and the second time in
Smalltalk on a Tektronix 4405. The experimental software I built on
top of these two frameworks was different, so I will restrict my
comments to the development of the framework itself.
1. Development Time
Development time in Smalltalk was a quarter or less the
time for the same task in C. Some of the time
saved came from not having to manage include files and
the decomposition of source code into modules. Some of it
came from faster debugging in Smalltalk and from the higher
level utility objects available in Smalltalk (like collections).
Some came from not having maintain consistent declarations
in several places and from not having to search through
multiple files for the right places to make changes. Finally,
some time was saved by not having to worry much about
comments and formatting. Notice that much of the speed of
development in Smalltalk has to do with the environment
rather than the language. However, freedom from storage
management concerns is really a time saver in Smalltalk,
both in designing and writing the code and in debugging.
(Finding pointer problems in C can be a demoralizing
nightmare; in Smalltalk, even when the program fails it
is easier to find the problem.)
2. Garbage Collection and Performance
I expected to have performance problems in Smalltalk and
I was planning to move time-critical code into user-defined
primitives after debugging the system and identifying
the performance bottlenecks. I was surprised to discover
that the system performed fine without this measure. It
could perform about 150 notes per second continuously.
I did have some problems handling the large amount of
real time data sent by some keyboards, but was able to
write a filter (still within Smalltalk) to handle this
problem. Garbage collection also turned out not to get
in the way despite the sensitive timing requirements. I
did put some thought into the run-time data structures to
minimize the storage throughput needs. However, these
optimizations were easily added after getting the
initial implementation working.
I will mostly let my experience speak for itself. However, the story isn't
complete if I fail to mention that, subjectively, I enjoy working with
Smalltalk more than with C. I find it less frustrating. I make fewer
silly mistakes ("oh, I typed '=' and meant '=='") in Smalltalk and I
can find the remaining mistakes much faster. I like letting the system
organize my code and data structures for me. And I find that NOT having
explicitely defined types save time, both because you don't have to type in
all those declarations and because I can change my mind without having
to fix all the existing declarations.
No doubt, however, that if I could perform 2000 notes/second I'd find
use for the extra cycles (drawing the score while the music plays, for
example). So I hope that either someone will do a "code extractor/optimizer"
for Smalltalk or else that C++ will one day have all the nice amenities
of the Smalltalk world (garbage collection, debugger, browser-like
editor, incremental compilation, automatic type inferencing, etc).
-- John Maloney (jmaloney@june.cs.washington.edu)bart@reed.UUCP (Bart Massey) (09/25/88)
In article <5797@june.cs.washington.edu> jmaloney@june.cs.washington.edu (John Maloney) writes: > 1. Development Time > Development time in Smalltalk was a quarter or less the > time for the same task in C.... I've written boatloads of C code and a reasonable amount of Smalltalk, and my conclusions have been very similar to yours. However note that point 1 really isn't too terribly indicative: I've found that the second time I write anything in any reasonable language it's likely to take me 1/4th or less of the time :-) The question that comes immediately to mind is what would have happened if you'd coded first in Smalltalk and then in C?? But please don't take this small nitpick as a criticism of a very well written and informative article... Bart Massey BART@REED.BITNET (uggh) ..tektronix!reed!bart
jmaloney@june.cs.washington.edu (John Maloney) (09/26/88)
>my conclusions have been very similar to yours. However note that point 1 >really isn't too terribly indicative: I've found that the second time I >write anything in any reasonable language it's likely to take me 1/4th or >less of the time... You are absolutely right, Bart, the second time a given person writes the same program the coding usually goes faster. Of course, there are also other problems with this "experiment," such as the difference between a Mac+ with a 68000, a tiny screen, 1 mbyte, and a slow disk and a Tek 4405/06 with a large screen, 68020, fast disk, and loads of memory. It would be great if someone collected some data on program development time for the two language under more controlled conditions with larger sample sizes. I suspect there would be a lot of variance in the numbers. I also believe that different programming languages work better for different people. I think the object-oriented approach works well for me in a C environment or in Smalltalk. I also think the Smalltalk enviroment supports my working style nicely and I hope that C++ develops a similar environment. My wishlist includes run-time binding, type declarations optional or inferred, a code "browser" with intelligent search functions (e.g. "senders" and "implementors"), garbage collection, incremental compilation, the compiler available in the environment, object level debugger and inspector, large library of classes, inheritance, and possibly a change management system. I would also like things that Smalltalk is lacking such as better packaging of systems to avoid potential name conflicts and for tracking dependencies on system facilities, optional static type inference and checking when possible, and the ability to produce an optimized, object-code only packaging of a final product. -- John Maloney (jmaloney@june.cs.washington)
scc@cl.cam.ac.uk (Stephen Crawley) (09/26/88)
I sent a message to John Maloney asking about the speed of the C version of the program and the relative performance of the raw machines involved. John's reply follows ... -- Steve > The Tek 4405/6 on which the Smalltalk version was run is based on a > 16 Mhz 68020 which is three to four times as fast as a Mac Plus. The > C version of the program on the Mac Plus ran at about 200 notes per > second as I recall. The difference in the raw processing speeds of the > two machines would imply that the C program running on the faster > machine should be able to send 600-800 notes per second. So the cost > of using Smalltalk is to run four or five slower. I am not disappointed > at this; the loss of performance is offset by the ease of development > to my mind. I always expected to move the time-critical code into > efficient primitives (implemented in C). However, I never needed to > do this to get the performance I desired, which was a nice surprise. > > You may post this analysis to the net if you wish. > > -- John Maloney