[Vm-dev] Cog VM idling performance

John M McIntosh johnmci at smalltalkconsulting.com
Thu Jun 7 17:39:16 UTC 2012


I tried suspending the watchdog thread on sleep and got mixed results if it bade a difference as suspend/resume takes time. However someone is welcome to try that again and produce some numbers 

Sent from my iPhone

On Jun 7, 2012, at 1:24 PM, Eliot Miranda <eliot.miranda at gmail.com> wrote:

> 
> 
> 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/5c4f50cf/attachment.htm


More information about the Vm-dev mailing list