JBQ
No and yes :)
> Also is anyone working on adding hardware acceleration so we can take
> full advantage of the processor?
We have a prototype of SGL running on top of OpenGL (it was actually
shown publicly in the SDK 0.9) but it's not the correct solution at
the moment.
>
> Thanks
> Jeff
>
>> Date: Wed, Nov 26 2008 3:23 am
>> From: "Dianne Hackborn"
>>
>>
>> Uh, there is a lot more going on in that UI than just doing transparent
>> drawing. Also currently all drawing within a window is not hardware
>> accelerated so must be done in software. And the G1's processor runs at
>> well below 500MHz, and doesn't have a wonderful memory bus.
>
--
Romain Guy
www.curious-creature.org
On Wed, Nov 26, 2008 at 10:49 AM, blindfold <seeingw...@gmail.com> wrote:
>
--
Romain Guy
www.curious-creature.org
JBQ
Some people might also want the reverse where it can be downgraded
even further to extend the battery even longer.
> reducing the maximum speed it will run probably won't have much impact,You mean that the phone will overheat, or what? My users (of the Java
> unless you have some app sitting there spinning the cpu all of the time
> (and then you really have far worse problems).
ME version, that is) are generally willing to sacrifice battery life
and even UI responsiveness to obtain acceptable performance.
Some apps, including mine, need to run CPU-intensive algorithms
(nearly) continuously, so it is not a matter of "fixing the app".
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
I'm not a hardware or kernel guy, so I don't know whether the CPU
speed could be adjusted dynamically.
It's probably a much harder problem than it seems.
JBQ
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
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
I propose a special kind of wake lock that requires a specific
permission to acquire (so that users can know which applications can
request battery-killing privileges), such that acquiring that wake
lock would clock the CPU higher for as long as it's held.
Because there's been a lot of user-level discussion about putting
users in control of more aspects of their phones, and since there've
been a lot of comments about the G1's battery life when under heavy
use, I think it's also necessary to allow users to turn that wake lock
into a no-op.
I suggest that you wait a bit after the holiday week-end to let all
competent parties give their opinion, so that the design can be
refined before you spend too much time working on the implementation.
JBQ, looking forward to reviewing those patches.
On Fri, Nov 28, 2008 at 6:45 PM, Gary13579 <Gary...@gmail.com> wrote:
>
--
Romain Guy
www.curious-creature.org
As usual, it is critically important to understand the fundamental
difference between Android (the Open-Source project) and devices that
run derivatives of Android. Nothing in the license of the Android
source code prevents a device manufacturer from adding and removing
functionality relative to the baseline provided by Android itself.
If a manufacturer is worried about their device's stability or
integrity when running the CPU at a higher clock than the default one,
they've got full power to decide whether that specific capability
increases a given device's value more than it increases its costs, and
whether to include it in their devices.
Also, back on topic for the specific feature of varying the CPU speed,
the issues of user interface have to be resolved: it's important to
figure out how many users will care about such a feature at all, and
how sternly the message has to be worded for most users to understand
that they're trading a lot of battery life for a little speed.
JBQ
-When talking about AC power, let's not lose from sight that most
people plug into AC power to recharge their phones. Using too much
power while the device is plugged in could significantly slow down the
charging rate, and in some extreme cases could even use so much power
that the device would continue discharging while plugged in (!). It
might make sense to let users control high-drain features (like an
increased CPU clock) with 4 different levels: allow always, only when
plugged in, only when plugged in and fully charged, never.
-On devices that have a temperature sensor for the relevant parts of
the hardware, controlling high-drain features for those parts of the
hardware based on the temperature sounds like it could protect the
hardware better.
JBQ
-I'm not convinced that "most device owners" actually feel that they
have the kind of issues that you mention. That might be true of a
certain minority that is very vocal on some areas of the Internet that
are highly visible to you personally, but it doesn't clearly
extrapolate to the entire population of G1 users. I'm not in a
position to have definitive statistics in that area, though, so your
guess is as good as mine.
-I'm sadly quite sure however that informing users doesn't mean that
users will understand the consequences of their decisions. Support
calls where the user complains about battery life and the support
person guides the users through the advanced settings to check whether
the "high CPU speed" option was activated still cost money to the
operator (and if there's no such option, things get much worse).
JBQ
Back to the issue of CPU speed:
-The CPU in the G1 runs at a lower speed than what the chip could
support in ideal conditions. Higher speeds could result in issues of
stability or device integrity, would lower the battery life, and would
likely increase the speed of some applications. The CPU speed is not
the only factor in overall application speed.
-Android currently has very limited capabilities in terms of varying
the CPU speed based on the operating conditions. Design discussions
and code contributions are welcome. We've already established that
regressions in the domain of battery life for similar use cases are
unlikely to be acceptable.
-Do not assume that adding that ability in Android will automagically
mean that the G1 can be made to run at a higher clock. You could find
that that ability gets hooked to a no-op in the G1, or even that it is
used to lower the default clock speed for most applications except the
ones that explicitly request the "higher" speed, which would be
identical to the current speed.
JBQ
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!
I get the following on my G1: Runtime = 5589 ms; sum = 2752852
/Eddie
--
___________________________________________________brainaid_____________
Eddie C. Dost Rue de la Chapelle 51 phone +32 87 788817
B-4850 Moresnet fax +32 87 788818
e...@brainaid.de Belgium cell +49 172 9312808
/Eddie
--
Erm, anyone here who can better explain
how Dalvik byte code interpretation was meant to save power? ;-)
JBQ
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
JBQ
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.
http://www.mobilehandsetdesignline.com/209100312
I would conclude from this that for the same hardware increasing the
clock frequency *could* make sense if some sort of dynamic voltage
supply is implemented in the hardware, as the overall system would
require less power in the then greater idle phase. Of course this
assumes the same amount of work to be done by the system.
All in all the effect would *probably* be marginal.
I am marking my words with * where I make assumptions that I cannot
avoid because I do not have detailed information on the internals
of the G1 nor of the msm7201a. It is be Google's job to verify or
falsify such assumptions, probably working together with HTC. As long as
the hardware of the G1 is disclosed, the community cannot be of much
help here.
What would reduce power consumption would be reduction of the actual
duty cycle of the processor, using less instructions for the same job,
by either using less instructions per java byte code or using more
native code for permanently running tasks.
I would like to provide some real measurements and play with various
benchmarks and settings on my G1, but that would require ability to
run applications at the system level or to install my self compiled
kernel on the device, which I sadly cannot do. I would know what I am
doing, as I have been developing embedded Linux systems for over 20
years now. But I will not use Java to do system programming, there is
no way to convince me of that.
Sorry if the last sentence went somewhat off topic. I hope the rest is
of some informative value.
/Eddie
--
Linux? Over 20 years? Right :)
--
Romain Guy
www.curious-creature.org
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
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