At 3:43 PM -0800 11/14/98, Jan Bottorff wrote:
>Something that would be MUCH easier, would be to arrange for calling
>external code in a different thread. For example, you would have a pool of
>threads that were used to run slow OS calls. This would give mostly the
>same advantages as a true multithreaded VM, for single processor machines.
>It would also bypass many of the problems..................
This is a very good idea and would accomplish much of what is needed, that
is, avoiding VM blocking during "long" external calls.

>A big question is: do
>most people want multi-thread support so they can run Smalltalk compute
>intensive apps on multiple processors? Or do they just want to be able to
>make external calls without all Smalltalk processes blocking?

My gut feeling is that the latter is more important. In the past, there was
a lot of attention paid to trying to improve Smalltalk VM performance, per
se. SmalltalkAgents actually made some real progress. BUT, for many
applications (for example, scientific simulations) improved VM performance
was not the real problem. When a lot of computational data is involved,
generation and tracking of many objects is required, and this results in
major overall performance hits regardless of the VM performance. (We saw
this with Smalltalk manipulation of thousands of mesh points in 3-D
visualization.) For scientific apps the best way to use Smalltalk is for
the "intelligent interface" functions, and leave the numerically intensive
work to externals. Elimination of the Smalltalk process blocking is
essential if, for example, one wanted to do a computation in an external
process and simultaneously do some Smalltalk work on partial data returns
from the external process.

--dick peskin



=================================
R. L. Peskin,  Rutgers Univ. ; <peskin at caip.rutgers.edu>;
<http://www.caip.rutgers.edu/~peskin>
VT Phone (802) 824-4558  NJ Phone (732) 445-4208
"The corporate culture is concerned less with Occam's razor than his
aftershave lotion."