Smalltalk Virtual Machines in .Net
December 8, 2010
Silver Smalltalk uses a bytecode interpreter which is written in C#. Smalltalk source is compiled to a bytecode format (CompiledMethod) which is then interpreted at runtime. Here is an example:
Processor runMethod: (Compiler compileSnippet: '3+4')
The SST virtual machine is designed to *exactly* duplicate the actions of the Squeak virtual machine. So all Smalltalk behaviors, including “non local returns”, are supported. Plus the SST VM is designed to support debugging and multiple concurrent processes.
The advantage of this approach is flexibility and fidelity to the Smalltalk model. The disadvantage is reduced execution speed.
Try this small test:
| x | x := 0. 1 to: 100000 do:[:i | x := i*5]. x
It takes less than half a second to run in my browser. Increasing the count to 1,000,000 it takes about 2 seconds. And with a count of 10,000,000 it takes a painfully long time.
x = 0
for i in xrange(1000000): x = i*5
My sense is that they are similar in speed up to 1,000,000 iterations – after that IronPython is faster.
IronPython is built using the Dynamic Language Runtime (DLR) which is – AFAICT – another project that Microsoft has abandoned. DLR runs native .Net “IL” code in a dynamic environment.
Application speed as perceived by an end user depends upon multiple factors.
1) Startup speed is critically important. Silver Smalltalk’s XAP executable (which includes the compiler, runtime, and support classes) is about 150kb in size. By contrast, the IronPython DLR and scripting support are about 1.4 MB; then add nearly another MB for the IronPython compiler and libraries – perhaps 2.5 MB in total. So regardless of how fast IronPython runs once it is loaded, SST will start up much more quickly.
2) Compiling speed is important. The more complicated the compiler, the longer code takes to compile. SST compiles very quickly.
3) In most Silverlight applications, differences in the speed of a scripting language won’t even be noticeable. Consider that in Silverlight:
- widgets are written in compiled C# or native code
- graphic rendering is handled by native code (or hardware)
- most waiting time will be waiting for server communications
So, my guess is that for *most* Silverlight applications, a user would judge an app written in Silver Smalltalk to be faster than an app written in IronPython. Of course, it is possible for an application with a lot of numerical processing this would not be the case. However, it is easy in SST to access any custom C# library (by reflection or by recompiling the kernel) to handle heavy processing requirements.
But, at the end of the day, Smalltalk is going to win anyway. Why? Because it is a lot more fun to use and a lot more flexible for implementing *cool* online graphical applications.