Smalltalk › Squeak › Squeak VM

Another NuScratch issue

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

16 messages Options

Yoshiki Ohshima-3

Another NuScratch issue

So I built a new VM with a fix for the input method change. I did not fully test the other things but Scratch on the VM does not do animations. It updates screen only when mouse is moved, or some slower interval:

https://photos.app.goo.gl/QHgKCeeP2bnQGESu5

I suspect that there might have been some options I needed to pass in to specify some timers? Can you think of other reasons why this might happen and where to look to fix it?

-- Yoshiki

timrowledge

Re: Another NuScratch issue

> On 2020-11-20, at 3:10 PM, Yoshiki Ohshima <[hidden email]> wrote:
>
> So I built a new VM with a fix for the input method change. I did not fully test the other things but Scratch on the VM does not do animations. It updates screen only when mouse is moved, or some slower interval:
>
> https://photos.app.goo.gl/QHgKCeeP2bnQGESu5

That's really weird. I see two systems running at the same time there - same image? Different VM?

>
> I suspect that there might have been some options I needed to pass in to specify some timers? Can you think of other reasons why this might happen and where to look to fix it?

I never had any timer related options to worry about, so it shouldn't be anything to do with that.

What happens if you use the 'new' VM but don't use the compositor/input thing? IIRC I had terrible problems caused by that ibus program and we had to make sure it didn't get into the Raspbian release.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Several nuts over fruitcake minimum.

Yoshiki Ohshima-3

Re: Another NuScratch issue

On Fri, Nov 20, 2020 at 4:50 PM tim Rowledge <[hidden email]> wrote:

> On 2020-11-20, at 3:10 PM, Yoshiki Ohshima <[hidden email]> wrote:
>
> So I built a new VM with a fix for the input method change. I did not fully test the other things but Scratch on the VM does not do animations. It updates screen only when mouse is moved, or some slower interval:
>
> https://photos.app.goo.gl/QHgKCeeP2bnQGESu5

That's really weird. I see two systems running at the same time there - same image? Different VM?

Yeah, those are running the same image on different VMs.

>
> I suspect that there might have been some options I needed to pass in to specify some timers? Can you think of other reasons why this might happen and where to look to fix it?

I never had any timer related options to worry about, so it shouldn't be anything to do with that.

What happens if you use the 'new' VM but don't use the compositor/input thing? IIRC I had terrible problems caused by that ibus program and we had to make sure it didn't get into the Raspbian release.

I'll check it out. I wasn't expecting this kind of problem and did not fully test things out.

-- Yoshiki

Yoshiki Ohshima-3

Re: Another NuScratch issue

On Fri, Nov 20, 2020 at 5:11 PM Yoshiki Ohshima <[hidden email]> wrote:

On Fri, Nov 20, 2020 at 4:50 PM tim Rowledge <[hidden email]> wrote:

> On 2020-11-20, at 3:10 PM, Yoshiki Ohshima <[hidden email]> wrote:
>
> So I built a new VM with a fix for the input method change. I did not fully test the other things but Scratch on the VM does not do animations. It updates screen only when mouse is moved, or some slower interval:
>
> https://photos.app.goo.gl/QHgKCeeP2bnQGESu5

That's really weird. I see two systems running at the same time there - same image? Different VM?

Yeah, those are running the same image on different VMs.

>
> I suspect that there might have been some options I needed to pass in to specify some timers? Can you think of other reasons why this might happen and where to look to fix it?

I never had any timer related options to worry about, so it shouldn't be anything to do with that.

What happens if you use the 'new' VM but don't use the compositor/input thing? IIRC I had terrible problems caused by that ibus program and we had to make sure it didn't get into the Raspbian release.

I'll check it out. I wasn't expecting this kind of problem and did not fully test things out.

Not having compositioninput does not fix the problem. With a non-scratch image and I run BouncingAtomsMorph, the screen update on my VM is one frame per second unless I move the mouse pointer.

Which function to obtain the current time to tell the VM to run the next event loop? I can check if it is called.

-- Yoshiki

Yoshiki Ohshima-3

