A question somewhat related to my previous question is that the VM slows down from a performance standpoint when there hasn't been any keyboard or mouse input occurring for a while. Is there a way to programmatically toggle this behavior in the image? i.e. there are times when I'd like maximum performance regardless of whether or not the user is actively interacting with the image and am not concerned with CPU cycles or battery life.
Thanks, Phil
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
On 6 June 2012 18:41, Phil (list) pbpublist@gmail.com wrote:
A question somewhat related to my previous question is that the VM slows down from a performance standpoint when there hasn't been any keyboard or mouse input occurring for a while. Is there a way to programmatically toggle this behavior in the image? i.e. there are times when I'd like maximum performance regardless of whether or not the user is actively interacting with the image and am not concerned with CPU cycles or battery life.
Thanks, Phil
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
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.
On Wed, Jun 6, 2012 at 9:37 PM, Phil (list) pbpublist@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,
First, thanks for taking the time, your feedback is informative as always.
On Jun 6, 2012, at 10:07 PM, John McIntosh 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.
That sure seems to explain what's going on: my 50ms step time results in a significant fraction of the expected updates not to occur and it sounds like they essentially get missed/ignored unless the VM is awake due to other duties. I played around with various step times from 50-200ms and it seems to sync with your explanation (i.e. the Cog VM isn't terribly different in this regard?) At 200ms the idle slowdown nearly disappears.
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.
So I guess that leaves me with one more question for John:
Are there any gotchas that come to mind re: increasing the frequency of the pre-cog vm timer aside from system overhead?
And a question related to Cog:
Depending on John's answer, and assuming the Cog VM is similar re: timing architecture, how difficult would it be to allow the image to dynamically set the timer frequency?
Finally, one specific to the Event-based Cog for Android:
Is it be possible to dynamically enable/disable timer-based operation? (I haven't yet gotten the code in question running on Android, but I'm guessing that the experience won't be fun for non-interactive code)
I'm not asking anyone to commit to anything, rather just trying to get a handle on the feasibility / order of magnitude effort related to the above questions. I've already talked myself into a project that involves some VM/plugin hacking, and just want to understand how much deeper I'd be digging the hole if I decide I really want this :-)
Thanks, Phil
On Wed, Jun 6, 2012 at 7:07 PM, John McIntosh < johnmci@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@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@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com iPhone Apps. http://www.wikiserver.com ===========================================================================
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@gmail.com wrote:
On Wed, Jun 6, 2012 at 7:07 PM, John McIntosh johnmci@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@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@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com iPhone Apps. http://www.wikiserver.com ===========================================================================
-- best, Eliot
On 7 June 2012 03:37, Phil (list) pbpublist@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?
no.. when you say 'every 50ms' this means that your process will awake every 50ms but rest of the time it will put oh hold ==>> means nothing to do for VM during these 50ms. actually, morphic world default inter-cycle pause is 20ms.. but this doesn't changes the fact that when UI process is on hold, then scheduler scheduling idle process, which tells VM to relinquish CPU to OS. an idle process is always scheduled at minimum possible priority (like that, scheduler always can find a process which must be scheduled).
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.
you can play with #interCyclePause: in morphic to see if problem is there. because idle process pausing VM for 1ms.. this is too small to affect frame rate.
-- Best regards, Igor Stasenko.
On 07.06.2012, at 03:37, "Phil (list)" pbpublist@gmail.com wrote:
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?
Enable the higherPerformance preference.
This does not kill the idle process, but disables Morphic's regular 50 fps cap. Use a FrameRateMorph to show the frame rate, it should be in the hundreds of fps.
That said I'm not entirely sure if this relates to the move-mouse-to-do-anything phenomenon. We have seen this occasionally, only on Linux IIRC, but never got down to the root of it.
- Bert -
Hi Phil,
Take a look at the two numeric classVars in WorldState class>>initialize. Change their values, see how they are used. You can control the performance dependence on the mouse events. This works ok on your image, at least on a Mac.
Quoting Bert Freudenberg bert@freudenbergs.de:
On 07.06.2012, at 03:37, "Phil (list)" pbpublist@gmail.com wrote:
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?
Enable the higherPerformance preference.
This does not kill the idle process, but disables Morphic's regular 50 fps cap. Use a FrameRateMorph to show the frame rate, it should be in the hundreds of fps.
That said I'm not entirely sure if this relates to the move-mouse-to-do-anything phenomenon. We have seen this occasionally, only on Linux IIRC, but never got down to the root of it.
- Bert -
Cheers, Juan Vuletich
Juan,
On Jun 7, 2012, at 6:21 AM, Juan Vuletich (mail lists) wrote:
Hi Phil,
Take a look at the two numeric classVars in WorldState class>>initialize. Change their values, see how they are used. You can control the performance dependence on the mouse events. This works ok on your image, at least on a Mac.
Perfect... that addresses the issue on both platforms.
Thanks, Phil
vm-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Eliot Miranda -
Igor Stasenko -
John M McIntosh -
John McIntosh
-
Juan Vuletich (mail lists) -
Phil (list)