CPU SPEED

MIME-Version: 1.0
Date: Wed, 26 Nov 2008 10:32:32 -0800 (PST)
User-Agent: G2/1.0
Message-ID: <d1967e0b-b26a-4069-9ca0-25e21655d27e@z28g2000prd.googlegroups.com>
Subject: CPU SPEED
From: jdc4429 <jdc4...@gmail.com>
To: android-platform <android-platform@googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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

Received-SPF: pass (google.com: domain of j...@google.com designates 216.239.45.13 
as permitted sender) client-ip=216.239.45.13;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of 
j...@google.com designates 216.239.45.13 as permitted sender) 
smtp.mail=...@google.com; dkim=pass (test mode) header...@google.com
Received: from zps19.corp.google.com (zps19.corp.google.com [172.25.146.19])
	by smtp-out.google.com with ESMTP id mAQIbEma017171
	for <android-platform@googlegroups.com>; Wed, 26 Nov 2008 10:37:14 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta;
	t=1227724634; bh=aEn7r2lG4sCLpiSROVM0gc325aY=;
	h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date:
	 Message-ID:Subject:From:To:Content-Type:Content-Transfer-Encoding;
	b=ATtaK33uimLpFw/t1kPmr3JEQCuimZUCyKzWvuW4Hk7CMraU1vSLEVLH9ZNOc/rB5
	5+ht6TaDOZ85fgY1wChbg==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to:
	content-type:content-transfer-encoding;
	b=m58rZvcaeyIPxslhrCLcMYdOx09g+JbJO4GocCcZAiNiT1KgDgswDCEObATDndMVM
	5qq/71YIerbUG62NIC/cw==
Received: from rv-out-0506.google.com (rvfb25.prod.google.com [10.140.179.25])
	by zps19.corp.google.com with ESMTP id mAQIbDDO016707
	for <android-platform@googlegroups.com>; Wed, 26 Nov 2008 10:37:13 -0800
Received: by rv-out-0506.google.com with SMTP id b25so556740rvf.45
        for <android-platform@googlegroups.com>; Wed, 26 Nov 2008 10:37:13 -0800 (PST)
MIME-Version: 1.0
Received: by 10.141.63.20 with SMTP id q20mr3029709rvk.213.1227724633155; Wed, 
	26 Nov 2008 10:37:13 -0800 (PST)
In-Reply-To: <d1967e0b-b26a-4069-9ca0-25e21655d27e@z28g2000prd.googlegroups.com>
References: <d1967e0b-b26a-4069-9ca0-25e21655d...@z28g2000prd.googlegroups.com>
Date: Wed, 26 Nov 2008 10:37:13 -0800
Message-ID: <1702acb30811261037i5026b881j877899255daa1...@mail.gmail.com>
Subject: Re: CPU SPEED
From: Jean-Baptiste Queru <j...@google.com>
To: android-platform@googlegroups.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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

On Wed, Nov 26, 2008 at 10:32 AM, jdc4429 <jdc4...@gmail.com> wrote:
>
>
> 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.
>

MIME-Version: 1.0
Date: Wed, 26 Nov 2008 10:49:34 -0800 (PST)
In-Reply-To: <1702acb30811261037i5026b881j877899255daa1ed7@mail.gmail.com>
References: <d1967e0b-b26a-4069-9ca0-25e21655d27e@z28g2000prd.googlegroups.com> 
	<1702acb30811261037i5026b881j877899255daa1ed7@mail.gmail.com>
User-Agent: G2/1.0
Message-ID: <518107b9-14f8-49ba-aa21-cd32b80c9023@t3g2000yqa.googlegroups.com>
Subject: Re: CPU SPEED
From: blindfold <seeingwithso...@gmail.com>
To: android-platform <android-platform@googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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.

On Nov 26, 7:37=A0pm, 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

Received-SPF: neutral (google.com: 209.85.221.20 is neither permitted nor denied by 
best guess record for domain of hack...@android.com) client-ip=209.85.221.20;
Authentication-Results: mx.google.com; spf=neutral (google.com: 209.85.221.20 is 
neither permitted nor denied by best guess record for domain of hack...@android.com) 
smtp.mail=hack...@android.com
Received: by qyk13 with SMTP id 13so866857qyk.2
        for <android-platform@googlegroups.com>; Wed, 26 Nov 2008 10:56:02 -0800 (PST)
Received: by 10.142.199.10 with SMTP id w10mr2313387wff.257.1227725761930;
        Wed, 26 Nov 2008 10:56:01 -0800 (PST)
Received: by 10.142.191.18 with HTTP; Wed, 26 Nov 2008 10:56:01 -0800 (PST)
Message-ID: <26b7c7380811261056m5a112be9tdb517892cf643510@mail.gmail.com>
Date: Wed, 26 Nov 2008 10:56:01 -0800
From: "Dianne Hackborn" <hack...@android.com>
To: android-platform@googlegroups.com
Subject: Re: CPU SPEED
In-Reply-To: <518107b9-14f8-49ba-aa21-cd32b80c9023@t3g2000yqa.googlegroups.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_26208_29693157.1227725761947"
References: <d1967e0b-b26a-4069-9ca0-25e21655d27e@z28g2000prd.googlegroups.com>
	 <1702acb30811261037i5026b881j877899255daa1ed7@mail.gmail.com>
	 <518107b9-14f8-49ba-aa21-cd32b80c9023@t3g2000yqa.googlegroups.com>

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.

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

>
> 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.
>
> On Nov 26, 7: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
>

-- 
Dianne Hackborn
Android framework engineer
hack...@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.

MIME-Version: 1.0
Date: Wed, 26 Nov 2008 11:07:52 -0800 (PST)
In-Reply-To: <1702acb30811261037i5026b881j877899255daa1ed7@mail.gmail.com>
References: <d1967e0b-b26a-4069-9ca0-25e21655d27e@z28g2000prd.googlegroups.com> 
	<1702acb30811261037i5026b881j877899255daa1ed7@mail.gmail.com>
User-Agent: G2/1.0
Message-ID: <405822f0-f257-41af-8033-85118769e45c@w24g2000prd.googlegroups.com>
Subject: Re: CPU SPEED
From: jdc4429 <jdc4...@gmail.com>
To: android-platform <android-platform@googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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=A0pm, 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
>
> On Wed, Nov 26, 2008 at 10:32 AM, jdc4429 <jdc4...@gmail.com> wrote:
>
> > Hi Dianne,
>
> > Could you please elaborate on the below comment you made regarding the
> > G1's
> > processor speed. =A0Does 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 transparen=
t
> >> drawing. =A0Also currently all drawing within a window is not hardware
> >> accelerated so must be done in software. =A0And the G1's processor run=
s at

Received-SPF: neutral (google.com: 172.21.9.3 is neither permitted nor denied by 
best guess record for domain of hack...@android.com) client-ip=172.21.9.3;
Authentication-Results: mx.google.com; spf=neutral (google.com: 172.21.9.3 is neither 
permitted nor denied by best guess record for domain of hack...@android.com) 
smtp.mail=hack...@android.com
Received: by yx-out-1718.google.com with SMTP id 3so307719yxi.52
        for <android-platform@googlegroups.com>; Wed, 26 Nov 2008 11:11:26 -0800 (PST)
Received: by 10.142.238.12 with SMTP id l12mr2684471wfh.222.1227726686034;
        Wed, 26 Nov 2008 11:11:26 -0800 (PST)
Received: by 10.142.191.18 with HTTP; Wed, 26 Nov 2008 11:11:26 -0800 (PST)
Message-ID: <26b7c7380811261111n6737077dy5ba5024ef5411818@mail.gmail.com>
Date: Wed, 26 Nov 2008 11:11:26 -0800
From: "Dianne Hackborn" <hack...@android.com>
To: android-platform@googlegroups.com
Subject: Re: CPU SPEED
In-Reply-To: <405822f0-f257-41af-8033-85118769e45c@w24g2000prd.googlegroups.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_26326_22180677.1227726686035"
References: <d1967e0b-b26a-4069-9ca0-25e21655d27e@z28g2000prd.googlegroups.com>
	 <1702acb30811261037i5026b881j877899255daa1ed7@mail.gmail.com>
	 <405822f0-f257-41af-8033-85118769e45c@w24g2000prd.googlegroups.com>

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

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.

MIME-Version: 1.0
Date: Wed, 26 Nov 2008 11:59:11 -0800 (PST)
In-Reply-To: <26b7c7380811261111n6737077dy5ba5024ef5411818@mail.gmail.com>
References: <d1967e0b-b26a-4069-9ca0-25e21655d27e@z28g2000prd.googlegroups.com> 
	<1702acb30811261037i5026b881j877899255daa1ed7@mail.gmail.com> 
	<405822f0-f257-41af-8033-85118769e45c@w24g2000prd.googlegroups.com> 
	<26b7c7380811261111n6737077dy5ba5024ef5411818@mail.gmail.com>
User-Agent: G2/1.0
Message-ID: <70dc1d85-cda0-405f-b78f-37ff290683c6@j39g2000yqn.googlegroups.com>
Subject: Re: CPU SPEED
From: blindfold <seeingwithso...@gmail.com>
To: android-platform <android-platform@googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

> 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=A0pm, "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

Received-SPF: neutral (google.com: 209.85.200.169 is neither permitted nor denied by 
best guess record for domain of hack...@android.com) client-ip=209.85.200.169;
Authentication-Results: mx.google.com; spf=neutral (google.com: 209.85.200.169 is 
neither permitted nor denied by best guess record for domain of hack...@android.com) 
smtp.mail=hack...@android.com
Received: by wf-out-1314.google.com with SMTP id 24so641328wfg.23
        for <android-platform@googlegroups.com>; Wed, 26 Nov 2008 12:48:11 -0800 (PST)
Received: by 10.142.164.10 with SMTP id m10mr389726wfe.27.1227732491239;
        Wed, 26 Nov 2008 12:48:11 -0800 (PST)
Received: by 10.142.191.18 with HTTP; Wed, 26 Nov 2008 12:48:11 -0800 (PST)
Message-ID: <26b7c7380811261248v80b679o5d5527a7ed09b007@mail.gmail.com>
Date: Wed, 26 Nov 2008 12:48:11 -0800
From: "Dianne Hackborn" <hack...@android.com>
To: android-platform@googlegroups.com
Subject: Re: CPU SPEED
In-Reply-To: <70dc1d85-cda0-405f-b78f-37ff290683c6@j39g2000yqn.googlegroups.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_28191_10489291.1227732491253"
References: <d1967e0b-b26a-4069-9ca0-25e21655d27e@z28g2000prd.googlegroups.com>
	 <1702acb30811261037i5026b881j877899255daa1ed7@mail.gmail.com>
	 <405822f0-f257-41af-8033-85118769e45c@w24g2000prd.googlegroups.com>
	 <26b7c7380811261111n6737077dy5ba5024ef5411818@mail.gmail.com>
	 <70dc1d85-cda0-405f-b78f-37ff290683c6@j39g2000yqn.googlegroups.com>

