On Tue, Jan 01, 2013 at 03:47:54PM +0000, commits at source.squeak.org wrote:
> Nicolas Cellier uploaded a new version of Kernel to project The Trunk:
> http://source.squeak.org/trunk/Kernel-nice.725.mcz
> 
> ==================== Summary ====================
> 
> Name: Kernel-nice.725
> Author: nice
> Time: 1 January 2013, 4:47:30.911 pm
> UUID: 52a4994f-63bc-4f71-9f8f-6f2fad460bde
> Ancestors: Kernel-nice.724
> 
> Fast-up large integer modulo operations (\\ and rem:)
> 
> Implementation notes:
> Quotient and remainder are computed in a single LargeIntegersPlugin primitive (see digitDiv:neg:) so it's faster to just use it.
> For LargeInteger with 64 bits or less, LargeInteger primitives (31 32 33) are faster than the plugin (especially in COG) so try them first.
> This results in a 2x speed up of modulo operations in 4.2.5 VM (whatever bit length), and a 2x speed up in COG VM for bit length > 64.
> There is a penalty of 15% in COG for #rem: when bit length <= 64 because there is no primitiveRem...
> Well, I added primitiveRem and it is in both VM branches, but it has no primitive number assigned.
> If we assign a primitive number (20 ?) we can expect a 5x speed up for rem and bitLength <= 64.

Should we assign primitive number 20 to primitiveRemLargeIntegers? It is in
the range of numbered primitives allocated for large integer prims, and is
currently unused in both the interpreter VM and Cog.

I can't think of any reason not to do this, so someone please speak up if
it might cause problems.

Eliot, is this ok for Cog and Newspeak etc?

Dave