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
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 tonyg@leastfixedpoint.com: 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
On Sep 1, 2020, at 6:55 AM, Marcel Taeumel marcel.taeumel@hpi.de 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 tonyg@leastfixedpoint.com:
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
Hi Tony,
On Sep 1, 2020, at 6:50 AM, Tony Garnock-Jones tonyg@leastfixedpoint.com 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)
On Tue, Sep 1, 2020 at 8:36 AM Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Tony,
On Sep 1, 2020, at 6:50 AM, Tony Garnock-Jones <
tonyg@leastfixedpoint.com> 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 -
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 vanessa@codefrau.net: On Tue, Sep 1, 2020 at 8:36 AM Eliot Miranda <eliot.miranda@gmail.com [mailto:eliot.miranda@gmail.com]> wrote:
Hi Tony,
On Sep 1, 2020, at 6:50 AM, Tony Garnock-Jones <tonyg@leastfixedpoint.com [mailto:tonyg@leastfixedpoint.com]> 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 -
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 vanessa@codefrau.net wrote:
On Tue, Sep 1, 2020 at 8:36 AM Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Tony,
On Sep 1, 2020, at 6:50 AM, Tony Garnock-Jones <
tonyg@leastfixedpoint.com> 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 -
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 vanessa@codefrau.net wrote:
On Tue, Sep 1, 2020 at 8:36 AM Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Tony,
On Sep 1, 2020, at 6:50 AM, Tony Garnock-Jones <
tonyg@leastfixedpoint.com> 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
squeak-dev@lists.squeakfoundation.org
-
David T. Lewis -
Eliot Miranda -
Marcel Taeumel -
Stéphane Rollandin -
Tony Garnock-Jones -
Vanessa Freudenberg -
Yoshiki Ohshima