February 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Reducing the activity of the image

by Norbert Hartl

> Am 10.02.2015 um 11:23 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > >> >> On 10 Feb 2015, at 11:19, Norbert Hartl <norbert(a)hartl.name> wrote: >> >> Sven, >> >>> Am 10.02.2015 um 10:36 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >>> >>>> >>>> On 10 Feb 2015, at 09:51, Norbert Hartl <norbert(a)hartl.name> wrote: >>>> >>>> >>>>> Am 10.02.2015 um 09:23 schrieb ClÃ©ment Bera <bera.clement(a)gmail.com>: >>>>> >>>>> 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 <eliot.miranda(a)gmail.com>: >>>>> >>>>> >>>>> >>>>> On Feb 9, 2015, at 10:41 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>>> >>>>>> >>>>>>> On 10 Feb 2015, at 01:55, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>>>>>> >>>>>>> Hi Sven, >>>>>>> >>>>>>> On Mon, Feb 9, 2015 at 1:43 PM, Sven Van Caekenberghe <sven(a)stfx.eu> 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 <norbert(a)hartl.name> 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

Feb. 10, 2015

Re: [Pharo-dev] Reducing the activity of the image

by Sven Van Caekenberghe

> On 10 Feb 2015, at 11:19, Norbert Hartl <norbert(a)hartl.name> wrote: > > Sven, > >> Am 10.02.2015 um 10:36 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >> >>> >>> On 10 Feb 2015, at 09:51, Norbert Hartl <norbert(a)hartl.name> wrote: >>> >>> >>>> Am 10.02.2015 um 09:23 schrieb ClÃ©ment Bera <bera.clement(a)gmail.com>: >>>> >>>> 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 <eliot.miranda(a)gmail.com>: >>>> >>>> >>>> >>>> On Feb 9, 2015, at 10:41 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>> >>>>> >>>>>> On 10 Feb 2015, at 01:55, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>>>>> >>>>>> Hi Sven, >>>>>> >>>>>> On Mon, Feb 9, 2015 at 1:43 PM, Sven Van Caekenberghe <sven(a)stfx.eu> 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 <norbert(a)hartl.name> 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

Feb. 10, 2015

Re: [Pharo-dev] Reducing the activity of the image

by Norbert Hartl

Sven, > Am 10.02.2015 um 10:36 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > >> >> On 10 Feb 2015, at 09:51, Norbert Hartl <norbert(a)hartl.name> wrote: >> >> >>> Am 10.02.2015 um 09:23 schrieb ClÃ©ment Bera <bera.clement(a)gmail.com>: >>> >>> 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 <eliot.miranda(a)gmail.com>: >>> >>> >>> >>> On Feb 9, 2015, at 10:41 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>>> >>>>> On 10 Feb 2015, at 01:55, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>>>> >>>>> Hi Sven, >>>>> >>>>> On Mon, Feb 9, 2015 at 1:43 PM, Sven Van Caekenberghe <sven(a)stfx.eu> 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 <norbert(a)hartl.name> 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

Feb. 10, 2015

Re: [Pharo-dev] Reducing the activity of the image

by Sven Van Caekenberghe

> On 10 Feb 2015, at 09:51, Norbert Hartl <norbert(a)hartl.name> wrote: > > >> Am 10.02.2015 um 09:23 schrieb ClÃ©ment Bera <bera.clement(a)gmail.com>: >> >> 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 <eliot.miranda(a)gmail.com>: >> >> >> >> On Feb 9, 2015, at 10:41 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> > >> >> On 10 Feb 2015, at 01:55, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >> >> >> Hi Sven, >> >> >> >> On Mon, Feb 9, 2015 at 1:43 PM, Sven Van Caekenberghe <sven(a)stfx.eu> 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 <norbert(a)hartl.name> 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 >> > >> > >> >> >

Feb. 10, 2015

Re: [Pharo-dev] What is a Behavior, are Traits behavior too?

by Camille

> On 09 Feb 2015, at 18:24, Nicolai Hess <nicolaihess(a)web.de> wrote: > > I thought, Behaviors define the "behavior" of objects, therefore: > > Integer is a behavior, because it defines the behavior of "integer objects" > Integer class is a behavior because it defines the behavior of the object "Integer". > > 5 isBehavior -> false. > Integer isBehavior -> true. > Integer class isBehavior -> true. > > What about Traits? > > Traits are "behavioral(?)", but they don't define the behavior alone, only the composition of > Traits in an actual class defines the behavior of an Object. > > TClass isBehavior -> false. > > So far so good. In fact the first time I saw this I was a bit surprised, I was expecting it to return true. After all Trait class inherits TraitBehavior that uses the TBehavior trait. Sure a trait alone doesnât define the whole behavior of an object but at least part of it. In fact itâs because there is many senders of isBehavior which expect it to return true only if the receiver is instanciable. But still itâs a bit confusing. > Smalltalk globals allBehaviors includes:TClass -> true ! > > No suprise, because #allBehaviors explicitly collect all classes and traits. > But the question is, what do we want to call a "Behaviorâ? I would prefer isBehavior to return true for traits and rename the current isBehavior to isInstanciable for exemple. But this is quite a refactoring and itâs likely to break many things that are not in the image by default. Likewise in SystemDictionary and SystemNavigation: > All Classes and MetaClasses (-> Behavior allSubclasses) -> allInstanciable or allClassesAndMetaclasses > All Classes and Traits -> allInstanceSideBehaviors (and an equivalent allClassSideBehavior for metaclasses and classtraits) > All Classes and Traits and MetaClasses and ClassTraits -> allBehaviors > All Classes and MetaClasses and some Traits? not this one > (this of course, is related to http://forum.world.st/RBEnvironments-allClasses-Traits-Meta-tp4796370.html <http://forum.world.st/RBEnvironments-allClasses-Traits-Meta-tp4796370.html>). > > In squeak Traits are behavior too. Yes, itâs because in squeak traits are implemented differently: the class Trait inherits from Behavior so traits are instanciable. > > > nicolai > >

