CPU SPEED

[jdc4429]

Hi Dianne,

Could you please elaborate on the below comment you made regarding the
G1's
processor speed. Does that mean it's not running at 500mhz? Can that
be changed in software on the fly and was it set below maximum speed
to help with the battery issue?

Also is anyone working on adding hardware acceleration so we can take
full advantage of the processor?

Thanks
Jeff

> Date: Wed, Nov 26 2008 3:23 am
> From: "Dianne Hackborn"
>
>
> Uh, there is a lot more going on in that UI than just doing transparent
> drawing. Also currently all drawing within a window is not hardware
> accelerated so must be done in software. And the G1's processor runs at
> well below 500MHz, and doesn't have a wonderful memory bus.

[Jean-Baptiste Queru]

Indeed, the CPU in the G1 is clocked lower than its maximum rated
speed to conserve battery life. It's running somewhere between 300 and
400MHz if I remember correctly.

JBQ

[Romain Guy]

> Can that
> be changed in software on the fly and was it set below maximum speed
> to help with the battery issue?

No and yes :)

> Also is anyone working on adding hardware acceleration so we can take
> full advantage of the processor?

We have a prototype of SGL running on top of OpenGL (it was actually
shown publicly in the SDK 0.9) but it's not the correct solution at
the moment.

>
> Thanks
> Jeff
>
>> Date: Wed, Nov 26 2008 3:23 am
>> From: "Dianne Hackborn"
>>
>>
>> Uh, there is a lot more going on in that UI than just doing transparent
>> drawing. Also currently all drawing within a window is not hardware
>> accelerated so must be done in software. And the G1's processor runs at
>> well below 500MHz, and doesn't have a wonderful memory bus.
>

--
Romain Guy
www.curious-creature.org

[blindfold]

Interesting. I wonder how this will affect benchmarks against the Sony
Ericsson Xperia X1, which just like the T-Mobile G1 sports a 528 MHz
Qualcomm CPU. I do not know if the X1 also throttles the CPU down in
order to save battery power at the expense of speed.

[Dianne Hackborn]

It's not uncommon for phones to be running their CPU lower than their max spec'd speed, since often you can get a big decrease in power consumption by running a little slower.  (Also in the desktop world, where people who want "silent" computers will lower their clock rate a bit which can give a big enough decrease in power consumption to reduce the amount that fans need to run.)

I have no idea what speed anything else is actually running at though.  In general on phones, though, raw speed takes a back seat to other more important things like battery life, size, and cost.

--
Dianne Hackborn
Android framework engineer
hac...@android.com

Note: please don't send private questions to me, as I don't have time to provide private support.  All such questions should be posted on public forums, where I and others can see and answer them.

[Romain Guy]

In our tests, bumping the CPU speed to 528 Mhz brought very little
compared to what it cost in terms of battery life.

On Wed, Nov 26, 2008 at 10:49 AM, blindfold <seeingw...@gmail.com> wrote:
>

--
Romain Guy
www.curious-creature.org

[jdc4429]

Hi Jean

Thanks for the quick reply.

Can you explain how the CPU speed is set? Is this programmable? Could
this be an option added to the settings menu so the user can make the
decision rather then someone making that decision for us?

Some people might also want the reverse where it can be downgraded
even further to extend the battery even longer.


Thanks
Jeff

On Nov 26, 1:37 pm, Jean-Baptiste Queru <j...@google.com> wrote:
> Indeed, the CPU in the G1 is clocked lower than its maximum rated
> speed to conserve battery life. It's running somewhere between 300 and
> 400MHz if I remember correctly.
>
> JBQ
>

[Jean-Baptiste Queru]

I have no idea about that, sorry.

JBQ

[Dianne Hackborn]

Oh yeah that's another good point -- almost all of my experience on mobile hardware has been that the memory bus speed was far more of a performance bottleneck than the CPU was.  It generally just wasn't useful to run the CPU at its fastest speed and consume more power, because most of what it would be doing was sitting there waiting on memory.

You already see in the desktop world that raw CPU clock speed is not a very good indicator of the actual performance of your machine.  I've found this is even more the case in mobile devices.

[Dianne Hackborn]

On Wed, Nov 26, 2008 at 11:07 AM, jdc4429 <jdc...@gmail.com> wrote:

Some people might also want the reverse where it can be downgraded
even further to extend the battery even longer.

There are already lots of things done with the CPU to conserve battery; reducing the maximum speed it will run probably won't have much impact, unless you have some app sitting there spinning the cpu all of the time (and then you really have far worse problems).

[blindfold]

So rather than raw CPU speed the main speed bottleneck is then
possibly that "the memory bus is terribly slow" as you mentioned at
http://groups.google.com/group/android-platform/browse_thread/thread/a127495c6d0b2c37/
and also like Dianne notes in saying "almost all of my experience on

mobile hardware has been that the memory bus speed was far more of a
performance bottleneck than the CPU was".

I acknowledge that with mobile phones effective CPU speed is mostly
sacrificed for battery life and cost savings. It's just a bit strange
that the G1 specs that I had seen until now boasted, without
restraints, a 528 MHz CPU. I'm with Jeff that it would be nice if
there were user options to influence the trade-off. I apply that with
my UMPC all the time depending on whether I mostly need silence or
speed.

Thanks

[blindfold]

> reducing the maximum speed it will run probably won't have much impact,
> unless you have some app sitting there spinning the cpu all of the time
> (and then you really have far worse problems).

You mean that the phone will overheat, or what? My users (of the Java
ME version, that is) are generally willing to sacrifice battery life
and even UI responsiveness to obtain acceptable performance.

Thanks

On Nov 26, 8:11 pm, "Dianne Hackborn" <hack...@android.com> wrote:

> On Wed, Nov 26, 2008 at 11:07 AM, jdc4429 <jdc4...@gmail.com> wrote:
> > Some people might also want the reverse where it can be downgraded
> > even further to extend the battery even longer.
>
> There are already lots of things done with the CPU to conserve battery;
> reducing the maximum speed it will run probably won't have much impact,
> unless you have some app sitting there spinning the cpu all of the time (and
> then you really have far worse problems).
>
> --
> Dianne Hackborn
> Android framework engineer

> hack...@android.com

[Dianne Hackborn]

On Wed, Nov 26, 2008 at 11:59 AM, blindfold <seeingw...@gmail.com> wrote:

> reducing the maximum speed it will run probably won't have much impact,
> unless you have some app sitting there spinning the cpu all of the time
> (and then you really have far worse problems).

You mean that the phone will overheat, or what? My users (of the Java
ME version, that is) are generally willing to sacrifice battery life
and even UI responsiveness to obtain acceptable performance.

I'm not sure about what is being talked about now, but all I was saying was that there are already things done to reduce CPU usage when no work is to be done, so lowering the CPU clock speed any further would have little appreciable difference...  except for the case of apps that have a thread running in the background all of the time, but that whether or not you reduce the CPU speed this is going to be a big drain on the battery so it really doesn't matter and it would be better to fix the app.

As far as increasing the CPU speed, that is not supported.

--
Dianne Hackborn
Android framework engineer

[blindfold]

Some apps, including mine, need to run CPU-intensive algorithms
(nearly) continuously, so it is not a matter of "fixing the app". It
may be more a matter of unconventional uses of mobile phone
technology, with different priorities. T

> As far as increasing the CPU speed, that is not supported.

OK, good to know.

On Nov 26, 9:48 pm, "Dianne Hackborn" <hack...@android.com> wrote:
> I'm not sure about what is being talked about now, but all I was saying was
> that there are already things done to reduce CPU usage when no work is to be
> done, so lowering the CPU clock speed any further would have little
> appreciable difference...  except for the case of apps that have a thread
> running in the background all of the time, but that whether or not you
> reduce the CPU speed this is going to be a big drain on the battery so it
> really doesn't matter and it would be better to fix the app.
>
> As far as increasing the CPU speed, that is not supported.
>
> --
> Dianne Hackborn
> Android framework engineer

> hack...@android.com

[Dianne Hackborn]

