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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

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

fniephaus
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

Reply | Threaded
Open this post in threaded view
|

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

Levente Uzonyi
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:

> 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

Reply | Threaded
Open this post in threaded view
|

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

Eliot Miranda-2


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

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

Reply | Threaded
Open this post in threaded view
|

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

Levente Uzonyi
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

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