From: "Stephen Pair" spair@advantive.com Subject: RE: [ENH] Empty return expression Date: Mon, 27 Sep 1999 20:08:12 -0400
<big snip>
And, InstructionStreams are really the fundamental unit of processing and should take much of the responsibility currently held in Process. Especially when considering how one would architect a Squeak that takes advantage of multi-processor CPUs.
Is such work underway? My intuition tells me that this would be related to implementation of a Smalltalk which would be multithreaded on a single CPU (which would be great).
-Carl
______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com
And, InstructionStreams are really the fundamental unit of processing and should take much of the responsibility currently held in Process. Especially when considering how one would architect a Squeak that takes advantage of multi-processor CPUs.
Is such work underway? My intuition tells me that this would be related to implementation of a Smalltalk which would be multithreaded on a single CPU (which would be great).
Not that I am aware. Making Smalltalk multi-threaded is tricky. Some Smalltalks have taken the approach of making the "Process" concept in Smalltalk equate one-for-one with OS threads. I think that approach is very bad. First, it's difficult to implement, and second, it's inefficient because you have the additional overhead of the OS context switching.
There should never be any more OS threads executing Smalltalk than the number of microprocessors in the system. Any more is simply a waste and will slow down the system (note, having the VM maintain extra threads for things like disk and socket IO or external calls is a different issue).
The concept of a Process is closely related to the synchronous messaging that is currently the default in Smalltalk. If you move to a totally asynchronous messaging system, the concept of a Process needs to the re-thought. Essentially what you have is one process per method context. Providing an answer from a method (and then sending a message to that answer) becomes the primary synchronization mechanism.
Moving to a totally asynchronous system on a single processor would likely be much less efficient than the current synchronous scheme (of course, it could also be possible to optimize things in such a way that it wouldn't be much less efficient). However, if you imagine having 1000 processors on a single chip at your disposal, perhaps the completely asynchronous messaging scheme is the only way to go.
So, what's needed is a way to have more control over scheduling the method contexts on processors directly from Smalltalk. It might be possible using OS threads, but it might be a lot easier with more direct control that you would get by running Squeak without an underlying OS.
Multi-processor chips are not too far off in the future. It would be really cool if Squeak were one of the first systems to be able to take advantage of them.
- Stephen
Stephen Pair wrote:
And, InstructionStreams are really the fundamental unit of processing and should take much of the responsibility currently held in Process. Especially when considering how one would architect a Squeak that takes advantage of multi-processor CPUs.
Is such work underway? My intuition tells me that this would be related to implementation of a Smalltalk which would be multithreaded on a single CPU (which would be great).
Not that I am aware. Making Smalltalk multi-threaded is tricky. Some Smalltalks have taken the approach of making the "Process" concept in Smalltalk equate one-for-one with OS threads. I think that approach is very bad. First, it's difficult to implement, and second, it's inefficient because you have the additional overhead of the OS context switching.
<more good thots snipped>
I agree with Stephen. I do not think that just making all Smalltalk processes map 1:1 with OS threads is a good idea. The Smalltalk virtual machine is conceptually a single processor machine. Note the presence of one instance of Processor. Where I would like the line to be drawn is in the Processor class. IOW, if you really want two or more OS threads, you create an instance of Processor for each one. If you have a multi-processor machine, then you can create one Processor object which has an underlying VM OS thread per to run on each physical processor. But you can pretend you're a multiprocessor machine on any OS that supports OS threads.
In short, I'm not arguing for or against using OS threads, but rather trying to make a case that the correct association to make is between OS threads and instances of Processor (not Process).
-- Travis Griggs (a.k.a. Lord of the Fries) Member, Fravenic Skreiggser Software Collective Key Technology P-P-P-Penguin Power!
squeak-dev@lists.squeakfoundation.org
-
Carl Gundel -
Stephen Pair -
Travis Griggs