On Wed, Nov 26, 2008 at 11:59 AM, blindfold <seeingwithso...@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
hack...@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.

MIME-Version: 1.0
Date: Wed, 26 Nov 2008 13:32:16 -0800 (PST)
In-Reply-To: <26b7c7380811261248v80b679o5d5527a7ed09b007@mail.gmail.com>
References: <d1967e0b-b26a-4069-9ca0-25e21655d27e@z28g2000prd.googlegroups.com> 
	<1702acb30811261037i5026b881j877899255daa1ed7@mail.gmail.com> 
	<405822f0-f257-41af-8033-85118769e45c@w24g2000prd.googlegroups.com> 
	<26b7c7380811261111n6737077dy5ba5024ef5411818@mail.gmail.com> 
	<70dc1d85-cda0-405f-b78f-37ff290683c6@j39g2000yqn.googlegroups.com> 
	<26b7c7380811261248v80b679o5d5527a7ed09b007@mail.gmail.com>
User-Agent: G2/1.0
Message-ID: <41f0b2f4-f155-421e-9e07-b172ce1bbcf7@41g2000yqf.googlegroups.com>
Subject: Re: CPU SPEED
From: blindfold <seeingwithso...@gmail.com>
To: android-platform <android-platform@googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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=A0pm, "Dianne Hackborn" <hack...@android.com> wrote:
> I'm not sure about what is being talked about now, but all I was saying w=
as
> 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... =A0except for the case of apps that have a thre=
ad
> 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
>
> Note: please don't send private questions to me, as I don't have time to
> provide private support. =A0All such questions should be posted on public

Received: by 10.114.77.1 with SMTP id z1mr3478797waa.23.1227735522676;
        Wed, 26 Nov 2008 13:38:42 -0800 (PST)
Return-Path: <hack...@android.com>
Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168])
        by mx.google.com with ESMTP id k32si397284wah.1.2008.11.26.13.38.42;
        Wed, 26 Nov 2008 13:38:42 -0800 (PST)
Received-SPF: neutral (google.com: 209.85.200.168 is neither permitted nor denied by 
best guess record for domain of hack...@android.com) client-ip=209.85.200.168;
Authentication-Results: mx.google.com; spf=neutral (google.com: 209.85.200.168 is 
neither permitted nor denied by best guess record for domain of hack...@android.com) 
smtp.mail=hack...@android.com
Received: by wf-out-1314.google.com with SMTP id 28so697271wfa.25
        for <android-platform@googlegroups.com>; Wed, 26 Nov 2008 13:38:42 -0800 (PST)
Received: by 10.142.82.13 with SMTP id f13mr2727058wfb.301.1227735521624;
        Wed, 26 Nov 2008 13:38:41 -0800 (PST)
Received: by 10.142.191.18 with HTTP; Wed, 26 Nov 2008 13:38:41 -0800 (PST)
Message-ID: <26b7c7380811261338r5f1ba5ceh40961b52e78fe2a1@mail.gmail.com>
Date: Wed, 26 Nov 2008 13:38:41 -0800
From: "Dianne Hackborn" <hack...@android.com>
To: android-platform@googlegroups.com
Subject: Re: CPU SPEED
In-Reply-To: <41f0b2f4-f155-421e-9e07-b172ce1bbcf7@41g2000yqf.googlegroups.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_28613_24347857.1227735521620"
References: <d1967e0b-b26a-4069-9ca0-25e21655d27e@z28g2000prd.googlegroups.com>
	 <1702acb30811261037i5026b881j877899255daa1ed7@mail.gmail.com>
	 <405822f0-f257-41af-8033-85118769e45c@w24g2000prd.googlegroups.com>
	 <26b7c7380811261111n6737077dy5ba5024ef5411818@mail.gmail.com>
	 <70dc1d85-cda0-405f-b78f-37ff290683c6@j39g2000yqn.googlegroups.com>
	 <26b7c7380811261248v80b679o5d5527a7ed09b007@mail.gmail.com>
	 <41f0b2f4-f155-421e-9e07-b172ce1bbcf7@41g2000yqf.googlegroups.com>

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

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.

MIME-Version: 1.0
Received: by 10.150.201.17 with SMTP id y17mr477890ybf.8.1227751520485; Wed, 
	26 Nov 2008 18:05:20 -0800 (PST)
Date: Wed, 26 Nov 2008 18:05:20 -0800 (PST)
In-Reply-To: <26b7c7380811261338r5f1ba5ceh40961b52e78fe2a1@mail.gmail.com>
X-IP: 96.254.195.185
References: <d1967e0b-b26a-4069-9ca0-25e21655d27e@z28g2000prd.googlegroups.com> 
	<1702acb30811261037i5026b881j877899255daa1ed7@mail.gmail.com> 
	<405822f0-f257-41af-8033-85118769e45c@w24g2000prd.googlegroups.com> 
	<26b7c7380811261111n6737077dy5ba5024ef5411818@mail.gmail.com> 
	<70dc1d85-cda0-405f-b78f-37ff290683c6@j39g2000yqn.googlegroups.com> 
	<26b7c7380811261248v80b679o5d5527a7ed09b007@mail.gmail.com> 
	<41f0b2f4-f155-421e-9e07-b172ce1bbcf7@41g2000yqf.googlegroups.com> 
	<26b7c7380811261338r5f1ba5ceh40961b52e78fe2a1@mail.gmail.com>
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.4) 
	Gecko/2008102920 Firefox/3.0.1;MEGAUPLOAD 1.0,gzip(gfe),gzip(gfe)
Message-ID: <ad58d2a4-5ec1-4748-ab8b-53eab998bda2@w1g2000prm.googlegroups.com>
Subject: Re: CPU SPEED
From: jdc4429 <jdc4...@gmail.com>
To: android-platform <android-platform@googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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 wa=
nt
> "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.  I=
n
> 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=A0pm, "Dianne Hackborn" <hack...@android.com> wrote:
> On Wed, Nov 26, 2008 at 1:32 PM, blindfold <seeingwithso...@gmail.com>wro=
te:
>
> > 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. =A0You'll reduce the phone's battery life from days d=
own
> to hours. =A0A 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
>
> Note: please don't send private questions to me, as I don't have time to
> provide private support. =A0All such questions should be posted on public

Received: by 10.114.135.1 with SMTP id i1mr3597625wad.6.1227752826290;
        Wed, 26 Nov 2008 18:27:06 -0800 (PST)
Return-Path: <hack...@android.com>
Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233])
        by mx.google.com with ESMTP id k32si514616wah.1.2008.11.26.18.27.06;
        Wed, 26 Nov 2008 18:27:06 -0800 (PST)
Received-SPF: neutral (google.com: 209.85.198.233 is neither permitted nor denied by 
best guess record for domain of hack...@android.com) client-ip=209.85.198.233;
Authentication-Results: mx.google.com; spf=neutral (google.com: 209.85.198.233 is 
neither permitted nor denied by best guess record for domain of hack...@android.com) 
smtp.mail=hack...@android.com
Received: by rv-out-0506.google.com with SMTP id f6so896098rvb.5
        for <android-platform@googlegroups.com>; Wed, 26 Nov 2008 18:27:06 -0800 (PST)
Received: by 10.141.175.10 with SMTP id c10mr139465rvp.127.1227752826039;
        Wed, 26 Nov 2008 18:27:06 -0800 (PST)
Received: by 10.141.48.21 with HTTP; Wed, 26 Nov 2008 18:27:05 -0800 (PST)
Message-ID: <26b7c7380811261827m60cedc83oe9e80f3545ae228c@mail.gmail.com>
Date: Wed, 26 Nov 2008 18:27:05 -0800
From: "Dianne Hackborn" <hack...@android.com>
To: android-platform@googlegroups.com
Subject: Re: CPU SPEED
In-Reply-To: <ad58d2a4-5ec1-4748-ab8b-53eab998bda2@w1g2000prm.googlegroups.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_17873_32530898.1227752826035"
References: <d1967e0b-b26a-4069-9ca0-25e21655d27e@z28g2000prd.googlegroups.com>
	 <1702acb30811261037i5026b881j877899255daa1ed7@mail.gmail.com>
	 <405822f0-f257-41af-8033-85118769e45c@w24g2000prd.googlegroups.com>
	 <26b7c7380811261111n6737077dy5ba5024ef5411818@mail.gmail.com>
	 <70dc1d85-cda0-405f-b78f-37ff290683c6@j39g2000yqn.googlegroups.com>
	 <26b7c7380811261248v80b679o5d5527a7ed09b007@mail.gmail.com>
	 <41f0b2f4-f155-421e-9e07-b172ce1bbcf7@41g2000yqf.googlegroups.com>
	 <26b7c7380811261338r5f1ba5ceh40961b52e78fe2a1@mail.gmail.com>
	 <ad58d2a4-5ec1-4748-ab8b-53eab998bda2@w1g2000prm.googlegroups.com>

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.

On Wed, Nov 26, 2008 at 6:05 PM, jdc4429 <jdc4...@gmail.com> wrote:

>
> 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
> >
> > 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.
>



-- 
Dianne Hackborn
Android framework engineer
hack...@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.

MIME-Version: 1.0
Received: by 10.100.153.6 with SMTP id a6mr497520ane.12.1227779007136; Thu, 27 
	Nov 2008 01:43:27 -0800 (PST)
Date: Thu, 27 Nov 2008 01:43:27 -0800 (PST)
In-Reply-To: <26b7c7380811261827m60cedc83oe9e80f3545ae228c@mail.gmail.com>
X-IP: 80.255.245.177
References: <d1967e0b-b26a-4069-9ca0-25e21655d27e@z28g2000prd.googlegroups.com> 
	<1702acb30811261037i5026b881j877899255daa1ed7@mail.gmail.com> 
	<405822f0-f257-41af-8033-85118769e45c@w24g2000prd.googlegroups.com> 
	<26b7c7380811261111n6737077dy5ba5024ef5411818@mail.gmail.com> 
	<70dc1d85-cda0-405f-b78f-37ff290683c6@j39g2000yqn.googlegroups.com> 
	<26b7c7380811261248v80b679o5d5527a7ed09b007@mail.gmail.com> 
	<41f0b2f4-f155-421e-9e07-b172ce1bbcf7@41g2000yqf.googlegroups.com> 
	<26b7c7380811261338r5f1ba5ceh40961b52e78fe2a1@mail.gmail.com> 
	<ad58d2a4-5ec1-4748-ab8b-53eab998bda2@w1g2000prm.googlegroups.com> 
	<26b7c7380811261827m60cedc83oe9e80f3545ae228c@mail.gmail.com>
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.4) 
	Gecko/2008102920 Firefox/3.0.4,gzip(gfe),gzip(gfe)
Message-ID: <96fc674f-1de9-452a-b860-a24e4f0fcc02@h20g2000yqn.googlegroups.com>
Subject: Re: CPU SPEED
From: blindfold <seeingwithso...@gmail.com>
To: android-platform <android-platform@googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

> - Issues with the G1 hardware would really be better taken up with T-Mobi=
le;
> 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, ...".

