Currently, computational Android programs run 5 to 10 times slower on
Android phones than on comparable Nokia phones, apparently mostly due
to the fact that Nokia phones feature a JIT (just-in-time) compiler
for Java bytecodes to automatically profile and speed up time-critical
sections, whereas Dalvik bytecodes are always only run through an
interpreter. In looking for means to accelerate Android programs, I
would greatly prefer a platform-independent JIT compiler over any
platform-dependent solutions such as the NDK/JNI where different
distribution packages must be generated for different target platforms
based on ARM, x86, MIPS, whatever: a maintenance, packaging and
distribution headache.
Now with Google Chrome 2.0 for the PC incorporating V8, a JIT-like
fast Javascript compiler, with V8 already ported to ARM
http://code.google.com/apis/v8/build.html, and with Sergey Brin's
plans to make Chrome available under Android http://news.cnet.com/8301-1001_3-10031318-92.html,
can we expect a platform-independent interface for calling Javascript
functions from within Android apps? Counterintuitive as this may at
first seem since Javascript used to be slow and poorly defined in the
past, this may provide a mechanism to speed up time-critical Android
application sections in a platform-independent manner (from the
Android application programmer's perspective, that is). The math
benchmarks of the Sunspider Javascript benchmark suite show a speedup
of 5 to 10 times when comparing Google Chrome 2.0 to Firefox 3.010 on
the PC. Typically, math code looks syntactically very similar in Java
and Javascript, such that there is little effort involved in re-coding
one's time-critical sections in Javascript.
So, may we expect this major and platform-independent speed-up option
for Android applications shortly? :-)
On Sat, May 23, 2009 at 5:33 AM, blindfold <seeingwithso...@gmail.com>wrote:
> whereas Dalvik bytecodes are always only run through an > interpreter. In looking for means to accelerate Android programs, I > would greatly prefer a platform-independent JIT compiler over any > platform-dependent solutions such as the NDK/JNI where different > distribution packages must be generated for different target platforms > based on ARM, x86, MIPS, whatever: a maintenance, packaging and > distribution headache.
+1 By the way why Android still has no JIT (or Ahead-Of-Time JIT) at this time, is it because of a technical issue or just lack of time/resources??
Looks like it is one of the main current drawbacks of the platform right now..and potentially lessens battery life (ie. more code have to be executed to run the same thing in the end).
> Typically, math code looks syntactically very similar in Java > and Javascript, such that there is little effort involved in re-coding > one's time-critical sections in Javascript.
True but it would be even simpler just to get the JIT for Dalvik so we can use the same language everywhere.
One of the things that I like Android is Java and right now native
code runs few times faster than Java... JIT is a must for Android.
NDK is ok... but JIT is must.
Strange that Google decided to go with interpreter... mobile phones
have limited resources, lower performances and interpreter is
something that is not recommended on mobile phones...
Also increase VM's 16 MB to 32 MB.
On May 23, 2:19 am, Cedric Vivier <cedr...@neonux.com> wrote:
> On Sat, May 23, 2009 at 5:33 AM, blindfold <seeingwithso...@gmail.com>wrote:
> > whereas Dalvik bytecodes are always only run through an
> > interpreter. In looking for means to accelerate Android programs, I
> > would greatly prefer a platform-independent JIT compiler over any
> > platform-dependent solutions such as the NDK/JNI where different
> > distribution packages must be generated for different target platforms
> > based on ARM, x86, MIPS, whatever: a maintenance, packaging and
> > distribution headache.
> +1
> By the way why Android still has no JIT (or Ahead-Of-Time JIT) at this time,
> is it because of a technical issue or just lack of time/resources??
> Looks like it is one of the main current drawbacks of the platform right
> now..and potentially lessens battery life (ie. more code have to be executed
> to run the same thing in the end).
> > Typically, math code looks syntactically very similar in Java
> > and Javascript, such that there is little effort involved in re-coding
> > one's time-critical sections in Javascript.
> True but it would be even simpler just to get the JIT for Dalvik so we can
> use the same language everywhere.
> True but it would be even simpler just to get the JIT for Dalvik so we can
> use the same language everywhere.
I agree, and I prefer a good JIT compiler over everything else. My
main concern is how long it is going to take before we find a decent
Dalvik JIT compiler on the majority of Android phones. Although I
personally cannot judge what time frame is realistic, or how
priorities are set, the impression I got so far is that it might take
years before we have something approximating Sun's Hotspot technology.
Another possible advantage of Javascript over C (through JNI/NDK)
could here be that its security issues are pretty well understood and
managed through years of exposure on the Internet, while communicating
with Javascript may also further ease development of fancy and highly
interactive web-based augmented reality applications, which in turn is
good for... search. Hmm, I happen to know of a company with some
interest in just that.
It all looks like V8 can offer the shortest path to a platform-
independent performance boost for Android applications.
Regards
On May 23, 2:19 am, Cedric Vivier <cedr...@neonux.com> wrote:
> On Sat, May 23, 2009 at 5:33 AM, blindfold <seeingwithso...@gmail.com>wrote:
> > whereas Dalvik bytecodes are always only run through an
> > interpreter. In looking for means to accelerate Android programs, I
> > would greatly prefer a platform-independent JIT compiler over any
> > platform-dependent solutions such as the NDK/JNI where different
> > distribution packages must be generated for different target platforms
> > based on ARM, x86, MIPS, whatever: a maintenance, packaging and
> > distribution headache.
> +1
> By the way why Android still has no JIT (or Ahead-Of-Time JIT) at this time,
> is it because of a technical issue or just lack of time/resources??
> Looks like it is one of the main current drawbacks of the platform right
> now..and potentially lessens battery life (ie. more code have to be executed
> to run the same thing in the end).
> > Typically, math code looks syntactically very similar in Java
> > and Javascript, such that there is little effort involved in re-coding
> > one's time-critical sections in Javascript.
> True but it would be even simpler just to get the JIT for Dalvik so we can
> use the same language everywhere.
Did anyone attempt to use a Webview with its addJavascriptInterface()
to do, say, some basic vector processing in Javascript by passing
arrays back and forth? Is the interface's variable passing rich enough
to make that work? (Surely it will still be very slow for now for lack
of V8 on the G1.)
Thanks
On May 22, 11:33 pm, blindfold <seeingwithso...@gmail.com> wrote:
> Currently, computational Android programs run 5 to 10 times slower on
> Android phones than on comparable Nokia phones, apparently mostly due
> to the fact that Nokia phones feature a JIT (just-in-time) compiler
> for Java bytecodes to automatically profile and speed up time-critical
> sections, whereas Dalvik bytecodes are always only run through an
> interpreter. In looking for means to accelerate Android programs, I
> would greatly prefer a platform-independent JIT compiler over any
> platform-dependent solutions such as the NDK/JNI where different
> distribution packages must be generated for different target platforms
> based on ARM, x86, MIPS, whatever: a maintenance, packaging and
> distribution headache.
> Now with Google Chrome 2.0 for the PC incorporating V8, a JIT-like
> fast Javascript compiler, with V8 already ported to ARMhttp://code.google.com/apis/v8/build.html, and with Sergey Brin's
> plans to make Chrome available under Androidhttp://news.cnet.com/8301-1001_3-10031318-92.html,
> can we expect a platform-independent interface for calling Javascript
> functions from within Android apps? Counterintuitive as this may at
> first seem since Javascript used to be slow and poorly defined in the
> past, this may provide a mechanism to speed up time-critical Android
> application sections in a platform-independent manner (from the
> Android application programmer's perspective, that is). The math
> benchmarks of the Sunspider Javascript benchmark suite show a speedup
> of 5 to 10 times when comparing Google Chrome 2.0 to Firefox 3.010 on
> the PC. Typically, math code looks syntactically very similar in Java
> and Javascript, such that there is little effort involved in re-coding
> one's time-critical sections in Javascript.
> So, may we expect this major and platform-independent speed-up option
> for Android applications shortly? :-)
On 22 Mai, 23:33, blindfold <seeingwithso...@gmail.com> wrote:
> Currently, computational Android programs run 5 to 10 times slower on
> Android phones than on comparable Nokia phones, apparently mostly due
> to the fact that Nokia phones feature a JIT (just-in-time) compiler
> for Java bytecodes to automatically profile and speed up time-critical
> sections, whereas Dalvik bytecodes are always only run through an
> interpreter. In looking for means to accelerate Android programs, I
> would greatly prefer a platform-independent JIT compiler over any
> platform-dependent solutions such as the NDK/JNI where different
> distribution packages must be generated for different target platforms
> based on ARM, x86, MIPS, whatever: a maintenance, packaging and
> distribution headache.
+1 for a JIT on Android. It is a great platform already but the lack
of a JIT for the Java applications is a major drawback if you have an
application that requires some more computations.
