i just wonder, what takes so much CPU time, even if it completely idle...
4831- NBCog 4.8 51519- NBCog 3.5 if i kill a UI process, the load goes down to 2.5-3 % ... still too much. i would like to know how we can minimize this. The reason why i concerned is straightly pragmatic: extending battery life.. i found that if i run completely on battery.. it depleting quite fast with VM running (and i don't do anything just coding, i.e not running benchmarks, but more thinking and typing). -- Best regards, Igor Stasenko. |
Yes, we should at least understand why this happens.
BTW, another related question is: when running headless, do we actually need those 6 processes ? Sven On 04 Jun 2012, at 21:56, Igor Stasenko wrote: > i just wonder, what takes so much CPU time, even if it completely idle... > > > 4831- NBCog 4.8 > 51519- NBCog 3.5 > > if i kill a UI process, the load goes down to 2.5-3 % ... > still too much. > > i would like to know how we can minimize this. > The reason why i concerned is straightly pragmatic: extending battery life.. > > i found that if i run completely on battery.. it depleting quite fast > with VM running (and i don't do anything just coding, i.e not running > benchmarks, but more thinking and typing). > > -- > Best regards, > Igor Stasenko. > |
On 4 June 2012 22:07, Sven Van Caekenberghe <[hidden email]> wrote:
> Yes, we should at least understand why this happens. > > BTW, another related question is: when running headless, do we actually need those 6 processes ? > well, here ones: 1. Delay 2. Event fetcher 3. Low space watcher 4. UI process 5. finalization process 6. idle process well, i did following: InputEventFetcher shutDown. Delay stopTimerEventLoop. WeakArray finalizationProcess terminate. Processor activeProcess terminate. and still having constant 2.3-2.4% CPU load.. there's only idle process left.. > Sven -- Best regards, Igor Stasenko. |
In reply to this post by Sven Van Caekenberghe
Hehe, that reminds me time when i had clients using a st-80 app on a
server workstation. At that time, MVC UI was still polling, with some kind of heart beat for relaxing CPU cycles... But RAM was not cheap and was the true bottleneck, our app already did already consume a few Mbytes. Naturally users did notice that they would not be swapped out of memory if they shake the mouse. So they more or less instinctively shake the mouse and we got lot of complaints from system engineers. They could not understand how a modern application could waste so many cycles for nothing and be such a bad citizen... I see that many years later, despite our (late) conversion to event driven UI, we still have some remnant ghosts... Nicolas 2012/6/4 Sven Van Caekenberghe <[hidden email]>: > Yes, we should at least understand why this happens. > > BTW, another related question is: when running headless, do we actually need those 6 processes ? > > Sven > > On 04 Jun 2012, at 21:56, Igor Stasenko wrote: > >> i just wonder, what takes so much CPU time, even if it completely idle... >> >> >> 4831- NBCog 4.8 >> 51519- NBCog 3.5 >> >> if i kill a UI process, the load goes down to 2.5-3 % ... >> still too much. >> >> i would like to know how we can minimize this. >> The reason why i concerned is straightly pragmatic: extending battery life.. >> >> i found that if i run completely on battery.. it depleting quite fast >> with VM running (and i don't do anything just coding, i.e not running >> benchmarks, but more thinking and typing). >> >> -- >> Best regards, >> Igor Stasenko. >> > > |
In reply to this post by Igor Stasenko
On Mon, Jun 4, 2012 at 12:56 PM, Igor Stasenko <[hidden email]> wrote:
The basic issue is the idle process that spins doing a yield instead of blocking. Basically, instead of ioRelinquishProcessorForMicroseconds the VM should enter a blocking call that will terminate when the next delay or i/o event occurs. This requires rearchitecting delays because currently the VM polls for delay expiry. For the VM to block while a delay is active there must be a delay callback/signal/interrupt etc that has the side-effect of terminating the blocking call.
best, Eliot |
In reply to this post by Igor Stasenko
Hi Igor,
Quoting Igor Stasenko <[hidden email]>: > > i just wonder, what takes so much CPU time, even if it completely idle... > > > 4831- NBCog 4.8 > 51519- NBCog 3.5 > > if i kill a UI process, the load goes down to 2.5-3 % ... > still too much. Well, there are both image and VM issues here. I'll assume you're running Pharo on a Mac. Running Cuis on a Mac, when idle, uses 2.6 - 2.7%. So, the UI process can be optimized to the point where it takes almost zero CPU. But there are VM platform code issues too. Doing the same on a Windows 7 Atom netbook, Cuis uses 0% (zero!) CPU. > i would like to know how we can minimize this. > The reason why i concerned is straightly pragmatic: extending battery life.. > > i found that if i run completely on battery.. it depleting quite fast > with VM running (and i don't do anything just coding, i.e not running > benchmarks, but more thinking and typing). > > -- > Best regards, > Igor Stasenko. > Cheers, Juan Vuletich |
-------- Original-Nachricht --------
> Quoting Igor Stasenko <[hidden email]>: > > > > > i just wonder, what takes so much CPU time, even if it completely > idle... > > > > > > 4831- NBCog 4.8 > > 51519- NBCog 3.5 > > > > if i kill a UI process, the load goes down to 2.5-3 % ... > > still too much. > > Well, there are both image and VM issues here. I'll assume you're > running Pharo on a Mac. Running Cuis on a Mac, when idle, uses 2.6 - > 2.7%. So, the UI process can be optimized to the point where it takes > almost zero CPU. > > But there are VM platform code issues too. Doing the same on a Windows > 7 Atom netbook, Cuis uses 0% (zero!) CPU. The reason for which is that ioRelinquishProcessor() is implemented in precisely the fashion Eliot described it in his earlier message, by calling a blocking function which wakes up when there is some activity (either UI or other such as sockets). Cheers, - Andreas -- NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone! Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a |
Free forum by Nabble | Edit this page |