Re: Another NuScratch issue

On Sat, Nov 21, 2020 at 9:32 AM Yoshiki Ohshima <[hidden email]> wrote:

On Fri, Nov 20, 2020 at 5:11 PM Yoshiki Ohshima <[hidden email]> wrote:

On Fri, Nov 20, 2020 at 4:50 PM tim Rowledge <[hidden email]> wrote:

> On 2020-11-20, at 3:10 PM, Yoshiki Ohshima <[hidden email]> wrote:
>
> So I built a new VM with a fix for the input method change. I did not fully test the other things but Scratch on the VM does not do animations. It updates screen only when mouse is moved, or some slower interval:
>
> https://photos.app.goo.gl/QHgKCeeP2bnQGESu5

That's really weird. I see two systems running at the same time there - same image? Different VM?

Yeah, those are running the same image on different VMs.

>
> I suspect that there might have been some options I needed to pass in to specify some timers? Can you think of other reasons why this might happen and where to look to fix it?

I never had any timer related options to worry about, so it shouldn't be anything to do with that.

What happens if you use the 'new' VM but don't use the compositor/input thing? IIRC I had terrible problems caused by that ibus program and we had to make sure it didn't get into the Raspbian release.

I'll check it out. I wasn't expecting this kind of problem and did not fully test things out.

Not having compositioninput does not fix the problem. With a non-scratch image and I run BouncingAtomsMorph, the screen update on my VM is one frame per second unless I move the mouse pointer.

Which function to obtain the current time to tell the VM to run the next event loop? I can check if it is called.

One datapoint is that making the argument for aioSleepForUsecs in display_ioRelinquishProcessorForMicroseconds() to be always zero:

static sqInt display_ioRelinquishProcessorForMicroseconds(sqInt microSeconds)
{
aioSleepForUsecs(handleEvents() ? 0 : 0); // aioSleepForUsecs(handleEvents() ? 0 : 1000);
return 0;

}

makes it run smoothly. So the return value from handleEvents() would have to make sense.

(still investigating..)

-- Yoshiki

Yoshiki Ohshima-3

Re: Another NuScratch issue

On Sat, Nov 21, 2020 at 9:42 AM Yoshiki Ohshima <[hidden email]> wrote:

On Sat, Nov 21, 2020 at 9:32 AM Yoshiki Ohshima <[hidden email]> wrote:

On Fri, Nov 20, 2020 at 5:11 PM Yoshiki Ohshima <[hidden email]> wrote:

On Fri, Nov 20, 2020 at 4:50 PM tim Rowledge <[hidden email]> wrote:

> On 2020-11-20, at 3:10 PM, Yoshiki Ohshima <[hidden email]> wrote:
>
> So I built a new VM with a fix for the input method change. I did not fully test the other things but Scratch on the VM does not do animations. It updates screen only when mouse is moved, or some slower interval:
>
> https://photos.app.goo.gl/QHgKCeeP2bnQGESu5

That's really weird. I see two systems running at the same time there - same image? Different VM?

Yeah, those are running the same image on different VMs.

>
> I suspect that there might have been some options I needed to pass in to specify some timers? Can you think of other reasons why this might happen and where to look to fix it?

I never had any timer related options to worry about, so it shouldn't be anything to do with that.

What happens if you use the 'new' VM but don't use the compositor/input thing? IIRC I had terrible problems caused by that ibus program and we had to make sure it didn't get into the Raspbian release.

I'll check it out. I wasn't expecting this kind of problem and did not fully test things out.

Not having compositioninput does not fix the problem. With a non-scratch image and I run BouncingAtomsMorph, the screen update on my VM is one frame per second unless I move the mouse pointer.

Which function to obtain the current time to tell the VM to run the next event loop? I can check if it is called.

One datapoint is that making the argument for aioSleepForUsecs in display_ioRelinquishProcessorForMicroseconds() to be always zero:

static sqInt display_ioRelinquishProcessorForMicroseconds(sqInt microSeconds)
{
aioSleepForUsecs(handleEvents() ? 0 : 0); // aioSleepForUsecs(handleEvents() ? 0 : 1000);
return 0;
}

