Energy usage per application ?

[Skybuck Flying]

Hello,

Here is a whacky idea:

Would it be possible to measure the energy usage per application ?

So that a user could easily see it... like the windowss' task manager ?

Bye,
Skybuck.

 

[Sylvia Else]

Hello,

Here is a whacky idea:

Would it be possible to measure the energy usage per application ?

So that a user could easily see it... like the windowss' task manager ?

Bye,
Skybuck.

Is that before or after you include the energy used by the program
that's showing you the energy usage?

In any case, the energy used by an application is not so clearly
defined. You could in principle measure the increase in energy used by
the computer as a result of running the program, but some of that
increase will be the result of interactions (such as memory, cache or
disk contention) with other programs. That is - stop another program,
and then run the program of interest again - and you could find that it
causes a lower increase than before.

It doesn't appear to be a very useful thing to measure.

Sylvia.

 

[D Yuniskis]

Hello,

Here is a whacky idea:

Would it be possible to measure the energy usage per application ?

Possible -- to what level of accuracy?

My multimedia RTOS has hooks that allow the OS to signal
applications as to the level of resource usage that it
should indulge (to conserve "power", processing power
and/or memory resources). This allows me to extend battery
life dynamically without prior knowledge of which
applications may be running at any given time.

(I don't think this is a novel idea. I think I have
taken it to a level of detail that other RTOS's have
previously neglected -- but, given time, that should change)

So that a user could easily see it... like the windowss' task manager ?

Hmmm... I hadn't thought of showing the user this information.
I'm not sure they could appreciate it sufficiently to know
how to *use* it (to, for example, prolong battery usage).
It seems a significant cognitive task to try to offload
onto the user.

Rather, I felt it smarter to let the design of the applications
keep this in mind so they can adapt their algorithms to the
resources that the RTOS considers "precious".

 

[Skybuck Flying]

Is that before or after you include the energy used by the program that's
showing you the energy usage?

In any case, the energy used by an application is not so clearly defined.
You could in principle measure the increase in energy used by the computer
as a result of running the program, but some of that increase will be the
result of interactions (such as memory, cache or disk contention) with
other programs. That is - stop another program, and then run the program
of interest again - and you could find that it causes a lower increase
than before.

It doesn't appear to be a very useful thing to measure.

I was thinking myself along the following lines:

Mostly the cpu's energy consumption would be measured... it might do so on
an instruction-to-instruction basis... but it would need to know what
application or system component/kernel it belongs too...

I had this idea after reading the absurd constraints by "Steve Jobs" on
programming the iPhone... He being worried that "non apple development
tools" would create bad iPhone applications ?! Speculation is that he is
worried about "Slow applications", "Bad applications" and "Energy hungry
applications".

"Steve" seems to be "be-litting" his own users

Instead how about giving the users more insight into the functioning of the
device by: "Task manager like thingy" and "energy like thingy"

Then users can decide for themselfes if they want or do not want to run
energy hogs, and system hogs etc

Bye,
Skybuck.

 

[Skybuck Flying]

Possible -- to what level of accuracy?

My multimedia RTOS has hooks that allow the OS to signal
applications as to the level of resource usage that it
should indulge (to conserve "power", processing power
and/or memory resources). This allows me to extend battery
life dynamically without prior knowledge of which
applications may be running at any given time.

(I don't think this is a novel idea. I think I have
taken it to a level of detail that other RTOS's have
previously neglected -- but, given time, that should change)


Hmmm... I hadn't thought of showing the user this information.
I'm not sure they could appreciate it sufficiently to know
how to *use* it (to, for example, prolong battery usage).
It seems a significant cognitive task to try to offload
onto the user.

I was thinking along the lines of a simple "percentage indication".

