Removing the fear of using long integers

David N. Smith dnsmith at watson.ibm.com
Mon Feb 2 16:18:51 UTC 1998


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.





More information about the Squeak-dev mailing list