makes it run smoothly. So the return value from handleEvents() would have to make sense.

(still investigating..)

So the handleEvents() looks like this:

--------------------

int handleEvents(void)
{
if (recordPendingKeys())
return 0;

if (!isConnectedToXServer || !XPending(stDisplay)) {
return !iebEmptyP();
}

while (XPending(stDisplay))
{
XEvent evt;
XNextEvent(stDisplay, &evt);
handleEvent(&evt);
}
return 1;
}

--------------------

but the part that affecting the animation performance is "return !iebEmptyP()". If I take out "!", it tells the caller that it handled an event when (?) not collected to the X server (which is a weird test) or not X event is not pending, check if the input event buffer is empty or not.

This check may be okay but needs some clarifications.

But I suspect that aioSleepForUsecs() on this platform may be sleeping given milliseconds and not microseconds. That may be consistent with the symptom of waking up at every second...

-- Yoshiki

timrowledge

Re: Another NuScratch issue

In reply to this post by Yoshiki Ohshima-3

OK, just tried this on my built-last-week ARM64 VM on a Pi 4 and BouncingAtoms happily bounce. 300 -> throttled, 3000 -> 11fps.

The code for handleEvents() in this VM is the same as you posted. Apparently (if we trust 'guthub desktop') I last downloaded any sources on Oct 16 (or as I prefer to think of it, March 230th). Maybe that provides a useful check point.

> On 2020-11-21, at 9:32 AM, Yoshiki Ohshima <[hidden email]> wrote:
>
> Not having compositioninput does not fix the problem. With a non-scratch image and I run BouncingAtomsMorph, the screen update on my VM is one frame per second unless I move the mouse pointer.

The only weirdness about my setup that might, just possibly, affect this is that my Pi are all connected to my iMac with VNC; none have local displays.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Put a lens in each ear and you've got a telescope.

Yoshiki Ohshima-3

Re: Another NuScratch issue

On Sat, Nov 21, 2020 at 11:40 AM tim Rowledge <[hidden email]> wrote:

OK, just tried this on my built-last-week ARM64 VM on a Pi 4 and BouncingAtoms happily bounce. 300 -> throttled, 3000 -> 11fps.

Ok... How about ARM32? If that makes a difference, it may be about the complex ifdefs in aioPoll() that somehow fails to capture the case.

The code for handleEvents() in this VM is the same as you posted. Apparently (if we trust 'guthub desktop') I last downloaded any sources on Oct 16 (or as I prefer to think of it, March 230th). Maybe that provides a useful check point.

> On 2020-11-21, at 9:32 AM, Yoshiki Ohshima <[hidden email]> wrote:
>
> Not having compositioninput does not fix the problem. With a non-scratch image and I run BouncingAtomsMorph, the screen update on my VM is one frame per second unless I move the mouse pointer.

The only weirdness about my setup that might, just possibly, affect this is that my Pi are all connected to my iMac with VNC; none have local displays.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Put a lens in each ear and you've got a telescope.

-- Yoshiki

Eliot Miranda-2

Re: Another NuScratch issue

In reply to this post by Yoshiki Ohshima-3

Hi Yoshiki,

Levente replaced the select code with epoll code on Linux a fey weeks ago. Maybe there’s a regression.

_,,,^..^,,,_ (phone)

On Nov 21, 2020, at 10:28 AM, Yoshiki Ohshima <[hidden email]> wrote:

On Sat, Nov 21, 2020 at 9:42 AM Yoshiki Ohshima <[hidden email]> wrote:

On Sat, Nov 21, 2020 at 9:32 AM Yoshiki Ohshima <[hidden email]> wrote:

On Fri, Nov 20, 2020 at 5:11 PM Yoshiki Ohshima <[hidden email]> wrote:

On Fri, Nov 20, 2020 at 4:50 PM tim Rowledge <[hidden email]> wrote:

