Is the VA Smalltalk virtual machine currently able to make use of multiple cores? Our observations for Visual Age 5.5 show that processes are only created on one core. For our application, it would add huge performance benefits if the Smalltalk processes could be spread over all available cores.

crenz wrote:Is the VA Smalltalk virtual machine currently able to make use of multiple cores? Our observations for Visual Age 5.5 show that processes are only created on one core. For our application, it would add huge performance benefits if the Smalltalk processes could be spread over all available cores.

The virtual machine is using only ONE processor/core. Virtual machines using multiple cores are much more difficult. The only positive effect now of dual processors or cores can be seen, if you use asynchronous external API calls to pretty time consuming tasks - like for example
DNS queries or database calls or stuff like this. Another positive effect is, that when using asynchronous calls (future calls), that your GUI is still responsive.

There are two issues in your reply - one being that the implementation of a multi-core VM is much more difficult than a single-core VM. I agree with that.

The second is that supporting multiple cores does not have a big effect on the application performance. I agree that this is true with simpler applications. But we have a few computation-intensive processes in our tool that would benefit from multiple cores. It is a pity to see your application make full use of one core, and at the same time see your other core just idling around, so that the CPU usage constantly is at 50% only.

crenz wrote:The second is that supporting multiple cores does not have a big effect on the application performance.

I did not mean that in any way. I like to have speed, I like to have native threading and I would like to see Smalltalk to use all the cores it can get - but actually - except Smalltalk MT - no Smalltalk is able to give this support.

On the other hand: I've found out, that serious consideration when using native API with future calls can give good responsive AND can improve the speed of an application very much.

Yesterday he pointed to an article discussing the value (or lack thereof) of native thread support -- it relates to Ruby and Erlang, but is equally applicable to Smalltalk. What it points out is that there is more than one way to achieve good performance on a multi-core machine and using threads internally isn't necessarily the best one (in the author's opinion).

I don't have a position one way or the other on the approach discussed in the aritcle right now, but I will say that adding native threading support to Smalltalk will certainly complicate your development effort -- and your testing effort even more.

The current model in VA Smalltalk (and also VW, I believe) is to support calling out to external functions (like communications and DB access) on a native thread. This is a very specific usage of threading and is somewhat easier to control -- enough so that it is usually invisible to the developer.

This is not directly related to the initial post, but in our particular situation we run multiple images on a muti-core machine. We have spent extensive time at Intel labs tuning the application and found that on a Windows 2003 OS, the OS did a very good job of reducing context switching of running images. Of course handling concurrency of mutiple images accessing the same resources becomes a problem especially as processing speed is increased.

You may consider sharing data between images via a memory mapped file if it makes sense for your app. Assuming you could handle the concurrency / timing, it would spead the processing load across multiple cores.

[...
You may consider sharing data between images via a memory mapped file if it makes sense for your app. Assuming you could handle the concurrency / timing, it would spead the processing load across multiple cores.[/quote]

FYI, multiple concurrent images on the same or different machines may access the same set of VOSS virtual object spaces for load-balancing etc. Data may be partitioned into separate virtual spaces according to voltility, read-write/read-only access etc, and a transaction may include objects in any or all of the connected virtual object spaces.
More info on http://www.logicarts.com

I hadn't dropped by in a while, so I'm now suprised to see quite an interesting discussion ensued. I'd like to offer one suggestion: Obviously, it is always possible to implement some home-grown solution or find some external library that helps you to achieve your goals.

However, in my experience, it makes a huge difference whether your development system offers its own implementation to help you solve your problem or not. In real projects, things are often impossible to implement not due to technical, but due to budget or resource considerations. Therefore, if VAST were to offer something that makes it really easy to launch a new virtual machine from an image in a native thread/process -- even if it were to offer no data sharing at all --, it would make it a lot easier to make use of all those nice cores in our machines....

This is actually a thought that comes up in the blog post mentioned above as well. The author talks about Erlang's process model, which offers fewer features than Java, but is fast and very easy to use.

crenz wrote:Therefore, if VAST were to offer something that makes it really easy to launch a new virtual machine from an image in a native thread/process -- even if it were to offer no data sharing at all --, it would make it a lot easier to make use of all those nice cores in our machines....

This is actually a thought that comes up in the blog post mentioned above as well. The author talks about Erlang's process model, which offers fewer features than Java, but is fast and very easy to use.

I would say, that it is not fair to compare the programming model of Erlang with the one of Smalltalk. In the situation of Erlang it has much less problem of sharing data across "threads" than a typical Smalltalk (or other mainstream) language might have.

But what can be done is to take the ideas from Erlang to Smalltalk and do the programming in that way ... and this seems to be possible - though it might not be common ? One main thing what is missing is a concept of interprocess communication channels between different Smalltalk images - but even this could be done and then you do data copying from thread to thread. Additional enehancements could also give you some automatic management of loading Smalltalk modules packaged in ics to reduce the memory needs on your machines, when running several images concurrently.

We are working here on a project in .NET and native thread management introduces lots of problems and makes debugging very, very difficult. We more and more come to the conclusing, that even in our project we change the code in a way to put all data together for the thread and then let the thread run on that data and it returns another data structure, which can then be used in the "main" thread.

Actually we have perhaps a pretty good framework, which could be used for that: SST with its distributed features ... perhaps it would be possible to increase the speed by adding shared memory as transportation media ...

How about putting the GDK framework into the product. It uses SST and gives a nice interface to develop a distributed system in VA Smallalk. I used it at several car plants for tracking and interacting with vehicle movements on the shop floor through the manufacturing process. Its use of well defined interfaces between systems and modules allows one to develop very scalable applications. It is not perfect, the OR mapper takes a very simplistic approach and it does not keep object identity between images.