[Vm-dev] Re: RoarVM: The Manycore SqueakVM

Stefan Marr squeak at stefan-marr.de
Wed Nov 3 17:11:30 UTC 2010

Hi Yanni:

On 03 Nov 2010, at 17:45, Yanni Chiu wrote:

> On 03/11/10 9:13 AM, Stefan Marr wrote:
>> A small teaser:
>>   1 core   66286897 bytecodes/sec;  2910474 sends/sec
>>   8 cores 470588235 bytecodes/sec; 19825677 sends/sec
> I'm trying to understand what is meant by this benchmark. How does tinyBenchmarks get run on 8 cores. How does the work get distributed among the cores. But I cannot find the answer quickly - see below.
It is an adapted version of the tinyBenchmarks.
I will make the code available soonish...

Anyway, the idea is that the benchmark is started n-times in n-Smalltalk processes.
Then the overall time for execution is measured. If actually more cores are scheduling the started processes for execution, you will see the increase above. Otherwise, you just see your normal sequential performance.

>> For more detailed information, please refer to the README file[3].
> The links take you to the ACM portal. One promising link on the portal:
>    DLS '09 Proceedings of the 5th symposium on Dynamic languages
> is a dead link to HPI (www.uni-potsdam.de). I doubt I want to subscribe to ACM portal at this point, just to find out more about RoarVM. And, given that ACM portal is the only place to find out more, I doubt I'm going to look at RoarVM for any more than the brief glance through the github source that I've already done.
I am sorry that there is a pay-wall, however, I can't really do anything about it...
But, you can always ask the authors of a particular paper to give you a copy, I suppose.

So, the question is how the work gets distributed?
Well, like in Multiprocessor Smalltalk:

You have one scheduler, like in a standard image, it is only slightly adapted to accommodate the fact that there can be more than one activeProcess (See http://github.com/smarr/RoarVM/raw/master/image.st/RVM-multicore-support.mvc.st).

Once a core gets to a point where it needs to revaluate its scheduling decision, it goes to the central scheduler and picks a process to execute it.
Nothing fancy here, no sophisticated work stealing or distribution process.

Does that answer your question?

Best regards

Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
Phone: +32 2 629 2974
Fax:   +32 2 629 3525

More information about the Vm-dev mailing list