Primitives 34-37 for LargeIntegers bit operations not in use?

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

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.

Levente

On Sun, 30 Dec 2018, Fabio Niephaus wrote:

> On Dec 30, 2018, at 10:20 AM, Levente Uzonyi <[hidden email]> 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?

On Sun, 30 Dec 2018, Eliot Miranda wrote:

>
>
>> On Dec 30, 2018, at 10:20 AM, Levente Uzonyi <[hidden email]> 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