Benching #Smalltalk vs Squeak
goran.krampe at bluefish.se
goran.krampe at bluefish.se
Fri Nov 28 14:51:19 UTC 2003
"John Brant" <brant at refactory.com> wrote:
> Most likely the reasons will be the difference between a jitter VM and an
> interpreted one. One benchmark that was interesting was generating strings.
> I would have expected Squeak to be faster. This test prints all integers
> from 1 to 8000 and then reverses the print string. Since strings are
> immutable in .NET, the reverse method makes n+1 copies of a string that is n
> characters long.
The new implementation I posted as an ENH gave Squeak a 20% improvement.
> It appears that Squeak's printing of Integers is quite a bit slower than
> #Smalltalk's. I would expect the SmallInteger printing to be somewhat
> slower, since I defer to .NET for printing, but LargeInteger printing
> shouldn't be. In particular, if printing 1000 factorial in #Smalltalk takes
> 10ms, but doing that in Squeak takes 1.3 seconds.
Well, as far as I can tell it took about 100 ms (not 10ms) in
SharpSmalltalk and as you say 1.3 seconds in Squeak (so it seems our
machines are similar in performance) with the old code.
The new code I posted brings that down to about 430 ms, which is at
least closer to SharpSmalltalk. :) I guess the remainding difference is
more due to the VM - using mono btw takes about 190 ms on printing 1000
So if I am not mistaken this all generally puts SharpSmalltalk as the
King Performer among free Smalltalks on the Windows platform (saying "on
Windows" because under mono it is still slow).
But I am only aware of three free Smalltalks of interest (GST, Squeak,
SharpSmalltalk). Are there more btw? Well, Slate of course - but I think
it needs one or two more version steps to be counted. Hey, who knows -
perhaps GST is faster too! Hmmm, gotta pull it down and try it... it
seems Paolo is really busy with it.
(Hoping that Bryce will some day charge in like a knight on a white
horse and bring the crown back to Squeak :-))
> > Ok - but I also got very confused about the numbers - it didn't seem
> > like the smopstone number and the execution times are... properly
> > "related". But I didn't dig into it. :)
> > For example:
> > SSt+MS.net
> > 0,6909936 22,8439163546522 generating fractonaccis
> > 0,75108 20,577035735208 generating strings
> > Squeak
> > 0.499 6.32665330661323 generating fractonaccis
> > 0.187 16.52941176470588 generating strings
> > So... isn't short time = higher smopstone? For some tests it seems to
> > be, and not for others.
> Look at the repetition count. In Squeak they are only running once, but in
> #Smalltalk they are running 5 times.
Ah, duh. :)
> > Btw, how do *you* write SharpSmalltalk programs? I mean, what IDE do you
> > use?
> I use VisualWorks. I define #Smalltalk in its own namespace and have scripts
> that will export the packages. I also have some code that allows me to
> quickly port other VisualWorks packages to #Smalltalk.
> John Brant
PS. Dolphin was interesting, actually has a special implementation for
base 10 more or less equal to the one in SharpSmalltalk - and a
recursive implementation for the other bases (if I read the code
correctly). Was fast too, about 38 ms - when doing it 100 times.
More information about the Squeak-dev