On 23/10/2007, Klaus D. Witzel klaus.witzel@cobss.com wrote:
On Mon, 22 Oct 2007 19:10:49 +0200, Igor Stasenko wrote:
On 22/10/2007, Klaus D. Witzel wrote:
Not only slow-down :( For an example, have a look at the implementor of #debug:title:full: in class Process, where thisContext is assigned to a variable.
When #ifTrue:ifFalse: is really sent, ([thisContext] class) is BlockContext *and* its sender is nil so the test for #hasContext: in the next statement fails.
I think this is because of optimization. For BlockContext a sender should be a context of method #ifTrue:ifFalse: (which sends #value to block). But compiler never creates such context due to optimization. In this case, since compiler 'cuts' the #ifTrue:ifFalse: out, then a correct context, i think, should be a sender of #ifTrue:ifFalse?? but not nil.
But Squeak's compiler [usually] doesn't emit code for sending #ifTrue:ifFalse: so ([thisContext] class) is MethodContext and #hasContext: doesn't fail (in this example).
Then the only way how we could regain this loss is to use highly parallelisable algorithms.
... which can be employed regardless of 'erlangenization' :)
A trivial code comes in mind:
(1 to: 1000) do: [:i | [ aBlock value:i ] fork ]
but this leads to burden our parallel processes with scheduling. I would like, instead, to be able to run a number of parallel branches for same process (to schedule a process instead each of these branches).
(1 to: 1000) doInParallel: [:i | aBlock value ]
I really don't like adding another abstraction like Thread, in addition to Process. Maybe we should stick with a Process and have a subclass of it, like ProcessNoScheduling.
I think that the present multi-core CPU thread would benefit from having a look at what other people achieved in this area, I mean people who bet their whole carreer on optimizing resource allocation and resource scheduling, like for example this one
Scalability of Microkernel-Based Systems
(just skip the few pages in German, the paper is in English)
And one shouldn't care about that L4 folks are mainly concerned with OS components since that are objects like any other :) They [L4 folks] have minimalistic number of concepts and tough, very tough requirement definitions which have to be matched with reality ;-)
But, the way I understand the present multi-core CPU thread, Squeak people aim to save the multi-core processing world by reinventing it :-D
Of course not. I have read somewhere a description of system which uses such 'micro-kernel' architecture in mind. A system divided in parts which communicate by establishing a 'contracts' - some kind of agreement between system parts on protocols and security.
A Multi-Core CPU's working in parallel by having own 'private' memory (cache) and shared memory. Why then VM can't do the same? All we need to do, is to put this in use.
I'm just thinking, in what ways we can avoid excessive scheduling/preempting?
I think that you can find answers to this [with benchmarks and, comparisions also at the conceptual level] in the abovementioned paper :)
Or maybe, by following road of 'erlangisation' we should make a Process more lightweight, so spawning thousands of them will not cause a speed degradation.
But it will. There are hidden constants associated with our present understanding of massive parallelism (you mentioned the cost of resource allocation and resource scheduling, add to that that messages can get lost, non-local updates for keeping the system viable, etc).
And you have to find problems which can be solved with massive parallel threads/processes ;-)
/Klaus