Smalltalk › Squeak › Squeak - Dev

Squeak on a cellphone may need better blocking behavior

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

9 messages Options

Tony Garnock-Jones-5

Squeak on a cellphone may need better blocking behavior

It occurs to me that to get better power efficiency, Squeak may need to
learn how to go to sleep more often. At present it's using about a
quarter of a core on my phone when I'm not doing anything to it.

JIT could help that, I guess; but more generally, it'd be nice just not
to be awake when there's nothing pressing to do...

Tony

marcel.taeumel

Re: Squeak on a cellphone may need better blocking behavior

Hi Tony.

Can you improve the situation by tuning:

ProcessorScheduler class >> #idleProcess

WorldState >> #interCyclePause:

Best,

Marcel

Am 01.09.2020 15:50:53 schrieb Tony Garnock-Jones <[hidden email]>:
It occurs to me that to get better power efficiency, Squeak may need to
learn how to go to sleep more often. At present it's using about a
quarter of a core on my phone when I'm not doing anything to it.

JIT could help that, I guess; but more generally, it'd be nice just not
to be awake when there's nothing pressing to do...

Tony

Eliot Miranda-2

Re: Squeak on a cellphone may need better blocking behavior

In reply to this post by Tony Garnock-Jones-5

Hi Tony,

> On Sep 1, 2020, at 6:50 AM, Tony Garnock-Jones <[hidden email]> wrote:
>
> It occurs to me that to get better power efficiency, Squeak may need to
> learn how to go to sleep more often. At present it's using about a
> quarter of a core on my phone when I'm not doing anything to it.
>
> JIT could help that, I guess; but more generally, it'd be nice just not
> to be awake when there's nothing pressing to do...

The solution is a modified event architecture and jettisoning relinquishProcessorForMilliseconds:. Search the archives (squeak-dev & vm-dev) for “event driven vm”. This is work that should have been done a long time ago (I did this for the VisualWorks vm back at the turn of the century or thereabouts). But it isn’t going to get done unless someone steps up. My input queue is full to overflowing.

> Tony

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

Eliot Miranda-2

Re: Squeak on a cellphone may need better blocking behavior

In reply to this post by marcel.taeumel

On Sep 1, 2020, at 6:55 AM, Marcel Taeumel <[hidden email]> wrote:

Hi Tony.

Can you improve the situation by tuning:

ProcessorScheduler class >> #idleProcess
WorldState >> #interCyclePause:

This will always be a hack. The right solution is to have the vm scheduler enter a wait state when there are no runnable processes and to have no background process to needlessly consume cycles. The event architecture needs to allow input events to be one of the conditions (the other being i/o in sockets files et al) that the vm waits on. This is one of the key things that is meant by the “event driven vm”.

The other thing that is meant by “event driven vm” is that the vm runs within the GUI event loop rather than the vm calling it. I’m not sure how important this is; input events seem to work just fine with what we have. So the key thing it seems to me is blocking on input (& pending output) when there is nothing to do rather than spinning a background process that calls a primitive that blocks.

Best,
Marcel

Am 01.09.2020 15:50:53 schrieb Tony Garnock-Jones <[hidden email]>:
It occurs to me that to get better power efficiency, Squeak may need to
learn how to go to sleep more often. At present it's using about a
quarter of a core on my phone when I'm not doing anything to it.

JIT could help that, I guess; but more generally, it'd be nice just not
to be awake when there's nothing pressing to do...

Tony

codefrau

Re: Squeak on a cellphone may need better blocking behavior

In reply to this post by Eliot Miranda-2

On Tue, Sep 1, 2020 at 8:36 AM Eliot Miranda <[hidden email]> wrote:

Hi Tony,

> On Sep 1, 2020, at 6:50 AM, Tony Garnock-Jones <[hidden email]> wrote:
>
> It occurs to me that to get better power efficiency, Squeak may need to
> learn how to go to sleep more often. At present it's using about a
> quarter of a core on my phone when I'm not doing anything to it.
>
> JIT could help that, I guess; but more generally, it'd be nice just not
> to be awake when there's nothing pressing to do...

The solution is a modified event architecture and jettisoning relinquishProcessorForMilliseconds:. Search the archives (squeak-dev & vm-dev) for “event driven vm”. This is work that should have been done a long time ago (I did this for the VisualWorks vm back at the turn of the century or thereabouts). But it isn’t going to get done unless someone steps up. My input queue is full to overflowing.

