[Vm-dev] RoarVM: The Manycore SqueakVM

Bert Freudenberg bert at freudenbergs.de
Thu Nov 4 19:20:13 UTC 2010

On 04.11.2010, at 19:36, Stefan Marr wrote:

> On 04 Nov 2010, at 19:07, Bert Freudenberg wrote:
>> So it looks like you have to use a power-of-two cores?
> Yes, that is right. At the moment, the system isn't able to handle other numbers of cores.
>> And the benchmark invocation should be different if you want to actually use multiple cores. What's the magic incantation?
> The code I used to generate the numbers isn't actually in any image yet.
> I pasted it below for reference, its just a quick hack to have a parallel tinyBenchmarks version.
>> So RoarVM is about 4 times slower in sends, even more so for bytecodes. It needs 8 cores to be faster the regular interpreter on a single core. To the good news is that it can beat the old interpreter :)  But why is it so much slower than the normal interpreter?
> Well, one the one hand, we don't use stuff like the GCC label-as-value extension to have threaded-interpretation, which should help quite a bit.
> Then, the current implementation based on pthreads is quite a bit slower then our version which uses plain Unix processes.
> The GC is really not state of the art.
> And all that adds up rather quickly I suppose...

Hmm, that doesn't sound like it should make it 4x slower ...

>> Btw, user interrupt didn't work on the Mac. 
> Cmd+. ? Works for me ;) Well, can you be a bit more specific? In which situation did it not work?

I was doing the equivalent of

	SharedQueue new next

and that seems not interruptable. Also, when there are multiple processes, closing the window does not quit all processes, and even ctrl-c did not quit the VM.

>> And in the Squeak-4.1 image, when running on 2 or more cores Morphic gets incredibly sluggish, pretty much unusably so.
> Yes, same here. Sorry. Any hints where to start looking to fix such issues are appreciated.

Hmm. There are long freezes of many seconds and I would have no idea where to start even ...

- Bert -

More information about the Vm-dev mailing list