At 6:42 PM -0800 12/28/00, Tim Rowledge wrote:
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 :-)
That matches my experience with Squeak. It was surprising slow on the PPC 603, which had small caches, and unexpectedly fast on the G3, which has a very high-bandwidth second-level cache.
Re:
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.
Sounds plausible. I don't have a development environment for StrongARM, so I'll leave it up to Kevin for now.
In a private message, Joern Eyrich said he got over 10M bytecodes/sec on the iPaq with a WinCE-based VM, so C optimization must make a bigger difference than I expected. Either that, or WinCE is more efficient than Linux... no, let's not even *think* about that! :->
-- John