Squeak on iPaq..success!

John.Maloney at disney.com John.Maloney at disney.com
Fri Dec 29 20:13:39 UTC 2000


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






More information about the Squeak-dev mailing list