On Sat, Dec 29, 2012 at 01:15:43AM +0100, Nicolas Cellier wrote:

See http://smallissimo.blogspot.fr/2012/12/accelerating-largeinteger-in-squeak.h...

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