Posted by
Bert Freudenberg on
Nov 04, 2010; 8:49pm
URL: https://forum.world.st/RoarVM-The-Manycore-SqueakVM-tp3025321p3027754.html
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 -