[squeak-dev] Re: LargeInteger negative bitShift (Rshift) not optimized on byte boundary?

nicolas cellier ncellier at ifrance.com
Fri Jul 4 01:23:22 UTC 2008


nicolas cellier a écrit :
> 
> 
> I checked VW7.5 on same machine to get a reference:
> | x |
> x := SmallInteger maxVal raisedTo: 100.
> OrderedCollection new
>  add: (Time millisecondsToRun: [100000 timesRepeat: [x bitShift: -1600]]);
>  add: (Time millisecondsToRun: [100000 timesRepeat: [x bitShift: -1597]]);
>  add: (Time millisecondsToRun: [100000 timesRepeat: [x bitShift: 1597]]);
>  add: (Time millisecondsToRun: [100000 timesRepeat: [x bitShift: 1600]]);
>  asArray
> VW: #(29 29 92 92)
> squeak:  #(164 172 315 120)
> 
> I'm surprised by the factor 3 in VW...
> But since more bytes are allocated in Lshift...
> The byteBounded Lshift is not far from VW.
> every other operation is definitly improvable.
> 
> 

I just pushed http://bugs.squeak.org/view.php?id=7109 for a small 
improvment of bitShift:.

I marked as Kernel, but should rather be VM. Ken, can you here me?

Above test shows a little speed up (don't compare to above results, my 
machine is sloooower):

Regular 3.10-1unix VM:  #(503 550 933 489)
Patched 3.10-1nice VM:  #(357 416 673 495)
VWNC 7.6 reference VM:  #(124 138 347 344)

Now that i exercized a bit with plugins, I will try a Karatsuba * 
implementation. The algorithm is very simple.
However naive algorithm should still be used when the smaller Integer 
operand is sparse, like (1 << 1000 + 1)*(1 << 10000 - 1)...




More information about the Squeak-dev mailing list