[Vm-dev] RoarVM: The Manycore SqueakVM

ungar at mac.com ungar at mac.com
Fri Nov 5 04:09:02 UTC 2010


On performance: we have done very little to tune it. Please feel free to pitch in! I suspect you might find some tasty, low-hanging fruit.

- David


On Nov 4, 2010, at 1:49 PM, Bert Freudenberg wrote:

> 
> On 04.11.2010, at 21:18, Stefan Marr wrote:
> 
>> Hi Bert:
>> 
>> On 04 Nov 2010, at 20:20, Bert Freudenberg wrote:
>> 
>>>>> 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.
> 
> Wait. What do you mean by "current version" vs. "our version"?
> 
>>>> 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 ...
>> Do you know some numbers for the switch/case-based vs. the threaded version on the standard VM?
>> How much do you typically gain by it? 
> 
> I don't really remember but it was well below 50%, more like 10%-20% I think.
> 
>> One thing I forgot to mentioned in this context, it the object table we use.
>> That is also something which is not exactly making the VM faster.
> 
> Ah, yes. That could make quite a difference. You wouldn't be calling a function for each object access though I hope?
> 
>>>>> 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.
>> 
>> Closing the window, how does that relate to processes? You mean a window inside the image?
>> Per se, processes are not really owned or managed, so there is also nobody kill processes. However, I am not sure what you are referring to exactly.  
> 
> The X11 window.
> 
>> Ctrl-C doesn't work, that's true.
>> However, closing the X11 window usually does the trick ;)
> 
> Well, it didn't. At least not immediately. Took several seconds ad ctrl-c's untill I got my prompt back.
> 
>>>>> 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 ...
>> Ok, several seconds, hm. That does not really sound like the GC pauses I see.
>> But I haven't used the Squeak image a lot myself on the RoarVM.
>> I was more thinking in the direction of what kind of tricks are currently pulled to make things fast.
>> Perhaps, the X11 interface is already not the fastest compared to the standard approach, or there are some plugins in the VM which help performance but aren't included in RoarVM yet. I have never looked at the Squeak VM code myself, so I don't know a lot about what is actually done there.
>> 
>> Best regards
>> Stefan
> 
> I guess some profiling is in order ...
> 
> - Bert -
> 
> 



More information about the Vm-dev mailing list