On Wed, Nov 26, 2008 at 1:32 PM, blindfold <seeingw...@gmail.com> wrote:

Some apps, including mine, need to run CPU-intensive algorithms
(nearly) continuously, so it is not a matter of "fixing the app".

Continually running CPU-intensive code in the background is something you just should not do.  You'll reduce the phone's battery life from days down to hours.  A big reason why phones have decent battery life is because they take a lot of care to -not- do stuff.

--
Dianne Hackborn
Android framework engineer

hac...@android.com

[jdc4429]

Dianne,

In reference to your comments:

> It's not uncommon for phones to be running their CPU lower than their max
> spec'd speed, since often you can get a big decrease in power consumption by
> running a little slower. (Also in the desktop world, where people who want
> "silent" computers will lower their clock rate a bit which can give a big
> enough decrease in power consumption to reduce the amount that fans need to
> run.)

I think in the desktop world the same issue would apply... If you paid
for a 2Ghz CPU and were only allowed to
run it at 1.3Ghz you would not be a happy camper. A key statement you
made was "people who want silence" which shows they have a choice... I
think we should also be given a choice. We did pay for a 528mhz CPU.

I don't know if you misunderstood the question in the beginning so I
will reiterate:

I asked if the CPU was limited. I was told it is limited to 350Mhz.
I asked if a setting could be added to allow the user to decide if
they wanted to run the CPU at the rated speed (Not overclocked) or
slow it down to conserve power. Or better yet as a secondary setting,
add the ability for it to detect a high load and up the speed
accordingly to match the demand. I would still want to be able to
scale the CPU if desired manually. I don't see adding these settings
as being an issue unless we have a design flaw that will not allow for
the power dissipation at the rated speed or these chips are only rated
or licensed to run at 350mhz and we were misguided into believing they
were rated for 528mhz.

As far as it not being uncommon for phones to lower the max CPU, I
bought this phone because of the advances putting it more in line with
a portable computer then a phone and I believe many others purchased
it for this reason as well. I already have a Palm TX. I was looking
for something to go to the next level. I hope this will be it.
Getting Flash released (which I'm sure along with the browser is very
CPU intensive) will be a nice step in that direction.

In reference to:

> I have no idea what speed anything else is actually running at though. In
> general on phones, though, raw speed takes a back seat to other more
> important things like battery life, size, and cost.

I don't understand what this means? "what speed anything else is
running at"

OS vs. Apps ? main processor vs. co-processor?

Also regarding this comment:

> There are already lots of things done with the CPU to conserve battery;

> reducing the maximum speed it will run probably won't have much impact,
> unless you have some app sitting there spinning the cpu all of the time (and
> then you really have far worse problems).

That seems to contradict your previous statement saying that this was
done to help conserve the battery.
I also thought that the ARM CPU's already had many power optimizations
built in already?

Thanks
Jeff

On Nov 26, 4:38 pm, "Dianne Hackborn" <hack...@android.com> wrote:

> On Wed, Nov 26, 2008 at 1:32 PM, blindfold <seeingwithso...@gmail.com>wrote:
>
> > Some apps, including mine, need to run CPU-intensive algorithms
> > (nearly) continuously, so it is not a matter of "fixing the app".
>
> Continually running CPU-intensive code in the background is something you
> just should not do.  You'll reduce the phone's battery life from days down
> to hours.  A big reason why phones have decent battery life is because they
> take a lot of care to -not- do stuff.
>
> --
> Dianne Hackborn
> Android framework engineer

> hack...@android.com

[Dianne Hackborn]

Sorry, I don't have time to respond point by point, but basically:

- The android platform does not have a user setting to adjust the CPU speed, and there is no plan at this point to add one.

- Issues with the G1 hardware would really be better taken up with T-Mobile; software engineers working on the Android platform just can't help you here.  We can tell you what we know about the hardware, but that is about all.

hac...@android.com

[blindfold]

> Continually running CPU-intensive code in the background is something
> you just should not do.

This is up to the user to decide. Of course the user should be
informed that the app may drain the battery more quickly.

> You'll reduce the phone's battery life from days down to hours.

Yes, so the informed user may decide to run the app continuously only
for minutes at a time.

Regards

On Nov 26, 10:38 pm, "Dianne Hackborn" <hack...@android.com> wrote:

> On Wed, Nov 26, 2008 at 1:32 PM, blindfold <seeingwithso...@gmail.com>wrote:
>
> > Some apps, including mine, need to run CPU-intensive algorithms
> > (nearly) continuously, so it is not a matter of "fixing the app".
>
> Continually running CPU-intensive code in the background is something you
> just should not do.  You'll reduce the phone's battery life from days down
> to hours.  A big reason why phones have decent battery life is because they
> take a lot of care to -not- do stuff.
>
> --
> Dianne Hackborn
> Android framework engineer

> hack...@android.com

[blindfold]

> - Issues with the G1 hardware would really be better taken up with T-Mobile;
> software engineers working on the Android platform just can't help you
> here. We can tell you what we know about the hardware, but that is about
> all.

Romain stated "In our tests, bumping the CPU speed to 528 Mhz brought
very little compared to what it cost in terms of battery life,"
suggesting that you (Android Team) do have control over CPU speed
available in development. His post did not read "In T-Mobile's
tests, ...".

[Jean-Baptiste Queru]

Our systems team has been in close collaboration with HTC (which
manufactures the G1) and was able to change the CPU speed for testing
purposes at some point during the development phase, which allowed the
Android team as a whole to explore multiple options in terms of user
experience and power consumption, and found that the speed that was
eventually settled on seemed to be the overall "sweet spot", though
obviously a single speed couldn't possibly satisfy both the most
frugal and the most hungry apps.

As far as cell phones go, the CPU in the G1 (at its current clock
speed) is quite speedy, and I wouldn't be surprised to see Android run
on phones with significantly less power at some point. If your app has
critical difficulties running on the G1 as it is, you should expect
that you'll find similar or worse difficulties on other devices in the
future.

JBQ

[jdc4429]

Hi Jean,

So your saying that the CPU speed is not controlled by the Android
software?
I was looking through the code and found this in the arch/arm/mach-msm/
clock.c file...

617 #define CPUFREQ_TABLE_MAX 4
618 static struct cpufreq_frequency_table cpufreq_table[] = {
619 { 0, 81920 },
620 { 1, 122880 },
621 { 2, 245760 },
622 { 3, 384000 },
623 { CPUFREQ_TABLE_MAX, CPUFREQ_TABLE_END },
624 };

It looks like the max speed is set to 384mhz and it seems it can be
easily changed.
It also seems that the phone already downshifts the CPU based on this
table and the
screen_open/closed speed setting...


702 if (screen_on) {
703 policy->user_policy.min = cpufreq_table
[2].frequency; // 245mhz
704 policy->user_policy.max = cpufreq_table
[3].frequency; // 384mhz
705 } else {
706 policy->user_policy.min = cpufreq_table
[0].frequency; // 82mhz
707 policy->user_policy.max = cpufreq_table
[2].frequency; // 245mhz
708 }

Sure looks controllable to me through Android. Is it really that hard
to add a setting to allow min/max settings
to be adjusted by the user?

Thanks
Jeff

On Nov 27, 9:35 am, Jean-Baptiste Queru <j...@google.com> wrote:
> Our systems team has been in close collaboration with HTC (which
> manufactures the G1) and was able to change the CPU speed for testing
> purposes at some point during the development phase, which allowed the
> Android team as a whole to explore multiple options in terms of user
> experience and power consumption, and found that the speed that was
> eventually settled on seemed to be the overall "sweet spot", though
> obviously a single speed couldn't possibly satisfy both the most
> frugal and the most hungry apps.
>
> As far as cell phones go, the CPU in the G1 (at its current clock
> speed) is quite speedy, and I wouldn't be surprised to see Android run
> on phones with significantly less power at some point. If your app has
> critical difficulties running on the G1 as it is, you should expect
> that you'll find similar or worse difficulties on other devices in the
> future.
>
> JBQ
>

[Jean-Baptiste Queru]

