Dear Squeakers,
I have changed my mind a little bit after studying some Squeak sources.
Now I plan to implement LargeInteger primitives (20-39) _without_ changing the representation of LargeIntegers by extending the Interpreter arithmetic primitives using the CCodeGenerator. This avoids some problems dealing with different platforms.
In a later step changing the representation to bigger 'digits' (16,32,.. bits?) _could_ be interesting.
What do you think?
Stephan
P.S.: Is [Q] the right string to get attention from Squeak Central?
-----Original Message----- From: Stephan Rudlof [mailto:stephan.rudlof@ipk.fhg.de] Sent: Dienstag, 26. Oktober 1999 11:24 To: squeak Subject: RE: Better integer performance possible?
Dan, Michael and others,
There are three reasons LargeInts are slower:
It is all written in ST (no primitive support) The inner loops runs byte by byte [FYI, they were written when Squeak had 12-bit smallInts -- can you guess out why?] Squeak does not have a JIT -- yet.
If I'd have the freedom to change the representation of LargeInts I would like to implement this stuff as primitives in C.
We would happily invite a replacement LargeInt package into Squeak if it were at least as simple and understandable (I cannot imagine this not being the case!!), and if it did not add a significant overhead to the VM.
And change some Smalltalk methods to call the new primitives.
Timeline: Because I'm a new squeaker - but familiar with VW Smalltalk - and haven't change implementations of a VM - but implemented user primitives for VW Smalltalk - I'm planning quiet some time to become familiar with it. I could start in the mid of November - then I will have holidays - and I think I could finish around christmas.
What do you think?
Greetings,
Stephan Rudlof
sr (stephan.rudlof@ipk.fhg.de) "Genius doesn't work on an assembly line basis. You can't simply say, 'Today I will be brilliant.'" -- Kirk, "The Ultimate Computer", stardate 4731.3
-----Original Message----- From: Dan Ingalls [mailto:Dan.Ingalls@disney.com] Sent: Montag, 25. Oktober 1999 22:32 To: squeak@cs.uiuc.edu Subject: Re: Better integer performance possible?
Stephan Rudlof stephan.rudlof@ipk.fhg.de wrote...
The integer performance of Squeak is poor compared with other
Smalltalks,
especially for big ints (~ factor 500) and not so much for
small ones (~
factor 3).
What's the reason? Does anybody know if improvements are possible?
There are three reasons LargeInts are slower:
It is all written in ST (no primitive support) The inner loops runs byte by byte [FYI, they were written when Squeak had 12-bit smallInts -- can you guess out why?] Squeak does not have a JIT -- yet.
There is one reason SmallInts are slower:
Squeak does not have a JIT -- yet. Also, in the factorial example, it may matter that Squeak allocates real objects for all contextx
Ask Ian about Jitter -- he has been having fun with it recently. When he's done, I think the SmallInt comparison will be much better. LargeInts will be similarly better, but not like the Dolphin numbers. I personally have not ever found LargeInt speed to be a concern in any useful code.
We would happily invite a replacement LargeInt package into Squeak if it were at least as simple and understandable (I cannot imagine this not being the case!!), and if it did not add a significant overhead to the VM.
- Dan
PS: I know Squeak's bytecode speed got better on Windows in a recent VM, so 2.6 may be somewhat faster than 2.5.
WinNT Dolphin Smalltalk Version 2.1 Patch Level 2:
Time millisecondsToRun: [2000 factorial]. "big ints" 76 75 76 Time millisecondsToRun: [1000 timesRepeat: [12 factorial]].
"small ints"
11 11 10
WinNT Squeak 2.5: Time millisecondsToRun: [2000 factorial]. "big ints" 34520 34520 35080 Time millisecondsToRun: [1000 timesRepeat: [12 factorial]].
"small ints"
30 30 30
Stephan