[Vm-dev] OS X Mavericks & cog tickers

[Igor Stasenko]

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

>
>
>
>
> On Thu, Oct 24, 2013 at 5:21 PM, tim Rowledge <tim at rowledge.org> wrote:
>
>>
>>
>> On 24-10-2013, at 5:09 PM, Igor Stasenko <siguctua at 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 at rowledge.org; http://www.rowledge.org/tim
>> Useful random insult:- A kangaroo loose in her top paddock.
>>
>>
>>
>
>
> --
> best,
> Eliot
>
>


-- 
Best regards,
Igor Stasenko.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20131025/9585c72f/attachment.htm