You've been reading a little bit too much in my words. I said that at
some point in time it was decided that the CPU speed that is currently
used in the G1 was a reasonable compromise.

I'm not a hardware or kernel guy, so I don't know whether the CPU
speed could be adjusted dynamically.

It's probably a much harder problem than it seems.

JBQ

[blindfold]

Thank you for this information, Jean-Baptiste!

> If your app has critical difficulties running on the G1 as it is, you
> should expect that you'll find similar or worse difficulties on other
> devices in the future.

For Android-based devices, yes, unfortunately. Not for other platforms
such as Nokia/Symbian, where I already obtain real-time performance
with exactly the same source code for my CPU-intensive core routines
(pure Java functions that compile without change as both Java ME and
Android). In fact I get fairly acceptable performance even on my old
Nokia 6680 with its 220 MHz ARM CPU, well below the clock frequency of
the throttled-down (~350 MHz) ARM CPU of the G1. So it looks like even
a factor two in CPU clock frequency cannot bridge the current
performance gaps, and either hardware acceleration a la ARM Jazelle or
JIT byte code compilation is needed for Dalvik to maybe gain an order
of magnitude or so in computational performance.

See also a few early G1 performance benchmark attempts that I found at
http://occipital.com/blog/2008/10/31/android-performance-2-loop-speed-and-the-dalvik-vm/
and http://occipital.com/blog/2008/11/02/android-performance-3-iphone-comparison/

Now since battery life of the G1 is reportedly mediocre at best, one
cannot convincingly argue that Dalvik was used for a longer battery
life, while memory (to support a JIT approach) is only getting
cheaper. Indeed the CPU in the G1 itself looks mostly speedy enough,
so I think it is rather the (Dalvik) bytecode handling where vast
improvements are needed - and possible. I'm looking forward to the
further maturation of the Android platform and its implementations.
Can you disclose something about plans for future JIT or Jazelle
support for Android devices?

Thanks and regards

[Jean-Baptiste Queru]

Those potential features that you're talking about aren't mentioned in
the official android roadmap, and there is therefore nothing I can
disclose in that area.

It's my understanding that the Jazelle instructions are extremely
tightly tied to specific implementations of virtual machines that run
a specific bytecode, and that Dalvik doesn't fall in that category.
I'm neither an ARM or a virtual machine expert. I understand just
enough to guess that work in that area involves more than a couple
hours of idle engineering time.

I will point out however that memory in the G1 isn't going to get
cheaper. While the Android platform might evolve over time, the
hardware that's in users' hands today won't.

JBQ

[blindfold]

Hi Jeff,

> It also seems that the phone already downshifts the CPU based on this
> table and the
> screen_open/closed speed setting...

So maybe there is some indirect control available to Android
applications by setting, say, a FULL_WAKE_LOCK with
android.os.PowerManager, to at least prevent the clock frequency from
dropping well below 384 MHz?

Regards

[blindfold]

Thanks again, Jean-Baptiste. I fully understand that those features
(JIT, Jazelle support) are far from trivial to implement, but as
Android and Java ME application developers we try to form an informed
opinion about which platforms offer which benefits, as well as obtain
an outlook on expected future changes in the respective benefits. You
may well be right that Dalvik and Jazelle do not make a good match. My
point about memory cost was just that JIT was already applied in the
mobile phone market long before Android and G1 appeared, and
apparently the cost was not prohibitive even at that time. Since then,
memory prices per bit have dropped. With future Android devices,
memory prices are likely to drop still further.

Regards

[Jean-Baptiste Queru]

Sounds good to me.

Do keep in mind that the design constraints of a classic Java ME
environment (where there's typically only one application running at a
time, in an amount of RAM that's often fixed) are quite different from
those of Android (where it's not uncommon to have a dozen or more
VM-containing processes sharing a single CPU and a single pool of
RAM).

It would be sad if running applications in Android became so
memory-heavy that you couldn't have multiple of them providing
services to one another.

JBQ

[jdc4429]

I would think the power control on Android would already throttle up
if needed to 384. Unless the screen is off... then it's less by
looking at that code... I'm not too worried about that.. I'm more
worried about how every time I turn around I'm learning just how
closed Android really is... I guess I can only hope they start to
realize that they are only hurting themselves (and those like me who
bought the phone sight unseen believing in Google) by limiting what
people can do with the G1 and truly open up the platform. All these
limits get out to the general public and destroy sales.. All people
are going to hear is... I bought a phone with a really cool CPU that
can only run at 2/3 it's rated speed... Oh they also only have 192mb
of ram and like 75mb to store apps in... It doesn't have flash
support, and I can't store apps on my memory card. Has really cool 3d
acceleration on the CPU but they didn't enable hardware acceleration
either. And they said it was open, but wont allow people to have root
access or create/use other images.

Would you buy that phone? I think the response would be along the
lines.. Wow, You really got screwed.

Thanks for listening...

Jeff

[blindfold]

I get your point, but I'm not quite convinced. Just to get back to
that Nokia 6680: it uses JIT and AFAIK it has just 10 MB RAM, against
192 MB RAM for the non-JIT G1. So theoretically the G1 should be able
to have 19 processes with JIT running? Even with for some overhead,
that likely allows well over a dozen processes with JIT. :-)

Also, the JIT-compiled native code of inactive or background processes
may to a large extent be discarded until a process is reactivated or
brought to the foreground. Lots of room for hybrid approaches, e.g.
with JIT only applied to one (say foreground) process. I have no idea
to what extent having a single pool of RAM would have to be a
showstopper.

Regards

[blindfold]

> Would you buy that phone?

No. I've learnt enough about the G1 now to skip the first generation
of Android phones, even as a developer who is eager to explore new
technologies and build on that. In addition to what you have mentioned
I ran into too many problems with Android's camera processing and
audio output. Maybe a next major SDK release and firmware upgrade will
change my mind, but there is virtually no information on what
improvements to expect from that, and when.

Regards

[Gary13579]

I am still shocked, day by day, at how closed Android truly is. I can
understand locking off root because of agreements with T-Mobile. It
sucks, but I understand. I can understand not storing applications on
the SD card because it would open them up to cracks (which have still
happened anyway. FireWallet has a key generator out there already). I
can even understand not letting us flash our own versions.

But honestly? Not letting us change the CPU frequency? That is an
option that should be left up to the end user. It would take no more
than 10 minutes to implement it into the code, along with UI and all.
Yes, it may still be bottle necked by memory bus. Sure, it'll kill
your battery. But this is not some insane request that we're asking
for; we simply want just a *tiny* bit more control of this "open"
platform.

I'm truly glad that a root exploit was found so fast, and that at
least some people have the control they should over their phone. I
love the idea behind Android, OHA, and Google. But honestly, get your
act together...

[Jean-Baptiste Queru]

All right, let's start to discuss a design.

I propose a special kind of wake lock that requires a specific
permission to acquire (so that users can know which applications can
request battery-killing privileges), such that acquiring that wake
lock would clock the CPU higher for as long as it's held.

Because there's been a lot of user-level discussion about putting
users in control of more aspects of their phones, and since there've
been a lot of comments about the G1's battery life when under heavy
use, I think it's also necessary to allow users to turn that wake lock
into a no-op.

I suggest that you wait a bit after the holiday week-end to let all
competent parties give their opinion, so that the design can be
refined before you spend too much time working on the implementation.

JBQ, looking forward to reviewing those patches.

[Romain Guy]

There are overheating issues with running at 528 Mhz on the G1. The hw
is not stable at the frequency.

On Fri, Nov 28, 2008 at 6:45 PM, Gary13579 <Gary...@gmail.com> wrote:
>

--
Romain Guy
www.curious-creature.org

[Jean-Baptiste Queru]

Yup. There's no guarantee that the functionality in question would be
exposed in the G1 (or in any other device for that matter) even if it
was implemented in the core of Android.

As usual, it is critically important to understand the fundamental
difference between Android (the Open-Source project) and devices that
run derivatives of Android. Nothing in the license of the Android
source code prevents a device manufacturer from adding and removing
functionality relative to the baseline provided by Android itself.