On Nov 27, 3:27=A0am, "Dianne Hackborn" <hack...@android.com> wrote:
> 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 spe=
ed,
> and there is no plan at this point to add one.
>
> - Issues with the G1 hardware would really be better taken up with T-Mobi=
le;
> software engineers working on the Android platform just can't help you
> here. =A0We can tell you what we know about the hardware, but that is abo=
ut
> all.
>
>
>
> On Wed, Nov 26, 2008 at 6:05 PM, jdc4429 <jdc4...@gmail.com> wrote:
>
> > 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 consump=
tion
> > by
> > > running a little slower. =A0(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 n=
eed
> > 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. =A0A key statement yo=
u
> > made was "people who want silence" which shows they have a choice... I
> > think we should also be given a choice. =A0We 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. =A0I 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. =A0Or 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. =A0I would still want to be able to
> > scale the CPU if desired manually. =A0I 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. =A0I already have a Palm TX. =A0I was looki=
ng
> > for something to go to the next level. =A0I 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=
.
> > =A0In
> > > 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? =A0"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 batter=
y;
> > > reducing the maximum speed it will run probably won't have much impac=
t,
> > > unless you have some app sitting there spinning the cpu all of the ti=
me
> > (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
> > =A0Jeff
>
> > 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. =A0You'll reduce the phone's battery life from da=
ys
> > down
> > > to hours. =A0A big reason why phones have decent battery life is beca=
use
> > they
> > > take a lot of care to -not- do stuff.
>
> > > --
> > > Dianne Hackborn
> > > Android framework engineer
> > > hack...@android.com
>
> > > Note: please don't send private questions to me, as I don't have time=
 to
> > > provide private support. =A0All such questions should be posted on pu=
blic
> > > forums, where I and others can see and answer them.
>
> --
> Dianne Hackborn
> Android framework engineer
> hack...@android.com
>
> Note: please don't send private questions to me, as I don't have time to
> provide private support. =A0All such questions should be posted on public

Received: by 10.115.109.18 with SMTP id l18mr3877357wam.8.1227796508498;
        Thu, 27 Nov 2008 06:35:08 -0800 (PST)
Return-Path: <j...@google.com>
Received: from smtp-out.google.com ([216.239.45.13])
        by mx.google.com with ESMTP id m37si898281waf.0.2008.11.27.06.35.07;
        Thu, 27 Nov 2008 06:35:07 -0800 (PST)
Received-SPF: pass (google.com: domain of j...@google.com designates 216.239.45.13 as 
permitted sender) client-ip=216.239.45.13;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of j...@google.com 
designates 216.239.45.13 as permitted sender) smtp.mail=...@google.com; dkim=pass 
(test mode) header...@google.com
Received: from zps38.corp.google.com (zps38.corp.google.com [172.25.146.38])
	by smtp-out.google.com with ESMTP id mAREZ6i4004691
	for <android-platform@googlegroups.com>; Thu, 27 Nov 2008 06:35:06 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta;
	t=1227796507; bh=/pRf/eeC5/m93UT3gMVItyYscMA=;
	h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date:
	 Message-ID:Subject:From:To:Content-Type:Content-Transfer-Encoding;
	b=KNKzCRQooHZPfNnUna4q75dy7r6QnPhw3tjOQyePN+xmgeAzuMh4iUTndvp2ByXKH
	hKUfE6vG1pGcsIizr0lOg==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to:
	content-type:content-transfer-encoding;
	b=EBQ5ffnhNptyyTwl6YkBkPB71EO/IgumMuIHJJJ9yHIUvxkBtQhkO9tp3ReS0DOo8
	6jw0iDaHUy8N5YQKROESQ==
Received: from wf-out-1314.google.com (wfc25.prod.google.com [10.142.3.25])
	by zps38.corp.google.com with ESMTP id mAREYeON005100
	for <android-platform@googlegroups.com>; Thu, 27 Nov 2008 06:35:05 -0800
Received: by wf-out-1314.google.com with SMTP id 25so1003949wfc.22
        for <android-platform@googlegroups.com>; Thu, 27 Nov 2008 06:35:05 -0800 (PST)
MIME-Version: 1.0
Received: by 10.142.128.15 with SMTP id a15mr2986408wfd.260.1227796505503; 
	Thu, 27 Nov 2008 06:35:05 -0800 (PST)
In-Reply-To: <96fc674f-1de9-452a-b860-a24e4f0fcc02@h20g2000yqn.googlegroups.com>
References: <d1967e0b-b26a-4069-9ca0-25e21655d...@z28g2000prd.googlegroups.com>
	 <405822f0-f257-41af-8033-85118769e...@w24g2000prd.googlegroups.com>
	 <26b7c7380811261111n6737077dy5ba5024ef5411...@mail.gmail.com>
	 <70dc1d85-cda0-405f-b78f-37ff29068...@j39g2000yqn.googlegroups.com>
	 <26b7c7380811261248v80b679o5d5527a7ed09b...@mail.gmail.com>
	 <41f0b2f4-f155-421e-9e07-b172ce1bb...@41g2000yqf.googlegroups.com>
	 <26b7c7380811261338r5f1ba5ceh40961b52e78fe...@mail.gmail.com>
	 <ad58d2a4-5ec1-4748-ab8b-53eab998b...@w1g2000prm.googlegroups.com>
	 <26b7c7380811261827m60cedc83oe9e80f3545ae2...@mail.gmail.com>
	 <96fc674f-1de9-452a-b860-a24e4f0fc...@h20g2000yqn.googlegroups.com>
Date: Thu, 27 Nov 2008 06:35:05 -0800
Message-ID: <1702acb30811270635m2d66f1dfv5f0e5393233eb...@mail.gmail.com>
Subject: Re: CPU SPEED
From: Jean-Baptiste Queru <j...@google.com>
To: android-platform@googlegroups.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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

On Thu, Nov 27, 2008 at 1:43 AM, blindfold <seeingwithso...@gmail.com> wrote:
>
>> - 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, ...".
>
> On Nov 27, 3:27 am, "Dianne Hackborn" <hack...@android.com> wrote:
>> 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.
>>
>>
>>
>> On Wed, Nov 26, 2008 at 6:05 PM, jdc4429 <jdc4...@gmail.com> wrote:
>>
>> > 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
>>
>> > > 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.
>>
>> --
>> Dianne Hackborn
>> Android framework engineer
>> hack...@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.
>

MIME-Version: 1.0
Received: by 10.100.106.1 with SMTP id e1mr523173anc.19.1227798899100; Thu, 27 
	Nov 2008 07:14:59 -0800 (PST)
Date: Thu, 27 Nov 2008 07:14:59 -0800 (PST)
In-Reply-To: <1702acb30811270635m2d66f1dfv5f0e5393233eb5a7@mail.gmail.com>
X-IP: 80.255.245.177
References: <d1967e0b-b26a-4069-9ca0-25e21655d27e@z28g2000prd.googlegroups.com> 
	<405822f0-f257-41af-8033-85118769e45c@w24g2000prd.googlegroups.com> 
	<26b7c7380811261111n6737077dy5ba5024ef5411818@mail.gmail.com> 
	<70dc1d85-cda0-405f-b78f-37ff290683c6@j39g2000yqn.googlegroups.com> 
	<26b7c7380811261248v80b679o5d5527a7ed09b007@mail.gmail.com> 
	<41f0b2f4-f155-421e-9e07-b172ce1bbcf7@41g2000yqf.googlegroups.com> 
	<26b7c7380811261338r5f1ba5ceh40961b52e78fe2a1@mail.gmail.com> 
	<ad58d2a4-5ec1-4748-ab8b-53eab998bda2@w1g2000prm.googlegroups.com> 
	<26b7c7380811261827m60cedc83oe9e80f3545ae228c@mail.gmail.com> 
	<96fc674f-1de9-452a-b860-a24e4f0fcc02@h20g2000yqn.googlegroups.com> 
	<1702acb30811270635m2d66f1dfv5f0e5393233eb5a7@mail.gmail.com>
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.4) 
	Gecko/2008102920 Firefox/3.0.4,gzip(gfe),gzip(gfe)
Message-ID: <871ff307-a080-4c39-8723-6fda4cbe8b81@t2g2000yqm.googlegroups.com>
Subject: Re: CPU SPEED
From: blindfold <seeingwithso...@gmail.com>
To: android-platform <android-platform@googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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-t=
he-dalvik-vm/
and http://occipital.com/blog/2008/11/02/android-performance-3-iphone-compa=
rison/

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

On Nov 27, 3:35=A0pm, 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

Received: by 10.114.77.1 with SMTP id z1mr3902834waa.23.1227799630849;
        Thu, 27 Nov 2008 07:27:10 -0800 (PST)
Return-Path: <j...@google.com>
Received: from smtp-out.google.com ([216.239.45.13])
        by mx.google.com with ESMTP id m37si929715waf.0.2008.11.27.07.27.09;
        Thu, 27 Nov 2008 07:27:09 -0800 (PST)
Received-SPF: pass (google.com: domain of j...@google.com designates 216.239.45.13 as 
permitted sender) client-ip=216.239.45.13;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of j...@google.com 
designates 216.239.45.13 as permitted sender) smtp.mail=...@google.com; dkim=pass 
(test mode) header...@google.com
Received: from zps75.corp.google.com (zps75.corp.google.com [172.25.146.75])
	by smtp-out.google.com with ESMTP id mARFR9jr020214
	for <android-platform@googlegroups.com>; Thu, 27 Nov 2008 07:27:09 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta;
	t=1227799629; bh=yvw7WaB39PKEc/gpw7LDStpwEMo=;
	h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date:
	 Message-ID:Subject:From:To:Content-Type:Content-Transfer-Encoding;
	b=ZumKdv6kEZGamzTbqSTtnB2LJO7Zw7iztELbBrdLoOd0Vb+V55FJoKCAcIx/xfBd8
	HoA1BxGRWpo1Ob9e5NWVw==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to:
	content-type:content-transfer-encoding;
	b=X8bOdIEFez0l99dV6zyKxlRZBWEz68c2+M24SFZxvU7lrTEeqRE/rWYXHhzfdN8xY
	CVjUsQJDuJNA54TYzl+Og==
Received: from wf-out-1314.google.com (wfd27.prod.google.com [10.142.4.27])
	by zps75.corp.google.com with ESMTP id mARFQfkT009143
	for <android-platform@googlegroups.com>; Thu, 27 Nov 2008 07:27:08 -0800
Received: by wf-out-1314.google.com with SMTP id 27so1059562wfd.31
        for <android-platform@googlegroups.com>; Thu, 27 Nov 2008 07:27:08 -0800 (PST)
MIME-Version: 1.0
Received: by 10.142.203.19 with SMTP id a19mr2995245wfg.310.1227799627040; 
	Thu, 27 Nov 2008 07:27:07 -0800 (PST)
