A: Yes.

This article describes how VA Smalltalk takes advantage of the underlying hardware and provides performance numbers for a real world example running on a multi-core machine.

Multi-processor and multi-core machines have become increasingly common, and, while the VM itself does not take advantage of multiple cores or CPUs itself, VA Smalltalk interactions with the operating system do leverage all the resources of the underlying hardware. Computation-intensive applications which do not interact with the operating system during the computation will continue to work, but the computation will not occur on multiple platforms and so will not proceed more quickly on a multi-core machine.

The VA Smalltalk VM is designed to support an internal multitasking model for efficiently forking parallel processes without incurring the significantly higher overhead of OS calls. This approach still permits great flexibility in multitasked processing with much higher overall performance than that dependent upon an underlying OS for scheduling. The underlying OS will still schedule other OS calls and operations such as database queries in parallel. However, this model does not explicitly support putting multiple Smalltalk processes within a single runtime image on multiple processors. In reality this is not a concern.

Among the components of an application, the VM makes fewer demands on the underlying hardware than the database calls, transaction processing and other operating system calls. The VM is light weight enough that it will not overwhelm the resources of the core on which it runs. Because VA Smalltalk does make system calls in such a way that the operating system routes the call to other cores whose CPUs are less utilized, the net result is a VA Smalltalk application which realizes the performance benefits promised by multi-core architecture. The underlying OS will automatically schedule VA Smalltalk onto one processor/core while automatically loading up the other available processors to run associated OS calls, other middleware and database queries. The net result is that the underlying Smalltalk based application is more efficient at handling applications with multiple processes and the overall utilization of a multiprocessor system is typically NOT constrained by the VA Smalltalk application.

A case in point is a mission critical Smalltalk based medical application which has been running without a flaw for years on Dual XEON processor based Dell servers. This application was built using VisualAge 6.0.2, but similar results can be expected for all VA Smalltalk versions. It makes use of the WebConnect feature of the product and interacts with DB2 and WebSphere.

To illustrate CPU utilization, this application was run on the following configuration:

The tester exercised the application repeatedly requesting new web pages from the server which resulted in forms being pulled up from the database and placed in web pages using WebConnect. Database requests were made via SQL calls.

Figures 1 and 2 show CPU usage under these conditions. It supports the statement that, although the packaged runtime will only take advantage of one core, other activities such as operating system and database calls are automatically routed onto less utilized cores so that all four cores are noticeably utilized. In Figure 1 the task manager shows the CPU usage.

Please note that the Task Manager is consistently showing almost no activity at ~0-1%. What little activity is showing up, is the same whether or not the WebConnect application is being exercised or not. Normal OS function calls like printing a document or a periodic DB2 table replication are several orders of magnitude more CPU performance intensive.

The message to be gleaned from this is that VA Smalltalk WebConnect is extremely efficient at CPU utilization.

Figure 2 shows the various CPU processes sorted by CPU utilization time under the same conditions as for Figure 1.  The VAST WebConnect process is the one underlined in pink labeled abtntsrv.exe.

You can see its cumulative CPU utilization is negligible when compared to  DB2 (db2syscs.exe) and WebSphere (java.exe). The memory usage is ~10% that of WebSphere or DB2. There are so many other routine operating system tasks being spread across the multiple processor cores that WebConnect's efficiency make its affinity to one core a moot issue in real world applications. In fact its ability to efficiently fork internal tasks, in no small way contributes to this overall efficiency.

Real world VA Smalltalk 7 applications will automatically have the OS use multiple cores when available to run OS and middleware without any special programming effort on the part of the developer.  Overall performance can be expected to improve under multiprocessor/multi core hardware with an appropriate OS.