> On 2020-11-20, at 3:10 PM, Yoshiki Ohshima <[hidden email]> wrote:
>
> So I built a new VM with a fix for the input method change. I did not fully test the other things but Scratch on the VM does not do animations. It updates screen only when mouse is moved, or some slower interval:
>
> https://photos.app.goo.gl/QHgKCeeP2bnQGESu5

That's really weird. I see two systems running at the same time there - same image? Different VM?

Yeah, those are running the same image on different VMs.

>
> I suspect that there might have been some options I needed to pass in to specify some timers? Can you think of other reasons why this might happen and where to look to fix it?

I never had any timer related options to worry about, so it shouldn't be anything to do with that.

What happens if you use the 'new' VM but don't use the compositor/input thing? IIRC I had terrible problems caused by that ibus program and we had to make sure it didn't get into the Raspbian release.

I'll check it out. I wasn't expecting this kind of problem and did not fully test things out.

Not having compositioninput does not fix the problem. With a non-scratch image and I run BouncingAtomsMorph, the screen update on my VM is one frame per second unless I move the mouse pointer.

Which function to obtain the current time to tell the VM to run the next event loop? I can check if it is called.

One datapoint is that making the argument for aioSleepForUsecs in display_ioRelinquishProcessorForMicroseconds() to be always zero:

static sqInt display_ioRelinquishProcessorForMicroseconds(sqInt microSeconds)
{
   aioSleepForUsecs(handleEvents() ? 0 : 0); // aioSleepForUsecs(handleEvents() ? 0 : 1000);
return 0;
}

makes it run smoothly. So the return value from handleEvents() would have to make sense.

(still investigating..)

So the handleEvents() looks like this:

--------------------
int handleEvents(void)
{
if (recordPendingKeys())
return 0;

if (!isConnectedToXServer || !XPending(stDisplay)) {
   return !iebEmptyP();
}

while (XPending(stDisplay))
{
XEvent evt;
XNextEvent(stDisplay, &evt);
handleEvent(&evt);
}
return 1;
}
--------------------
but the part that affecting the animation performance is "return !iebEmptyP()". If I take out "!", it tells the caller that it handled an event when (?) not collected to the X server (which is a weird test) or not X event is not pending, check if the input event buffer is empty or not.

This check may be okay but needs some clarifications.

But I suspect that aioSleepForUsecs() on this platform may be sleeping given milliseconds and not microseconds. That may be consistent with the symptom of waking up at every second...

--
-- Yoshiki

Levente Uzonyi

Re: Another NuScratch issue

On Sat, 21 Nov 2020, Eliot Miranda wrote:

> Hi Yoshiki,
>
> Levente replaced the select code with epoll code on Linux a fey weeks
> ago. Maybe there’s a regression.

That is indeed the culprit. epoll_wait expects the timeout in milliseconds
but the value is in microseconds. Unfortunately, fixing that brings back
the old increased cpu usage.

Levente

timrowledge

Re: Another NuScratch issue

> On 2020-11-22, at 8:50 PM, Levente Uzonyi <[hidden email]> wrote:
>
> On Sat, 21 Nov 2020, Eliot Miranda wrote:
>
>> Hi Yoshiki,
>>
>> Levente replaced the select code with epoll code on Linux a fey weeks
>> ago. Maybe there’s a regression.
>
> That is indeed the culprit. epoll_wait expects the timeout in milliseconds but the value is in microseconds. Unfortunately, fixing that brings back the old increased cpu usage.

Do we have a decent solution for this issue? It *utterly* ruins NuScratch on a Pi and I'm trying to make a new release. Won't someone please think of the children?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: ETO: Emulate Toaster Oven

Levente Uzonyi

Re: Another NuScratch issue

On Sun, 13 Dec 2020, tim Rowledge wrote:

>
>
>
>> On 2020-11-22, at 8:50 PM, Levente Uzonyi <[hidden email]> wrote:
>>
>> On Sat, 21 Nov 2020, Eliot Miranda wrote:
>>
>>> Hi Yoshiki,
>>>
>>> Levente replaced the select code with epoll code on Linux a fey weeks
>>> ago. Maybe there’s a regression.
>>
>> That is indeed the culprit. epoll_wait expects the timeout in milliseconds but the value is in microseconds. Unfortunately, fixing that brings back the old increased cpu usage.
>
> Do we have a decent solution for this issue? It *utterly* ruins NuScratch on a Pi and I'm trying to make a new release. Won't someone please think of the children?

