Now with Mavericks we can tell that Pharo is hungry for energy :) Cheers! Uko
I would not worry too much over this. I have MenuMeters even before I was introduced to smalltalk over a year ago and Pharo is steadily reported consuming a 5% of my CPU which is average for an ObjC app on Macos 10.7Â http://www.ragingmenace.com/software/menumeters/ So personally I am impressed with pharo speed so far. A big thumbs up from me. Also take into account that even though MacOS is a great OS it comes with its own fair share of bugs, especially the first year of its release so I would not put too much attention into this if I was you. On Monday, 28 October 2013, 18:08, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote: Now with Mavericks we can tell that Pharo is hungry for energy :) Cheers! Uko
Itâs not about the thing that it uses 5% CPU. Apple does some magic with optimisation so they group threads in order to reduce power usage. And Pharo is not good at that. Iâm not telling that Pharo is slow. Battery lasts longer with Safari compared to Chrome. Probably with Pharo itâs something similar. On 28 Oct 2013, at 17:31, dimitris chloupis <thekilon@yahoo.co.uk> wrote:
I would not worry too much over this. I have MenuMeters even before I was introduced to smalltalk over a year ago and Pharo is steadily reported consuming a 5% of my CPU which is average for an ObjC app on Macos 10.7
http://www.ragingmenace.com/software/menumeters/
So personally I am impressed with pharo speed so far. A big thumbs up from me. Also take into account that even though MacOS is a great OS it comes with its own fair share of bugs, especially the first year of its release so I would not put too much attention into this if I was you.
On Monday, 28 October 2013, 18:08, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote: Now with Mavericks we can tell that Pharo is hungry for energy :)
<Screenshot 2013-10-28 17.05.48.png>
Cheers! Uko
A greater than, say, 1% base CPU load from an otherwise idle application would indicate that it's doing some busy waiting somewhere... in my Activity Monitor, I don't see too many processes doing that, so just using an ObjC framework doesn't seem to be the guilty part. By the way, very old versions of VisualWorks used to be bad in that way, but not any more; so there is something that can be done about it. A large virtual memory working set wouldn't help either for power efficiency, though with today's RAM sizes it's probably less important. On Oct 28, 2013, at 11:46, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
Itâs not about the thing that it uses 5% CPU. Apple does some magic with optimisation so they group threads in order to reduce power usage. And Pharo is not good at that. Iâm not telling that Pharo is slow. Battery lasts longer with Safari compared to Chrome. Probably with Pharo itâs something similar.
On 28 Oct 2013, at 17:31, dimitris chloupis <thekilon@yahoo.co.uk> wrote:
I would not worry too much over this. I have MenuMeters even before I was introduced to smalltalk over a year ago and Pharo is steadily reported consuming a 5% of my CPU which is average for an ObjC app on Macos 10.7
http://www.ragingmenace.com/software/menumeters/
So personally I am impressed with pharo speed so far. A big thumbs up from me. Also take into account that even though MacOS is a great OS it comes with its own fair share of bugs, especially the first year of its release so I would not put too much attention into this if I was you.
On Monday, 28 October 2013, 18:08, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote: Now with Mavericks we can tell that Pharo is hungry for energy :)
<Screenshot 2013-10-28 17.05.48.png>
Cheers! Uko
There was already a discussion about this, search for the subject 'Pharo on Mac OS X 10.9 Mavericksâ. On 28 Oct 2013, at 18:37, Thomas Kendelbacher <tkendel@me.com> wrote:
A greater than, say, 1% base CPU load from an otherwise idle application would indicate that it's doing some busy waiting somewhere... in my Activity Monitor, I don't see too many processes doing that, so just using an ObjC framework doesn't seem to be the guilty part. By the way, very old versions of VisualWorks used to be bad in that way, but not any more; so there is something that can be done about it.
A large virtual memory working set wouldn't help either for power efficiency, though with today's RAM sizes it's probably less important.
On Oct 28, 2013, at 11:46, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
Itâs not about the thing that it uses 5% CPU. Apple does some magic with optimisation so they group threads in order to reduce power usage. And Pharo is not good at that. Iâm not telling that Pharo is slow. Battery lasts longer with Safari compared to Chrome. Probably with Pharo itâs something similar.
On 28 Oct 2013, at 17:31, dimitris chloupis <thekilon@yahoo.co.uk> wrote:
I would not worry too much over this. I have MenuMeters even before I was introduced to smalltalk over a year ago and Pharo is steadily reported consuming a 5% of my CPU which is average for an ObjC app on Macos 10.7
http://www.ragingmenace.com/software/menumeters/
So personally I am impressed with pharo speed so far. A big thumbs up from me. Also take into account that even though MacOS is a great OS it comes with its own fair share of bugs, especially the first year of its release so I would not put too much attention into this if I was you.
On Monday, 28 October 2013, 18:08, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote: Now with Mavericks we can tell that Pharo is hungry for energy :)
<Screenshot 2013-10-28 17.05.48.png>
Cheers! Uko
A greater than, say, 1% base CPU load from an otherwise idle application would indicate that it's doing some busy waiting somewhere... in my Activity Monitor, I don't see too many processes doing that, so just using an ObjC framework doesn't seem to be the guilty part. By the way, very old versions of VisualWorks used to be bad in that way, but not any more; so there is something that can be done about it.
if I'm correct there are some busy waiting process in the VM instead of an event based + semaphore architecture. We already removed some of the polling behavior at the image level but there are probably more and there was a discussion in the VM mailing list. Now I do not know the conclusion.
A large virtual memory working set wouldn't help either for power efficiency, though with today's RAM sizes it's probably less important.
The conclusion is: more work is required on both sides, VM and image. 2013/10/29 Stéphane Ducasse <stephane.ducasse@inria.fr>
A greater than, say, 1% base CPU load from an otherwise idle application would indicate that it's doing some busy waiting somewhere... in my Activity Monitor, I don't see too many processes doing that, so just using an ObjC framework doesn't seem to be the guilty part. By the way, very old versions of VisualWorks used to be bad in that way, but not any more; so there is something that can be done about it.
if I'm correct there are some busy waiting process in the VM instead of an event based + semaphore architecture. We already removed some of the polling behavior at the image level but there are probably more and there was a discussion in the VM mailing list. Now I do not know the conclusion.
A large virtual memory working set wouldn't help either for power efficiency, though with today's RAM sizes it's probably less important.
participants (6)
-
dimitris chloupis -
Nicolas Cellier -
Stéphane Ducasse -
Sven Van Caekenberghe -
Thomas Kendelbacher -
Yuriy Tymchuk