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 <http://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 <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.
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
