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
- http://l4ka.org/publications/2005/uhlig_phd-thesis_scalability.pdf
(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

> 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

>
>