In-Reply-To: <871ff307-a080-4c39-8723-6fda4cbe8b81@t2g2000yqm.googlegroups.com>
References: <d1967e0b-b26a-4069-9ca0-25e21655d...@z28g2000prd.googlegroups.com>
	 <70dc1d85-cda0-405f-b78f-37ff29068...@j39g2000yqn.googlegroups.com>
	 <26b7c7380811261248v80b679o5d5527a7ed09b...@mail.gmail.com>
	 <41f0b2f4-f155-421e-9e07-b172ce1bb...@41g2000yqf.googlegroups.com>
	 <26b7c7380811261338r5f1ba5ceh40961b52e78fe...@mail.gmail.com>
	 <ad58d2a4-5ec1-4748-ab8b-53eab998b...@w1g2000prm.googlegroups.com>
	 <26b7c7380811261827m60cedc83oe9e80f3545ae2...@mail.gmail.com>
	 <96fc674f-1de9-452a-b860-a24e4f0fc...@h20g2000yqn.googlegroups.com>
	 <1702acb30811270635m2d66f1dfv5f0e5393233eb...@mail.gmail.com>
	 <871ff307-a080-4c39-8723-6fda4cbe8...@t2g2000yqm.googlegroups.com>
Date: Thu, 27 Nov 2008 07:27:06 -0800
Message-ID: <1702acb30811270727r5bd5c81ay3eccc2d92743...@mail.gmail.com>
Subject: Re: CPU SPEED
From: Jean-Baptiste Queru <j...@google.com>
To: android-platform@googlegroups.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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

On Thu, Nov 27, 2008 at 7:14 AM, blindfold <seeingwithso...@gmail.com> wrote:
>
> 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
>
>
> On Nov 27, 3:35 pm, 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
>

MIME-Version: 1.0
Received: by 10.101.1.16 with SMTP id d16mr525276ani.7.1227801008019; Thu, 27 
	Nov 2008 07:50:08 -0800 (PST)
Date: Thu, 27 Nov 2008 07:50:08 -0800 (PST)
In-Reply-To: <1702acb30811270727r5bd5c81ay3eccc2d92743329@mail.gmail.com>
X-IP: 80.255.245.177
References: <d1967e0b-b26a-4069-9ca0-25e21655d27e@z28g2000prd.googlegroups.com> 
	<70dc1d85-cda0-405f-b78f-37ff290683c6@j39g2000yqn.googlegroups.com> 
	<26b7c7380811261248v80b679o5d5527a7ed09b007@mail.gmail.com> 
	<41f0b2f4-f155-421e-9e07-b172ce1bbcf7@41g2000yqf.googlegroups.com> 
	<26b7c7380811261338r5f1ba5ceh40961b52e78fe2a1@mail.gmail.com> 
	<ad58d2a4-5ec1-4748-ab8b-53eab998bda2@w1g2000prm.googlegroups.com> 
	<26b7c7380811261827m60cedc83oe9e80f3545ae228c@mail.gmail.com> 
	<96fc674f-1de9-452a-b860-a24e4f0fcc02@h20g2000yqn.googlegroups.com> 
	<1702acb30811270635m2d66f1dfv5f0e5393233eb5a7@mail.gmail.com> 
	<871ff307-a080-4c39-8723-6fda4cbe8b81@t2g2000yqm.googlegroups.com> 
	<1702acb30811270727r5bd5c81ay3eccc2d92743329@mail.gmail.com>
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.4) 
	Gecko/2008102920 Firefox/3.0.4,gzip(gfe),gzip(gfe)
Message-ID: <bedecb8f-9927-47f1-8f25-0a0ccabbcd5e@y18g2000yqn.googlegroups.com>
Subject: Re: CPU SPEED
From: blindfold <seeingwithso...@gmail.com>
To: android-platform <android-platform@googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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

On Nov 27, 4:27=A0pm, Jean-Baptiste Queru <j...@google.com> wrote:
> 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

Received: by 10.140.201.6 with SMTP id y6mr3133963rvf.17.1227801388700;
        Thu, 27 Nov 2008 07:56:28 -0800 (PST)
Return-Path: <j...@google.com>
Received: from smtp-out.google.com ([216.239.45.13])
        by mx.google.com with ESMTP id k19si942735waf.2.2008.11.27.07.56.27;
        Thu, 27 Nov 2008 07:56:27 -0800 (PST)
Received-SPF: pass (google.com: domain of j...@google.com designates 216.239.45.13 
as permitted sender) client-ip=216.239.45.13;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of j...@google.com 
designates 216.239.45.13 as permitted sender) smtp.mail=...@google.com; dkim=pass 
(test mode) header...@google.com
Received: from spaceape7.eur.corp.google.com (spaceape7.eur.corp.google.com 
[172.28.16.141])
	by smtp-out.google.com with ESMTP id mARFuQmS012411
	for <android-platform@googlegroups.com>; Thu, 27 Nov 2008 07:56:27 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta;
	t=1227801387; bh=GxOPGZZj7PP6Oc40u/7M6ZGJWo4=;
	h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date:
	 Message-ID:Subject:From:To:Content-Type:Content-Transfer-Encoding;
	b=jsWOaA4eYnbQYA+OQBZPQXNMKaZ//nnMG0Z9Mpze2PsoGs31xFy5VM8/AEcThOxWu
	HOdVe5O9mZXw+vLJE+C2w==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to:
	content-type:content-transfer-encoding;
	b=FO+8ollvA7iFRabovZRdQ0LEWEAD0tVH9a3/GPia7m2l8n+/YsqWc12jPsfpmcWU+
	7qjZdw5IH6rEzFR8dGo9A==
Received: from wf-out-1314.google.com (wfg24.prod.google.com [10.142.7.24])
	by spaceape7.eur.corp.google.com with ESMTP id mARFuOZH003224
	for <android-platform@googlegroups.com>; Thu, 27 Nov 2008 07:56:24 -0800
Received: by wf-out-1314.google.com with SMTP id 24so1057053wfg.15
        for <android-platform@googlegroups.com>; Thu, 27 Nov 2008 07:56:24 -0800 (PST)
MIME-Version: 1.0
Received: by 10.142.166.1 with SMTP id o1mr2997588wfe.337.1227801383972; Thu, 
	27 Nov 2008 07:56:23 -0800 (PST)
In-Reply-To: <bedecb8f-9927-47f1-8f25-0a0ccabbcd5e@y18g2000yqn.googlegroups.com>
References: <d1967e0b-b26a-4069-9ca0-25e21655d...@z28g2000prd.googlegroups.com>
	 <41f0b2f4-f155-421e-9e07-b172ce1bb...@41g2000yqf.googlegroups.com>
	 <26b7c7380811261338r5f1ba5ceh40961b52e78fe...@mail.gmail.com>
	 <ad58d2a4-5ec1-4748-ab8b-53eab998b...@w1g2000prm.googlegroups.com>
	 <26b7c7380811261827m60cedc83oe9e80f3545ae2...@mail.gmail.com>
	 <96fc674f-1de9-452a-b860-a24e4f0fc...@h20g2000yqn.googlegroups.com>
	 <1702acb30811270635m2d66f1dfv5f0e5393233eb...@mail.gmail.com>
	 <871ff307-a080-4c39-8723-6fda4cbe8...@t2g2000yqm.googlegroups.com>
	 <1702acb30811270727r5bd5c81ay3eccc2d92743...@mail.gmail.com>
	 <bedecb8f-9927-47f1-8f25-0a0ccabbc...@y18g2000yqn.googlegroups.com>
Date: Thu, 27 Nov 2008 07:56:23 -0800
Message-ID: <1702acb30811270756l293f36f5k7e4678c05f6e5...@mail.gmail.com>
Subject: Re: CPU SPEED
From: Jean-Baptiste Queru <j...@google.com>
To: android-platform@googlegroups.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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

On Thu, Nov 27, 2008 at 7:50 AM, blindfold <seeingwithso...@gmail.com> wrote:
>
> 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
>
> On Nov 27, 4:27 pm, Jean-Baptiste Queru <j...@google.com> wrote:
>> 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
>

MIME-Version: 1.0
Received: by 10.100.106.1 with SMTP id e1mr815199anc.19.1228058648799; Sun, 30 
	Nov 2008 07:24:08 -0800 (PST)
Date: Sun, 30 Nov 2008 07:24:08 -0800 (PST)
In-Reply-To: <38ea46ac-9681-4771-9373-1bf478cab5f2@j38g2000yqa.googlegroups.com>
X-IP: 82.171.47.248
References: <d1967e0b-b26a-4069-9ca0-25e21655d27e@z28g2000prd.googlegroups.com> 
	<67b68355-cc63-4062-9dc3-eee6ba2ed2ca@a12g2000yqm.googlegroups.com> 
	<72332619-4560-448f-af27-59baafba5c2e@f20g2000yqg.googlegroups.com> 
	<76cb1592-8470-4c27-b7da-e02c616d00bb@k8g2000yqn.googlegroups.com> 
	<1702acb30811281912w39a13642x6d5575416b2fa772@mail.gmail.com> 
	<bef3ac65-dd86-4695-82ac-b8d287d86140@v13g2000yqm.googlegroups.com> 
	<1702acb30811290317g7a63a40bl7d62c41c24e52a93@mail.gmail.com> 
	<993c834c-f193-410c-8cca-56dc1bae9131@x14g2000yqk.googlegroups.com> 
	<1702acb30811290527k26af6b11n9919da983740623b@mail.gmail.com> 
	<705355c8-5cca-42fe-9eab-198b3d9900b0@x38g2000yqj.googlegroups.com> 
	<1702acb30811290812h4d735abfl7928efca27855f8c@mail.gmail.com> 
	<38ea46ac-9681-4771-9373-1bf478cab5f2@j38g2000yqa.googlegroups.com>
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.4) 
	Gecko/2008102920 Firefox/3.0.4,gzip(gfe),gzip(gfe)
Message-ID: <c764c3b1-80b8-4c08-b189-b3c99aa3d7cd@w3g2000yqc.googlegroups.com>
Subject: Re: CPU SPEED
From: blindfold <seeingwithso...@gmail.com>
To: android-platform <android-platform@googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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

Received: by 10.151.155.9 with SMTP id h9mr2373294ybo.18.1228059974188;
        Sun, 30 Nov 2008 07:46:14 -0800 (PST)
Return-Path: <mmur...@commonsware.com>
Received: from mail.commonsware.com (208-75-86-238.slicehost.net [208.75.86.238])
        by mx.google.com with ESMTP id 39si4679463yxd.2.2008.11.30.07.46.13;
        Sun, 30 Nov 2008 07:46:14 -0800 (PST)
Received-SPF: pass (google.com: domain of mmur...@commonsware.com designates 
208.75.86.238 as permitted sender) client-ip=208.75.86.238;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of 
mmur...@commonsware.com designates 208.75.86.238 as permitted sender) 
smtp.mail=mmur...@commonsware.com
Received: from gx260.lan (70.44.71.92.res-cmts.sm.ptd.net [70.44.71.92])
	by mail.commonsware.com (Postfix) with ESMTP id 418291E8B8B
	for <android-platform@googlegroups.com>; Sun, 30 Nov 2008 15:46:13 +0000 (UTC)
