On Thu, Oct 24, 2013 at 4:25 PM, John McIntosh < johnmci@smalltalkconsulting.com> wrote:

Must not hit enter...

relinquishProcessorForMicroseconds may or may not one has to find the actual code and maybe it is platform dependent etc etc.

An attempt was made to ask the VM what the next wakeup time is. The VM actually knows this it's the bottom end of the Delay logic. We then sleep to this tick, using a call that should awake the process if an BSD interrupt (ill defined) arrives.

In here we also service socket handles etc and oh maybe some other house keeping.

Still the objective was to sleep until we have to wake up for Morphics 50 times a second poll, or some UI/socket/interrupt arrives.

But the objective should be to sleep until theres' something to do: - i/o is possible - a delay has expired - a callback from some other thread has occurred (if the VM is multi-threaded) Otherwise it should block forever.

This "pause for a little while" is bogus.

In practice there are some artifacts like the Scheduler saying go to sleep but awake -2 milliseconds ago because of some race condition with in the Delay logic. (good luck finding that)...

On Thu, Oct 24, 2013 at 7:18 PM, John McIntosh < johnmci@smalltalkconsulting.com> wrote:

...

Well let me reflect. Nothing has changed, the VM energy sapping field is the same as yesterday, just more evident.

I wasn't able to determine what code base is used, but if I go back 5 or 10 years.

(a) The morphic event polling cycle runs 50 times a second. One could write some timer consolidation code there to consider when do I have to wake up and paint all those morphs? No C/Objective-C/assembler/fortran required...

(b) Maybe the VMs are event driven now and Morphic does not need to poll 50 times a second?

(c) The BSD Unix socket system requires polling of some form. But see work by Craig 10-15 back on "Flow"

(d) When all the Smalltalk Processes settle, the dispatcher runs the lowest priority task which calls relinquishProcessorForMicroseconds with a bogus value.

On Thu, Oct 24, 2013 at 6:21 PM, tim Rowledge tim@rowledge.org wrote:

...

Looking through some of the low-level changes in Mavericks I noticed stuff about timer consolidation. I *think* that it is something that you can offer to allow, rather than something done unto you code, but almost certainly it will have some sort of impact on the heartbeat ticker type of code used in stackvm/cog. Where is a skilled Mac vm maintainer when you need one?

tim

tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "bOtHeR" said Pooh, mistaking the LSD tablet for aspirin

--

=========================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. Twitter: squeaker68882

===========================================================================

--

John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. Twitter: squeaker68882 ===========================================================================

On 25 October 2013 01:18, John McIntosh johnmci@smalltalkconsulting.comwrote:

Well let me reflect. Nothing has changed, the VM energy sapping field is the same as yesterday, just more evident.

I wasn't able to determine what code base is used, but if I go back 5 or 10 years.

(a) The morphic event polling cycle runs 50 times a second. One could write some timer consolidation code there to consider when do I have to wake up and paint all those morphs? No C/Objective-C/assembler/fortran required...

(b) Maybe the VMs are event driven now and Morphic does not need to poll 50 times a second?

(c) The BSD Unix socket system requires polling of some form. But see work by Craig 10-15 back on "Flow"

(d) When all the Smalltalk Processes settle, the dispatcher runs the lowest priority task which calls relinquishProcessorForMicroseconds with a bogus value.

(e) Cog uses heartbeat timer to interrupt interpreter at regular time periods what can be done, i think it to suppress heartbeat, during relinquishProcessorForMicroseconds execution. but that won't buy much, unless we increase the time period to sleep to be times larger than heartbeat cycle (both are 1ms).

sqMacV2Time.c:

sqInt ioRelinquishProcessorForMicroseconds(sqInt microSeconds) { //API Documented /* This operation is platform dependent. */ #pragma unused(microSeconds)

sqInt realTimeToWait,now,next; extern sqInt getNextWakeupTick(void); //This is a VM Callback extern sqInt setInterruptCheckCounter(sqInt value); //This is a VM Callback

setInterruptCheckCounter(0); now = ioMSecs(); next = getNextWakeupTick();

/*BUG??? what if clock wraps? */

if (next <= now) if (next == 0) realTimeToWait = 16; else { return 0; } else realTimeToWait = next - now;

aioSleep((int) realTimeToWait*1000); return 0; }

The real solution would be to not fall asleep, but just put process into waitable state on 'wake up semaphore' which then signaled if there's some i/o or timeout.

On Thu, Oct 24, 2013 at 6:21 PM, tim Rowledge tim@rowledge.org wrote:

...