If a manufacturer is worried about their device's stability or
integrity when running the CPU at a higher clock than the default one,
they've got full power to decide whether that specific capability
increases a given device's value more than it increases its costs, and
whether to include it in their devices.

Also, back on topic for the specific feature of varying the CPU speed,
the issues of user interface have to be resolved: it's important to
figure out how many users will care about such a feature at all, and
how sternly the message has to be worded for most users to understand
that they're trading a lot of battery life for a little speed.

JBQ

[Joe Onorato]

Like all software projects, some features were cut because we didn't have time to build and test them.  Some features were cut because it won't be a frequently enough used feature to warrant a settings panel.  If we had a settings option for every kernel parameter, the settings panel would be even harder to navigate than it already is.

Now, it could be in Spare Parts or some other extras app, but even putting it in there requires engineering work.  Don't pretend that that's free, because scarce engineering resources are by far the limiting factor on Android development.

When you demand a feature, unless you're volunteering the resources to design, implement, QA and maintain it, you have to consider which other feature you want to cut instead.

-joe

[blindfold]

Hi Jean-Baptiste and all,

> I propose a special kind of wake lock that requires a specific
> permission to acquire (so that users can know which applications can
> request battery-killing privileges), such that acquiring that wake
> lock would clock the CPU higher for as long as it's held.

I'm all for it! In fact I already inquired about "abusing" the
existing (mostly screen lighting oriented) wake locks for this
purpose. A dedicated wake lock for the CPU - maybe with a user note on
reduced battery lifetime for higher speed associated with the
permission - is a good idea. Thanks.

Joe notes

> Some features were cut because it won't be a frequently enough used
> feature to warrant a settings panel. If we had a settings option for
> every kernel parameter, the settings panel would be even harder to
> navigate than it already is.

I agree. An extended wake lock set as proposed by Jean-Baptiste would
get around this problem by not extending the phone's already large
standard set of user settings but instead letting applications that
need it expose the relevant (for the particular app) CPU options to
the user via their own menus or dialogs. Then the trade-off between
needed functionality and settings clutter is moved to the application,
which can limit settings clutter by only exposing those settings that
are relevant to that particular application. So an extended wake lock
set could largely avoid/solve this problem.

BTW, also I wonder if we need another wake lock for audio output,
because for me (and I'm sure for many other future audio apps,
including screen readers for blind accessibility in listening to long
texts) the audio output acts as a screen that must be kept alive just
like the normal screen for other applications. Right now it is
unspecified whether any of the screen wake locks also keep the audio
device alive (maybe any running audio already does? I've no idea), and
a dedicated audio wake lock would seem more elegant while allowing the
screen to go dim or dark to save battery power.

BTW 2, I do not know if the G1/Android has hard limits on the screen
saver timing, but for most Nokia phones that I know the user cannot
set the time before the screen saver kicks in beyond 30 minutes (with
a default of 5 minutes or so). This too is annoying for apps that need
to be able to run over 30 minutes without user interaction, and some
means to optionally extend this time limit is desired. Even a "battery-
killing" app might easily run for over an hour before the battery is
drained, and if an AC adapter is detected then obviously there should
not be any hard limit on application runtime, e.g., for apps that use
the camera to continuously or periodically monitor the environment
without user intervention.

Thanks for the overheating note, Romain. This I can understand as a
physicist, and for developers it is good to know that this is a main
reason for the currently imposed clock frequency limits.

Regards

Peter

[Jean-Baptiste Queru]

-If you had asked me 6 weeks ago, I'd have said that there was no need
for a user setting and that a permission would be enough. Right now,
given the user outcry about battery life when running certain
applications, I have to reverse my position and say that any new
feature that significantly cuts battery life (and we're talking about
cutting it by half here) compared to the original "baseline" release
must be user-controllable. That's just my individual opinion as an
engineer, though, and since that's not my code I'm mostly sitting on
the sidelines here.

-When talking about AC power, let's not lose from sight that most
people plug into AC power to recharge their phones. Using too much
power while the device is plugged in could significantly slow down the
charging rate, and in some extreme cases could even use so much power
that the device would continue discharging while plugged in (!). It
might make sense to let users control high-drain features (like an
increased CPU clock) with 4 different levels: allow always, only when
plugged in, only when plugged in and fully charged, never.

-On devices that have a temperature sensor for the relevant parts of
the hardware, controlling high-drain features for those parts of the
hardware based on the temperature sounds like it could protect the
hardware better.

JBQ

[blindfold]

Yes, there will always remain some tension between the outcry for
battery life versus the demand not to be patronized by suppliers in
what one is or is not allowed to do with one's device - even at the
expense of battery life. From what I've read over time, most device
owners feel that they are entitled to do with their device whatever
they want, and make their own trade-offs where needed. Informing the
user about possible consequences of his choices can prevent user (and
developer) frustration while minimizing usage restrictions. The latter
is also important for opening up new application areas and hence new
markets.

> -When talking about AC power, let's not lose from sight that most
> people plug into AC power to recharge their phones.

I agree. However, some users will want to have their phone do some
useful tasks while charging, ranging from the camera-based monitoring
that I mentioned to checking for e-mail or RSS feeds and giving event
alarms whenever something is detected according to the information
filters that the user has set. Most users will understand that this
can slow down charging, but the supplier does indeed need to cover
"cat in the microwave" liability risks by applying a reasonable effort
at informing the user of possible implications of his choices, through
disclaimers and warnings in the device manual and at runtime when
overriding certain default (conservative) device settings. Beyond that
it is mostly the user's responsibility. Where to draw the line is a
matter of considering the term "reasonable effort" in relation to
usage nuisances. The infamous Windows Vista UAC security popups
probably went too far and only increased user frustration without
noticeably increasing security. Should Android pop up a user warning
whenever the sound volume is set to a higher-than-default level,
notifying the user of risks of hearing damage in long-term listening
at high volume? What about getting warnings when making long phone
calls in relation to possible adverse health effects (brain cancer)?
These things are perhaps better put in the manual that comes with the
device, to minimize user annoyance. For the CPU clock frequency in
relation to battery life this remains to be decided, but I guess the
percentage of applications that need the extra speed at the expense of
battery life is relatively low, such that the user will in practice
not be bothered often by having to check yet another permission (only)
when installing applications, like mine, that need the associated
permission.

> -On devices that have a temperature sensor for the relevant parts of
> the hardware, controlling high-drain features for those parts of the
> hardware based on the temperature sounds like it could protect the
> hardware better.

Definitely. As an anecdotal side note: it regularly happens that my
notebook PC overheats while running my app on the Android emulator,
causing the PC to suddenly turn off without prior notice! This only
happens with the Android emulator. :-)

Regards

[Jean-Baptiste Queru]

-I don't think that this discussion has anything to do with what's
allowed or forbidden. Like Joe explained earlier in the thread, the
issue was purely about working with limited engineering resources, and
therefore having to prioritize the various features.

-I'm not convinced that "most device owners" actually feel that they
have the kind of issues that you mention. That might be true of a
certain minority that is very vocal on some areas of the Internet that
are highly visible to you personally, but it doesn't clearly
extrapolate to the entire population of G1 users. I'm not in a
position to have definitive statistics in that area, though, so your
guess is as good as mine.