Received: from [192.168.9.197] (nc8000.lan [192.168.9.197])
	by gx260.lan (Postfix) with ESMTP id B1EA06BE005
	for <android-platform@googlegroups.com>; Sun, 30 Nov 2008 10:45:42 -0500 (EST)
Message-ID: <4932B544.4070406@commonsware.com>
Date: Sun, 30 Nov 2008 10:46:12 -0500
From: Mark Murphy <mmur...@commonsware.com>
User-Agent: Thunderbird 2.0.0.17 (X11/20080925)
MIME-Version: 1.0
To: android-platform@googlegroups.com
Subject: Re: CPU SPEED
References: <d1967e0b-b26a-4069-9ca0-25e21655d27e@z28g2000prd.googlegroups.com>  
<67b68355-cc63-4062-9dc3-eee6ba2ed2ca@a12g2000yqm.googlegroups.com>  
<72332619-4560-448f-af27-59baafba5c2e@f20g2000yqg.googlegroups.com>  
<76cb1592-8470-4c27-b7da-e02c616d00bb@k8g2000yqn.googlegroups.com>  
<1702acb30811281912w39a13642x6d5575416b2fa772@mail.gmail.com>  
<bef3ac65-dd86-4695-82ac-b8d287d86140@v13g2000yqm.googlegroups.com>  
<1702acb30811290317g7a63a40bl7d62c41c24e52a93@mail.gmail.com>  
<993c834c-f193-410c-8cca-56dc1bae9131@x14g2000yqk.googlegroups.com>  
<1702acb30811290527k26af6b11n9919da983740623b@mail.gmail.com>  
<705355c8-5cca-42fe-9eab-198b3d9900b0@x38g2000yqj.googlegroups.com>  
<1702acb30811290812h4d735abfl7928efca27855f8c@mail.gmail.com>  
<38ea46ac-9681-4771-9373-1bf478cab...@j38g2000yqa.googlegroups.com> 
<c764c3b1-80b8-4c08-b189-b3c99aa3d...@w3g2000yqc.googlegroups.com>
In-Reply-To: <c764c3b1-80b8-4c08-b189-b3c99aa3d...@w3g2000yqc.googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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!

MIME-Version: 1.0
Received: by 10.151.112.12 with SMTP id p12mr819446ybm.23.1228061547937; Sun, 
	30 Nov 2008 08:12:27 -0800 (PST)
Date: Sun, 30 Nov 2008 08:12:27 -0800 (PST)
In-Reply-To: <4932B544.4070406@commonsware.com>
X-IP: 82.171.47.248
References: <d1967e0b-b26a-4069-9ca0-25e21655d27e@z28g2000prd.googlegroups.com> 
	<72332619-4560-448f-af27-59baafba5c2e@f20g2000yqg.googlegroups.com> 
	<76cb1592-8470-4c27-b7da-e02c616d00bb@k8g2000yqn.googlegroups.com> 
	<1702acb30811281912w39a13642x6d5575416b2fa772@mail.gmail.com> 
	<bef3ac65-dd86-4695-82ac-b8d287d86140@v13g2000yqm.googlegroups.com> 
	<1702acb30811290317g7a63a40bl7d62c41c24e52a93@mail.gmail.com> 
	<993c834c-f193-410c-8cca-56dc1bae9131@x14g2000yqk.googlegroups.com> 
	<1702acb30811290527k26af6b11n9919da983740623b@mail.gmail.com> 
	<705355c8-5cca-42fe-9eab-198b3d9900b0@x38g2000yqj.googlegroups.com> 
	<1702acb30811290812h4d735abfl7928efca27855f8c@mail.gmail.com> 
	<38ea46ac-9681-4771-9373-1bf478cab5f2@j38g2000yqa.googlegroups.com> 
	<c764c3b1-80b8-4c08-b189-b3c99aa3d7cd@w3g2000yqc.googlegroups.com> 
	<4932B544.4070406@commonsware.com>
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.4) 
	Gecko/2008102920 Firefox/3.0.4,gzip(gfe),gzip(gfe)
Message-ID: <50b3cf2a-9b94-44c9-abac-db9e1f7f29b1@v4g2000yqa.googlegroups.com>
Subject: Re: CPU SPEED
From: blindfold <seeingwithso...@gmail.com>
To: android-platform <android-platform@googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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) =3D 8 - 10, or an order of magnitude.

Thanks for posting the G1 test results!


On Nov 30, 4:46=A0pm, 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

Received: by 10.90.113.11 with SMTP id l11mr2527612agc.11.1228062900052;
        Sun, 30 Nov 2008 08:35:00 -0800 (PST)
Return-Path: <e...@brainaid.de>
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186])
        by mx.google.com with ESMTP id 7si4717788yxg.0.2008.11.30.08.34.59;
        Sun, 30 Nov 2008 08:34:59 -0800 (PST)
Received-SPF: neutral (google.com: 212.227.126.186 is neither permitted nor denied by 
best guess record for domain of e...@brainaid.de) client-ip=212.227.126.186;
Authentication-Results: mx.google.com; spf=neutral (google.com: 212.227.126.186 is 
neither permitted nor denied by best guess record for domain of e...@brainaid.de) 
smtp.mail=...@brainaid.de
Received: from panic.int.moresnet.net (ip135.dyn1.gretry2.schedom-europe.net 
[83.101.21.135])
	by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis)
	id 0ML31I-1L6pG62F5z-0004yu; Sun, 30 Nov 2008 17:34:58 +0100
Received: from tl1.int.moresnet.net ([10.0.0.5] ident=Debian-exim)
	by panic.int.moresnet.net with esmtp (Exim 4.63)
	(envelope-from <e...@brainaid.de>)
	id 1L6pFt-0003lR-2f
	for android-platform@googlegroups.com; Sun, 30 Nov 2008 17:34:57 +0100
Received: from ecd by tl1.int.moresnet.net with local (Exim 4.63)
	(envelope-from <e...@brainaid.de>)
	id 1L6pFs-0005rO-Bg
	for android-platform@googlegroups.com; Sun, 30 Nov 2008 17:34:44 +0100
Date: Sun, 30 Nov 2008 17:34:44 +0100
To: android-platform@googlegroups.com
Subject: Re: CPU SPEED
Message-ID: <20081130163444.GA10321@brainaid.de>
References: <bef3ac65-dd86-4695-82ac-b8d287d86140@v13g2000yqm.googlegroups.com> 
<1702acb30811290317g7a63a40bl7d62c41c24e52a93@mail.gmail.com> 
<993c834c-f193-410c-8cca-56dc1bae9131@x14g2000yqk.googlegroups.com> 
<1702acb30811290527k26af6b11n9919da983740623b@mail.gmail.com> 
<705355c8-5cca-42fe-9eab-198b3d9900b0@x38g2000yqj.googlegroups.com> 
<1702acb30811290812h4d735abfl7928efca27855f8c@mail.gmail.com> 
<38ea46ac-9681-4771-9373-1bf478cab5f2@j38g2000yqa.googlegroups.com> 
<c764c3b1-80b8-4c08-b189-b3c99aa3d7cd@w3g2000yqc.googlegroups.com> 
<4932B544.4070...@commonsware.com> 
<50b3cf2a-9b94-44c9-abac-db9e1f7f2...@v4g2000yqa.googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <50b3cf2a-9b94-44c9-abac-db9e1f7f2...@v4g2000yqa.googlegroups.com>
User-Agent: Mutt/1.5.13 (2006-08-11)
From: "Eddie C. Dost" <e...@brainaid.de>
X-Provags-ID: V01U2FsdGVkX19jw4VlHp5JxX5mfd4up3Y6//VeH/5RAFdxwV/
 GNWlla/v2LhVMlHhKrAClpb8g/Mkwo93VC9Mxw7rO4f2Gy8tMy
 A7MnTCVSCQFc+PYrP3taA==

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

/Eddie

On Sun, Nov 30, 2008 at 08:12:27AM -0800, blindfold wrote:
> 
> 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
> > _The Busy Coder's Guide to Android Development_ Version 1.4 Published!

-- 
___________________________________________________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

MIME-Version: 1.0
Received: by 10.100.139.20 with SMTP id m20mr912834and.15.1228142106928; Mon, 
	01 Dec 2008 06:35:06 -0800 (PST)
Date: Mon, 1 Dec 2008 06:35:06 -0800 (PST)
In-Reply-To: <20081130163444.GA10321@brainaid.de>
X-IP: 80.255.245.177
References: <bef3ac65-dd86-4695-82ac-b8d287d86140@v13g2000yqm.googlegroups.com> 
	<1702acb30811290317g7a63a40bl7d62c41c24e52a93@mail.gmail.com> 
	<993c834c-f193-410c-8cca-56dc1bae9131@x14g2000yqk.googlegroups.com> 
	<1702acb30811290527k26af6b11n9919da983740623b@mail.gmail.com> 
	<705355c8-5cca-42fe-9eab-198b3d9900b0@x38g2000yqj.googlegroups.com> 
	<1702acb30811290812h4d735abfl7928efca27855f8c@mail.gmail.com> 
	<38ea46ac-9681-4771-9373-1bf478cab5f2@j38g2000yqa.googlegroups.com> 
	<c764c3b1-80b8-4c08-b189-b3c99aa3d7cd@w3g2000yqc.googlegroups.com> 
	<4932B544.4070406@commonsware.com> 
	<50b3cf2a-9b94-44c9-abac-db9e1f7f29b1@v4g2000yqa.googlegroups.com> 
	<20081130163444.GA10321@brainaid.de>
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.4) 
	Gecko/2008102920 Firefox/3.0.4,gzip(gfe),gzip(gfe)
Message-ID: <4820fb82-0f00-4579-88f9-fd642892beed@w34g2000yqm.googlegroups.com>
Subject: Re: CPU SPEED
From: blindfold <seeingwithso...@gmail.com>
To: android-platform <android-platform@googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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 =3D 725 ms; sum =3D -4394332
   Runtime =3D 702 ms; sum =3D -4394332
   Runtime =3D 705 ms; sum =3D -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/mount=
side.pdf).
Or maybe the X1 too, like the G1, runs the CPU well below the
specified 528 MHz. :-)

Regards

On Nov 30, 5:34=A0pm, "Eddie C. Dost" <e...@brainaid.de> wrote:
> And this is one of the many reasons why developers want native code
> on the G1. Google: Free your phone!
>
> /Eddie

MIME-Version: 1.0
Received: by 10.151.109.11 with SMTP id l11mr714829ybm.20.1228160317593; Mon, 
	01 Dec 2008 11:38:37 -0800 (PST)
Date: Mon, 1 Dec 2008 11:38:37 -0800 (PST)
In-Reply-To: <4820fb82-0f00-4579-88f9-fd642892beed@w34g2000yqm.googlegroups.com>
X-IP: 172.18.103.19
References: 4820fb82-0f00-4579-88f9-fd642892beed@w34g2000yqm.googlegroups.com
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9) 
	Gecko/2008052912 Firefox/3.0,gzip(gfe),gzip(gfe)
