Just a suggestion for someone looking for something to do: Squeak keeps long integers as a byte array and smashes them in Smalltalk code. For example, #+ in Integer is inherited by the long integer classes and, after a primitive failure, is run to do addition.
I ran a quick test of Squeak and IBM Smalltalk on the same machine and got these results:
| a b | a := 12345678901234567890. b := 98765432109876543210. Time millisecondsToRun: [ 10000 timesRepeat: [ a * b ] ] 5500 "Squeak 10000 times" 13200 "IBM 1000000 times"
5500 * 100 / 13200.0 41.67
IBM Smalltalk (and at least some other commercial Smalltalks) use 32 bit integers and do the work in a primitive. There exist C packages which implement long integer operations and which are portable, so such support should not limit the portability of Squeak.
I suggest that Squeak be changed to use 32 bit integer components in long integers; the factor of 40+ is typical and matches what I've measured on other hardware platforms and other Smalltalk systems in the past.
But, you say, no one ever uses long integers! Of course they don't; not on purpose when they are paying 550 microseconds for a multiply; when it is only 13 microseconds (as in the tests above) it's usable. On fast systems I use long integers a lot, and at least sometimes just by ignoring the issue. So what if I get a long integer? It only matters in super-critical loops. (Fractions even become fast enough to use!)
Anyone willing to do it? (I'd love to but I'm up to my ears in something at the moment). I can provide a bunch of pointers to code and literature.
Dave
_______________________________ David N. Smith IBM T J Watson Research Center Hawthorne, NY _______________________________ Any opinions or recommendations herein are those of the author and not of his employer.
"David N. Smith" dnsmith@watson.ibm.com wrote...
IBM Smalltalk (and at least some other commercial Smalltalks) use 32 bit integers and do the work in a primitive. There exist C packages which implement long integer operations and which are portable, so such support should not limit the portability of Squeak.
I suggest that Squeak be changed to use 32 bit integer components in long integers; the factor of 40+ is typical and matches what I've measured on other hardware platforms and other Smalltalk systems in the past.
Dave -
I agree with your desire, but I'd like you to consider another approach.
The largeInt code is exactly the kind of code that can be compiled into Squeak primitives, with some attention to detail. We typically see 20-40x improvement when we do this. Along the way, a couple of the algorithms could use some cleanup and tuning as well (like, multiply could certainly go faster than NxM bytes). Wouldn't you like to be able to see the code in Squeak, be able to test it by commenting out the <primitive>, and be able still to run everything in a tiny VM that didn't implement the primitives? I wouldn't suggest this alternative if I didn't think it could go just as fast too.
In technology, ALWAYS ask to have your cake and eat it too.
- Dan
squeak-dev@lists.squeakfoundation.org