[Vm-dev] Accelerating LargeInteger Plugin

[David T. Lewis]

On Sat, Dec 29, 2012 at 01:15:43AM +0100, Nicolas Cellier wrote:
>  
> See http://smallissimo.blogspot.fr/2012/12/accelerating-largeinteger-in-squeak.html
> 
> This simple experiment is interesting but is not ready to use.
> If we change LargeIntegersPlugin to use 32bits words rather than
> bytes, we are introducing one more clever hack in the system (two for
> handling MSB efficiently).

This would be a reasonable thing to do. It is ok to have a clever hack
in the plugin as long as it is not visible to the user. But the big
endian/little endian byte ordering may make this not worth the
effort.

> If we want to make LargeInteger a word array, then we have a transition problem.
> I thought of a few more or less evil solutions, but I fail to see how
> to not break the smooth trunk update
> - perform the operation on a stripped image not requiring LargeIntegers...
> - remove the LargeIntegerPlugin, redefine digitAt: digitAt:put: and
> digitLength as a hack answering proper byte for both a Byte and
> WordArray, then redefine LargePositiveInteger as word Array on such
> VM, then add the new plugin...
> - use an image tracer

The transition problem is difficult, and I do not have an answer for that.
But consider the difference between an image format 6505 (Cog) image
and a 6404 image (standard interpreter). The only meaningful difference
is little endian/big ending word ordering for the internal storage of
float objects. This actually has nothing at all to do with Cog, it is
just an incidental optimization that Eliot introduced at the same time
as he did the Cog changes, so consider it from the point of view of
the float object storage - there is a new image format (6505) that is
essentially identical to the prior image format except that on a
little-endian platform the high and low order words of a double precision
float object are swapped to match the word order conventions of a little
endian machine.

Something similar could be done to allow large integers to be stored
internally as 32-bit words according to platform endianness convention,
and have an image format number that indicates that this is the case.
The VM could be responsible for loading and saving the image correctly
based on that image format number. I am not sure how to coordinate that
with the large integer plugin, which presumably would need to know that
the VM had loaded the image in one format or the other, but I'm sure
something could be done.

> 
> Thoughts?
> 
> Nicolas

Nice optimization, I hope we can figure out how to make it happen.

Dave