[Vm-dev] 64bit FFI?

David T. Lewis lewis at mail.msen.com
Thu Feb 12 23:30:28 UTC 2009


On Thu, Feb 12, 2009 at 12:18:42PM -0800, Eliot Miranda wrote:
>  
> I don't want to be sarcastic, but that doesn't seem to be very far.  From
> Bert I get the sense that no-one is actually using 64-bit Squeak images (he
> just said as much).  The Squeak 64-bit image format is not particularly
> ambitious.  It doesn't give one wider SmallInteger range, more identity hash
> bits, larger objects, more literals in a method or faster floats, or
> immediate characters.  It is as naive a conversion to 64-bits as one can
> imagine.  I don't see that the rather conservative approach taken with the
> 64-bit VM has produced something particularly compelling.  Note that a
> memory-bound 64-bit Smalltalk application that can't take advantage of
> 64-bits to speed-up computation (as for example immediate doubles do) simply
> uses twice the memory bandwidth to accomplish exactly the same thing as a
> 32-bit application, and so if memory-limited (doesn't fit in cache) can run
> twice as slow.  The only advantage such a 64-bit system has is in being ale
> to instantiate more objects.

The 64 bit image was a research project that I believe was intentionally
done in the simplest way possible. Your observations are correct, but
your expectations may be a bit high. The objective was to get it working,
and the "compelling" part was left for whomever might choose to take up
the initial work and do something further with it.

You're quite right that the 64 bit image is as naive a conversion to
64 bits as one can imagine, but this was entirely intentional and the
folks who made that design choice were not being naive about it in the
least. From my point of view, the really nice thing about having the naive
implementation available is that, well, it works. Even an amateur like
me can pick it up, figure it out, and maybe make a few useful contributions
along the way. Worst case I might learn something while I'm at it ;)

Dave



More information about the Vm-dev mailing list