Greg -

It's good to hear more interest in speeding up Squeak.  I thought I would comment on a few of your items from the perspective of the Jitter (II) project.  Ian may have more to say about this as well.  It will be easier to be specific when JII is released, but I thought you and everyone would want to consider this as part of the perspective when plotting the direction for future work.

>   -------------------- Where do we want to go? --------------------
>We could choose to equal the speed of any of the faster Smalltalk
>(or Self) implementations.  I would propose doing things in stages.
>
>1. Optimize the virtual machine, but keeping a bytecode interpreter.
>   This should get us to the performance level of Dolphin or Smalltalk/V
>   or perhaps slightly better.  (We ought to be able to at least as 
>   well as Smalltalk-V, which runs in a 16-bit code environment and
>   so has to do slow segment loads all over the place.)

The Squeak interpreter is already pretty heavily optimized.  At this point there appear to be three main improvements that could be made:

	Change from bytecodes to word-length threaded code
	In-line caching of method lookups
	Streamlining of activation (context management)

Jitter II is a JIT (just-in-time compiler), but the first version to be released, will actually translate to threaded code (we've been calling this J2T or JIIT).  This has the benefit of retaining complete portability while providing somewhat faster instruction dispatch, inline method lookup and streamlined activation.

>2. Compile to native code.  If the VM was well optimized before this,
>   we might be able to reach performance near Visual Works.
>   (It is interesting to note the almost factor of two speed difference
>    between VisualWorks and Smalltalk-MT, indicating what an 
>    optimized VM can do.)

The threaded phase of Ian's implementation is intended to be be easier to debug, and much easier to port.  However the architecture is designed for native code from the ground up.  The plan is to reduce to an absolute minimum the complexity introduced by the change to native code.  In particular, except for code generation, there should be almost no change to the translation and management of translated methods, to the handling of contexts, and to the interpreter interface.

Jitter II is an elegant and relatively simple design.  Whether it will reach the performance of VW is not known, but it is unlikely that the first versions will do that well.  If Jitter achieves between 2x and 4x while maintaining Squeak's relative simplicity and rampant portability, we will consider it to be a triumph.

[big snip]

>Some of the things I have ideas on speeding up include
>  (1) method dispatch
We agree, and Jitter IIT will incorporate both word-threading and inline caching.
>  (2) the garbage collector
Regarding changes to object headers, we may well want to make such changes.  However we're inclined to wait until we have analyzed a running Jitter for a while.  This is because Ian has done some very clever things with method preambles that reduce the overhead of variant headers.
>  (3) bytecode interpreter
It is our hope that Jitter II will be easily portable in both its threaded and native forms.  With an overhead of less than a megabyte, all but the tiniest Squeak implementations will want to run Jitter.  If so, then hopefully the pressures on the bytecode interpreter will reduce to simplicity and compactness.
>  (4) array access (including OrderedCollection)
Here again, we don't feel that the current treatment is necesarily ideal, but we do feel the importance of seeing the Jitter profiles before planning the next step.

>   -------------------------- Summary --------------------------
>I hope we can get a good discussion about speeding up Squeak going,
>as well as adding closures and any other basic VM level features.
>Various people are working on these issues, and it would
>be good to talk to each other and to hash out what can be
>done to create the "lean, mean, squeaking machine" that many
>of us would like Squeak to be.  
>
>We have a basic idea where we are.  We need to figure out
>where we are going, and how to get there.  
>
>As for me, I would like to see Squeak eventually have performance
>close to VisualWorks.  I have some ideas on how to move
>in that direction, but I am sure I am lacking many ideas,
>and even more, the time to implement all of them.
>(I have started on the header simplifications though.)

Hopefully it will not be long before we can include Jitter II in our benchmarks, and lay out some priorities for further optimization from that new perspective.

The points you raise in your message are all serious candidates, and it is great to see a general move toward making Squeak a serious contender in Smalltalk execution speed.

	- Dan