Just pushed a fix[1]. Let me know if that works.

Levente

[1] https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/3db3888c2a76bd91ef66d70521d85f80e9d18f1d
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Strange OpCodes: ETO: Emulate Toaster Oven

Yoshiki Ohshima-3

Re: Another NuScratch issue

Thanks.

I had a workaround but was not for real. Levente's patch works for me.

On Sun, Dec 13, 2020 at 9:35 PM Levente Uzonyi <[hidden email]> wrote:

On Sun, 13 Dec 2020, tim Rowledge wrote:

>
>
>
>> On 2020-11-22, at 8:50 PM, Levente Uzonyi <[hidden email]> wrote:
>>
>> On Sat, 21 Nov 2020, Eliot Miranda wrote:
>>
>>> Hi Yoshiki,
>>>
>>> Levente replaced the select code with epoll code on Linux a fey weeks
>>> ago. Maybe there’s a regression.
>>
>> That is indeed the culprit. epoll_wait expects the timeout in milliseconds but the value is in microseconds. Unfortunately, fixing that brings back the old increased cpu usage.
>
> Do we have a decent solution for this issue? It *utterly* ruins NuScratch on a Pi and I'm trying to make a new release. Won't someone please think of the children?

Just pushed a fix[1]. Let me know if that works.

Levente

[1] https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/3db3888c2a76bd91ef66d70521d85f80e9d18f1d
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Strange OpCodes: ETO: Emulate Toaster Oven

-- Yoshiki

timrowledge

Re: Another NuScratch issue

> On 2020-12-14, at 9:31 AM, Yoshiki Ohshima <[hidden email]> wrote:
>
> Thanks.
>
> I had a workaround but was not for real. Levente's patch works for me.

It's a big improvement but there is still something making for odd hesitations in Asteroid Blaster; which is obviously one of the most important benchmarks imaginable. Probably not a VM thing though

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Earth is 98% full...please delete anyone you can.

Yoshiki Ohshima-3

Re: Another NuScratch issue

Where can I try the Asteroid Blaster? My workaround was just divide the wait time by 1000 and I'm curious to see if that has different effects on a different example.

On Mon, Dec 14, 2020 at 10:01 AM tim Rowledge <[hidden email]> wrote:

> On 2020-12-14, at 9:31 AM, Yoshiki Ohshima <[hidden email]> wrote:
>
> Thanks.
>
> I had a workaround but was not for real. Levente's patch works for me.

It's a big improvement but there is still something making for odd hesitations in Asteroid Blaster; which is obviously one of the most important benchmarks imaginable. Probably not a VM thing though

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Earth is 98% full...please delete anyone you can.

-- Yoshiki

Yoshiki Ohshima-3

Re: Another NuScratch issue

I finally dug up the Asteroid Blaster project (thanks to Abe-san) and tried it on the last VM built from the head of Cog branch. I cannot tell the "odd hesitation", Is there something else I should check?

On Fri, Dec 18, 2020 at 10:44 AM Yoshiki Ohshima <[hidden email]> wrote:

Where can I try the Asteroid Blaster? My workaround was just divide the wait time by 1000 and I'm curious to see if that has different effects on a different example.

On Mon, Dec 14, 2020 at 10:01 AM tim Rowledge <[hidden email]> wrote:

> On 2020-12-14, at 9:31 AM, Yoshiki Ohshima <[hidden email]> wrote:
>
> Thanks.
>
> I had a workaround but was not for real. Levente's patch works for me.

It's a big improvement but there is still something making for odd hesitations in Asteroid Blaster; which is obviously one of the most important benchmarks imaginable. Probably not a VM thing though

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Earth is 98% full...please delete anyone you can.

--
-- Yoshiki

-- Yoshiki