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:
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
On Sun, Dec 30, 2018 at 7:20 PM Levente Uzonyi leves@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.
Thanks, makes sense.
Fabio
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
On Dec 30, 2018, at 10:20 AM, Levente Uzonyi leves@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?
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
On Sun, 30 Dec 2018, Eliot Miranda wrote:
On Dec 30, 2018, at 10:20 AM, Levente Uzonyi leves@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
squeak-dev@lists.squeakfoundation.org