-I'm sadly quite sure however that informing users doesn't mean that
users will understand the consequences of their decisions. Support
calls where the user complains about battery life and the support
person guides the users through the advanced settings to check whether
the "high CPU speed" option was activated still cost money to the
operator (and if there's no such option, things get much worse).

JBQ

[blindfold]

> Like Joe explained earlier in the thread, the issue was
> purely about working with limited engineering resources,
> and therefore having to prioritize the various features.

OK, as I've also outlined earlier in this thread, CPU clock frequency
control helps but is not going to make a huge and overall decisive
difference, and a prioritization towards JIT compilation seems much
more fruitful. It can give a dramatic performance boost without
draining the battery - potentially even *saving* much battery power
when done right, because instructions need not be re-interpreted over
and over. These gains appear possible without bothering the user with
additional settings and permissions, but yes, they do take effort and/
or money to implement. The memory argument against JIT compilation has
already been proven highly questionable if not plain wrong by actual
devices on the market and their memory use versus performance (see
also my earlier Nokia 6680 example in this thread).

[The overheating of my PC while running the Android emulator is
actually another nice example of what happens when there is a poor
match between used instructions and native machine instructions. My
native Windows version of the app does much more complex (sound)
processing at far less dissipation. My UMPC does not even activate its
fan while running it.]

In case you would say that the Android Team lacks engineering
resources (or expertise) to develop a JIT compiler, perhaps consider
trying to convince your management that they need to buy the JIT
technology to get on par with other platforms? I would suggest that it
is about time that it gets on the (official or unofficial) Android
roadmap. The last time I heard the Android Team talk favorably about
adding JIT compilation to Android was over a year ago, in a post by
Dan Morril reading "However, a just-in-time compiler is definitely on
the Dalvik roadmap, and you can be sure that we'll have discussions
about it here" http://groups.google.com/group/android-developers/browse_thread/thread/c4a8b4d97f408b17/
(November 12, 2007).

Well, that discussion is here, now. :-)

Regards

[Jean-Baptiste Queru]

We're getting off-topic here, as most of the aspects that you are
mentioning are only loosely related to CPU speed. I don't think that
anyone needs to be convinced that the current implementation of
Android isn't the only possible option on a diagram of RAM - storage -
speed - battery - portability - familiarity - ease of development -
breadth of APIs, everybody knows that there are definitely other
options out there. It is now time to move to constructive discussions
about the different aspects, feel free to do so on separate threads
dedicated to the individual aspects (so, the discussion can happen
right now, but please not quite right here).

Back to the issue of CPU speed:

-The CPU in the G1 runs at a lower speed than what the chip could
support in ideal conditions. Higher speeds could result in issues of
stability or device integrity, would lower the battery life, and would
likely increase the speed of some applications. The CPU speed is not
the only factor in overall application speed.

-Android currently has very limited capabilities in terms of varying
the CPU speed based on the operating conditions. Design discussions
and code contributions are welcome. We've already established that
regressions in the domain of battery life for similar use cases are
unlikely to be acceptable.

-Do not assume that adding that ability in Android will automagically
mean that the G1 can be made to run at a higher clock. You could find
that that ability gets hooked to a no-op in the G1, or even that it is
used to lower the default clock speed for most applications except the
ones that explicitly request the "higher" speed, which would be
identical to the current speed.

JBQ

[blindfold]

> We're getting off-topic here

I came to that because you made the more general statement that "the

issue was purely about working with limited engineering resources, and

therefore having to prioritize the various features". I would not want
to waste your limited engineering resources on lesser issues. I don't
think anyone cares about CPU speed in terms of clock frequency if that
raw speed gets wasted through the software layers that sit on top of
that CPU. Nobody cares about having a 10 THz CPU if it does not
improve net computational performance. Once we could agree that, say,
JIT compilation has for now priority 1, and CPU clock frequency
priority 2, we can next split the threads to zoom into the respective
options like you propose. Romain mentioned the G1 memory bus as
another important performance bottleneck, and that might make
increasing or not lowering the CPU clock frequency even less effective
as compared to adding JIT compilation. We really need to first
identify and understand Android's main performance bottlenecks and
associated options for performance improvement, and not let us get
distracted at this point by the original subject line that happens to
be slightly more narrow in scope. Some drift is normal. We don't want
to restart the speed discussion in a new thread labelled
"computational performance", do we? However, I will concede if other
developers think differently.

Regards

> > about it here"http://groups.google.com/group/android-developers/browse_thread/threa...

[blindfold]

Hi All,

I threw together a very simple if not brain-dead benchmark program for
testing runtimes in both Android and Java ME. Their corresponding zip
files with source code can temporarily be downloaded from the
following two links for SpeedTest_Android.zip and
SpeedTest_JavaME.zip:

http://www.seeingwithsound.com/phone/SpeedTest_Android.zip
http://www.seeingwithsound.com/phone/SpeedTest_JavaME.zip

Note that the runBenchmark() function representing the CPU-intensive
calculations is identical for Android and Java ME.

On my old Nokia 6680 phone (with JIT compiler, 220 MHz CPU and 10 MB
RAM), a typical result is

Runtime = 1016 ms; sum = -4394332

(The Jave ME phone emulator on my 2 GHz AMD Windows XP notebook PC
gave runtimes of ~2400 ms and the Android emulator gave runtimes of
~7500 ms.)

I do not have a T-Mobile G1, so could someone please run this
benchmark program on his/her G1 and post the results here?

Of course I do not claim that this first shot at creating a CPU
benchmark is a representative one.

Thanks

[Mark Murphy]

blindfold wrote:
> I do not have a T-Mobile G1, so could someone please run this
> benchmark program on his/her G1 and post the results here?

Three trials on a Pentium-M 1.6GHz notebook and the Android emulator
average ~8000ms.

Eight trials on a G1 (4 with USB plugged in, 4 without) average ~4900ms,
with no obvious difference between USB being connected or not.

--
Mark Murphy (a Commons Guy)
http://commonsware.com
_The Busy Coder's Guide to Android Development_ Version 1.4 Published!

[Eddie C. Dost]

Hi,

I get the following on my G1: Runtime = 5589 ms; sum = 2752852

/Eddie

--
___________________________________________________brainaid_____________
Eddie C. Dost Rue de la Chapelle 51 phone +32 87 788817
B-4850 Moresnet fax +32 87 788818
e...@brainaid.de Belgium cell +49 172 9312808

[blindfold]

Well, this seems to confirm the earlier conjecture that for CPU-
intensive processing the G1 is roughly an order of magnitude slower
than contemporary high-end Nokia phones running Java ME (with a JIT
compiler). The G1 is here apparently 5 to 6 times slower than my old
Nokia 6680 with its 220 MHz ARM9 CPU, while the more modern Nokia N85
reportedly has an ARM11 running at 369MHz, so we can estimate a factor
of at least 369/220 * (5,6) = 8 - 10, or an order of magnitude.

Thanks for posting the G1 test results!

On Nov 30, 4:46 pm, Mark Murphy <mmur...@commonsware.com> wrote:
> blindfold wrote:
> > I do not have a T-Mobile G1, so could someone please run this
> > benchmark program on his/her G1 and post the results here?
>
> Three trials on a Pentium-M 1.6GHz notebook and the Android emulator
> average ~8000ms.
>
> Eight trials on a G1 (4 with USB plugged in, 4 without) average ~4900ms,
> with no obvious difference between USB being connected or not.
>
> --

> Mark Murphy (a Commons Guy)http://commonsware.com

[Eddie C. Dost]

And this is one of the many reasons why developers want native code
on the G1. Google: Free your phone!

/Eddie

--

[blindfold]

The same benchmark was now run on the new Sony Ericsson Xperia X1,
which holds virtually the same 528 MHz processor as the T-Mobile G1
(X1: 528 MHz Qualcomm ARM 11 MSM7200A CPU, 256 MB RAM; G1: 528 MHz
Qualcomm ARM 11 MSM7201A CPU, 192 MB RAM).

Results for three runs on the X1:

Runtime = 725 ms; sum = -4394332
Runtime = 702 ms; sum = -4394332
Runtime = 705 ms; sum = -4394332

making the X1 with Java ME about 7 to 8 times faster than the G1 with
Android, at least for this benchmark.

I'm not sure to what extent the Jbed Java compiler in the X1 with its
"Way Ahead of Time Compilation" (WAT) approach does things dynamically
like JIT (Just In Time) compilation, or how this affects memory
footprint, but here too the Java ME application gets mapped to native
code for a much better speed performance. Actually I had expected
still faster results for the X1 given its more modern processor and
higher clock frequency as compared to the Nokia 6680, but the
remaining difference may originate from compiler differences and the
very different approach taken by Jbed from Esmertec with its special
JVM-OS coupling (e.g., http://www.dedicated-systems.com/Magazine/99q3/mountside.pdf).
Or maybe the X1 too, like the G1, runs the CPU well below the
specified 528 MHz. :-)

