John.Maloney@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