Somehow the system or cpu would know what the maximum energy consumption of
the device is...
(This could be pre-determined or it could also be measured as an "absolute
max" and/or "moving max" over time...)
(Or a percentage of the currenty total usage)

Therefore it should be possible to calculate a "usage percentage" per
application.
(Application Energy Percentage = (Application measurement / (Total or Max)
Measurement) * 100;

So I already described two modes:

1. The absolute would be interesting to see how much the system is being
stressed to it's absolute maximum point.
For example if total energy usage is only 1% of maximum system energy then
that's pretty good.

2. The current sitution would be interesting to see which application is
currently the biggest energy hog relative to the others.
This mode could further analyze that last 1% to see what is the biggest
hog... to try and cut it down even further
This mode would be best which would prevent system builders from setting the
maximum in 1 unrealistically high... so current/actual measurements
are much more trust worthy ?!

The user can then decide if he likes or does not like the application

And if he/she wants or does not want to run it... or find an alternative

It could also be usefull for data centers that want to safe on energy bills
and want developers to develop energy efficient application for as far as
possible.

Developers themselfes could also want to do that to try and prevent
"thermal/overheat/noise/dust" issue's

Rather, I felt it smarter to let the design of the applications
keep this in mind so they can adapt their algorithms to the
resources that the RTOS considers "precious".

Bye,
Skybuck

 

[D Yuniskis]

Hi Sylvia,

Is that before or after you include the energy used by the program
that's showing you the energy usage?

Ha! Good point! ;-)

In any case, the energy used by an application is not so clearly
defined. You could in principle measure the increase in energy used by
the computer as a result of running the program, but some of that
increase will be the result of interactions (such as memory, cache or
disk contention) with other programs. That is - stop another program,
and then run the program of interest again - and you could find that it
causes a lower increase than before.

This is true of many details "under the hood". E.g., many
operating systems try to "be fair" and divide the processors
resources (e.g., time) among concurrently executing tasks
by giving each a similar slice of time in which they are
granted use of the processor.

But, if one application "does something" that causes something
else to happen "some time afterwards" *and* that "something else"
unconditionally takes resources away from whatever is currently
executing (e.g., the first application causes some disk
activity to be initiated. That activity takes some time to
come to fruition. When it does, resources will be diverted
from whichever application is *currently* executed -- which
may not be the application that initiated the activity! -- so
that other application loses part of its time slice so the
processor can perform some activity that benefits the original
application)

The "power analogy" is similar. How do you "charge" the
application for the cost of its disk accesses? Do you
know the power differential involved in any *particular*
disk access? I.e., how much does the head actuator move?
How do you "charge" applications for the cost of keeping
the disk spinning? If application 1 is a "load once"
application that never needs the disk again, why should it
have to pay for a spinning disk that *it* would rather
see spun down??

It doesn't appear to be a very useful thing to measure.

Agreed. I think the smarter approach is to design an API that
lets application developers be aware of how their application
is operating at any given time. And, ways to tell that
application to "conserver" -- or not.

 

[D Yuniskis]

I was thinking myself along the following lines:

Mostly the cpu's energy consumption would be measured... it might do so on
an instruction-to-instruction basis... but it would need to know what
application or system component/kernel it belongs too...

I had this idea after reading the absurd constraints by "Steve Jobs" on
programming the iPhone... He being worried that "non apple development
tools" would create bad iPhone applications ?! Speculation is that he is
worried about "Slow applications", "Bad applications" and "Energy hungry
applications".

Developing code for very low power applications is an art.
Publishing SDK's for Joe Random Developer to develop any
sort of application he/she envisions without regard for
the constraints of the device exposed the user's impressions
of the device (and its manufacturer).

I.e., if every application was 100MB, then the iPhone would
look like an underpowered device.

If every application insisted on the radio being "on", then
the iPhone's battery would look like it was undersized.

If every application wanted to run in "Administrator mode",
then the inevitable security compromises would make the
iPhone look like an insecure device.

Etc.

Instead, developers need to be aware that you don't use
resources (memory, CPU, power, etc.) casually on a device
that is severely constrained, resource wise. I.e., those
folks who write desktop applications probably will be
writing bad iPhone applications!

"Steve" seems to be "be-litting" his own users

Instead how about giving the users more insight into the functioning of the
device by: "Task manager like thingy" and "energy like thingy"

Then users can decide for themselfes if they want or do not want to run
energy hogs, and system hogs etc

As Sylvia mentioned, you need to come up with a way of charging
each application for the actual TOTAL costs of its actions.

 

[Sylvia Else]

I had this idea after reading the absurd constraints by "Steve Jobs" on
programming the iPhone... He being worried that "non apple development
tools" would create bad iPhone applications ?! Speculation is that he is
worried about "Slow applications", "Bad applications" and "Energy hungry
applications".

He's probably justified. Whether due to ignorance, or just laziness,
developers seem able to use all of whatever computing resource is
available. Sometimes it's because they're doing new stuff that couldn't
be done before on lesser powered devices, but often it's just people
using less efficient algorithms - for example, linear searches rather
than binary cut or hash searches - because they're easier, and don't
cause obvious headaches on faster hardware. Until, that is, that faster
hardware is trying to do other things at the same time.

We also see more and more use of interpreted scripting languages for
tasks that really demand a compiled language. I'm waiting (I doubt I'll
wait long, if it doesn't exist already) for an interpreted scripting
language whose interpreter is written in another interpreted scripting
language.

Sylvia.

 

[Skybuck Flying]

<nonsense snipped>

I think good desktop application developers are well-aware that iPhones and
such have limited resources.

As well as application-tool developers.

For Steve Jobs/Apple to say that some tools are bad seems almost
slanderous...

He/they better be able to prove it !

Bye,
Skybuck =D

 

[[email protected]]

<nonsense snipped>

I think good desktop application developers are well-aware that iPhones and
such have limited resources.

As well as application-tool developers.

For Steve Jobs/Apple to say that some tools are bad seems almost
slanderous...

He/they better be able to prove it !

Bye,
Skybuck =D

Time is running out for you, son. You better become self-aware soon...