[Vm-dev] Accelerating LargeInteger Plugin

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Sat Dec 29 10:10:58 UTC 2012

2012/12/29 Levente Uzonyi <leves at elte.hu>:
> On Sat, 29 Dec 2012, 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).
>> 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
>> Thoughts?
> I think the reason why the difference in case of #+ and #- is not
> significant is because of the overhead of #bench. The actual numbers (for
> all cases) are probably better than your numbers for the 10000 bits case.

Assymptotically we could expect x4 on + and - and x16 on *
Or maybe only x2 and x8 with emulated 64bits operations

> I wonder if it's possible to keep the current format of the classes
> (variableByte), but do the computation using 32/64-bit operations. Writing
> it in slang wouldn't be easy, but it would let us use the new code with
> existing images.

Yes, the recipe is:
- store the LargeInteger as words in machine endianness
- hack primitives for digitAt: digitAt:put: to accomodate for above hack
- hack the initial unswapping of Byte like to ignore LargeInteger (we
want them to be swapped)
maybe I forgot something...


> Levente
>> Nicolas

More information about the Vm-dev mailing list