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.

You can compare this to IronPython (developed and abandoned by Microsoft) running in Silverlight at http://www.trypython.org/. I used:

x = 0
for i in xrange(1000000): x = i*5
x

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.

 

Advertisements

2 Responses to “Smalltalk Virtual Machines in .Net”

  1. Carl Gundel Says:

    Can SST be used to implement desktop .Net apps?


  2. There will be an SDK for desktop development.

    The major difference is that apps in the browser have very limited access to IO – you cannot access files, for example.

    The desktop SDK will use the full .Net libraries, not just the Silverlight libraries.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: