On Tue, Dec 7, 2010 at 3:41 AM, Lukas Renggli renggli@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.
HTH Eliot
Lukas
-- Lukas Renggli www.lukas-renggli.ch
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@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
vm-dev@lists.squeakfoundation.org