Not just the VM, but we would also need to modify the image to be event-driven.

A lot of Morphic code works by polling for changes in state (typically in a "step" method), rather than reacting to events. That is almost elegant in its simplicity, but rather wasteful. It was designed before power consumption became an issue we care about. Nowadays, Morphs should only be stepping if they are actively animating something without user input.

Basically, the UI process should sleep until there is an event, which could be a user event, a timer event, or some asynchronous state change (like a network package arrived, etc).

I guess Morphic can accommodate that, or it might need a larger re-design. E.g. Tweak was designed around every UI element running in a separate thread, and sleeping until there was actually something to do.

- Vanessa -

marcel.taeumel

Re: Squeak on a cellphone may need better blocking behavior

Hi all.

If one does not depend on accurate timing for animations, it would be possible to re-design WorldState >> #doOneCycle to go to sleep after each cycle, only waking up if some (unknown) delay or event triggers from another Squeak process. We could design events for Morph >> #changed and also Morphic stepping, as Vanessa explained. Maybe the stepping logic could be handled in an extra process altogether. Not sure about the Tweak approach because not sure about the scheduling efficiency when facing loads (!) of Squeak processes. :-)

User input is -- basically -- event-driven already. See EventSensor >> #eventTickler, #nextEvent and HandMorph >> #processEvent. There is just a "polling layer" on top of it to make it compatible with the Morphic main loop (i.e. #doOneCycle). If that event-tickler process would still consume too much CPU time, there is a rough sketch of an "inputSemaphore" in the image. See EventSensor >> #primSetInputSemaphore:. However, one would have to double-check the VM code whether that semaphore is signaled in all cases on all platforms. Then, even the event-tickler process could avoid the use of a fixed delay. Then, the VM would tell the image when it is time to call #primGetNextEvent:. No unnecessary polling.

Best,

Marcel

Am 02.09.2020 03:28:11 schrieb Vanessa Freudenberg <[hidden email]>:

On Tue, Sep 1, 2020 at 8:36 AM Eliot Miranda <[hidden email]> wrote:
Hi Tony,

> On Sep 1, 2020, at 6:50 AM, Tony Garnock-Jones <[hidden email]> wrote:
>
> It occurs to me that to get better power efficiency, Squeak may need to
> learn how to go to sleep more often. At present it's using about a
> quarter of a core on my phone when I'm not doing anything to it.
>
> JIT could help that, I guess; but more generally, it'd be nice just not
> to be awake when there's nothing pressing to do...

The solution is a modified event architecture and jettisoning relinquishProcessorForMilliseconds:. Search the archives (squeak-dev & vm-dev) for “event driven vm”. This is work that should have been done a long time ago (I did this for the VisualWorks vm back at the turn of the century or thereabouts). But it isn’t going to get done unless someone steps up. My input queue is full to overflowing.

Not just the VM, but we would also need to modify the image to be event-driven.

A lot of Morphic code works by polling for changes in state (typically in a "step" method), rather than reacting to events. That is almost elegant in its simplicity, but rather wasteful. It was designed before power consumption became an issue we care about. Nowadays, Morphs should only be stepping if they are actively animating something without user input.

Basically, the UI process should sleep until there is an event, which could be a user event, a timer event, or some asynchronous state change (like a network package arrived, etc).

I guess Morphic can accommodate that, or it might need a larger re-design. E.g. Tweak was designed around every UI element running in a separate thread, and sleeping until there was actually something to do.

- Vanessa -

Stéphane Rollandin

Re: Squeak on a cellphone may need better blocking behavior

>
> If one does not depend on accurate timing for animations,

That's a big 'if'. I certainly desire the most accurate timing for
animations (and also for everything else...)

Stef

Yoshiki Ohshima-3

Re: Squeak on a cellphone may need better blocking behavior

In reply to this post by codefrau

Besides Tweak, I have some recollection that Andreas was making the Android VM that was requires to be event-driven, and in turn making a Morphic image event-driven. Does anybody know how it went?

On Tue, Sep 1, 2020 at 6:28 PM Vanessa Freudenberg <[hidden email]> wrote:

On Tue, Sep 1, 2020 at 8:36 AM Eliot Miranda <[hidden email]> wrote:
Hi Tony,