Message-ID: <b92cfab5-aa83-45ca-8c26-3fc15cbd5563@p2g2000prf.googlegroups.com>
Subject: Re: CPU SPEED
From: fadden <fad...@android.com>
To: android-platform <android-platform@googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Dec 1, 6:35=A0am, 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

MIME-Version: 1.0
Received: by 10.150.12.4 with SMTP id 4mr941140ybl.10.1228166224185; Mon, 01 
	Dec 2008 13:17:04 -0800 (PST)
Date: Mon, 1 Dec 2008 13:17:04 -0800 (PST)
In-Reply-To: <b92cfab5-aa83-45ca-8c26-3fc15cbd5563@p2g2000prf.googlegroups.com>
X-IP: 82.171.47.248
References: 4820fb82-0f00-4579-88f9-fd642892beed@w34g2000yqm.googlegroups.com 
	<b92cfab5-aa83-45ca-8c26-3fc15cbd5563@p2g2000prf.googlegroups.com>
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.4) 
	Gecko/2008102920 Firefox/3.0.4,gzip(gfe),gzip(gfe)
Message-ID: <377da486-f555-48f1-b221-89e1c4b097fd@y18g2000yqn.googlegroups.com>
Subject: Re: CPU SPEED
From: blindfold <seeingwithso...@gmail.com>
To: android-platform <android-platform@googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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.

On Dec 1, 8:38=A0pm, fadden <fad...@android.com> wrote:
> On Dec 1, 6:35=A0am, 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:
>
> =A0 Assembly =A0 =A0 =A01.0
> =A0 C/C++ =A0 =A0 =A0 =A0 1.5
> =A0 Java (compiled) =A0 =A0 =A0 3.5

Received: by 10.90.100.17 with SMTP id x17mr4186543agb.5.1228170563233;
        Mon, 01 Dec 2008 14:29:23 -0800 (PST)
Return-Path: <hack...@android.com>
Received: from yx-out-1718.google.com ([172.21.8.36])
        by mx.google.com with ESMTP id 39si6426385yxd.2.2008.12.01.14.29.23;
        Mon, 01 Dec 2008 14:29:23 -0800 (PST)
Received-SPF: neutral (google.com: 172.21.8.36 is neither permitted nor denied by best 
guess record for domain of hack...@android.com) client-ip=172.21.8.36;
Authentication-Results: mx.google.com; spf=neutral (google.com: 172.21.8.36 is neither 
permitted nor denied by best guess record for domain of hack...@android.com) 
smtp.mail=hack...@android.com
Received: by yx-out-1718.google.com with SMTP id 36so1343307yxh.32
        for <android-platform@googlegroups.com>; Mon, 01 Dec 2008 14:29:23 -0800 (PST)
Received: by 10.142.245.6 with SMTP id s6mr4655870wfh.213.1228170562816;
        Mon, 01 Dec 2008 14:29:22 -0800 (PST)
Received: by 10.142.158.19 with HTTP; Mon, 1 Dec 2008 14:29:22 -0800 (PST)
Message-ID: <26b7c7380812011429u1ecadca0r9c8a0c50d89033a3@mail.gmail.com>
Date: Mon, 1 Dec 2008 14:29:22 -0800
From: "Dianne Hackborn" <hack...@android.com>
To: android-platform@googlegroups.com
Subject: Re: CPU SPEED
In-Reply-To: <377da486-f555-48f1-b221-89e1c4b097fd@y18g2000yqn.googlegroups.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_88067_6991082.1228170562805"
References: <b92cfab5-aa83-45ca-8c26-3fc15cbd5563@p2g2000prf.googlegroups.com>
	 <377da486-f555-48f1-b221-89e1c4b097fd@y18g2000yqn.googlegroups.com>

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

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.

MIME-Version: 1.0
Received: by 10.100.239.11 with SMTP id m11mr972097anh.14.1228194435311; Mon, 
	01 Dec 2008 21:07:15 -0800 (PST)
Date: Mon, 1 Dec 2008 21:07:15 -0800 (PST)
In-Reply-To: <26b7c7380812011429u1ecadca0r9c8a0c50d89033a3@mail.gmail.com>
X-IP: 82.171.47.248
References: <b92cfab5-aa83-45ca-8c26-3fc15cbd5563@p2g2000prf.googlegroups.com> 
	<377da486-f555-48f1-b221-89e1c4b097fd@y18g2000yqn.googlegroups.com> 
	<26b7c7380812011429u1ecadca0r9c8a0c50d89033a3@mail.gmail.com>
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.4) 
	Gecko/2008102920 Firefox/3.0.4,gzip(gfe),gzip(gfe)
Message-ID: <3d406cd6-27de-46f8-9129-9aff8cf46066@w34g2000yqm.googlegroups.com>
Subject: Re: CPU SPEED
From: blindfold <seeingwithso...@gmail.com>
To: android-platform <android-platform@googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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=A0pm, "Dianne Hackborn" <hack...@android.com> wrote:
> On Mon, Dec 1, 2008 at 1:17 PM, blindfold <seeingwithso...@gmail.com> wro=
te:
> > 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. =A0You'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 h=
ave
> an impact on process startup time, etc.
>
> NOBODY is telling you that a JIT is bad and shouldn't be done. =A0The iss=
ue is
> that doing one that works well and actually improves things for the andro=
id
> 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? =A0That would be great. =A0Otherwise,=
 it's
> currently not on the road map, and there are probably higher priority thi=
ngs
> that people have to work on. =A0For example, it might be much more import=
ant
> to spend VM engineering effort on improving the garbage collector and
> overall memory usage. =A0Or maybe porting to x86 if that is what is neede=
d.
> Continuing to complain about this is not likely to change those other
> priorities.
>
> --
> Dianne Hackborn
> Android framework engineer
> hack...@android.com

Received: by 10.90.83.18 with SMTP id g18mr4359124agb.23.1228197733654;
        Mon, 01 Dec 2008 22:02:13 -0800 (PST)
Return-Path: <j...@android.com>
Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185])
        by mx.google.com with ESMTP id 39si6884943yxd.2.2008.12.01.22.02.13;
        Mon, 01 Dec 2008 22:02:13 -0800 (PST)
Received-SPF: neutral (google.com: 64.233.182.185 is neither permitted nor denied by 
best guess record for domain of j...@android.com) client-ip=64.233.182.185;
Authentication-Results: mx.google.com; spf=neutral (google.com: 64.233.182.185 is 
neither permitted nor denied by best guess record for domain of j...@android.com) 
smtp.mail=j...@android.com
Received: by nf-out-0910.google.com with SMTP id e27so1484956nfd.29
        for <android-platform@googlegroups.com>; Mon, 01 Dec 2008 22:02:12 -0800 (PST)
Received: by 10.210.65.17 with SMTP id n17mr8297978eba.76.1228197732649;
        Mon, 01 Dec 2008 22:02:12 -0800 (PST)
Received: by 10.210.41.7 with HTTP; Mon, 1 Dec 2008 22:02:12 -0800 (PST)
Message-ID: <81277710812012202s38ccd717n6b8fa232cc7d31d4@mail.gmail.com>
Date: Tue, 2 Dec 2008 01:02:12 -0500
From: "Joe Onorato" <j...@android.com>
To: android-platform@googlegroups.com
Subject: Re: CPU SPEED
In-Reply-To: <3d406cd6-27de-46f8-9129-9aff8cf46066@w34g2000yqm.googlegroups.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_111239_24569161.1228197732653"
References: <b92cfab5-aa83-45ca-8c26-3fc15cbd5563@p2g2000prf.googlegroups.com>
	 <377da486-f555-48f1-b221-89e1c4b097fd@y18g2000yqn.googlegroups.com>
	 <26b7c7380812011429u1ecadca0r9c8a0c50d89033a3@mail.gmail.com>
	 <3d406cd6-27de-46f8-9129-9aff8cf46066@w34g2000yqm.googlegroups.com>

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.


On Tue, Dec 2, 2008 at 12:07 AM, blindfold <seeingwithso...@gmail.com>wrote:

>
> 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
>

MIME-Version: 1.0
Received: by 10.150.153.3 with SMTP id a3mr1002014ybe.5.1228228235045; Tue, 02 
	Dec 2008 06:30:35 -0800 (PST)
Date: Tue, 2 Dec 2008 06:30:35 -0800 (PST)
In-Reply-To: <81277710812012202s38ccd717n6b8fa232cc7d31d4@mail.gmail.com>
X-IP: 195.55.103.50
References: <b92cfab5-aa83-45ca-8c26-3fc15cbd5563@p2g2000prf.googlegroups.com> 
	<377da486-f555-48f1-b221-89e1c4b097fd@y18g2000yqn.googlegroups.com> 
	<26b7c7380812011429u1ecadca0r9c8a0c50d89033a3@mail.gmail.com> 
	<3d406cd6-27de-46f8-9129-9aff8cf46066@w34g2000yqm.googlegroups.com> 
	<81277710812012202s38ccd717n6b8fa232cc7d31d4@mail.gmail.com>
User-Agent: G2/1.0
X-HTTP-Via: 1.1 NEI-APPLIANCE
X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.0.4) 
	Gecko/2008102920 Firefox/3.0.4,gzip(gfe),gzip(gfe)
Message-ID: <d28701ff-24b4-47cd-af56-69f189bc04fe@d23g2000yqc.googlegroups.com>
Subject: Re: CPU SPEED
From: qvark <joseluishuertasfernan...@gmail.com>
To: android-platform <android-platform@googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

> 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=A0am, "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. =A0We'll get right on it.
>
> On Tue, Dec 2, 2008 at 12:07 AM, blindfold <seeingwithso...@gmail.com>wro=
te:
>
>
>
> > 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. =A0You'll need to deal w=
ith
> > the
> > > fact that any increase in memory usage gets magnified across all of t=
he
> > > processes so you can easily kill the system by leaving it without eno=
ugh
> > > 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. =A0The=
 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? =A0That would be great. =A0Otherw=
ise,
> > it's
> > > currently not on the road map, and there are probably higher priority
> > things
> > > that people have to work on. =A0For example, it might be much more
> > important
> > > to spend VM engineering effort on improving the garbage collector and
> > > overall memory usage. =A0Or maybe porting to x86 if that is what is n=
eeded.
> > > Continuing to complain about this is not likely to change those other
> > > priorities.
>
> > > --
> > > Dianne Hackborn
> > > Android framework engineer

Received: by 10.140.201.6 with SMTP id y6mr5730238rvf.17.1228229662531;
        Tue, 02 Dec 2008 06:54:22 -0800 (PST)
Return-Path: <j...@google.com>
Received: from smtp-out.google.com ([216.239.45.13])
        by mx.google.com with ESMTP id k19si4454422waf.2.2008.12.02.06.54.21;
        Tue, 02 Dec 2008 06:54:21 -0800 (PST)
