LargePositiveInteger prims (was: [Pharo-project] Fwd: [Vm-dev] Image freeze because handleTimerEvent and Seaside process gone?!)

[David T. Lewis]

On Tue, Dec 07, 2010 at 10:47:39AM -0800, Eliot Miranda wrote:
>  
> On Tue, Dec 7, 2010 at 3:41 AM, Lukas Renggli <renggli at gmail.com> wrote:
> 
> > > One change that I don't understand, although it probably is unrelated, is
> > in [2]:
> > >
> > > LargePositiveInteger removeSelector: #=!
> > > LargePositiveInteger removeSelector: #bitAnd:!
> > > LargePositiveInteger removeSelector: #bitOr:!
> > > LargePositiveInteger removeSelector: #bitShift:!
> > > LargePositiveInteger removeSelector: #bitXor:!
> > > LargePositiveInteger removeSelector: #'~='!
> > >
> > > Why would one want to remove these primitive calls from large integers?
> >
> > AFAIK, Cog needs those.
> >
> 
> That's right.  Those methods used SmallInteger primitives (7, 8, 14, 15, 16
> & 17) and in Cog SmallInteger primitives only work on SmallIntegers, not on
> up to 64-bit LargeIntegers; i.e. they don't bother to test the receiver for
> being a SmallInteger and hence crash if installed on LargeInteger.  I
> probably made a mistake in deciding to save a tag test, but I did.  Instead
> these methods should use the relevant LargeInteger primitives.  The issue is
> I think those are missing in the standard VM.  See primitives 27 28 34 35 36
> &
> 37 primitiveEqualLargeIntegers, primitiveNotEqualLargeIntegers,
> primitiveBitAndLargeIntegers, primitiveBitOrLargeIntegers,
> primitiveBitXorLargeIntegers, primitiveBitShiftLargeIntegers
> in the Cog VM and perhaps the standard VM.  If they're missing in teh
> standard VM it should be fine to redefine those methods to include the 27 28
> 34 35 36 & 37 primitive numbers.  If they're defined differently someone
> needs to check that using those numbers works in the standard VM.

r.e. saving the tag test on primitives 7, 8, 14, 15, 16, and 17:

Actually, this does have a significant (2X) performance hit for 
LargePositiveInteger values in the 32-bit range for the interpreter
VM.  I ran the test below with a trunk image, then repeated the test
after restoring the original bindings in LargePositiveInteger for #=,
#~=, #bitAnd:, #bitOr:, #bitShift: and #bitXor:. The results show a
better than 2X improvement for large positive integers within the
32-bit range of values with the primitive bindings restored.

Conclusion: It would be good if the tag check could be added to Cog,
and the LargePositiveInteger primitive bindings should be restored at
some future time when this change is in general circulation for all VMs.

Note: The LargeInteger primitives 27, 28, 34, 35, 35, 36 & 37 are now
added to the interpreter VM but were not used in this test. These
primitives use 64-bit values and I would therefore not expect them
to be as fast as the 32-bit primitives 7, 8 ... 17 but I did not
actually test this to confirm.

- Dave

To verify the above:

large32Ints := 16r40000000 to: 16r41000000.
testBlock := [ | t1 t2 |
	t1 := Time primMillisecondClock.
	large32Ints do: [:e |
	e = e.
	e bitAnd: e.
	e bitOr: e.
	e bitShift: 1.
	e bitXor: e.
	e ~= e.
	t2 := Time primMillisecondClock].
	t2 - t1].

"Squeak trunk (large int prim bindings removed:"
testBlock value ==> 69370

"After restoring original large int prim bindings"
testBlock value ==> 30560