>
> 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 -
>
>