> Am 10.02.2015 um 11:23 schrieb Sven Van Caekenberghe <[email protected]>: > >> >> On 10 Feb 2015, at 11:19, Norbert Hartl <[email protected]> wrote: >> >> Sven, >> >>> Am 10.02.2015 um 10:36 schrieb Sven Van Caekenberghe <[email protected]>: >>> >>>> >>>> On 10 Feb 2015, at 09:51, Norbert Hartl <[email protected]> wrote: >>>> >>>> >>>>> Am 10.02.2015 um 09:23 schrieb Clément Bera <[email protected]>: >>>>> >>>>> Hello, >>>>> >>>>> About the Morphic rendering loop, the delay between rendering is handled >>>>> in WorldState>>#interCyclePause:. The best solution to reduce the cost of >>>>> the Morphic rendering loop is to put it in server mode by executing in >>>>> Pharo: WorldState serverMode: true. In squeak you have to set that in the >>>>> Preferences. >>>>> >>>> I'll play with it and see what can be gained. >>> >>> I tried the following on an otherwise idle DigitalOcean VM running Ubuntu >>> 13.10 >>> >>> $ mkdir pharo4 >>> $ curl get.pharo.org/40+vm | bash >>> $ ./pharo Pharo.image save Server >>> >>> First patch (slower event handling, extra delay of 50ms): >>> >>> $ ./pharo Server.image eval --save 'WorldState serverMode: true' >>> >>> Second patch (give time back to OS while idle for 10ms instead of for 1ms): >>> >>> $ cat ProcessorScheduler-class-idleProcess.st >>> 'From Pharo4.0 of 18 March 2013 [Latest update: #40484] on 10 February 2015 >>> at 9:49:15.412839 am!ProcessorScheduler class methodsFor: 'background >>> process' stamp: 'SvenVanCaekenberghe 2/10/2015idleProc[true] w[self >>> relinquishProcessorForMicroseconds: 10000]! ! >>> >>> $ ./pharo Server.image eval "'ProcessorScheduler-class-idleProcess.st' >>> asFileReference fileIn" >>> $ ./pharo Server.image eval '(ProcessorScheduler class>>#idleProcess) >>> sourceCode' >>> 'idleProcess >>> "A default background process which is invisible." >>> >>> [true] whileTrue: >>> [self relinquishProcessorForMicroseconds: 10000]' >>> >>> Run an image with a basic Zn HTTP server in background: >>> >>> $ ./pharo Server.image eval --no-quit 'ZnServer startDefaultOn: 1701' & >>> $ curl http://localhost:1701 >>> >>> Overall load is 0.01% but this is virtual/shared hardware, so who knows. >>> >>> CPU load of the pharo process hovers around a couple of %, I am not seeing >>> much difference, maybe it is a bit lower, but that might be wishful >>> thinking. >>> >> my findings are similar. I have a CPU usage of 6%. WorldState serverMode >> adds a Delay for 50ms. Setting a higher number in the idle process does not >> seem to have any effect until the number is too high, then the image does >> not start anymore. >> I tuned all of these things and it is not faster sometimes it appears to >> take more CPU which probably is not true. > > I am afraid that we as a community do not fully understand what is happening > or how we can control it. > Same here.
> On the other hand, on a machine with many images running, things are still > totally fine, so we should not worry too much. It is only in specific case > like yours where it becomes a concern. > It is ok. I have 19 images on my machine running and I'm happy. It is just completely unnecessary to burn all the cycles. If it wasn't about temperature I don't think I would have worried. Norbert >> Norbert >> >>>>> But as it was discussed, the cpu consumption most probably does not come >>>>> from Morphic but comes from the idle loop, which can be solved by doing >>>>> an event-driven VM. >>>>> >>>>> I am particularly willing to have an event-driven VM because it then >>>>> means that the VM performance would then be directly proportional to the >>>>> cpu consumption. For example, theoretically, with an event-driven VM, >>>>> having the VM twice faster with Spur would also mean that the VM consumes >>>>> twice less energy. Go Green IT :-) >>>>> >>>> That is exactly my point. While consumed energy is turned into heat the >>>> act of saving energy is the same as having a cool device (pun intended). >>>> >>>> So I would like to take my consortium hat to state my upvote on this. >>>> >>>> Norbert >>>> >>>>> 2015-02-10 8:00 GMT+01:00 Eliot Miranda <[email protected]>: >>>>> >>>>> >>>>> >>>>> On Feb 9, 2015, at 10:41 PM, Sven Van Caekenberghe <[email protected]> wrote: >>>>> >>>>>> >>>>>>> On 10 Feb 2015, at 01:55, Eliot Miranda <[email protected]> wrote: >>>>>>> >>>>>>> Hi Sven, >>>>>>> >>>>>>> On Mon, Feb 9, 2015 at 1:43 PM, Sven Van Caekenberghe <[email protected]> >>>>>>> wrote: >>>>>>> There is some timer thread between the image and the vm that ticks >>>>>>> every millisecond, that is the cause. I don't know what it does but it >>>>>>> is apparently needed. >>>>>>> >>>>>>> Anyway, that is how I understood it from Igor and Eliot, long ago. >>>>>>> >>>>>>> So basically, the VM is always slightly busy. >>>>>>> >>>>>>> Yet the VM is always slightly busy with the heartbeat thread, but this >>>>>>> is very cheap. The actual idle cost comes form the idle loop in the >>>>>>> background process that sends relinquishProcessorForMicroseconds:, >>>>>>> which is a primitive that eventually calls the select system call. >>>>>>> This is the source of the cost. >>>>>> >>>>>> Can we change something about that ? >>>>>> Maybe just as an experiment to prove your point ? >>>>> >>>>> What do you think halving or doubling the argument to >>>>> relinquishProcessorForMicroseconds: should do if this is the major source >>>>> of overhead? Processor usage at idle should be closely inversely >>>>> proportional right? >>>>> >>>>>> >>>>>>>> On 09 Feb 2015, at 21:11, Norbert Hartl <[email protected]> wrote: >>>>>>>> >>>>>>>> I have an installation where a pharo powered hardware is used in a >>>>>>>> closed case. Over time that collects quite some heat. One reason for >>>>>>>> this is that the pharo vm is taking approx. 6% CPU all the time. The >>>>>>>> only thing that happens is network/sockets. I suspended the ui thread >>>>>>>> in the image but on this platform it doesn't help. >>>>>>>> Are there any tweaks to lower the polling and the activity of the >>>>>>>> image/vm even more? >>>>>>>> >>>>>>>> thanks, >>>>>>>> >>>>>>>> Norbert >>>>>>> -- >>>>>>> best, >>>>>>> Eliot
