On Sun, 30 Dec 2018, Eliot Miranda wrote:

>
>
>> On Dec 30, 2018, at 10:20 AM, Levente Uzonyi <leves at caesar.elte.hu> wrote:
>> 
>> Those primitives will fail unless the receiver, the argument and the result fit into 64 bits. The LargeIntegers plugin provides primitives without such limitation, so currently the latter is in use.
>
> IMO the LargeIntegerPlugin (LIP) primitives should substitute for the 64 bit ones, but that’s probably something that should wait for a major release.
>
> The numbered ones are a quick hack.  Now we have the LIP, along with Nicolas’ fast rewrite (internally they are accessed in 32-bit units), and my macrology to avoid push/popRememberedOop in Spur, we have something general, powerful, and efficient.  Has anyone looked at the relative performance of LIP and numbered prime for the 64-bit range?  If so, care to post some numbers?

I ran some quick benchmarks where primitive 36 (bitXor) was 4.8x faster 
than the LIP primitive for 64-bit LargeIntegers. For SmallIntegers, it was 
3.5x slower. For mixed operands, it was 6.5x-7.5x quicker.

Levente

>
>> 
>> Levente
>> 
>>> On Sun, 30 Dec 2018, Fabio Niephaus wrote:
>>> 
>>> Hi all,
>>> 
>>> I just noticed that Squeak-trunk does not use the primitives for
>>> LargeIntegers bit operations (#34 to #37). Is there are good reason
>>> for this (disabled in the VM?) or is this just a mistake? See:
>>> 
>>> SystemNavigation default browseAllSelect: [:cm | cm primitive between:
>>> 34 and: 37]
>>> 
>>> Fabio
>>