Regards

[fadden]

On Dec 1, 6:35 am, blindfold <seeingwithso...@gmail.com> wrote:
> making the X1 with Java ME about 7 to 8 times faster than the G1 with
> Android, at least for this benchmark.
>
> I'm not sure to what extent the Jbed Java compiler in the X1 with its
> "Way Ahead of Time Compilation" (WAT) approach does things dynamically

[...]

That's about what you'd expect for interpreted vs. JIT code
benchmarks.

(This doesn't mean JITted apps would run 7x faster, for the many
reasons explained elsewhere, and says nothing about the relative RAM
and flash storage requirements of the implementations.)

A quick rule of thumb on relative performance (derived from
shootout.alioth.debian.org); smaller numbers are better:

Assembly 1.0
C/C++ 1.5
Java (compiled) 3.5
Java (Interp) 25

[blindfold]

So it looks like with JIT you can get the same speed performance at
1/7 of the current clock frequency. Don't nail me on exact figures,
but taking as a first back-of-the-envelope estimate the Pentium 4 CPU
and looking at its maximum clock frequency as a function of voltage in
Figure 24 of http://download.intel.com/technology/itj/2002/volume06issue02/art01_130nmlogic/vol6iss2_art01.pdf
you see that you can roughly halve the supply voltage for the
processor in exchange for a reduction of a factor 5 or so in maximum
clock frequency. Now supply voltage contributes quadratically to a CPU
logic's power dissipation, so you can get a four times longer battery
life by using JIT and reducing the clock frequency for the same
effective speed performance. Erm, anyone here who can better explain
how Dalvik byte code interpretation was meant to save power? ;-)

Using JIT compilation instead of interpretation is by itself not
necessarily bad for power according to
http://www.usenix.org/events/jvm01/full_papers/vijaykrishnan/vijaykrishnan_html/node9.html
and seemingly depending (among many other factors) on whether the
parts of the app that need compilation are small enough as compared to
the total app size, and reading "This indicates that the even when the
process technology significantly improves in the future, the JIT will
remain the choice of implementors from an energy perspective". I did
not validate these assertions though, because for that I would have to
dig much more deeply.

[blindfold]

Oh, and I even forgot the linear power savings by the significant
frequency downscaling, which should make results look still better.

On Dec 1, 10:17 pm, blindfold <seeingwithso...@gmail.com> wrote:
> So it looks like with JIT you can get the same speed performance at
> 1/7 of the current clock frequency. Don't nail me on exact figures,

...

[Pierre Bonnefoy]

My understanding was that JIT capability in Dalvik VM was going to be in the roadmap. That is what a google employee stated in the android developers mailing list one year ago.

Would be interesting to be updated on that topic though ...

Pierre 

2008/12/1 blindfold <seeingw...@gmail.com>

[Dianne Hackborn]

On Mon, Dec 1, 2008 at 1:17 PM, blindfold <seeingw...@gmail.com> wrote:

Erm, anyone here who can better explain
how Dalvik byte code interpretation was meant to save power? ;-)

Feel free to go ahead and write a JIT for android that works better, for the overall system, than what we currently have.  You'll need to deal with the fact that any increase in memory usage gets magnified across all of the processes so you can easily kill the system by leaving it without enough memory to keep all of the things needed running, making sure it doesn't have an impact on process startup time, etc.

NOBODY is telling you that a JIT is bad and shouldn't be done.  The issue is that doing one that works well and actually improves things for the android environment is very non-trivial.

Do you want to help out and see how you can go about doing something that can be contributed to the platform?  That would be great.  Otherwise, it's currently not on the road map, and there are probably higher priority things that people have to work on.  For example, it might be much more important to spend VM engineering effort on improving the garbage collector and overall memory usage.  Or maybe porting to x86 if that is what is needed.  Continuing to complain about this is not likely to change those other priorities.

--
Dianne Hackborn
Android framework engineer
hac...@android.com

Note: please don't send private questions to me, as I don't have time to provide private support.  All such questions should be posted on public forums, where I and others can see and answer them.

[blindfold]

Houston, we have a problem. We just discovered that our computers are
not only draining the batteries, they also run way too slowly to keep
us in orbit. Why didn't you tell us? Please advise!

Houston: Yeah, we know. Stop complaining, go ahead and fix it
yourself, cause we have better things to do. Oh yes, and beware that
fixing it is highly non-trivial and your craft will likely explode if
you do not do it quite right.

(Rumour has it that the crew was later rescued by a Soyuz.)


On Dec 1, 11:29 pm, "Dianne Hackborn" <hack...@android.com> wrote:

> On Mon, Dec 1, 2008 at 1:17 PM, blindfold <seeingwithso...@gmail.com> wrote:
> > Erm, anyone here who can better explain
> > how Dalvik byte code interpretation was meant to save power? ;-)
>
> Feel free to go ahead and write a JIT for android that works better, for the
> overall system, than what we currently have.  You'll need to deal with the
> fact that any increase in memory usage gets magnified across all of the
> processes so you can easily kill the system by leaving it without enough
> memory to keep all of the things needed running, making sure it doesn't have
> an impact on process startup time, etc.
>
> NOBODY is telling you that a JIT is bad and shouldn't be done.  The issue is
> that doing one that works well and actually improves things for the android
> environment is very non-trivial.
>
> Do you want to help out and see how you can go about doing something that
> can be contributed to the platform?  That would be great.  Otherwise, it's
> currently not on the road map, and there are probably higher priority things
> that people have to work on.  For example, it might be much more important
> to spend VM engineering effort on improving the garbage collector and
> overall memory usage.  Or maybe porting to x86 if that is what is needed.
> Continuing to complain about this is not likely to change those other
> priorities.
>
> --
> Dianne Hackborn
> Android framework engineer

> hack...@android.com

[Jean-Baptiste Queru]

You know, that's not actually funny.

JBQ

[Joe Onorato]

Right, there's some email list, and there's a guy on it who doesn't even own a G1, who wants a CPU speed slider.  We'll get right on it.

[qvark]

> Right, there's some email list, and there's a guy on it who doesn't even own
> a G1, who wants a CPU speed slider. We'll get right on it.

Joe, you know, that's not actually funny.

On Dec 2, 7:02 am, "Joe Onorato" <j...@android.com> wrote:
> Right, there's some email list, and there's a guy on it who doesn't even own
> a G1, who wants a CPU speed slider.  We'll get right on it.
>

[Jean-Baptiste Queru]

Well, what have you done to make some progress here?

At least 3 Android engineers at Google spent some time yesterday
gathering benchmark data at several clock speeds on the G1 (and
several more chimed in to try to analyze the results). We've confirmed
that the power consumption makes a significant jump when increasing
the clock speed, but we haven't been able to get conclusive evidence
on a performance gain at clock speeds higher than the current 384Mhz.
We'll continue gathering and analyzing results if it seems to make
sense to do so.

So far we've heard many more user complaints about battery life than
we've heard about performance, and based on that data it's hard to
justify spending engineering time in a direction that would hurt
battery life.

JBQ

[blindfold]

Hi Jean-Baptiste,

Another factor not yet considered in relation to the overheating
mentioned by Romain is duty cycle. In my specific case, once a phone
runs fast enough for real-time operation, as defined by synthesizing
one second of sound well within one second, it only needs the fast
mode (say 528 MHz) for the sub-second sound generation phase, and for
the remainder of the second it can run at a much less power-consuming
clock frequency, say 200 MHz, for playing the sound that has just been
synthesized. The average power dissipation over a relatively short
time window can thus be much lower than what one would get with
continuous 528 MHz operation, thereby preventing overheating. Of
course the phone manufacturer must still prevent that ill-designed
apps could overheat and damage the phone, so a temperature sensor is
needed to independently throttle the clock frequency down whenever the
device temperature becomes too high. Does the G1 contain that kind of
hardware protection through temperature sensors controlling the CPU's
clock frequency?