Feb. 10, 2015

Re: [Pharo-dev] What is Phlow?

by Norbert Hartl

Doru, I didn't mean material about your actual work. It is more a question like Thierry asked. What is the working model beneath. Is it FRP, something different, something new? Just a few words as a teaser ;) Norbert > Am 10.02.2015 um 08:59 schrieb Tudor Girba <tudor(a)tudorgirba.com>: > > Things move fast, don't they?! In fact, they seem to be moving faster and faster. Faster than any one of us can think. That is what accelerating acceleration means. We are approaching amazing times. > > About Phlow, please wait for a little while. We are still working on it. It will likely need some months, but we'll let you know when we have something more complete :) > > Doru > > On Tue, Feb 10, 2015 at 8:42 AM, Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name>> wrote: > That sounds really interesting. Are there any materials available? > > Norbert > > > > Am 10.02.2015 um 08:14 schrieb stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>>: > >> This is fun because I wanted to propose to have a dataflow engine based on slot for event manipulation >> and there is phlow :) >> >> Stef >> >>> 2015-02-09 21:50 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com <mailto:tudor@tudorgirba.com>>: >>> Hi, >>> >>> First, thanks for reviewing the code :). >>> >>> Phlow is a small engine that makes it possible to link Brick slots to one another to enable flow of data. >>> >>> Sounds interesting! >>> >>> >>> >>> Cheers, >>> Doru >>> >>> >>> >>> On Mon, Feb 9, 2015 at 1:46 PM, Nicolai Hess <nicolaihess(a)web.de <mailto:nicolaihess@web.de>> wrote: >>> For example GLMBrick subclass: #GLMPhlowBrick >>> in category: 'Glamour-Morphic-Brick-Phlow' >>> >>> >>> >>> >>> -- >>> www.tudorgirba.com <http://www.tudorgirba.com/> >>> >>> "Every thing has its own flow" >>> >> > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com/> > > "Every thing has its own flow"

Feb. 10, 2015

Re: [Pharo-dev] Reducing the activity of the image

by Norbert Hartl

> Am 10.02.2015 um 09:23 schrieb ClÃ©ment Bera <bera.clement(a)gmail.com>: > > 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 <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>>: > > > > On Feb 9, 2015, at 10:41 PM, Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>> wrote: > > > > >> On 10 Feb 2015, at 01:55, Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>> wrote: > >> > >> Hi Sven, > >> > >> On Mon, Feb 9, 2015 at 1:43 PM, Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>> 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 <norbert(a)hartl.name <mailto:norbert@hartl.name>> 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 > > > > > >

Feb. 10, 2015

Re: [Pharo-dev] What is Phlow?

by Thierry Goubier

2015-02-10 8:14 GMT+01:00 stepharo <stepharo(a)free.fr>: > This is fun because I wanted to propose to have a dataflow engine based > on slot for event manipulation > and there is phlow :) > Stef, would that mean you could do dataflow programming (a la FRP or STEPS) with the appropriate slots? Could it be possible as well to run a constraint satisfaction engine behind slots? Thierry > > Stef > > 2015-02-09 21:50 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > >> Hi, >> >> First, thanks for reviewing the code :). >> >> Phlow is a small engine that makes it possible to link Brick slots to >> one another to enable flow of data. >> > > Sounds interesting! > > > >> >> Cheers, >> Doru >> >> >> >> On Mon, Feb 9, 2015 at 1:46 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: >> >>> For example GLMBrick subclass: #GLMPhlowBrick >>> in category: 'Glamour-Morphic-Brick-Phlow' >>> >>> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > > >

Feb. 10, 2015

Re: [Pharo-dev] Reducing the activity of the image

by ClÃ©ment Bera

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. 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 :-) 2015-02-10 8:00 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > > On Feb 9, 2015, at 10:41 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > >> On 10 Feb 2015, at 01:55, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > >> > >> Hi Sven, > >> > >> On Mon, Feb 9, 2015 at 1:43 PM, Sven Van Caekenberghe <sven(a)stfx.eu> > 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 <norbert(a)hartl.name> 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 > > > > > >

Feb. 10, 2015

Re: [Pharo-dev] What is Phlow?

by Tudor Girba

Things move fast, don't they?! In fact, they seem to be moving faster and faster. Faster than any one of us can think. That is what accelerating acceleration means. We are approaching amazing times. About Phlow, please wait for a little while. We are still working on it. It will likely need some months, but we'll let you know when we have something more complete :) Doru On Tue, Feb 10, 2015 at 8:42 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > That sounds really interesting. Are there any materials available? > > Norbert > > > > Am 10.02.2015 um 08:14 schrieb stepharo <stepharo(a)free.fr>: > > This is fun because I wanted to propose to have a dataflow engine based on > slot for event manipulation > and there is phlow :) > > Stef > > 2015-02-09 21:50 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > >> Hi, >> >> First, thanks for reviewing the code :). >> >> Phlow is a small engine that makes it possible to link Brick slots to >> one another to enable flow of data. >> > > Sounds interesting! > > > >> >> Cheers, >> Doru >> >> >> >> On Mon, Feb 9, 2015 at 1:46 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: >> >>> For example GLMBrick subclass: #GLMPhlowBrick >>> in category: 'Glamour-Morphic-Brick-Phlow' >>> >>> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > > > -- www.tudorgirba.com "Every thing has its own flow"

Feb. 10, 2015