Looking through some of the low-level changes in Mavericks I noticed stuff about timer consolidation. I *think* that it is something that you can offer to allow, rather than something done unto you code, but almost certainly it will have some sort of impact on the heartbeat ticker type of code used in stackvm/cog. Where is a skilled Mac vm maintainer when you need one?

tim

tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "bOtHeR" said Pooh, mistaking the LSD tablet for aspirin

--

John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. Twitter: squeaker68882 ===========================================================================

On Thu, Oct 24, 2013 at 7:38 PM, tim Rowledge tim@rowledge.org wrote:

On 24-10-2013, at 4:34 PM, Igor Stasenko siguctua@gmail.com wrote:

...

(e) Cog uses heartbeat timer to interrupt interpreter at regular time

periods

...

what can be done, i think it to suppress heartbeat, during

relinquishProcessorForMicroseconds execution.

...

but that won't buy much, unless we increase the time period to sleep to

be times larger than heartbeat cycle (both are 1ms).

If I understood, the timer coalescing can push timers around to produce spurts of activity followed by quiescence; this results in better overall power performance. It *might* cause problems with a high-frequency heartbeat.

You pick the "drain my battery real fast" option.... Also in the past known as "higher performance" to remove the delay in the morphic polling loop.

tim

tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim The problem with the gene pool is that there is no lifeguard.

On 25 October 2013 01:43, John McIntosh johnmci@smalltalkconsulting.comwrote:

On Thu, Oct 24, 2013 at 7:38 PM, tim Rowledge tim@rowledge.org wrote:

...

On 24-10-2013, at 4:34 PM, Igor Stasenko siguctua@gmail.com wrote:

...

(e) Cog uses heartbeat timer to interrupt interpreter at regular time

periods

...

what can be done, i think it to suppress heartbeat, during

relinquishProcessorForMicroseconds execution.

...

but that won't buy much, unless we increase the time period to sleep to

be times larger than heartbeat cycle (both are 1ms).

If I understood, the timer coalescing can push timers around to produce spurts of activity followed by quiescence; this results in better overall power performance. It *might* cause problems with a high-frequency heartbeat.

You pick the "drain my battery real fast" option.... Also in the past known as "higher performance" to remove the delay in the morphic polling loop.

yeah, we should get rid of that polling thing and Delay, instead make it wait on semaphore..

P.S. what i missing on BSD systems is good analogy to WaitForMultipleEvents() function which available in Windows kernel. It is far superior to select() and poll(). i don't know, if situation is improved in this are since last time i checked.

...

tim

tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim The problem with the gene pool is that there is no lifeguard.

--

John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. Twitter: squeaker68882 ===========================================================================

On 25 October 2013 02:05, John McIntosh johnmci@smalltalkconsulting.comwrote:

On Thu, Oct 24, 2013 at 8:02 PM, Igor Stasenko siguctua@gmail.com wrote:

...

On 25 October 2013 01:43, John McIntosh johnmci@smalltalkconsulting.comwrote:

...

On Thu, Oct 24, 2013 at 7:38 PM, tim Rowledge tim@rowledge.org wrote:

...

On 24-10-2013, at 4:34 PM, Igor Stasenko siguctua@gmail.com wrote:

...

(e) Cog uses heartbeat timer to interrupt interpreter at regular time

periods

...

what can be done, i think it to suppress heartbeat, during

relinquishProcessorForMicroseconds execution.

...

but that won't buy much, unless we increase the time period to sleep

to be times larger than heartbeat cycle (both are 1ms).

If I understood, the timer coalescing can push timers around to produce spurts of activity followed by quiescence; this results in better overall power performance. It *might* cause problems with a high-frequency heartbeat.

You pick the "drain my battery real fast" option.... Also in the past known as "higher performance" to remove the delay in the morphic polling loop.

yeah, we should get rid of that polling thing and Delay, instead make it wait on semaphore..

Morphs have an expectation of being called 50 times a second, you'll need to fix that first...

you mean stepping? you can signal that semaphore if someone needs to step, as easy as:

[ [stepTime asDelay wait. sema signal ] repeat ] fork

(sure not exactly like above, but you got an idea)

i see no problem here.

...

P.S. what i missing on BSD systems is good analogy to WaitForMultipleEvents() function which available in Windows kernel. It is far superior to select() and poll(). i don't know, if situation is improved in this are since last time i checked.

...

...

tim

tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim The problem with the gene pool is that there is no lifeguard.

--

=========================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. Twitter: squeaker68882

===========================================================================

-- Best regards, Igor Stasenko.

--

John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. Twitter: squeaker68882 ===========================================================================

