> 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.
> 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] > <mailto:[email protected]>>: > > > > On Feb 9, 2015, at 10:41 PM, Sven Van Caekenberghe <[email protected] > <mailto:[email protected]>> wrote: > > > > >> On 10 Feb 2015, at 01:55, Eliot Miranda <[email protected] > >> <mailto:[email protected]>> wrote: > >> > >> Hi Sven, > >> > >> On Mon, Feb 9, 2015 at 1:43 PM, Sven Van Caekenberghe <[email protected] > >> <mailto:[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] > >>> <mailto:[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 > > > > > >
