On Thursday 18 October 2007 10:58 pm, Peter William Lount wrote:
I propose that any distributed object messaging system that is developed for inter-image communication meet a wide range of criteria and application needs before being considered as a part of the upcoming next Smalltalk Standard. These criteria would need to be elucidated from the literature and the needs of members of the Smalltalk community and their clients.
- It's been mentioned that it would be straightforward to have squeak
start up multiple copies of the image (or even multiple different images) in one process (task) memory space with each image having it's own native thread and keeping it's object table and memory separate within the larger memory space. This sounds like a very nice approach.
I am not so sure. Squeak VM is a processor hog. Threads within VM will need processor for bytecode interpretation. So a VM process can only scale to a few threads before it starves for processor. On the downside, coding errors could trash object memory across threads making testing and debugging difficult. Will the juice be worth the squeeze?
- A single image running on N-cores with M-native threads (M may be
larger than N) is the full generalization of course. This may be the best way to take advantage of paradigm shaking chips such as the Tile64 processor from Tilera.
With single or few processors, we tend to "serialize" logic ourselves and create huge linear programs. When processors are aplenty, we are free to exploit inherent parallelism and create many small co-ordinating programs. So the N-cores are a problem only for small N (around 8).
However, we may need to rethink the entire architecture of the Smalltalk virtual machine notions since the Tile 64 chip has capabilities that radically alter the paradigm. Messages between processor nodes take less time to pass between nodes then the same amount of data takes to be written into memory. Think about that. It offers a new paradigm unavailable to other N-Core processors (at this current time).
True. Squeak's VM could virtualize display/sensors and spawn each project in its own background process bound to a specific processor. The high-speed, low latency paths are well-suited for UI events. Imagine running different projects on each face of a rotating hexecontahedron :-).
Subbu