Performance (was: RE: HyperSqueak)
Andreas.Raab at disney.com
Wed Mar 15 09:22:04 UTC 2000
> As a final ramble in an otherwise rambling e-mail, it's
> interesting to note the current arguments against Squeak,
> which are the same ones we saw in 1989 when we started using
> Smalltalk for building interfaces for GPs to use: it's
> large and it's slow. Hopefully the image segments should
> help to sort out 'large', but I'm not sure what to do about 'slow'.
> When we re-coded our terminology engine in C, a 24-hour knowledge
> base compile went down to 7 minutes. Extreme, I know, but can the
> interpreted-language and OO communities do anything about this?
I believe we can. Just have a look at what Squeak presents to you in this
area - if you really need high performance you have actually several
choices. You can write your stuff in Slang and translate it to C afterwards
(thus allowing you to debug the entire thing right within Squeak) or code it
all in C (the way I did it partly in the 3D renderer) or use some existing C
stuff (through the FFI interface). The performance improvements are immense
(usually in the range of 30-150, depending on what you're doing) but your
example (suggesting a speedup of ~200) is not too far away from it. But the
faremost important thing is that you can actually develop your application
very rapidly and if (and only if) certain parts are too slow you can go on
and improve those. Thus choosing exactly those aspects that need to go
faster and don't worry about everything else. After you actually understood
the problem ;-)
> Yes, some of it can be solved by the 'buy a faster processor'
> argument, but developers will continue to develop
> systems that are at the edge of what current processors can
> achieve --- just look at Windows 2000 for an example.
> Anyone trying to use Squeak as a server (as I am) will also
> get bitten by this, as CPU cycles rapidly become
> important in that environment.
It's clear that Squeak is designed much more as a client side application
rather than a server. The fact that you can use Squeak as a pretty well
running server says more about flexibility than speed. Though there are in
fact several people working on the server part - take for instance the
high-performance XSockets implementation. Also, don't forget that Squeak is
running a pure byte code interpreter. Once the J3 is in place I think the
numbers will change quite a bit...
In the end it's all a question of tradeoffs. You will have applications that
need some parts really fast and others that are not that important. Squeak
(and other interpreted languages) give you a choice between the flexibility
and speed you need to do a certain project.
More information about the Squeak-dev