Multiple OS Threads

Are there any plans for future releases to enhance the VM to support
multiple OS threads? I know it has a lot of implications for a Smalltalk
system to support this.

I want multiple OS threads to do number crunching. A typical problem takes a
minute to solve, and is very easy to parallelize.

Runar Jordahl wrote:

> I want multiple OS threads to do number crunching. A typical problem
> takes a minute to solve, and is very easy to parallelize.

If you are doing number crunching, and especially if you are crunching floating
point numbers, then you'll almost certainly be best off if you move the bulk of
the calculations into a DLL written in C, C++, or even Fortran.  The gains of
doing that would probably be in the order of 10x to 100x (in my limited
experience), which is a lot more than you will get by splitting a calculation
across a small number of CPUs (unless, of course, you have /lots/ of CPUs --
and if you do then I /hate/ you ;-).

Once you've created your DLL you can fork as many OS threads as you like from
within it.  Or, more easily, if you can split the problem up at the Smalltalk
level (and it sounds as if you can) then you can induce Dolphin to start an OS
thread for each the sub-calculation by:
    a) running each sub-calculation in a separate Dolphin Process;
and:
    b) marking the external call(s) to the DLL 'overlapped'.
When Dolphin executes an overlapped external call, it starts a new OS thread to
execute it, and then blocks only the calling Process while it waits for that to
complete, leaving any other Processes free to run.  So you can use that to
"fork off" external calculations in OS threads.  BTW, Dolphin uses a thread
pool, so starting a new OS thread isn't too expensive.

Not all arithmetic-intensive tasks are easy to translate into a DLL, of course,
but often number crunching is just rather simple nested array manipulations and
loops -- which may even be easier to write in a language like C than in
Smalltalk.  And you don't have to translate all of your algorithm into C.  It's
true that the fewer external calls there are, the less the overhead of crossing
the Smalltalk/C threshold, but that overhead is pretty small in Dolphin, and so
you can split out rather small chunks of code into the DLL (just the inner
loops, say) and still see significant benefits.

    -- chris

Runar,

> Are there any plans for future releases to enhance the VM to support
> multiple OS threads? I know it has a lot of implications for a
> Smalltalk system to support this.

No, we don't have any plans to enable native threading. As you say,
there would be a lot of implications to this; I think, overall,
performance would suffer and there is also the problem of there being a
limit to the number of OS threads that can be created quickly versus
"green" processes. I believe that James Robertson's blog has covered
this several times in the past.

best regards,

--
Andy Bower
Dolphin Support
www.object-arts.com

Runar,

> Are there any plans for future releases to enhance the VM to support
> multiple OS threads? I know it has a lot of implications for a Smalltalk
> system to support this.
>
> I want multiple OS threads to do number crunching. A typical problem takes a
> minute to solve, and is very easy to parallelize.

I agree with Chris that a C/C++ DLL is probably your best bet.  Note
that in C++, you can define functions as extern "C" to prevent name
mangling, but that you can still use all the C++ constructs you want
inside the method.  As an example, you can use templated array classes
that wrap pointers and sizes passed as arguments, classes for complex
numbers, etc.  You can't pass references in the extern "C" functions,
but you can call C++ functions that use them from these functions.

Here's an example that might help; a gem from the school of hard knocks.
  I once did all kinds of memory management, strcpy(), poiner arithmetic
etc., before realizing that all I needed to do was instantiate a String
class in C-callable DLL.

The mix of Smalltalk for logic control and C++ for numerics with
operator overloading, precedence, speed (emphasis on the latter) is a
win-win.

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]