Well, and then did I mention that it depends on the implementation of the virtual machine? It turns out that fast VMs for dynamic languages are kind of like black magic in terms of the number of people who understand them well, but you can get one for Squeak now!

http://www.mirandabanda.org/cogblog/downloads/

It has a JIT, polymorphic inline thingummies, and gets the job done right fast. Combined with improvements made to the Smalltalk code recently in Squeak, the system has gotten quite fast.

Wandered past this post for the second time and thought I’d set the record straight now that the game has changed in the Squeak world:)

That is really cool: it really nicely demonstrates the benefits of turtles all the way down I guess. Cheers for the update.

Ian


printString
"Highly optimized version for base 10, and utilizing the fact
that we know SmallInteger maxVal and not using a WriteStream."

| integer next result i sz |
self = 0 ifTrue: [^'0'].
self < 0 ifTrue: [^'-', self negated printString].
result := String new: 10.
i := 10.
integer := self.
[integer > 0] whileTrue: [
next := integer // 10.
result byteAt: i put: 48 + (integer - (next * 10)).
i := i - 1.
integer := next].
sz := 10 - i.
^(String new: sz) replaceFrom: 1 to: sz with: result startingAt: i+1


I am a long time Squeaker/Smalltalker and looked into this for fun.
If we look at your original code there are a few things we can do:

1. Use #printString instead of asString. Of course gives almost no improvements but it might be the “correct” message to use.

2. Avoid concatenation since it has to create new buffer and copy etc.

3. Not call “String crlf” every time. We can assign “crlf := String crlf” in a local var and use that in the loop.

4. And finally of course, we could create an optimized #printString for SmallIntegers.

So let’s see, here is SmallInteger>>printString:

printString
"Highly optimized version for base 10, and utilizing the fact
that we know SmallInteger maxVal and not using a WriteStream."

| integer next result i sz |
self = 0 ifTrue: [^'0'].
self 0] whileTrue: [
next := integer // 10.
result byteAt: i put: 48 + (integer - (next * 10)).
i := i - 1.
integer := next].
sz := 10 - i.
^(String new: sz) replaceFrom: 1 to: sz with: result startingAt: i+1

And here is your snippet with some modifications:

| myFile ios |
ios := ReadWriteStream on: ''.
crlf := String crlf.
Transcript show: 'Populate Buffer: ',
(Time millisecondsToRun: [
1 to: 10000 do: [
:i | ios nextPutAll: i printString; nextPutAll: crlf
]]) asString , ' millseconds' ; cr.
MessageTally spyOn: [
1 to: 10000 do: [
:i | ios nextPutAll: i printString; nextPutAll: crlf]].
Transcript show: 'Position: ', (ios position) asString ; cr.
myFile := StandardFileStream fileNamed: 'test.txt'.
Transcript show: 'Output Buffer: ',
(Time millisecondsToRun: [
myFile nextPutAll: (ios contents); close]) asString,
' milliseconds' ; cr.


The end result? On my box this makes your test run more than 4x faster – from 141 ms to 34 ms for the population. I would presume this matches both Perl and GNU St given your numbers.

Now, note that I did this just for fun – the comparison in itself doesn’t say anything in general IMHO. I was just curious how much faster we can make it using “regular” optimizations.

regards, Göran

Squeak: ~170ms
Smalltalk/X: ~10ms
Gnu Smalltalk: ~80ms

I know Smalltalk/X has some optimizations through primitives but i’m not sure about Gnu Smalltalk.

After, i decided to try a different approach outputting the 10,000 numbers directly to a file:


|ios|
ios := StandardFileStream fileNamed: 'c:\test.txt'.
Transcript
cr;
show: 'Write to file stream: ';
show:
(Time millisecondsToRun:
[1 to: 10000 do: [:each| each printOn: ios. ios nextPut: Character lf]]) printString;
show: ' ms';
cr.


This last code performed with the following results:

squeak: ~210ms
Smalltalk/X: ~10ms
Gnu Smalltalk: ~62ms

So if i see it correctly the Smalltalk/X primitive optimizations result in a constant time for both approaches. Gnu Smalltalk slightly benefits from this approach (FileStream possibly performs buffered I/O ??) while squeak comes last with even worse results. I’d believe commercial smalltalk implementations should yield even better results (Cincom Visual Works, Instantiations VA Smalltalk, Dolphin).

So although i find smalltalk very acceptable in terms of performance for most applications, i must agree that at least when comparing to other implementations and almost certainly with other languages, squeak is somewhat slow.

Grant wrote: Am I reading that right? You’re using a profiler in Smalltalk, and just timing the perl? Apples and oranges. Profilers have an inherant performance penalty in any language.

The timings reported come from this line without the profiler running:

Transcript show: 'Populate Buffer: ',
(Time millisecondsToRun: [
1 to: 10000 do: [
:i | ios nextPutAll: ((i asString) , String crlf)
]]) asString , ' millseconds' ; cr.

The profiler shows that 80% of the time is spent converting i from a SmallInteger to a String.

Kirit wrote: It’s a while since I did any Smalltalk seriuosly and I’ve never done any Perl, but it looks to me like the two versions aren’t doing the same thing. I’m not sure how much difference it would make though – maybe very little.

My initial version wrote directly to the file and took almost the same amount of time. On the Squeak beginner list it was suggested that this was because the I/O is buffered in Perl and unbuffered in Squeak and the recommendation was to write to a stream in memory first and then dump to a file.