[Vm-dev] Accelerating LargeInteger Plugin

[Nicolas Cellier]

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...

Nicolas

>
> Levente
>
>>
>> Nicolas
>>
>