Actually, I have to retract what I said in my last email.  After looking
at the inlining structure for the benchmark (which I now see is the
benchmark I put in the Strongtalk tour), it does appear that the
Strongtalk system is currently treating timesRepeat: and to:do:
specially (remember we did all this stuff 6-7 years ago- my alzheimer's
is setting in).  If you use timesRepeat2: to defeat the timesRepeat:
optimization, on my machine it appears about 36% slower.

I think this optimization is probably done (probably in the bytecode
compiler) for two reasons: it lets the interpreter handle such loops
relatively efficiently before they are fully compiled (remember
Strongtalk starts running it with an interpreter), and it makes some
additional optimizations like elimination of overflow checking on the
counter increment much easier to do.  But it seems like it is not a
completely necessary optimization.

Of course, even with the optimization defeated using timesRepeat2:
Strongtalk is still ~3.5 times faster than Visualworks, which not
coincidentally is almost the exact speedup we measured for general
Smalltalk code and other more representative benchmarks.
-Dave

"Andreas Raab" <Andreas.Raab at gmx.de> wrote:
> Viktor,
>
> > Producers of Dolphin Smalltalk (www.object-arts.com) said
> > theirs Smalltalk is pure interpreter too.
>
> Oh sure it is, but your benchmark is no good. What you are
> measuring is
> a specific optimization - namely whether the compiler inlines
> #timesRepeat: messages or not. To prove that point I've copied the
> message timesRepeat: in Dolphin, VW, and Squeak and renamed it
> #timesRepeat2: (to prevent the compiler recognizing it). Let's have a
> look at the results when we use timesRepeat: or timesRepeat2:
> with your
> code (taken on a 1.2GHz P3):
>
> 		timesRepeat:		timesRepeat2:
> VW			 380ms			 680ms
> Dolphin		1311ms			3447ms
> Squeak		3351ms			3358ms
>