John.Maloney at disney.com wrote:
> 
> Hi, Kevin,
> 
> It's incredible how critical the cache is for Squeak performance.
> >From comparing Tim and your figures, it looks like the larger
> cache of the SA110 nearly doubles Squeak performance at the same
> clock speed. Of course, some of the increase is from the C code
> optimization in Tim's VM, but it's hard to imagine that accounting
> for more than 20-30% of the difference.
Certainly is - my CC is now five years old with no great likelihood of a
replacement :-( I DO have a gcc for Acorn but the libraries don't seem
to be very helpful at the moment. Maybe I'll have time to play with it soon.

I've claimed for years that the key determinant of speed for Smalltalk
is memory bandwidth. Any trick you can do to provide more actual or
virtual bandwidth will help. Caches simply fake out the cpu to make it
think you have faster memory than is really the case. JITters
pre-process to remove some of the bandwidth usage. Better C compilers
likewise. What I really want is a nice simple machine with a gigaHertz
clock and memory that can keep up :-)

> We actually have an iPaq and I am looking forward to getting
> Squeak up on it. You mentioned that you were writing down the
> steps needed to put Squeak on the iPaq. Let me know when that's
> available (but no rush; it's the holidays!). If I can get the
> proper development environment set up, I may try to compile
> a VM myself. Perhaps there is some level of C optimization that
> produces correct but faster code.
There's a resonable chance that you could use higher optimisation for
most of the vm and just drop it for the parts that have problems. Ought
to be a relatively simple makefile hack, surely? Particularly if all the
plugins are made external.

tim