I'm afraid though that the G1 with Android currently cannot nearly get
to the speed as needed for sub-second sound synthesis to fulfill the
requirements for the above duty cycle benefit, due to the
interpretation-only processing mode of the Dalvik interpreter and also
because synthesized sound must in Android first be written to flash
before it can be sent to the audio output device via MediaPlayer. My
old 220 MHz Nokia 6680 typically spends maybe 50% of the time
synthesizing sound (half a second of processing for one second of
sound output), but the lack of a JIT compiler suggests that the G1 may
need a factor 6 or so more time for the same calculations, hence
taking some three seconds for one second of sound. Overclocking the G1
CPU above its current 384Mhz limit to 528 MHz would therefore not
suffice to get to sub-second synthesis times, although it may still
benefit other CPU-intensive applications.

> So far we've heard many more user complaints about battery life than
> we've heard about performance, and based on that data it's hard to
> justify spending engineering time in a direction that would hurt
> battery life.

I fully understand. Although my own interest lies more in processing
speed with Android, I have in previous posts argued that JIT
compilation (and related methods) may also be applied to alleviate the
battery life problems that most of your customers complain about,
while maintaining a processing speed similar to what the G1 offers
today. So some of those engineering directions seem promising either
way.

Regards

[Jean-Baptiste Queru]

At this point, my interest is to have some hard data that would allow
to make a decision on whether increasing the G1 clock speed at all
makes any sense. Generic statements aren't helping, sorry.

JBQ

[Dianne Hackborn]

On Tue, Dec 2, 2008 at 8:08 AM, blindfold <seeingw...@gmail.com> wrote:

I fully understand. Although my own interest lies more in processing
speed with Android, I have in previous posts argued that JIT
compilation (and related methods) may also be applied to alleviate the
battery life problems that most of your customers complain about,
while maintaining a processing speed similar to what the G1 offers
today. So some of those engineering directions seem promising either
way.

I am willing to bet that introducing a JIT compiler would help very little if at all with battery life on a plain production G1, and if not done very carefully has a very good chance of harming it (as I've outlined before).

Again, there is no point in arguing with people trying to convince them to write a JIT or what-not, as nobody is saying a JIT is intrinsically bad, but it's very tricky, and there are most likely higher priority items they have to work on.

If this is a high priority for you, it would be a much more effective use of time working on patches to implement the improvements you want, rather than arguing about their importance on a mailing list.

--
Dianne Hackborn
Android framework engineer

[Eddie C. Dost]

A nice overview on the facts that influence power dissipation and
with that energy on processors can be found here:

http://www.mobilehandsetdesignline.com/209100312

I would conclude from this that for the same hardware increasing the
clock frequency *could* make sense if some sort of dynamic voltage
supply is implemented in the hardware, as the overall system would
require less power in the then greater idle phase. Of course this
assumes the same amount of work to be done by the system.

All in all the effect would *probably* be marginal.

I am marking my words with * where I make assumptions that I cannot
avoid because I do not have detailed information on the internals
of the G1 nor of the msm7201a. It is be Google's job to verify or
falsify such assumptions, probably working together with HTC. As long as
the hardware of the G1 is disclosed, the community cannot be of much
help here.

What would reduce power consumption would be reduction of the actual
duty cycle of the processor, using less instructions for the same job,
by either using less instructions per java byte code or using more
native code for permanently running tasks.

I would like to provide some real measurements and play with various
benchmarks and settings on my G1, but that would require ability to
run applications at the system level or to install my self compiled
kernel on the device, which I sadly cannot do. I would know what I am
doing, as I have been developing embedded Linux systems for over 20
years now. But I will not use Java to do system programming, there is
no way to convince me of that.

Sorry if the last sentence went somewhat off topic. I hope the rest is
of some informative value.

/Eddie

--

[blindfold]

I doubt that you will find harder data. Increasing the CPU clock
frequency makes rather little sense: no major performance gains
against a quite noticeable increase in power dissipation. Within the
limited set of simple options that you are currently considering, it
makes more sense to have options to prevent the clock frequency from
dropping below 384 MHz. In the currently implemented G1 set {82 MHz,
123 MHz, 246 MHz, 384 MHz} (cpufreq_table[] in
http://android.git.kernel.org/?p=kernel/msm.git;a=blob_plain;f=arch/arm/mach-msm/clock.c;hb=msm-2.6.25),
it can be annoying if the phone would drop the clock frequency to 82
MHz and become almost five times slower for mere lack of user
interaction or with screen brightness dimming, that is, because of
wrong system assumptions about what criteria should determine clock
frequency for running applications. This is where Android application
developers could benefit from more control. I do not know what
criteria Android currently uses to dynamically adjust the clock
frequency: I suppose the android.os.PowerManager documentation about
wake locks is incomplete? It does not say anything about the CPU's
clock frequency for the various wake lock flag settings.

The performance gaps against other platforms will certainly not be
bridged by increasing the clock frequency. I have already provided
pretty hard data on that.

Regards

[Peli]

> but we haven't been able to get conclusive evidence
> on a performance gain at clock speeds higher than the current 384Mhz.

I think it depends on the application you are analyzing. Have you
tried to benchmark this? :
http://code.google.com/p/mandelbrot/

3 Android engineers should be able to extract hard data for that
one :-)

Peli

[Romain Guy]

> I would know what I am
> doing, as I have been developing embedded Linux systems for over 20
> years now.

Linux? Over 20 years? Right :)

--
Romain Guy
www.curious-creature.org

[blindfold]

Hi Dianne,

> I am willing to bet that introducing a JIT compiler would help very little
> if at all with battery life on a plain production G1, and if not done very
> carefully has a very good chance of harming it (as I've outlined before).

If you say so. You could be right. I can only speak for specific types
of (typical sound and image processing) applications that spend most
CPU cycles within relatively small functions. To judge the normal
operation of vanilla production G1's, I would need profiling data that
probably only Google can provide, determining whether or not most
cycles of typical bundled applications are spent in small chunks of
Android code that could benefit from JIT compilation at little
overhead.

> If this is a high priority for you, it would be a much more effective use of
> time working on patches to implement the improvements you want, rather than
> arguing about their importance on a mailing list.

For me that would be a waste of time. I do not like it, but with the
now - from the discussions - apparent lack of drive towards speed
performance it is becoming much more effective for me to just give up
on Android, and explain to customers that for good performance they
must forget about Android and buy, say, a Nokia 97 instead of a T-
Mobile G1. Of course it means loss of months of work developing for
Android, but so be it. I'll still have a nice demonstrator (hard
data!) to prove that Android really doesn't dig it. I'm then simply
driven back to another commercial platform that happens to offer more
than adequate performance for exactly the same computational
complexity.

Regards

On Dec 2, 7:05 pm, "Dianne Hackborn" <hack...@android.com> wrote:

