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