faster Android
llr...@qq.com
I'm now trying to understand the internal structure of android, and
have some brief understanding on android. As u know, the framework is
based on java, which is less efficiency than the native code. In my
oppinion, framework and the core applications like home/contacts/
wallpaper which are constantly used by the users should be native
code, so as to have better performance. Here's my idea: we can shift
the framework to native code, and support the java interface at the
same time. This may be a long march, and may not reach the success,
but on the way, we can have a better understanding on android. If u r
also interested in this idea, then let's work together. Like Linus
said, we do it just for fun!
By the way, is there a bible from android team or anyone else that
introduce the internal structure and source code of android? I can get
infomation from the internet here and there, but they're not official
and not complete. Such a bible would help a lot.
thanks.
Sam Berro
--
You received this message because you are subscribed to the Google Groups "android-platform" group.
To post to this group, send email to android-...@googlegroups.com.
To unsubscribe from this group, send email to android-platfo...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-platform?hl=en.
-- Sam Berro
leon lee
framework, like core service activitymanager/windowmanager/... u can
get the source code in frameworks\base\core\java\android\app\.
Casey Daniels
on line which seem to sorta of cover the subject but not exactly, what
I'm trying to do is Load an Array from a Data file saved on an android
device which the data file I would like to be able to update some how,
either change elements from within the App or download a new Data File
with out having to update the whole app. So far what I've figured out is
XML file might be the best way (if i'm wrong let me know a better way)
What I have is an Array called Airplanes its 100 units big of a class
called Aircraft. Each Aircraft has an Id Number, a Type, a Weight and a
Center of Gravity Index. I would like to fill the Array from the Data
file. I'll attach my XML code to the bottom to see if that looks alright.
Any Help would be much appreciated.
Casey'
(The Actual File is much longer but its just a repeat of itself with
different data.)
<?xml version="1.0" encoding="UTF-8"?>
<aircrafts count="2">
<aircraft>
<id>N327EN</id>
<type>DHC-8-311</type>
<index>4.72</index>
<bow>27026</bow>
</aircraft>
<aircraft>
<id>N975HA</id>
<type>DHC-8-102</type>
<index>3.64</index>
<bow>23905</bow>
</aircraft>
</aircrafts>
Kristopher Micinski
For a long time, Android has had a JIT compiler, so for all intents
and purposes, the traces of code that you're actually using a lot
*are* running in native code. Basically, if there's something that
you think is really slowing us down, you are free to profile it and
suggest modifications. However, once you understand a bit more of the
way the vm and jit is working with the framework code, I think you'll
see that there's not too much holding the system back perf wise, at
least with respect to the code contained in the Java part of the
framework..
kris
2012/1/28 leon lee <llr...@qq.com>:
Lado Kumsiashvili
--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
leon lee
said. :)
leon lee
optimzed a lot, and JNI makes native code available. But still there's
a virtual machine down there, and I'm afraid that efficiency would be
affected. Can u show me some document saying
there's not too much holding the system back perf wise?
I think android should be also more compatible with programmers who
are familiar with different program language, so that people can build
application of android with their familiar language and tools.
Also I never disrepspect the code contained in the Java part of the
framework. The code is great, and I'll dig into it and learn more.
Kristopher Micinski
> R u referring to DalvikVM(with JIT compiler) and JNI? Yes, DalvikVM is
> optimzed a lot, and JNI makes native code available. But still there's
> a virtual machine down there, and I'm afraid that efficiency would be
> affected.
In general, people who are worrying about this usually haven't taken
the time to actually think about what's going on under the hood.
Sure, there's a vm down there somewhere. But:
1) With JIT it doesn't really matter perf wise once you've got up
and running..
2) I remember that the system was benchmarked a while back (though I
don't remember the refs, though somebody here will point you at them)
that said that a relatively small portion of time was spent in
interpreted code, and that was *before* JIT..
Can u show me some document saying
> there's not too much holding the system back perf wise?
I'm sure there are a few out there, but I'm not sure exactly where
there are, or even how many are publicly available...
> I think android should be also more compatible with programmers who
> are familiar with different program language, so that people can build
> application of android with their familiar language and tools.
You can write Android apps using the NDK. But the truth is that the
platform is truly different. Switching to a new programming language
simply because some other people know it is a bad excuse for adding
new pieces of the system. In practice a huge piece of the Android
ecosystem runs atop Dalvik (the virtual machine, which is extremely
fast at interpretation, add a bit of jit and things really fly). The
structure of the system is based on a few core ideas that don't lend
themselves to the older UNIX philosophy to which you're most likely
referring. So if you're saying the system should port itself to work
more like a *nix system programming style, the system just isn't built
like that. There's nothing stopping people from porting more
programming languages to Android: they can port their compilers to
emit Dalvik bytecode, or even plan jvm code and then have "dx"
translate that. Also, if it comes down to languages, I highly doubt
writing in Java is holding people back. Java isn't a beautiful
language, and there are other languages that it would be nice to write
apps in, but it's not difficult to learn. You may want to look into
alternative language implementations within Android: I know
somebody's worked on a Scala implementation, but I'm not sure what the
news is on it.
> Also I never disrepspect the code contained in the Java part of the
> framework. The code is great, and I'll dig into it and learn more.
I think that your proposal is influenced by a slightly uninformed
story of the Android architecture. This is a common thing: the
Android structure to apps isn't the same as on many systems. There's
not a lot of common stuff there, and many new things, so you can't
just treat it like programming for Linux and hope for the best.
kris
Jan Burse
> affected. Can u show me some document saying
> there's not too much holding the system back perf wise?
The first limiting factor is the clock speed of your android
device. While there are for example sub note books around
that have 3.0 GHz TurboBoost the tablet I have touched had
only 1.0 GHz. So there is a slow down of 3x.
Then the Dalvik JIT is not among the fastests. The same
Java code that does not use GUI runs slower on Dalvik
then on Java SE. Here is a report that shows that:
http://blogs.oracle.com/javaseembedded/entry/how_does_android_22s_performance_stack_up_against_java_se_embedded
The report mentions JDK 1.6. And there is a slow down of
2-3x. But if you compare against JDK 1.7, then you get a
factor 3-4x, since JDK 1.7 again is a little faster than JDK 1.6.
If you combine the two factors you get a slowdown of ~11x.
Which I could recently measure in a benchmark I did.
Jan Burse
> If you combine the two factors you get a slowdown of ~11x.
> Which I could recently measure in a benchmark I did.
Kristopher Micinski
sucks because things are slower. The Dalvik vm is trace based, but
I'd think your benchmarks should have hit this relatively easily.
(I.e., sorting is fairly routine.) There are differences between more
than (3.4 Ghz vs 1 Ghz). You also have to take into account the
superlinear speedup you get with a machine, the fact that an Android
system is quite loaded down off the shelf, etc... So I'm not really
convinced that this was a good benchmark..
kris
Jan Burse
> You also have to take into account the
> superlinear speedup you get with a machine, the fact that an Android
> system is quite loaded down off the shelf, etc... So I'm not really
> convinced that this was a good benchmark..
My non-android system was loaded, I had in the background,
mostly idle I guess, the following programs (*):
- Word
- Excel
- Tomcat
- SQL Server
On the other hand the tablet I used was not loaded. I just
booted it and run the benchmark.
So I don't see that your argument has any grounds.
(*)
http://www.jekejeke.ch/idatab/doclet/prod/en/docs/05_run/06_bench/06_internal/01_results.html
Kristopher Micinski
>
Then open up your applications tab on an Android tablet and look at
what background services are running. Typically gtalk, email, etc...
will all be loaded. I assumed that you killed them all off also?
Also, you are benchmarking an ARM cortex 2 against an Intel i7! Laughs...
kris
Jan Burse
> Typically gtalk, email, etc... will all be loaded.
> Also, you are benchmarking an ARM cortex 2 against an Intel i7! Laughs...
Yes, but the Java did only use one core. And nominally
the i7 has 2.6 GHz or so. But I wrote that it runs 3.4
GHz because this is what is seen with CPU-Z that the
processor is actually using during the benchmark.
The Intel i7, when only one core is used, it increases
the processor speed in 100 MHz steps. Since the chip
can deal with more heat transfer for only one core.
So I am not comparing apples with oranges.
Bye
Kristopher Micinski
Wow, I really can't believe you don't see this.. Maybe you're
comparing CPUs with CPUs, but you can't in any way say that this
causes the JIT to be slow... For this to be anywhere near a fair test,
you would have to eliminate everything but the JIT from the equation.
This means running on the same machine. (I.e., run a Dalvik
implementation on x86.) You can't run on a top end CPU with an
advanced memory controller and more cache and say it's slow..
> Bye
>
So you're going to complain about the jit without properly testing it
and just leave? Ok..
kris
Jan Burse
> ARM cortex 2
BTW: The tablet had a Dual-Core ARM Cortex
A9 (Acer Iconia A501). But did not yet look into
a tool like CPU-Z or so what the CPU was doing
during the benchmark.
Any such tools available for Android?
But yes there are difference for example in
the cache size. The Intel has 4 MB on chip
cache, and the ARM only 1 MB on chip cache.
This needs also to go into the equation.
Bye
Jan Burse
> For this to be anywhere near a fair test,
> you would have to eliminate everything but the JIT from the equation.
> This means running on the same machine. (I.e., run a Dalvik
> implementation on x86.)
Well oracle did this already for me. I already posted the
link in my previous post:
http://blogs.oracle.com/javaseembedded/entry/how_does_android_22s_performance_stack_up_against_java_se_embedded
I only could verify their finding, in that their slow
down is somewhere inside the overall slowdown I found.
Bye
Kristopher Micinski
out it's not an 11 times slowdown...
I think this is something that is still a bit contentious, but it is
certainly possible that the embedded vm implementation runs faster
(but certainly not by 11x..). At the same time, most of the time in
Android apps is *not* spent in your app, it's spent either sleeping or
in system code.
I'd be interested to see this on an x86 benchmark, but I'm not sure
how I'd set it up to be fair yet.. But I will say that the jit on
Dalvik isn't "slow," and the interpreter is one of the quickest I've
seen.. (The previously mentioned zygote architecture and other tricks
help quite a bit too!)
kris
Jan Burse
> At the same time, most of the time in Android apps
> or in system code.
The benchmark shows the elapsed time on both Intel
and ARM. But one could also do a breakdown of the
elapsed time, into thread time, etc.. I did not yet try.
Usually I do a break down in terms of GC time and non
GC time (*). Which is easy on Java SE via javax.management,
but did not yet find a corrsponding API on Android.
> But I will say that the jit on Dalvik isn't "slow,"
> and the interpreter is one of the quickest I've
> seen..
It depends how many JITs you have seen. There are waste
differences for example in the time spend in GC (JDK 1.6
300ms vs JDK 1.7 30ms on same machine), then there is waste
differences between CPU architecture (JDK 1.6 64-bit 1.5
times faster than JDK 1.6 32-bit on same machine).
I am not astonished that inside the "ballpark" (term
used by Oracle) of JITs there can be still differences
of a factor 1-3.
When Dalvik aims at a different trade-off between speed
and memory usage, i.e. less memory usage. Why should
Dalvik than be able to compete with Java SE embedded in
speed? It would be natural that the trade-off consists
in little lesser speed...
Bye
Kristopher Micinski
>> and the interpreter is one of the quickest I've
>> seen..
>
> It depends how many JITs you have seen. There are waste
> differences for example in the time spend in GC (JDK 1.6
> 300ms vs JDK 1.7 30ms on same machine), then there is waste
> differences between CPU architecture (JDK 1.6 64-bit 1.5
> times faster than JDK 1.6 32-bit on same machine).
>
Reread: I haven't seen many JITs, but I've seen a few interpreters,
and the Dalvik interpreter is one of the fastest I've seen.
> I am not astonished that inside the "ballpark" (term
> used by Oracle) of JITs there can be still differences
> of a factor 1-3.
>
Right.
> When Dalvik aims at a different trade-off between speed
> and memory usage, i.e. less memory usage. Why should
> Dalvik than be able to compete with Java SE embedded in
> speed? It would be natural that the trade-off consists
> in little lesser speed...
>
It's going for less memory usage, but that's not only enforced by
Dalvik. It's also enforced by many other pieces of the Android
design...
But I think that benchmarks aside, this gets far outside of what the
OP was asking. What he suggests just doesn't make sense because the
platform doesn't work like that, not because the vm implementation
differs from that of Java SE embedded..
kris
Jan Burse
> At the same time, most of the time in
> in system code.
On another occasion I run the same benchmark on
Windows and on Linux. There was no difference
in elapsed time on the same machine. Was using
a dual boot partition, and run either Windows 7
(JDK 1.7) or Fedora 17 (OpenJDK 1.7).
So most of the time is anyway spent in application
user code or in JVM user code, in the case of my
benchmark. The JVM especially seems to need only a
few short system calls to manage its heap etc..
This my conclusions so far, not sure, but it
looks like.
Bye
Spyros Panaoussis
From: Kristopher Micinski <krismi...@gmail.com>
To: android-...@googlegroups.com
Sent: Sunday, January 29, 2012 10:03 AM
Subject: Re: faster Android
You received this message because you are subscribed to the Google Groups "android-platform" group.
To post to this group, send email to android-...@googlegroups.com.
Colin Chu
and ARM cortex, and interested on the performance between on the two
different VMs.
While there is an advice, we can build Android for x86 device.
If we can run android on the same Intel i7 device, then we can compare the
VM performance.
-----邮件原件-----
发件人: android-...@googlegroups.com
[mailto:android-...@googlegroups.com] 代表 Jan Burse
发送时间: 2012年1月30日 1:45
收件人: android-...@googlegroups.com
主题: Re: faster Android
Bye
Kristopher Micinski
spending that much time in the app. They should be sleeping a lot
more, or in system calls. I'm not saying that this mitigates the vm
jit's difference, but there's nothing intrinsically hard about JIT, so
it's not like Dalvik's implementation is slow because of poor design.
(I'm not saying that this is what you said either..). However, the
Android design principles dictate that your app should be spending a
lot of time "doing nothing." An app that taxed the CPU as much as
your benchmarks would be a really bad idea: these devices are powered
by batteries, not huge PSUs...
Frankly, though, I believe your points. The JIT on Dalvik isn't as
fast as on embedded java se, okay, so what? It's not by 11 times,
that's for sure, but it might be something. In practice the apps that
are designed to run on Android shouldn't be doing things like huge
sorts anyway. If you need something very perf heavy, you can always
use the ndk, there's nothing stopping you, except an ugly interface to
the vm.. :-(.. You bring up some good points, and I appreciated some
of the links you referenced. In the end, I think that perf on Android
apps is now to the point where it's not really holding things back,
and there would be no huge improvement from reimplementing the
framework in a traditional unix stack as the OP suggests..
kris
leon lee
Windows Phone 7 is worst would not change our goal.
leon lee
much from the discussion.
So as u see, Dalvik is not even the best VM with JIT. According to the
benchmark, I'm afraid it's 2 or 3X slower. It would be more slower
comparing with the native code. So still if we want to make android
the best, it's still a good choice to port android to native code.
Android has quite a lot of new stuff, but at the same time, we can
have old stuff on android, so that it would be more inspiring. Isn't
it wonderful to write android application with python/perl/... ? :)
Kristopher Micinski
> Thanks for the discussion between u and Jan Burse. I learned quite
> much from the discussion.
>
> So as u see, Dalvik is not even the best VM with JIT. According to the
> benchmark, I'm afraid it's 2 or 3X slower. It would be more slower
> comparing with the native code. So still if we want to make android
> the best, it's still a good choice to port android to native code.
>
You are *still* missing the point.. The way Android is set up, it
doesn't make any sense to move it to native code. Even if you rewrote
some of the core system components in native code, it wouldn't matter,
the difference would be negligible. The systems stuff (system calls,
etc...) are *still* happening in native code, and the only limiting
factor would be in app code. I don't believe that the jit would be
holding you back, and I think that before you make an arbitrary
decision to say "screw the code we have, let's rewrite it in native
code" you should consider that this would be pretty much impossible
without changing a lot of Android..
> Android has quite a lot of new stuff, but at the same time, we can
> have old stuff on android, so that it would be more inspiring. Isn't
> it wonderful to write android application with python/perl/... ? :)
You *can* do this. There's a scripting layer for android, it supports
python, and (I think) perl too. If you want to look for other
languages, go no further than Jan, who seems to have written a fairly
slick prolog implementation on Android.
Admittedly the python support could be better, it really could. And
I'd love to see new languages pop up, Scala and OCaml would be at the
top of my list. However, this isn't a problem with *Android*, it's a
problem with writing a compiler. The last time I checked Scala was
looking "okay," and OCaml had some limited amount of support (but not
enough to use it to write real apps), but other languages would
certainly be appreciated. If you wanted to do this, you would want to
look at implementing a backend for the compiler for the language you
want. Keep in mind that most languages not translate easily to
Android because they assume some other runtime system, etc.. (So
basically you become a compiler hacker...)
Kris
leon lee
here from time to time.
On 1月30日, 下午1时56分, Kristopher Micinski <krismicin...@gmail.com> wrote:
Jan Burse
Of course Java can be compiled directly to native code, and does
not necessarily need to go the way of a byte code. I guess the
same would hold for dalvik code, one could start a GNU Pproject
similar to the following GNU project:
GCJ: The GNU Compiler for the JavaTM Programming Language
http://gcc.gnu.org/java/
With the goal of a compiler that compiles Java/Android code to
native ARM code. One could then also go on and run the ARM code
through various optimizers and/or manually optimize it in some
places and/or complement it with code written in C etc..
But then there is the issue of function shipping. When you build
an application solely based on Java/Android and bundle it as an
.apk file and put it on the market. Then you don't need to think
whether the Dalvik code is later executed by an ARM virtual machine
or an x86 virtual machine or some virtual machine based on a processor
already existing or produced in the future.
You also don't need to think about the particular version of the
ARM processor and/or x86 virtual machine and some precious instructions
the processor might support and the Davlik machine might take into
account. Also your .apk file stays relatively slim since it is not
really an unversal file that combines different processor code,
it is simply a single byte code.
And if you write a proper manifest, that indicates the API level
expected from the Java/Android you might eventually even expect
the .apk to stay for years in the android market without change.
Even after a nuclear war, if you find a android application on some
memory chip and if you find an android device on the other hand, if
the API levels match they might still run.
The concept is called Write once, run anywhere (WORA). And I think
it Android could be a good example. I think there is still some way
to go. I recently had a look at some of the source code 2.3.3 and found
"/data/data" hard coded in some places instead of using
Environment.getXXX or Context.getXXX. And there are often rumors
that after upgrades devices get broken.
But still from the point of application developer WORA is a good idea,
the application provisioning effort is reduced. This facilitates
frequent updates of applications. There is no difficult build pipline
needed to create versions for various CPU architectures and no in house
know-how of CPU architectures is needed. All the corresponding burden
is delegated to the Dalvik developer, i.e. Google etc..
But on the other hand, if it turns out that Dalvik is slow, this might
not yet be in the public spotlight. So maybe better Dalviks will be
seen when the pressure on the Dalvik developer, i.e. Google etc..
increases. But since Dalvik is young and since the consumer is probably
not yet aware, I don't see this pressure yet...
Bye
leon lee
WORA. That's why IPhone is so successful. Apple only think about how
to make a best phone, best system, not WORA.
If android want to go beyond IPhone, change must be done!
Kristopher Micinski
That's *not* why Android uses Java..
kris
leon lee
app use quite a lot of JNI calls, and dalvikVM would help on the JNI
call, so u can't use JNI without dalvikVM. Also, the app needs to
connect with activitymanager/windowmanager/..., I think it's quite
difficult to do that with native code.
On 1月31日, 下午10时44分, Jan Burse <janbu...@fastmail.fm> wrote:
> leon lee schrieb:
leon lee
Kristopher Micinski
the vm easily, translating from java class files.
The code you write for Android certainly isn't write once run
anywhere... There isn't a concept of activities, services, broadcast
receivers, etc.. on other systems. Porting a Java app from linux to
Android is an extremely nontrivial process, it's definitely not
changing a few libraries..
The system just uses that because it is more amenable to fit the
Android system semantics.
kris
2012/2/1 leon lee <llr...@qq.com>:
Karthik
Kristopher Micinski
> It is sort of write-once-run-anywhere.
>
> You don't need separate builds for Android Apps running on different
> architectures such as ARMv4, ARMv6, ARMv7, x86, MIPS. If you are writing in
> native, you`ll need separate builds for each architecture.
It runs on a vm, sure, but that wasn't necessarily the real reason why
Android was written that way. It's WORA in the low level portability
sense, but generally people refer to java's WORA in the more abstract
higher level sense.
I would say the real reason that Android uses Dalvik (Google employees
are free to completely kill off what I'm saying here, this is
conjecture) is that it allows you to sandbox apps really well, along
with providing another layer of abstraction that makes apps pretty
easy to write.
kris
Karthik
>> higher level sense
kris
Kristopher Micinski
>>> but generally people refer to java's WORA in the more abstract
>>> higher level sense
>
> Yes, that's why I said it is "sort of" write-once-run-anywhere
>
I heard you :-)
>>> it allows you to sandbox apps really well
>
> You can also sandbox native apps really well, given most of the SoC's comes
> with MMU.
True, but I didn't say this wasn't possible, I just said that a vm
makes gives you an obvious and clean implementation of it.
>>> providing another layer of abstraction that makes apps pretty easy to
>>> write
>
> Agreed, Java is more productive than native (at least for me)
>
> Best regards,
> Karthik
I also think that the zygote / fork model allows you to get some nice
properties as well, this was a major component in the vm
implementation that allows some great memory access properties that
fit well with the mobile low memory devices (and limiting to a
relatively small system library did this as well!). Am I saying you
can't also get some good memory access properties and do this with
native code? No, I'm not, but I think all these together made for a
nice system design on a device with 64Mb of ram..
kris
Jan Burse
> True, but I didn't say this wasn't possible, I just said that a vm
> makes gives you an obvious and clean implementation of it.
Actually the VM contribution to the sandbox model is rather
small. What makes something a sandbox here is the following:
- The *linux* permission model used by Android (users, groups)
Otherwise we have:
"Untrusted code cannot be safely isolated within the Dalvik VM."
http://developer.android.com/reference/java/lang/SecurityManager.html
Bye
Kristopher Micinski
> Kristopher Micinski schrieb:
>
>> True, but I didn't say this wasn't possible, I just said that a vm
>> makes gives you an obvious and clean implementation of it.
>
>
> Actually the VM contribution to the sandbox model is rather
> small. What makes something a sandbox here is the following:
>
> - The *linux* permission model used by Android (users, groups)
>
I didn't say it was just the permissions model, did I? I guess it
probably does read that way, but using a vm also gives you memory and
type safety.
> Otherwise we have:
>
> "Untrusted code cannot be safely isolated within the Dalvik VM."
> http://developer.android.com/reference/java/lang/SecurityManager.html
That's a deprecated part of the API...
But I feel like this was more of an off topic "one up" response...
kris
leon lee
on linux. After some research on meego, I believe this is feasible,
and it would be quick way.
colex.john
8-)
leon lee
在 2012年2月14日星期二UTC+8上午1时57分03秒，leon lee写道：