Andreas,

That is actually great news. I had absolutely no idea that the Self scheduler was implemented in Self (I had naturally assumed it was implemented in C).

Given that even their parser (what they call the part that translates source text into bytecodes) is in C++, it is natural to assume that the scheduler would be as well. But it isn't the case.

The fact that it uses the same idea is a great validation of our thoughts here ;-)

Exactly my point - it is always great to find a working example of something you are thinking of doing. Anyone wanting to do multicore work in Squeak should really watch David Ungar's talk at the OOPSLA 08 Squeak BOF, for example.

Do you by any chance know how Self performed in heavy process switch benchmarks? Has anyone ever assessed the overhead of the scheduler?

I think my friend's PhD project was probably the application which stressed the scheduler the most, but I don't think he made any measurements. Note that with the adaptive compilation technology, it probably was no slower than a VM based scheduler. But I think it is likely that it wasn't a hotspot and so the good compiler never got to it, in which case the performance didn't matter.

Normal Self applications are based on Morphic and tend to be single threaded. Given that Self doesn't have exception handling, for every pass through the world redraw code a background thread was started up to detect when the drawing logic go into an infinite loop. That would be some 30 new threads being created and destroyed per second (normally doing nothing but waiting for a timeout). I imagine we would need at least a hundred times that before the scheduler performance would have a significant effect.

-- Jecel