Received-SPF: pass (google.com: domain of j...@google.com designates 216.239.45.13 as 
permitted sender) client-ip=216.239.45.13;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of j...@google.com 
designates 216.239.45.13 as permitted sender) smtp.mail=...@google.com; dkim=pass 
(test mode) header...@google.com
Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88])
	by smtp-out.google.com with ESMTP id mB2EsK6Z011877
	for <android-platform@googlegroups.com>; Tue, 2 Dec 2008 06:54:21 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta;
	t=1228229661; bh=QoA86m+Pb8u6u3v5DBkhdM7WxUs=;
	h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date:
	 Message-ID:Subject:From:To:Content-Type:Content-Transfer-Encoding;
	b=cQcRdUEVlDp6URUlGzSABOcNJl7PSJcluURXpzBragPlbYphUpOll82GY+GsvwqwK
	55xr1ZC3+gWhba9vF9yjw==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to:
	content-type:content-transfer-encoding;
	b=u06GBg0L4Vh2BQlDI4tGx6U2MvNvSmtxrirprWeUVWwU3sqvH1fS2O+wD+IGocbB8
	i2H78rPXkpWRGg5cWUpVw==
Received: from rn-out-0910.google.com (rnej43.prod.google.com [10.38.161.43])
	by wpaz24.hot.corp.google.com with ESMTP id mB2ErpYV020048
	for <android-platform@googlegroups.com>; Tue, 2 Dec 2008 06:54:19 -0800
Received: by rn-out-0910.google.com with SMTP id j43so1263478rne.2
        for <android-platform@googlegroups.com>; Tue, 02 Dec 2008 06:54:19 -0800 (PST)
MIME-Version: 1.0
Received: by 10.143.17.13 with SMTP id u13mr4924148wfi.180.1228229659238; Tue, 
	02 Dec 2008 06:54:19 -0800 (PST)
In-Reply-To: <d28701ff-24b4-47cd-af56-69f189bc04fe@d23g2000yqc.googlegroups.com>
References: <b92cfab5-aa83-45ca-8c26-3fc15cbd5...@p2g2000prf.googlegroups.com>
	 <377da486-f555-48f1-b221-89e1c4b09...@y18g2000yqn.googlegroups.com>
	 <26b7c7380812011429u1ecadca0r9c8a0c50d8903...@mail.gmail.com>
	 <3d406cd6-27de-46f8-9129-9aff8cf46...@w34g2000yqm.googlegroups.com>
	 <81277710812012202s38ccd717n6b8fa232cc7d3...@mail.gmail.com>
	 <d28701ff-24b4-47cd-af56-69f189bc0...@d23g2000yqc.googlegroups.com>
Date: Tue, 2 Dec 2008 06:54:19 -0800
Message-ID: <1702acb30812020654ja25ff5dq5ac03c61ebd08...@mail.gmail.com>
Subject: Re: CPU SPEED
From: Jean-Baptiste Queru <j...@google.com>
To: android-platform@googlegroups.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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

On Tue, Dec 2, 2008 at 6:30 AM, qvark
<joseluishuertasfernan...@gmail.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.
>
> 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.
>>
>> On Tue, Dec 2, 2008 at 12:07 AM, blindfold <seeingwithso...@gmail.com>wrote:
>>
>>
>>
>> > 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
>

MIME-Version: 1.0
Received: by 10.100.163.15 with SMTP id l15mr1008484ane.24.1228234139131; Tue, 
	02 Dec 2008 08:08:59 -0800 (PST)
Date: Tue, 2 Dec 2008 08:08:59 -0800 (PST)
In-Reply-To: <1702acb30812020654ja25ff5dq5ac03c61ebd084ea@mail.gmail.com>
X-IP: 80.255.245.177
References: <b92cfab5-aa83-45ca-8c26-3fc15cbd5563@p2g2000prf.googlegroups.com> 
	<377da486-f555-48f1-b221-89e1c4b097fd@y18g2000yqn.googlegroups.com> 
	<26b7c7380812011429u1ecadca0r9c8a0c50d89033a3@mail.gmail.com> 
	<3d406cd6-27de-46f8-9129-9aff8cf46066@w34g2000yqm.googlegroups.com> 
	<81277710812012202s38ccd717n6b8fa232cc7d31d4@mail.gmail.com> 
	<d28701ff-24b4-47cd-af56-69f189bc04fe@d23g2000yqc.googlegroups.com> 
	<1702acb30812020654ja25ff5dq5ac03c61ebd084ea@mail.gmail.com>
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.4) 
	Gecko/2008102920 Firefox/3.0.4,gzip(gfe),gzip(gfe)
Message-ID: <169a0709-f252-4193-86fb-a1e617655f93@g38g2000yqd.googlegroups.com>
Subject: Re: CPU SPEED
From: blindfold <seeingwithso...@gmail.com>
To: android-platform <android-platform@googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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

On Dec 2, 3:54=A0pm, Jean-Baptiste Queru <j...@google.com> wrote:
> 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

Received: by 10.90.65.14 with SMTP id n14mr4531051aga.4.1228241142723;
        Tue, 02 Dec 2008 10:05:42 -0800 (PST)
Return-Path: <hack...@android.com>
Received: from yw-out-1718.google.com (yw-out-1718.google.com [74.125.46.158])
        by mx.google.com with ESMTP id 7si7702772yxg.0.2008.12.02.10.05.42;
        Tue, 02 Dec 2008 10:05:42 -0800 (PST)
Received-SPF: neutral (google.com: 74.125.46.158 is neither permitted nor denied by 
best guess record for domain of hack...@android.com) client-ip=74.125.46.158;
Authentication-Results: mx.google.com; spf=neutral (google.com: 74.125.46.158 is 
neither permitted nor denied by best guess record for domain of hack...@android.com) 
smtp.mail=hack...@android.com
Received: by yw-out-1718.google.com with SMTP id 5so1218500ywm.34
        for <android-platform@googlegroups.com>; Tue, 02 Dec 2008 10:05:42 -0800 (PST)
Received: by 10.142.110.10 with SMTP id i10mr4963331wfc.300.1228241142329;
        Tue, 02 Dec 2008 10:05:42 -0800 (PST)
Received: by 10.142.158.19 with HTTP; Tue, 2 Dec 2008 10:05:42 -0800 (PST)
Message-ID: <26b7c7380812021005y6b1d6199q7eb5eecce8109b5d@mail.gmail.com>
Date: Tue, 2 Dec 2008 10:05:42 -0800
From: "Dianne Hackborn" <hack...@android.com>
To: android-platform@googlegroups.com
Subject: Re: CPU SPEED
In-Reply-To: <169a0709-f252-4193-86fb-a1e617655f93@g38g2000yqd.googlegroups.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_103471_30168369.1228241142323"
References: <b92cfab5-aa83-45ca-8c26-3fc15cbd5563@p2g2000prf.googlegroups.com>
	 <377da486-f555-48f1-b221-89e1c4b097fd@y18g2000yqn.googlegroups.com>
	 <26b7c7380812011429u1ecadca0r9c8a0c50d89033a3@mail.gmail.com>
	 <3d406cd6-27de-46f8-9129-9aff8cf46066@w34g2000yqm.googlegroups.com>
	 <81277710812012202s38ccd717n6b8fa232cc7d31d4@mail.gmail.com>
	 <d28701ff-24b4-47cd-af56-69f189bc04fe@d23g2000yqc.googlegroups.com>
	 <1702acb30812020654ja25ff5dq5ac03c61ebd084ea@mail.gmail.com>
	 <169a0709-f252-4193-86fb-a1e617655f93@g38g2000yqd.googlegroups.com>

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

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.

Received: by 10.141.86.14 with SMTP id o14mr5945461rvl.8.1228255061156;
        Tue, 02 Dec 2008 13:57:41 -0800 (PST)
Return-Path: <danf...@google.com>
Received: from smtp-out.google.com ([216.239.45.13])
        by mx.google.com with ESMTP id m37si4738273waf.0.2008.12.02.13.57.40;
        Tue, 02 Dec 2008 13:57:40 -0800 (PST)
Received-SPF: pass (google.com: domain of danf...@google.com designates 216.239.45.13 
as permitted sender) client-ip=216.239.45.13;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of 
danf...@google.com designates 216.239.45.13 as permitted sender) 
smtp.mail=danf...@google.com; dkim=pass (test mode) header...@google.com
Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65])
	by smtp-out.google.com with ESMTP id mB2Lvd2B031858
	for <android-platform@googlegroups.com>; Tue, 2 Dec 2008 13:57:39 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta;
	t=1228255059; bh=3jwj+3+OJv3IoF87J2gsmkabRHE=;
	h=DomainKey-Signature:MIME-Version:Sender:In-Reply-To:References:
	 Date:X-Google-Sender-Auth:Message-ID:Subject:From:To:Content-Type:
	 Content-Transfer-Encoding:X-GMailtapped-By:X-GMailtapped; b=nDOyPG
	OvHqIhvRB7VrhBR/a06SIw5IfRzSPEmxyz9dDZRUoO0ofhk71xdVvt0gtGcaQwuPeeS
	gIFy690SXvCJw==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns;
	h=mime-version:sender:in-reply-to:references:date:
	x-google-sender-auth:message-id:subject:from:to:content-type:
	content-transfer-encoding:x-gmailtapped-by:x-gmailtapped;
	b=hylAVlVUi96ztF/cI0DU9iV0g4K68g28TMB2HuM02fTGGGxxAtY8hWmcIFXqUPf89
	7z3ObEbFDoUTnRBtwe1LQ==
Received: from rv-out-0506.google.com (rvbf9.prod.google.com [10.140.82.9])
	by wpaz1.hot.corp.google.com with ESMTP id mB2LvbRX005764
	for <android-platform@googlegroups.com>; Tue, 2 Dec 2008 13:57:37 -0800
Received: by rv-out-0506.google.com with SMTP id f9so2645852rvb.6
        for <android-platform@googlegroups.com>; Tue, 02 Dec 2008 13:57:37 -0800 (PST)
MIME-Version: 1.0
Sender: danf...@google.com
Received: by 10.141.212.5 with SMTP id o5mr5952161rvq.247.1228255057035; Tue, 
	02 Dec 2008 13:57:37 -0800 (PST)
In-Reply-To: <cb4f1e2c-3407-47c1-ab00-5c0a72b31...@r40g2000yqj.googlegroups.com>
References: <b92cfab5-aa83-45ca-8c26-3fc15cbd5...@p2g2000prf.googlegroups.com>
	 <377da486-f555-48f1-b221-89e1c4b09...@y18g2000yqn.googlegroups.com>
	 <26b7c7380812011429u1ecadca0r9c8a0c50d8903...@mail.gmail.com>
	 <3d406cd6-27de-46f8-9129-9aff8cf46...@w34g2000yqm.googlegroups.com>
	 <81277710812012202s38ccd717n6b8fa232cc7d3...@mail.gmail.com>
	 <d28701ff-24b4-47cd-af56-69f189bc0...@d23g2000yqc.googlegroups.com>
	 <1702acb30812020654ja25ff5dq5ac03c61ebd08...@mail.gmail.com>
	 <19dfcde1-a1a9-4e3e-9710-23fba245f...@c1g2000yqg.googlegroups.com>
	 <cb4f1e2c-3407-47c1-ab00-5c0a72b31...@r40g2000yqj.googlegroups.com>
