[Vm-dev] Cog VM idling performance

Eliot Miranda eliot.miranda at gmail.com
Thu Jun 7 17:24:59 UTC 2012


On Wed, Jun 6, 2012 at 7:07 PM, John McIntosh <
johnmci at smalltalkconsulting.com> wrote:

>
> I've resisted reponding, but way less busy tonight.
>
> Ok, in general pre-cog as I can't quite comment about how that works.
>
> After most things are killed there is really only the Morphic polling loop
> running.
> What happens is it attempts about 50 times a second to wake up and service
> morphic steps and collect VM events and turn them into mophic events.
> That of course takes CPU.
>
> Now when the morphic poll loop goes to sleep by scheduling a variable
> length delay to met the 50 times a second, what happens is what Igor
> alluded to
> some other process has to run otherwise the VM will terminate with no
> processes to run.
>
> This process is the lowest level idle process.
> What it does is get passed a FAKE millisecond time.
> Note in the previous century I attempted to pass how log to sleep as the
> Delay logic knows that... But we found out after it was pushed to the
> squeak change stream that there was a deadlock... Oops.
>
> Later I realized we know in the VM when the next wakeup time is.
>
> So in the VM when it calls the primitive to do idle time sleep we can grab
> the next known wakeup time and sleep until then.
> or until some interrupt happens, like a file system, socket, UI input
> wakes us up early.
> Then we usually on unix run the async file handle logic to deal with
> pending semaphores for sockets etc.
> That all sounds fairly rational, until you instrument and discover things
> like you are asked to sleep, yet a delay a millisecond or two in the past
> needs to be serviced...
> You'll need to look at the platform support code to understand what
> happens, 50 times a second..
>
>
> I think for COG there is also a high priority millisecond tick process
> running to update the millisecond/microsecond clock?  That spins the CPU
> dial too.
>

Yes, but only when the VM is running.  It *doesn't* need to run if the VM
is blocked sleeping.  And the overhead of this watchdog thread is very low.
 Don't confuse the watchdog thread with not blocking for i/o when at idle.
 There's nothing to stop one disabling the watchdog during idle, provided
scheduled delays break out of idle.


>
> On Wed, Jun 6, 2012 at 9:37 PM, Phil (list) <pbpublist at gmail.com> wrote:
>
>>
>> Igor,
>>
>> On Jun 6, 2012, at 2:24 PM, Igor Stasenko wrote:
>>
>> >
>> > just kill an idle process.
>> > but you must be sure that at any moment of time there will be some
>> > scheduled process
>> > available, otherwise VM will leave to OS, since it will unable to find
>> > anything to run
>> >
>>
>> I'm not sure I understand: I have a morph with stepping enabled (every
>> 50ms)... shouldn't that keep the idle process from taking over?  If not
>> (i.e. and your suggestion is the way to go), what's the recommended way to
>> kill the idle process and how would I restart it when I no longer want
>> maximum performance?
>>
>> The link to the image I posted in my reply to Bert will also display the
>> behavior I'm describing: simply moving the mouse around while the stepping
>> is active will increase the framerate, when you stop moving the mouse it
>> decreases.
>>
>> > --
>> > Best regards,
>> > Igor Stasenko.
>>
>> Thanks,
>> Phil
>
>
>
>
> --
> ===========================================================================
> John M. McIntosh <johnmci at smalltalkconsulting.com>
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> iPhone Apps.  http://www.wikiserver.com
> ===========================================================================
>
>
>
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20120607/73042dc3/attachment-0001.htm


More information about the Vm-dev mailing list