> On Sep 1, 2020, at 6:50 AM, Tony Garnock-Jones <[hidden email]> wrote:
>
> It occurs to me that to get better power efficiency, Squeak may need to
> learn how to go to sleep more often. At present it's using about a
> quarter of a core on my phone when I'm not doing anything to it.
>
> JIT could help that, I guess; but more generally, it'd be nice just not
> to be awake when there's nothing pressing to do...

The solution is a modified event architecture and jettisoning relinquishProcessorForMilliseconds:. Search the archives (squeak-dev & vm-dev) for “event driven vm”. This is work that should have been done a long time ago (I did this for the VisualWorks vm back at the turn of the century or thereabouts). But it isn’t going to get done unless someone steps up. My input queue is full to overflowing.

Not just the VM, but we would also need to modify the image to be event-driven.

A lot of Morphic code works by polling for changes in state (typically in a "step" method), rather than reacting to events. That is almost elegant in its simplicity, but rather wasteful. It was designed before power consumption became an issue we care about. Nowadays, Morphs should only be stepping if they are actively animating something without user input.

Basically, the UI process should sleep until there is an event, which could be a user event, a timer event, or some asynchronous state change (like a network package arrived, etc).

I guess Morphic can accommodate that, or it might need a larger re-design. E.g. Tweak was designed around every UI element running in a separate thread, and sleeping until there was actually something to do.

- Vanessa -

-- Yoshiki

David T. Lewis

Re: Squeak on a cellphone may need better blocking behavior

On Wed, Sep 02, 2020 at 07:58:46AM -0700, Yoshiki Ohshima wrote:
> Besides Tweak, I have some recollection that Andreas was making the Android
> VM that was requires to be event-driven, and in turn making a Morphic image
> event-driven. Does anybody know how it went?
>

Anreas' event-driven Android VM was successful. I had it installed on my
phone for several years. I think that it was downloaded from the Google Play
Store, but is no longer available there.

Ian provides a pointer to archived information and code http://squeakvm.org/

By "successful" I mean that the event-driven VM worked, and it was able to
run an image on my phone. I do not recall any issues with CPU consumption,
although I do not remember looking for that as an issue. In any case, it
ran on my phone with no obvious problems that I could notice.

It was clear that a good deal of work would be required in order make Squeak
itself usable on a device with no real keyboard or mouse.

Dave

> On Tue, Sep 1, 2020 at 6:28 PM Vanessa Freudenberg <[hidden email]>
> wrote:
>
> > On Tue, Sep 1, 2020 at 8:36 AM Eliot Miranda <[hidden email]>
> > wrote:
> >
> >> Hi Tony,
> >>
> >>
> >> > On Sep 1, 2020, at 6:50 AM, Tony Garnock-Jones <
> >> [hidden email]> wrote:
> >> >
> >> > ???It occurs to me that to get better power efficiency, Squeak may need to
> >> > learn how to go to sleep more often. At present it's using about a
> >> > quarter of a core on my phone when I'm not doing anything to it.
> >> >
> >> > JIT could help that, I guess; but more generally, it'd be nice just not
> >> > to be awake when there's nothing pressing to do...
> >>
> >> The solution is a modified event architecture and jettisoning
> >> relinquishProcessorForMilliseconds:. Search the archives (squeak-dev &
> >> vm-dev) for ???event driven vm???. This is work that should have been done a
> >> long time ago (I did this for the VisualWorks vm back at the turn of the
> >> century or thereabouts). But it isn???t going to get done unless someone
> >> steps up. My input queue is full to overflowing.
> >>
> >
> > Not just the VM, but we would also need to modify the image to be
> > event-driven.
> >
> > A lot of Morphic code works by polling for changes in state (typically in
> > a "step" method), rather than reacting to events. That is almost elegant in
> > its simplicity, but rather wasteful. It was designed before power
> > consumption became an issue we care about. Nowadays, Morphs should only be
> > stepping if they are actively animating something without user input.
> >
> > Basically, the UI process should sleep until there is an event, which
> > could be a user event, a timer event, or some asynchronous state change
> > (like a network package arrived, etc).
> >
> > I guess Morphic can accommodate that, or it might need a larger re-design.
> > E.g. Tweak was designed around every UI element running in a separate
> > thread, and sleeping until there was actually something to do.
> >
> > - Vanessa -
> >
> >
>
> --
> -- Yoshiki