64 bit images(was: A plan for 3.8/4.0...)

Dan Ingalls Dan at SqueakLand.org
Fri Apr 2 18:11:04 UTC 2004


Hi, Jecel -

>Given the current ratio of cpu and disk speeds, I considered it
>reasonable to do some computing while reading/writing images and so
>came up with a compressed format for them. Integers are encoded to take
>up the smallest number of bits possible without imposing any limit this
>size. Something like (example made up on the spot):

You know, we have talked about compressed images before.  One approach is simply to leverage the ZIP code which is already in the VM.

I had a revelation back when we first got image segments working.  On the average, as I recall, zipping an image saves about 50%.  Since image segments are essentially the same format, I figured we would get about 50% there as well.  Guess what?  They typically compress by about 4x.  Of course it makes sense when you think about it, because the internal (local)pointers in segments are small, and the integers are small, and all the in-pointers and out-pointers go through tables, so they are small as well, and the net effect is that image segments are full of words that are mostly zeroes, or mostly ones.

I'm expecting the same thing to be true for any normal-sized 64-bit image, so I would expect zipping to take out just about all the bloat due to the doubled word size.  I'll put out an image in both formats as soon as I get one converted, so we can play around with it.

A related topic is general compatibility.  It would be nice if...

	A 64-bit VM could read in a 32-bit image
	This would mean we wouldn't have to store separate 64-bit images
	for every release.

	A 64-bit Squeak could read in a 32-bit image segment (ie project)
	This would offer at least one-way sharing of projects.

	A V4 Squeak could read in a V3 imageSegment
	This would carry forward all current projects to V4

It's possible to do all of these and more on the fly, or we may choose to do them with special converters.  This is one of the areas we need to evaluate and decide on in the near future.

	- Dan



More information about the Squeak-dev mailing list