Helge,

Any thoughts on StarSqueak primitives that could be added to speed
up your StarSqueakLife simulation? Perhaps a primitive to sum up
some numeric property of the 8 adjacent cells? (I haven't looked at
your code, but I can imagine how it must work...)

	-- John

At 7:28 PM -0800 3/15/02, Helge Horch wrote:
>At 23:30 15.03.2002 +0100, Hannes Hirzel wrote:
>>What perhaps misled me: The simulations are still rather _slow_.
>
>Well, StarSqueak*Life* is kindof slow, yes.  I gauge AntColony, ForestFire, 
>and SlimeMold as exceptionally *snappy*.  IIRC the Java-StarLogo project 
>folks *envied* us for the speed we Squeakers got.  All thanks to John Maloney.
>
>There are faster Life implementations than StarSqueakLife out there, first 
>and foremost Dan's tricky BitBlt version.  After all, in Conway's game 
>definition, there was nothing else to cells than "alive or dead."  You can 
>just treat the field as a whole, and flip bits.  Except, StarSqueakLife 
>implements the game differently, and more costly:  Each cell has an 
>identity as a LifeTurtle object, and decides for itself whether it will 
>live on or die.  Autonomously.  Each queries its neighbours, knows its age, 
>and changes its color and its very existence accordingly.  The game is 
>turned inside-out.  I recommend Resnick's book (Turtles, Termites, and 
>Traffic Jams) and the code.
>
>E.g., see LifeTurtle>>live and how LifeTurtles account for the fact that a 
>randomly initialized StarSqueakWorld may place multiple turtles on the same 
>spot:  They shriek and steam off into random directions, turning "Color 
>tan" in the process...
>
>Maybe Bijan and Tansel were right.  I should have found the time to write 
>more about it.  Yeah, I know.  But well, you know...
>
>Cheers,
>Helge