[Vm-dev] Accelerating LargeInteger Plugin
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:
>> 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
>> 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
> 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...
More information about the Vm-dev