Date: Tue, 2 Dec 2008 13:57:36 -0800
Message-ID: <8084e12c0812021357w322c3b77u6e4b37e3c0a6b...@mail.gmail.com>
Subject: Re: CPU SPEED
From: Dan Bornstein <danf...@android.com>
To: android-platform@googlegroups.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-GMailtapped-By: 172.24.198.65
X-GMailtapped: danfuzz

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

MIME-Version: 1.0
Received: by 10.101.1.16 with SMTP id d16mr1089185ani.7.1228295588079; Wed, 03 
	Dec 2008 01:13:08 -0800 (PST)
Date: Wed, 3 Dec 2008 01:13:08 -0800 (PST)
In-Reply-To: <8084e12c0812021357w322c3b77u6e4b37e3c0a6be83@mail.gmail.com>
X-IP: 80.255.245.177
References: <b92cfab5-aa83-45ca-8c26-3fc15cbd5563@p2g2000prf.googlegroups.com> 
	<377da486-f555-48f1-b221-89e1c4b097fd@y18g2000yqn.googlegroups.com> 
	<26b7c7380812011429u1ecadca0r9c8a0c50d89033a3@mail.gmail.com> 
	<3d406cd6-27de-46f8-9129-9aff8cf46066@w34g2000yqm.googlegroups.com> 
	<81277710812012202s38ccd717n6b8fa232cc7d31d4@mail.gmail.com> 
	<d28701ff-24b4-47cd-af56-69f189bc04fe@d23g2000yqc.googlegroups.com> 
	<1702acb30812020654ja25ff5dq5ac03c61ebd084ea@mail.gmail.com> 
	<19dfcde1-a1a9-4e3e-9710-23fba245f616@c1g2000yqg.googlegroups.com> 
	<cb4f1e2c-3407-47c1-ab00-5c0a72b31c88@r40g2000yqj.googlegroups.com> 
	<8084e12c0812021357w322c3b77u6e4b37e3c0a6be83@mail.gmail.com>
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.4) 
	Gecko/2008102920 Firefox/3.0.4,gzip(gfe),gzip(gfe)
Message-ID: <7c1084bd-f6f6-4e9e-832f-e866112b73f9@q9g2000yqc.googlegroups.com>
Subject: Re: CPU SPEED
From: blindfold <seeingwithso...@gmail.com>
To: android-platform <android-platform@googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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

On Dec 2, 10:57 pm, Dan Bornstein <danf...@android.com> wrote:
> 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

Received: by 10.90.93.17 with SMTP id q17mr3730188agb.6.1228298868157;
        Wed, 03 Dec 2008 02:07:48 -0800 (PST)
Return-Path: <expelia...@googlemail.com>
Received: from qb-out-1314.google.com (qb-out-1314.google.com [72.14.204.172])
        by mx.google.com with ESMTP id 22si8656435yxr.1.2008.12.03.02.07.47;
        Wed, 03 Dec 2008 02:07:47 -0800 (PST)
Received-SPF: pass (google.com: domain of expelia...@googlemail.com designates 
72.14.204.172 as permitted sender) client-ip=72.14.204.172;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of 
expelia...@googlemail.com designates 72.14.204.172 as permitted sender) 
smtp.mail=expelia...@googlemail.com; dkim=pass (test mode) header...@googlemail.com
Received: by qb-out-1314.google.com with SMTP id c5so3445281qbc.2
        for <android-platform@googlegroups.com>; Wed, 03 Dec 2008 02:07:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from:to
         :subject:in-reply-to:mime-version:content-type:references;
        bh=87kyXCoOpOiUJrxMRzlrbShI3PBMRdRBaDd7LvR/wZs=;
        b=GrK3FHBpYjKa8qn89OA2d1/KZ68YB2LDSHtMj+Vt9kNPzakifdLlnUVhShx1EB4bQN
         0UwxlD84ln1Em3sT1okguTgjkWW0df3ttWmL+og0uP+/X7XHOq9WZWX5duRc1K1SHpYh
         KZGes7LXfAe8HE2LrE7DWePc1kqBmxDdATerg=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=googlemail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:references;
        b=vlZaxQiHrpWSYtOX6Ewqle/C3/U70+BRUQnbCRQp93+mKwQJGQvUc0SbIb7bCo1DLt
         w4pFsvXwpPR2lmJt8Y2yqiQ4O9whbomXCicbd6/IkcNBmvBeRKYchV6p0hDlbmBdoc8j
         6CxkWM5bcv8mZx1ryCySLzSGu6Z+NGVUpmEGA=
Received: by 10.181.48.4 with SMTP id a4mr4617016bkk.6.1228298866901;
        Wed, 03 Dec 2008 02:07:46 -0800 (PST)
Received: by 10.181.206.18 with HTTP; Wed, 3 Dec 2008 02:07:46 -0800 (PST)
Message-ID: <813b5bb40812030207s3464b02ajf948f3686110c75e@mail.gmail.com>
Date: Wed, 3 Dec 2008 10:07:46 +0000
From: "F H" <expelia...@googlemail.com>
To: android-platform@googlegroups.com
Subject: Re: CPU SPEED
In-Reply-To: <7c1084bd-f6f6-4e9e-832f-e866112b7...@q9g2000yqc.googlegroups.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_2945_28700801.1228298866870"
References: <b92cfab5-aa83-45ca-8c26-3fc15cbd5...@p2g2000prf.googlegroups.com>
	 <26b7c7380812011429u1ecadca0r9c8a0c50d8903...@mail.gmail.com>
	 <3d406cd6-27de-46f8-9129-9aff8cf46...@w34g2000yqm.googlegroups.com>
	 <81277710812012202s38ccd717n6b8fa232cc7d3...@mail.gmail.com>
	 <d28701ff-24b4-47cd-af56-69f189bc0...@d23g2000yqc.googlegroups.com>
	 <1702acb30812020654ja25ff5dq5ac03c61ebd08...@mail.gmail.com>
	 <19dfcde1-a1a9-4e3e-9710-23fba245f...@c1g2000yqg.googlegroups.com>
	 <cb4f1e2c-3407-47c1-ab00-5c0a72b31...@r40g2000yqj.googlegroups.com>
	 <8084e12c0812021357w322c3b77u6e4b37e3c0a6b...@mail.gmail.com>
	 <7c1084bd-f6f6-4e9e-832f-e866112b7...@q9g2000yqc.googlegroups.com>

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.


On Wed, Dec 3, 2008 at 9:13 AM, blindfold <seeingwithso...@gmail.com> wrote:

>
> 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
>
> On Dec 2, 10:57 pm, Dan Bornstein <danf...@android.com> wrote:
> > 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
>

Received: by 10.140.255.19 with SMTP id c19mr6516086rvi.1.1228336562816;
        Wed, 03 Dec 2008 12:36:02 -0800 (PST)
Return-Path: <danf...@google.com>
Received: from smtp-out.google.com ([216.239.45.13])
        by mx.google.com with ESMTP id k19si5534185waf.2.2008.12.03.12.36.01;
        Wed, 03 Dec 2008 12:36:01 -0800 (PST)
Received-SPF: pass (google.com: domain of danf...@google.com designates 216.239.45.13 
as permitted sender) client-ip=216.239.45.13;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of 
danf...@google.com designates 216.239.45.13 as permitted sender) 
smtp.mail=danf...@google.com; dkim=pass (test mode) header...@google.com
Received: from zps19.corp.google.com (zps19.corp.google.com [172.25.146.19])
	by smtp-out.google.com with ESMTP id mB3Ka16g028999
	for <android-platform@googlegroups.com>; Wed, 3 Dec 2008 12:36:01 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta;
	t=1228336561; bh=mi0GJS8R77P5wop5uN4S1YzjHbI=;
	h=DomainKey-Signature:MIME-Version:Sender:In-Reply-To:References:
	 Date:X-Google-Sender-Auth:Message-ID:Subject:From:To:Content-Type:
	 Content-Transfer-Encoding:X-GMailtapped-By:X-GMailtapped; b=gG2hIw
	shuFDjJ4mKOyvMlIomiIEmdO/vu+MeyVjfYIofhUcZn9QcAtzmddt+6NkH6w+mo+uO9
	p52GntZ0x1hKA==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns;
	h=mime-version:sender:in-reply-to:references:date:
	x-google-sender-auth:message-id:subject:from:to:content-type:
	content-transfer-encoding:x-gmailtapped-by:x-gmailtapped;
	b=OEhLPmWFHg4Kc9h3OY9KEgVqzeVh/l2vOHCC4bvtBoKxlnvUtau1nNIvH4fLh/e2q
	funJrFIa7lMPE7GwwpvPw==
Received: from rv-out-0506.google.com (rvfb25.prod.google.com [10.140.179.25])
	by zps19.corp.google.com with ESMTP id mB3KZwa0022479
	for <android-platform@googlegroups.com>; Wed, 3 Dec 2008 12:35:58 -0800
Received: by rv-out-0506.google.com with SMTP id b25so3610498rvf.41
        for <android-platform@googlegroups.com>; Wed, 03 Dec 2008 12:35:58 -0800 (PST)
MIME-Version: 1.0
Sender: danf...@google.com
Received: by 10.141.212.5 with SMTP id o5mr6487813rvq.247.1228336558446; Wed, 
	03 Dec 2008 12:35:58 -0800 (PST)
In-Reply-To: <813b5bb40812030207s3464b02ajf948f3686110c...@mail.gmail.com>
References: <b92cfab5-aa83-45ca-8c26-3fc15cbd5...@p2g2000prf.googlegroups.com>
	 <3d406cd6-27de-46f8-9129-9aff8cf46...@w34g2000yqm.googlegroups.com>
	 <81277710812012202s38ccd717n6b8fa232cc7d3...@mail.gmail.com>
	 <d28701ff-24b4-47cd-af56-69f189bc0...@d23g2000yqc.googlegroups.com>
	 <1702acb30812020654ja25ff5dq5ac03c61ebd08...@mail.gmail.com>
	 <19dfcde1-a1a9-4e3e-9710-23fba245f...@c1g2000yqg.googlegroups.com>
	 <cb4f1e2c-3407-47c1-ab00-5c0a72b31...@r40g2000yqj.googlegroups.com>
	 <8084e12c0812021357w322c3b77u6e4b37e3c0a6b...@mail.gmail.com>
	 <7c1084bd-f6f6-4e9e-832f-e866112b7...@q9g2000yqc.googlegroups.com>
	 <813b5bb40812030207s3464b02ajf948f3686110c...@mail.gmail.com>
Date: Wed, 3 Dec 2008 12:35:58 -0800
Message-ID: <8084e12c0812031235h51a744c4ib024b4c39fb44...@mail.gmail.com>
Subject: Re: CPU SPEED
From: Dan Bornstein <danf...@android.com>
To: android-platform@googlegroups.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-GMailtapped-By: 172.25.146.19
X-GMailtapped: danfuzz

On Wed, Dec 3, 2008 at 2:07 AM, F H <expelia...@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