> On Tue, Dec 2, 2008 at 8:08 AM, blindfold <seeingwithso...@gmail.com> wrote:
> > I fully understand. Although my own interest lies more in processing
> > speed with Android, I have in previous posts argued that JIT
> > compilation (and related methods) may also be applied to alleviate the
> > battery life problems that most of your customers complain about,
> > while maintaining a processing speed similar to what the G1 offers
> > today. So some of those engineering directions seem promising either
> > way.
>
> I am willing to bet that introducing a JIT compiler would help very little
> if at all with battery life on a plain production G1, and if not done very
> carefully has a very good chance of harming it (as I've outlined before).
>
> Again, there is no point in arguing with people trying to convince them to
> write a JIT or what-not, as nobody is saying a JIT is intrinsically bad, but
> it's very tricky, and there are most likely higher priority items they have
> to work on.
>
> If this is a high priority for you, it would be a much more effective use of
> time working on patches to implement the improvements you want, rather than
> arguing about their importance on a mailing list.
>
> --
> Dianne Hackborn
> Android framework engineer

> hack...@android.com

[Peli]

It helped me to look at the presentation slides about Dalvik to
appreciate better what it was designed for:
http://sites.google.com/site/io/dalvik-vm-internals

Particularly, look at presentation slides:
* slide 22: uncompressed dex file is smaller than compressed jar file.
* slide 33: Reason for no JIT is availability of JNI.

So, instead of a JIT, I think most people concerned about speed will
be more than happy if JNI was fully supported by the system for
application developers.

I think I read somewhere that JNI support was higher in priority list,
although it is not listed on the public roadmap: http://source.android.com/roadmap

Maybe a clarification on the status of JNI support would be helpful.

Peli

[blindfold]

Hi Peli,

I doubt that they will want hard data for this one, as it presents yet
another example where JIT compilation will really shine: most CPU
cycles go into the complex-valued iterations in
http://mandelbrot.googlecode.com/svn/trunk/mandelbrot/src/com/alfray/mandelbrot/NativeMandel.java
that are limited to very small chunks of source code (functions like
the z2c()). No point in smoking a G1 on this one by increasing the
clock frequency. A JIT enabled phone would still run circles around a
smoking G1 here. Of course the point will be made that most G1 users
do not view Mandelbrot on a daily basis. :-(

Regards

[Dan Bornstein]

I just wanted to add a quick note here:

Apologies for the left-hand right-hand problem, but in fact the Dalvik
team is just starting to do the research (profiling, etc.) that could
lead up to adding a JIT to the VM.

I want to reiterate that this is not a trivial problem, nor in
particular is it an already solved one, at least in the context of a
battery-powered memory-constrained platform where multiple VMs run
simultaneously. We only want to deploy a solution that allows for as
many simultaneous processes (in a given amount of RAM) as we can
already do, and we only want to deploy a solution that is
neutral-to-positive on the battery life front. And it should go
without saying, but we only want to deploy a solution that provides a
net improvement in performance systemwide.

I see the existing interpreter-only VM as a great baseline, and I hope
we will in fact be able to improve upon it significantly. I wanted 1.0
to go out the door with a solid and stable VM. I think we achieved
that, but we certainly aren't resting on our laurels now.

-dan

[blindfold]

Great to hear that, Dan! Thanks also for informing us. Basically this
is all that I, and probably also many others, wanted to hear in order
to keep confidence and interest in (the future of) the Android
platform. Without this strive I did not see a future for live
multimedia processing and augmented reality under Android, and it
would likely have kept many new application areas from being mapped to
the Android platform. My own app only targets a tiny niche market with
little or no commercial value, but its technological demands present
an early example of and a test-case for various mobile processing
issues that will grow in importance.

I fully recognize that adding JIT compilation, perhaps in combination
with dynamic CPU clock frequency control, and under the (perfectly
reasonable) neutral-to-positive conditions will be a major and complex
undertaking that will take much time even if you can build on solid
work already done by others (say buy or license a prototype JIT-or-
similar compiler?). I know that Esmertec, maker of the Jbed Java
compiler, is a member of Android's Open Handset Alliance (http://
www.esmertec.com/102.html), while Qualcomm, maker of the CPU in the
G1, is currently seeking a JIT Optimization Engineer (http://
www.simplyhired.com/job-id/f5cg4vuac2/jit-optimization-jobs/). Would
be nice to have something tangible by Q4 2009 though. Just
probing. :-)

> I see the existing interpreter-only VM as a great baseline

> ...

> I wanted 1.0 to go out the door with a solid and stable VM.

Indeed, first things first. I think you did a fabulous job on that.

> I think we achieved that, but we certainly aren't resting on our laurels now.

I commend you for the continuing ambition to stretch what can be done
with the speed-performance-versus-battery-life (and memory, and multi-
process) trade-offs.

Thanks and regards

Peter

[F H]

Dan,

 

I too would appreciate where JIT and JNI support lie on the roadmap.

 

I ask from the perspective of a product manager deciding where to invest his resources with respect to Android. The last thing I want to do is to invest in our own JIT technology, only to find it was a waste of time, likewise our own native platform definition.  Making these decisions is incredibly difficult when Google's own Android roadmap only extends out by a quarter and is fuzzy. (A short roadmap is not really a roadmap it's a list of things that are being finished).

 

For example it was clearly stated in a recent e-mail that JIT is not on the roadmap, whereas you imply that it is. An earlier recent example is inclusion of TTS, which again isn't on the official roadmap, but implied that it is from a Google e-mail. A robust (as far as is possible) Roadmap of what Google intends to do over the next 1-2 years would be incredibly useful for those of us considering embarking on investing resource into an Android platform which is better than the competition.

 

Google's leadership is necessary to minimise Android fragmentation. A platform company for example that develops a JIT compiler  is highly unlikely to donate it to the project because it gives them a competetive advantage. Likewise other functionality, thus important platform areas will get implemented in different ways. This then becomes a problem for developers because Android loses its consistency. 

 

Please can we have a Roadmap which goes out at least 1 or 2 years.

 

Many Thanks.

[qvark]

Hi, after reading the whole thread I have got a simple conclusion
(maybe I'm wrong wo please feel free to correct me):

Task
Complexity Gain
--------------------------------------------------------------------------------------------------
Increasing CPU speed
Low Low
JIT
High High
JNI
Low High

So in my opinion enabling JNI for developers should be the first
preference, don't you think?

Jose Luis.

On Dec 2, 10:57 pm, Dan Bornstein <danf...@android.com> wrote:

[blindfold]

> So in my opinion enabling JNI for developers should be the first
> preference, don't you think?

Yes, in the short term that is the easy route that can deal with many
of the current performance bottlenecks. Longer term it can cause
issues with supporting multiple CPU types (as I started discussing in
another thread http://groups.google.com/group/android-platform/browse_thread/thread/97f37bf341d70ec2/)
unless every phone comes bundled with a standard C compiler that gets
invoked, say, at installation time of any app that uses JNI.

Regards

[Dan Bornstein]

On Wed, Dec 3, 2008 at 2:07 AM, F H <expel...@googlemail.com> wrote:
> I too would appreciate where JIT and JNI support lie on the roadmap.

JNI support already exists in Dalvik. (UTSL!) There's still an open
question, though, of when we expose it as a fully-supported part of
the Android platform. I don't know when that will be. The issues here
are (a) making sure we have a good multi-architecture story (as noted
by "blindfold"); not all Android devices will be ARM, and there are
even architectural variants of ARM with different instruction sets to
be concerned about; and (b) settling on a set of truly supportable
native libraries (libc, etc.), as this will become part of the API
Android will have to continue to support on an ongoing basis. We don't
want to commit lightly or capriciously on either of these fronts.

As for JIT, there's nothing to announce, other than what I already
said: we are starting to look into it. There is no hard deadline for
its inclusion; after all, we don't yet even know if it will work out
acceptably. Maybe "research JIT" should be on the roadmap, and it
should be listed as happening "now."

-dan

[blindfold]

Once there is something to try out at application level, I'd be
interested. I'm currently repartitioning my code such that the CPU-
intensive parts are mostly in a single class for use with a JIT
compiler via java.lang.Compiler.compileClass() (http://code.google.com/
android/reference/java/lang/Compiler.html). It's all just regular
computational stuff with arrays and math expressions, so a light-
weight Android class compiler might come a long way in significantly
improving speed performance - perhaps getting close to what the JNI
approach can deliver.

Regards

On Dec 3, 9:35 pm, Dan Bornstein <danf...@android.com> wrote:
> As forJIT, there's nothing to announce, other than what I already

> said: we are starting to look into it. There is no hard deadline for
> its inclusion; after all, we don't yet even know if it will work out

> acceptably. Maybe "researchJIT" should be on the roadmap, and it

[blindfold]

I have now repartitioned my app at http://www.seeingwithsound.com/android.htm
to make explicit use of compileClass() in
http://code.google.com/android/reference/java/lang/Compiler.html for
the CPU-intensive calculations, so JIT compiler developers may try
their compiler on a real app that needs JIT for adequate speed and
check that it doesn't crash or otherwise malfunction after JIT
compilation. I hope - and assume in my code - that I can avoid
redundant recompilation with every run by invoking compileClass()
through a variable declaration that only gets initialized upon the
first run (after program installation).

Regards