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