On 24-10-2013, at 5:09 PM, Igor Stasenko siguctua@gmail.com wrote:

you mean stepping? you can signal that semaphore if someone needs to step, as easy as:

[ [stepTime asDelay wait. sema signal ] repeat ] fork

(sure not exactly like above, but you got an idea)

i see no problem here.

That - or something similar, as you say - would provide current morphic behaviour BUT it is really just a way to cause the problem time coalescing is trying to solve.

I strongly suspect there is a lot of improvement in Morphic performance that can be gained by making the morphs do smarter (or less) stepping work. Obviously an animated widget is going to want to, well, animate. Almost all widgets to do with text display (editors, lists, buttons) aren't animating. They don't need to step unless there is good reason to think something relevant has changed. As an example, Scratch performance on a Pi took a good step (d'oh, bad pun) forward simply by stopping UpdatingStringMorphs (used for watcher-morphs, for game scores etc) from querying and redisplaying their value every time and instead only re-displaying when the value changed. I suspect here are a lot of cases where we know that some code is going to change state that will then need displays updating and instead of relying on a large number of dumb polling tests we might use an analogue of the old changed/update mvc protocols that *only* advise of a need to step soon.

tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- A kangaroo loose in her top paddock.

On Thu, Oct 24, 2013 at 8:32 PM, Eliot Miranda eliot.miranda@gmail.comwrote:

On Thu, Oct 24, 2013 at 5:21 PM, tim Rowledge tim@rowledge.org wrote:

...

On 24-10-2013, at 5:09 PM, Igor Stasenko siguctua@gmail.com wrote:

...

you mean stepping? you can signal that semaphore if someone needs to step, as easy as:

[ [stepTime asDelay wait. sema signal ] repeat ] fork

(sure not exactly like above, but you got an idea)

i see no problem here.

That - or something similar, as you say - would provide current morphic behaviour BUT it is really just a way to cause the problem time coalescing is trying to solve.

I strongly suspect there is a lot of improvement in Morphic performance that can be gained by making the morphs do smarter (or less) stepping work. Obviously an animated widget is going to want to, well, animate. Almost all widgets to do with text display (editors, lists, buttons) aren't animating. They don't need to step unless there is good reason to think something relevant has changed. As an example, Scratch performance on a Pi took a good step (d'oh, bad pun) forward simply by stopping UpdatingStringMorphs (used for watcher-morphs, for game scores etc) from querying and redisplaying their value every time and instead only re-displaying when the value changed. I suspect here are a lot of cases where we know that some code is going to change state that will then need displays updating and instead of relying on a large number of dumb polling tests we might use an analogue of the old changed/update mvc protocols that *only* advise of a need to step soon.

OK, but these are separable issues. Making morphs smart enough to know they're animated or not, and hence know whether they should be redrawn within 50ms or not is completely orthogonal from what the VM should do at idle. When the VM has nothing to do it should sleep until there *is* something to do. One of those things to do is to wake up when the mnext delay fires. So *if* a Morph wants service 50ms from now the VM can still sleep until that time.

Can we please stop confusing the conversation and concentrate on the VM's bogus idle behaviour. What we should eb concentrating on now is arranging that the VM can enter a fully quiescent idle state that it will exit when

• i/o is possible (which includes input events, there are a form of "i" in

"i/o"

• a signal is delivered (except this could also be a variation of the

above)

• the next delay is due to fire
• a callback has occurred

I think I'm right in thinking that nothing else can happen that justifies the VM leaving its idle state.

Note that in the VisualWorks VM it is the scheduler that enters the idle state whenever there is no runnable process, and hence the idle process is conspicuously absent. And a very nice solution that is too.

Ok, that would be this code, what clock time is it now, what clock time do we have to wake up at? Sleep until then, or some interrupt.

now = ioMSecs(); next = getNextWakeupTick(); realTimeToWait = next - now; aioSleep((int) realTimeToWait*1000);

...

tim

tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- A kangaroo loose in her top paddock.

-- best, Eliot

On 25 October 2013 02:32, Eliot Miranda eliot.miranda@gmail.com wrote:

On Thu, Oct 24, 2013 at 5:21 PM, tim Rowledge tim@rowledge.org wrote:

...

On 24-10-2013, at 5:09 PM, Igor Stasenko siguctua@gmail.com wrote:

...

you mean stepping? you can signal that semaphore if someone needs to step, as easy as:

[ [stepTime asDelay wait. sema signal ] repeat ] fork

(sure not exactly like above, but you got an idea)

i see no problem here.

That - or something similar, as you say - would provide current morphic behaviour BUT it is really just a way to cause the problem time coalescing is trying to solve.

I strongly suspect there is a lot of improvement in Morphic performance that can be gained by making the morphs do smarter (or less) stepping work. Obviously an animated widget is going to want to, well, animate. Almost all widgets to do with text display (editors, lists, buttons) aren't animating. They don't need to step unless there is good reason to think something relevant has changed. As an example, Scratch performance on a Pi took a good step (d'oh, bad pun) forward simply by stopping UpdatingStringMorphs (used for watcher-morphs, for game scores etc) from querying and redisplaying their value every time and instead only re-displaying when the value changed. I suspect here are a lot of cases where we know that some code is going to change state that will then need displays updating and instead of relying on a large number of dumb polling tests we might use an analogue of the old changed/update mvc protocols that *only* advise of a need to step soon.

OK, but these are separable issues. Making morphs smart enough to know they're animated or not, and hence know whether they should be redrawn within 50ms or not is completely orthogonal from what the VM should do at idle. When the VM has nothing to do it should sleep until there *is* something to do. One of those things to do is to wake up when the mnext delay fires. So *if* a Morph wants service 50ms from now the VM can still sleep until that time.

This is exactly what i implemented in Hydra, by a) implementing a low-level event queue b) so you can really then sleep until event arrives

the point is that heartbeat is needed to interrupt long-running st code to give chance scheduler to wake up higher priority process to handle i/o activity.. (In Hydra, i combined heartbeat logic with Delay semaphore logic)

And, you need to run heartbeat, only when your VM is running (interpreting ST code), and if there's nothing to do, heartbeat should be also suspended.

And of course, without changes on image side, there's no way how to make it less power-hungry. But that, of course is slightly different story.

Can we please stop confusing the conversation and concentrate on the VM's bogus idle behaviour. What we should eb concentrating on now is arranging that the VM can enter a fully quiescent idle state that it will exit when

• i/o is possible (which includes input events, there are a form of "i" in

"i/o"

• a signal is delivered (except this could also be a variation of the

above)

• the next delay is due to fire
• a callback has occurred

I think I'm right in thinking that nothing else can happen that justifies the VM leaving its idle state.

yes.

Note that in the VisualWorks VM it is the scheduler that enters the idle state whenever there is no runnable process, and hence the idle process is conspicuously absent. And a very nice solution that is too.

...

tim

tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- A kangaroo loose in her top paddock.

-- best, Eliot

So as I understand it, the scheduling in Mavericks is designed to cut down on wasted time and energy powering up and down the CPU/GPU. I have no idea what that's going to do to the heartbeat. AppNap is I think orthogonal to the processor scheduling thing.

Anyway, has anyone built a VM on Mavericks yet? Seems like the best way to find out what the impact of this stuff might be.

On Thu, Oct 24, 2013 at 5:21 PM, tim Rowledge tim@rowledge.org wrote:

On 24-10-2013, at 5:09 PM, Igor Stasenko siguctua@gmail.com wrote:

...

you mean stepping? you can signal that semaphore if someone needs to step, as easy as:

[ [stepTime asDelay wait. sema signal ] repeat ] fork

(sure not exactly like above, but you got an idea)

i see no problem here.

That - or something similar, as you say - would provide current morphic behaviour BUT it is really just a way to cause the problem time coalescing is trying to solve.

I strongly suspect there is a lot of improvement in Morphic performance that can be gained by making the morphs do smarter (or less) stepping work. Obviously an animated widget is going to want to, well, animate. Almost all widgets to do with text display (editors, lists, buttons) aren't animating. They don't need to step unless there is good reason to think something relevant has changed. As an example, Scratch performance on a Pi took a good step (d'oh, bad pun) forward simply by stopping UpdatingStringMorphs (used for watcher-morphs, for game scores etc) from querying and redisplaying their value every time and instead only re-displaying when the value changed. I suspect here are a lot of cases where we know that some code is going to change state that will then need displays updating and instead of relying on a large number of dumb polling tests we might use an analogue of the old changed/update mvc protocols that *only* advise of a need to step soon.

tim

tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- A kangaroo loose in her top paddock.

On 25 October 2013 01:39, John McIntosh johnmci@smalltalkconsulting.comwrote:

After you solve aioPoll()

You could consider waiting in the morphic polling loop until a VM UI event interrupt comes in, or to when you need to wake up to service your Morphic responsibilities.

you always know when image wants to wake up - it is a delay semaphore. basically , when image sets new Delay, it says to VM: wake me up at this moment. This is i think the only thing, of course aside the async i/o & UI events.

I don't know how well different platforms support that, but at least on windows, a following can be realized without the problem:

self primPleaseWakeMeUpWhenSomethingHappensButNotForNoReason

instead of:

[ self sleep:1000 "or wakeup if there something happens" ] repeat.

means, that OS Kernel can handle that and it halts CPU for your process until hardware interrupt arrives.

On Thu, Oct 24, 2013 at 7:34 PM, Igor Stasenko siguctua@gmail.com wrote:

...

On 25 October 2013 01:18, John McIntosh johnmci@smalltalkconsulting.comwrote:

...

Well let me reflect. Nothing has changed, the VM energy sapping field is the same as yesterday, just more evident.

I wasn't able to determine what code base is used, but if I go back 5 or 10 years.

(a) The morphic event polling cycle runs 50 times a second. One could write some timer consolidation code there to consider when do I have to wake up and paint all those morphs? No C/Objective-C/assembler/fortran required...

(b) Maybe the VMs are event driven now and Morphic does not need to poll 50 times a second?

(c) The BSD Unix socket system requires polling of some form. But see work by Craig 10-15 back on "Flow"

(d) When all the Smalltalk Processes settle, the dispatcher runs the lowest priority task which calls relinquishProcessorForMicroseconds with a bogus value.

(e) Cog uses heartbeat timer to interrupt interpreter at regular time periods what can be done, i think it to suppress heartbeat, during relinquishProcessorForMicroseconds execution. but that won't buy much, unless we increase the time period to sleep to be times larger than heartbeat cycle (both are 1ms).

sqMacV2Time.c:

sqInt ioRelinquishProcessorForMicroseconds(sqInt microSeconds) { //API Documented /* This operation is platform dependent. */ #pragma unused(microSeconds)

sqInt       realTimeToWait,now,next;
extern sqInt getNextWakeupTick(void);                //This is a VM

Callback extern sqInt setInterruptCheckCounter(sqInt value); //This is a VM Callback

setInterruptCheckCounter(0);
now = ioMSecs();
next = getNextWakeupTick();

/*BUG??? what if clock wraps? */

if (next <= now)
    if (next == 0)
            realTimeToWait = 16;
        else {
            return 0;
        }
    else
        realTimeToWait = next - now;

aioSleep((int) realTimeToWait*1000);
return 0;

}

The real solution would be to not fall asleep, but just put process into waitable state on 'wake up semaphore' which then signaled if there's some i/o or timeout.

...

On Thu, Oct 24, 2013 at 6:21 PM, tim Rowledge tim@rowledge.org wrote:

...

Looking through some of the low-level changes in Mavericks I noticed stuff about timer consolidation. I *think* that it is something that you can offer to allow, rather than something done unto you code, but almost certainly it will have some sort of impact on the heartbeat ticker type of code used in stackvm/cog. Where is a skilled Mac vm maintainer when you need one?

tim

tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "bOtHeR" said Pooh, mistaking the LSD tablet for aspirin

--

=========================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. Twitter: squeaker68882

===========================================================================

-- Best regards, Igor Stasenko.

--

John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. Twitter: squeaker68882 ===========================================================================

On Thu, Oct 24, 2013 at 4:18 PM, John McIntosh < johnmci@smalltalkconsulting.com> wrote:

Well let me reflect. Nothing has changed, the VM energy sapping field is the same as yesterday, just more evident.

I wasn't able to determine what code base is used, but if I go back 5 or 10 years.

(a) The morphic event polling cycle runs 50 times a second. One could write some timer consolidation code there to consider when do I have to wake up and paint all those morphs? No C/Objective-C/assembler/fortran required...

(b) Maybe the VMs are event driven now and Morphic does not need to poll 50 times a second?

Ah, that's the right code word. yes, the VMs should be event-driven.

(c) The BSD Unix socket system requires polling of some form. But see work by Craig 10-15 back on "Flow"

(d) When all the Smalltalk Processes settle, the dispatcher runs the lowest priority task which calls relinquishProcessorForMicroseconds with a bogus value.

On Thu, Oct 24, 2013 at 6:21 PM, tim Rowledge tim@rowledge.org wrote:

...

Looking through some of the low-level changes in Mavericks I noticed stuff about timer consolidation. I *think* that it is something that you can offer to allow, rather than something done unto you code, but almost certainly it will have some sort of impact on the heartbeat ticker type of code used in stackvm/cog. Where is a skilled Mac vm maintainer when you need one?

tim

tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "bOtHeR" said Pooh, mistaking the LSD tablet for aspirin

--

John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. Twitter: squeaker68882 ===========================================================================