[Vm-dev] Cog Primitive Performance

[Nicolas Cellier]

2017-04-18 4:02 GMT+02:00 Andres Valloud <avalloud at smalltalk.comcastbiz.net>
:

>
> On 4/17/17 16:45 , Eliot Miranda wrote:
>
>> FYI, hash multiply is
>> hashMultiply
>> | low |
>> low := self bitAnd: 16383.
>> ^(16r260D * low + ((16r260D * (self bitShift: -14) + (16r0065 * low)
>> bitAnd: 16383) * 16384))
>> bitAnd: 16r0FFFFFFF
>>
>> and when written as a primitive is
>> hashMultiply
>> | low |
>> low := self bitAnd: 16383.
>> ^(16r260D * low + (16r260D * (self bitShift: -14) + (16r0065 * low) *
>> 16384))
>> bitAnd: 16r0FFFFFFF
>> because we don't care about the multiply by 16384 overflowing; when
>> written as a primitive it won't overflow into a LargePositiveInteger.
>>
>
> Hopefully this doesn't mean the primitive got implemented by actually
> doing these operations verbatim.  As you have probably seen, that
> convoluted arithmetic is done this way in Smalltalk only to simulate a
> 32x32 multiplication bit-anded down to 28 bits without overflowing into
> large integers (the original code from August 2000 had my initials).
>
> At a sufficiently low level such as C, all that complexity is just an
> unsigned multiplication by 1664525.  The image code should still have a
> comment to that effect, did it get lost?
>
> Andres.
>

More: if it's a 64 bit image, then we have 60 bit long unsigned small int
since 1664525 highBit = 21, and self is a hash result not exceeding 30
bits, we can implement hashMultiply as
    ^self * 1664525 bitAnd: 16r0FFFFFFF

Maybe the JIT can be given a second chance too.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170418/bc17c791/attachment.html>