> 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. 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. > 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
