10 ms·

Introducing ART – A new Android runtime being introduced experimentally in 4.4

152 points by alsutton010203 13y ago

wmf 13y ago
What a tease!
fabian2k 13y ago
Unfortunately that page doesn't actually explain the difference between ART and Dalvik. I found some random benchmark by a user on XDA (http://www.xda-developers.com/android/new-runtime-compiler-in-android-4-4/#comment-1104912482 http://www.xda-developers.com/android/new-runtime-compiler-i...) that could indicate significant speedups with ART. Though I would take this information with a huge grain of salt right now as it is one benchmark from an unknown source.
- Zigurd 13y ago
  As Android adds more features, more of Android is implemented in Java. Pretty much all of Google Play Services is implemented in Java. That means Android can rely less on the fact that graphics and the guts of many UI widgets are native code under a thin layer of Java. Android was always a "Java OS" but it has become more so since Android 3. So ART is important to keeping Android quick. Still, your mileage may vary. Unless you are doing significant computation in your app, a synthetic benchmark will vastly over-emphasize the impact of a better JIT.
jordanthoms 13y ago
So this is why we haven't seen much happening on the dalvik side. The source is here: https://android.googlesource.com/platform/art/+/kitkat-release https://android.googlesource.com/platform/art/+/kitkat-relea... and commit log: https://android.googlesource.com/platform/art/+log/kitkat-release https://android.googlesource.com/platform/art/+log/kitkat-re... - So if somebody has the time to investigate it most questions should be able to be answered.
- randallu 13y ago
  I thought Dalvik was quiet because the principal author (Dan Bornstein) left Google a while ago. Is ART from the recent FlexyCore acquisition, or something else that has been going on for a while?
  - BitMastro 13y ago
    The commit history suggests that it started more than 2 years ago
    - yohui 13y ago
      While Google's acquisition of Flexycore was only made public recently, the process must have started years ago. As Ars Technica noted, http://arstechnica.com/gadgets/2013/10/google-buys-flexycore-creator-of-a-10x-speed-boost-app-for-android/ http://arstechnica.com/gadgets/2013/10/google-buys-flexycore... > FlexyCore doesn't seem to have done anything on the Internet for the last two years. The company actively promoted its product, releasing 11 videos in a one-year span, and then just stopped. The lack of recent activity makes it unclear if Flexycore has continued development outside the public eye.
  - Ologn 13y ago
    One unfortunate thing about Bornstein leaving is he seemed to be the only one working on fixing the 65536 method limit bug/feature for Dalvik executables.
    - mateor 13y ago
      Tell me about it. All we get is simply spinning methods into separate jars every six months or so. Not a solution, IMO.
- rayiner 13y ago
  The guts are substantially different and seemingly more sophisticated. Notable things: 1) The compiler under compiler/dex seems to do a pretty simple set of optimizations and generate either code directly (compiler/dex/quick) or using LLVM through an intermediate code called GBC (compiler/dex/portable). 2) There's a new file format, OAT. Contrary to some reports, it doesn't appear to be a new bytecode, but rather a new file format for DEX bytecode. My guess it exists to support features like caching generated native code or compiling applications to images that don't have to be JIT-ed. The compiler has support for writing out ELF files, and LLVM can load ELF files dynamically with MCLinker. 3) There seems to be the start of a more sophisticated compiler under compiler/sea_ir. My guess is that it's intended to enable more high-level optimizations in the future. It seems to be a sea-of-nodes IR like the one used in Hotspot's C2 compiler, but doesn't seem to be either finished or plugged in. The change log suggests that it's still getting off the ground. 4) Judging by the commit logs, there seems to be a parallel-marking garbage collector, though otherwise it doesn't seem to be anything fancy.
devx 13y ago
If this is indeed the work of Flexycore, there are some explanations here, although they don't go into a lot of details either: https://www.youtube.com/watch?v=tEAz9fRoDmA&list=UUowARqiVYkRt_Qb54CCtQWg https://www.youtube.com/watch?v=tEAz9fRoDmA&list=UUowARqiVYk...
- loudmax 13y ago
  That video is tantalizing, but it's dated 2010. If it works as well as advertised, then why has it taken three years to be part of Android? I'd love to see ART work out though. And the video is almost worth watching just for the very awesome French accent.
- Zigurd 13y ago
  Several have tried to "accelerate" Android, like Myriad with Turbo Dalvik, but it's not so simple. The ART benchmarks are tantalizing, but how much battery life do you give up to get 2X performance in a synthetic benchmark? Hopefully ART is at least as efficient as Dalvik, but nobody outside Google has measured that yet. Potential improvements in the VM need to show they don't give up in other performance dimensions what they gain in JIT'ed code performance.
  - ge0rg 13y ago
    Do you have reason to believe that by running code at twice the speed, the energy consumption will be higher? IMHO this will be absolutely compensated for by being able to switch into a low-power state earlier.
    - Zigurd 13y ago
      I'd wager Hotspot's JIT would beat the pants off Dalvik's JIT, and make your battery hot while doing it. Dalvik's JIT is designed unlike other JITs: It is designed to JIT compile less code, but to find the code that has the highest impact. Dalvik's bytecode interpreter already gains what Google has claimed is a 2X improvement over interpreted Java bytecode. Before Android 2.3, that's how Android ran code.
scotth 13y ago
Does anyone have information on what is actually different about ART?
- oscargrouch 13y ago
  Its a new compiler and VM, written in C++ instead of the Dalvik C, and with a new runtime; It looks that it can compile to two banckends: one called "Quick" and other called "Portable" I think "Quick" is a complete home backed Jit, while "Portable" is LLVM based So probably (im guessing from fast source code study): This VM can JIT from bytecode to native while running (the Quick backend) and can run a already native payload using the LLVM backend.. The native payload probably will be very optimized since is AOT, and the Quick, since is JIT will probably have lower optimizations (as a runtime compiled code) (and we can assume that, the Dalvik VM is getting obsolete) Edit: adding more observations.. They have created a very sophisticated retargatable compiler that deliver into a SSA based IR and from there it goes to the backends that i have cited earlier
  - devx 13y ago
    If it's LLVM, that pretty much opens the door for running Native Client apps on Android, and possibly even merging Android with ChromeOS, right?
    - oscargrouch 13y ago
      Thats a good guess.. theres a way to be sure of it.. The bitcode from Pnacl is different from the LLVM one.. But the "portable" backend naming scheme maybe could mean they will use the PNacl-LLVM instead of the pure LLVM one.. I wonder how Chrome could glue with this.. but if the Nacl/Pnacl uses the PPAPI api, in this hypotethical scenario they would replace the PPAPI runtime with a runtime compatible with ART.. it can be done, and the final c++ application source code would look like the java one.. edit: This could also mean the ndk applications will be first class citizens and wont need to rely on a java shim + native bindings.. I think that is more likely than the ChromeOS integration scenario
wehadfun 13y ago
So what is dalvik?
- wmf 13y ago
  Dalvik is the JVM[1] in Android. [1] Ignore the pedants saying otherwise; it walks like a duck and quacks like a duck.
  - Zigurd 13y ago
    Some people will complain that it is not a JVM at all, since it interprets Dalvik bytecode, not Java bytecode. You must run the Android toolchain, which translates Java bytecodes to Dalvik bytecodes, to produce code that runs on Dalvik.
  - eropple 13y ago
    If it actually did walk or quack like a duck, you'd be right--but it doesn't. It does not support the Java bytecode format; this is why Groovy, Rhino/LiveConnect, etc. don't work (and you can't do compile-time weaving, further limiting it). It does not support a recognized class library profile. There is a JVM specification and Dalvik does not conform to it: that means it's not a JVM. It isn't pedantic to say that Dalvik isn't a JVM, because it's not. RoboVM isn't a JVM, either. Supporting Java does not a JVM make.
    - Zigurd 13y ago
      > this is why Groovy, Rhino/LiveConnect, etc. don't work You were doing pretty good up to there. The Android toolchain does not compile to Dalvik bytecode. It translates from Java bytecode to Dalvik bytecode. So any language that compiles to Java bytecode could be used to write Android apps. There are many projects to bring other JVM languages to Android.
      - eropple 13y ago
        I am well aware of how Android's dexer tools work and that non-Java languages work on Dalvik; I use Scala on Android regularly. groovyc builds legal Java bytecode and (as of 2012, at least--since the advent of dexmaker this may have changed) fails when you try to run the dexed output on Android (RTCG). Rhino will work as an embedded runtime on Android with optimizations disabled--in which case it runs in fully interpreted mode--but fails when you enable optimizations or when you attempt to use LiveConnect (runtime class construction). And this is because Dalvik doesn't understand Java bytecode. It's not conformant to either J2SE or J2ME and these are examples of libraries that puke because of its nonconformance. That's all I'm saying.
donpdonp 13y ago
With a hostile owner of Java, it seems strategic to begin porting to a new runtime. I'm a little surprised its written in C++ and not go. Every step away from the JVM instruction set and disk formats is a harder case to make for patent/copyright infringement.
- mscottmcbee 13y ago
  Go is still very young. Doesn't make sense to write such a critical piece of software with it quite yet.
  - devx 13y ago
    Yeah, they probably want to wait until Go 2.0 or something, before they commit Android to supporting Go (and support only 64-bit apps while they're at it, since from what I hear Go handles 64-bit much better than 32-bit anyway). So maybe in 2-3 years. But I do think they should do it eventually, and move away completely from Java, because I think Java is a pain to learn, especially for new programmers who want to make Android apps. Being able to write Go apps for Android could make Android that much more attractive to developers. In the meantime, this transition to ART apps, will be a huge benefit for users, as their apps will run better, especially on lower-end devices, which KitKat also addresses.
    - binarycrusader 13y ago
      Go isn't a panace either, especially when it comes to dealing with OS-level threads and goroutines.
  - mortdeus 13y ago
    Go might be young but the underlying compiler suite is derived from Ken Thompson's c compiler written for plan9 ~25 years ago. Also taking into consideration that the people developing Go have an impressive history of innovation; its not an uncommon by the time somebody actually finishes developing that critical software, for the compilers and runtime to receive vast improvements via new useful diagnostic tools and optimizations.
AsymetricCom 13y ago
I can't wait for someone else to invest effort in making this a stable and secure runtime!
devx 13y ago
Someone benchmarked Dalvik vs ART, and it seems it's already 2x faster, and the performance is much more consistent: https://docs.google.com/spreadsheet/ccc?key=0AnE-DX9Fbr9KdFZtRlhQaWxmVG5XdDR3TFR1Q3JONnc&usp=sharing#gid=0 https://docs.google.com/spreadsheet/ccc?key=0AnE-DX9Fbr9KdFZ... Since this is still probably in alpha mode, I assume it could get even faster with further optimization.
- prlin 13y ago
  Any explanation of the giant spike for ART? GC misbehaving?
bitwize 13y ago
Pretty much tacit acknowledgement that Dalvik was a huge design mistake. Funny how Apple got the runtime right in 2007 and now, more than six years later, Google is still struggling with it.
- amaranth 13y ago
  I know you're trolling here but I'm pretty sure Apple has gone through at least two similarly large changes in their toolchain since launching the iPhone. And this isn't the first change Android has had. Over time you figure out better ways to do things.
  - dottrap 13y ago
    Actually, the iPhone Obj-C runtime has undergone very little changes since the launch of the iPhone. Apple had already debuted Obj-C 2.0 (which was the most significant change) in OS X 10.5 , before the iPhone launch. Apple's clang/llvm transition was also already underway, but this had more to do with building more integrated developer tools and not having to deal with gcc, not as much the runtime. ARC, perhaps the other big new thing you were thinking of, is again just a developer tool that was enabled by the transition to clang. Fundamentally, it is simply the compiler now being smart enough to inject retains/releases automatically when compiling your code instead of you doing it manually. Again, the impact of this is for developers, not end user (runtime) experience.
  - pjmlp 13y ago
    iOS has been fully native from day one. Microsoft dropped the JIT model from Windows Phone 7 and moved to fully native starting with Windows Phone 8.
- chubs 13y ago
  Actually, apple got the runtime right in the 80's :) Objective-C hasn't really changed all that much since then. It really is 'less is more'.
jithesh 13y ago
G had to do it. Compare Windows Phone 8 to Android - Dual core WP8 phones were better or equal in performance compared to quad core Androids! Had compared Lumia920 with SGS3 few months back.
- vidarh 13y ago
  My pet peeve with Android is drawing apps. I bought a ZTE Open with FirefoxOS, and the first thing that struck me is that the very first drawing app I tried on a low end phone like that totally trounced every (I've tested at least two dozen) drawing app I've tested on my far faster Android phone. On every single one of them, the brush ends up lagging ridiculously far behind my finger even with quite slow strokes, while on the FirefoxOS phone, I hardly noticed the lag unless I did fast sweeps or used a stylus (there is lag there but usually small enough that if using a finger, my fingertip obscures it)
- pjmlp 13y ago
  On Windows Phone 8 everything is native, even .NET code.
pjmlp 13y ago
So Google does acknowledge that Dalvik's JIT does not cut it.

152 points by alsutton010203 13y ago

wmf 13y ago

What a tease!

Unfortunately that page doesn't actually explain the difference between ART and Dalvik. I found some random benchmark by a user on XDA (http://www.xda-developers.com/android/new-runtime-compiler-in-android-4-4/#comment-1104912482 http://www.xda-developers.com/android/new-runtime-compiler-i...) that could indicate significant speedups with ART. Though I would take this information with a huge grain of salt right now as it is one benchmark from an unknown source.

Zigurd 13y ago
As Android adds more features, more of Android is implemented in Java. Pretty much all of Google Play Services is implemented in Java. That means Android can rely less on the fact that graphics and the guts of many UI widgets are native code under a thin layer of Java. Android was always a "Java OS" but it has become more so since Android 3. So ART is important to keeping Android quick. Still, your mileage may vary. Unless you are doing significant computation in your app, a synthetic benchmark will vastly over-emphasize the impact of a better JIT.

jordanthoms 13y ago

So this is why we haven't seen much happening on the dalvik side. The source is here: https://android.googlesource.com/platform/art/+/kitkat-release https://android.googlesource.com/platform/art/+/kitkat-relea... and commit log: https://android.googlesource.com/platform/art/+log/kitkat-release https://android.googlesource.com/platform/art/+log/kitkat-re... - So if somebody has the time to investigate it most questions should be able to be answered.

randallu 13y ago
I thought Dalvik was quiet because the principal author (Dan Bornstein) left Google a while ago. Is ART from the recent FlexyCore acquisition, or something else that has been going on for a while?
- BitMastro 13y ago
  The commit history suggests that it started more than 2 years ago
  - yohui 13y ago
    While Google's acquisition of Flexycore was only made public recently, the process must have started years ago. As Ars Technica noted, http://arstechnica.com/gadgets/2013/10/google-buys-flexycore-creator-of-a-10x-speed-boost-app-for-android/ http://arstechnica.com/gadgets/2013/10/google-buys-flexycore... > FlexyCore doesn't seem to have done anything on the Internet for the last two years. The company actively promoted its product, releasing 11 videos in a one-year span, and then just stopped. The lack of recent activity makes it unclear if Flexycore has continued development outside the public eye.
- Ologn 13y ago
  One unfortunate thing about Bornstein leaving is he seemed to be the only one working on fixing the 65536 method limit bug/feature for Dalvik executables.
  - mateor 13y ago
    Tell me about it. All we get is simply spinning methods into separate jars every six months or so. Not a solution, IMO.
rayiner 13y ago
The guts are substantially different and seemingly more sophisticated. Notable things: 1) The compiler under compiler/dex seems to do a pretty simple set of optimizations and generate either code directly (compiler/dex/quick) or using LLVM through an intermediate code called GBC (compiler/dex/portable). 2) There's a new file format, OAT. Contrary to some reports, it doesn't appear to be a new bytecode, but rather a new file format for DEX bytecode. My guess it exists to support features like caching generated native code or compiling applications to images that don't have to be JIT-ed. The compiler has support for writing out ELF files, and LLVM can load ELF files dynamically with MCLinker. 3) There seems to be the start of a more sophisticated compiler under compiler/sea_ir. My guess is that it's intended to enable more high-level optimizations in the future. It seems to be a sea-of-nodes IR like the one used in Hotspot's C2 compiler, but doesn't seem to be either finished or plugged in. The change log suggests that it's still getting off the ground. 4) Judging by the commit logs, there seems to be a parallel-marking garbage collector, though otherwise it doesn't seem to be anything fancy.

devx 13y ago

If this is indeed the work of Flexycore, there are some explanations here, although they don't go into a lot of details either: https://www.youtube.com/watch?v=tEAz9fRoDmA&list=UUowARqiVYkRt_Qb54CCtQWg https://www.youtube.com/watch?v=tEAz9fRoDmA&list=UUowARqiVYk...

loudmax 13y ago
That video is tantalizing, but it's dated 2010. If it works as well as advertised, then why has it taken three years to be part of Android? I'd love to see ART work out though. And the video is almost worth watching just for the very awesome French accent.
Zigurd 13y ago
Several have tried to "accelerate" Android, like Myriad with Turbo Dalvik, but it's not so simple. The ART benchmarks are tantalizing, but how much battery life do you give up to get 2X performance in a synthetic benchmark? Hopefully ART is at least as efficient as Dalvik, but nobody outside Google has measured that yet. Potential improvements in the VM need to show they don't give up in other performance dimensions what they gain in JIT'ed code performance.
- ge0rg 13y ago
  Do you have reason to believe that by running code at twice the speed, the energy consumption will be higher? IMHO this will be absolutely compensated for by being able to switch into a low-power state earlier.
  - Zigurd 13y ago
    I'd wager Hotspot's JIT would beat the pants off Dalvik's JIT, and make your battery hot while doing it. Dalvik's JIT is designed unlike other JITs: It is designed to JIT compile less code, but to find the code that has the highest impact. Dalvik's bytecode interpreter already gains what Google has claimed is a 2X improvement over interpreted Java bytecode. Before Android 2.3, that's how Android ran code.

scotth 13y ago

Does anyone have information on what is actually different about ART?

oscargrouch 13y ago
Its a new compiler and VM, written in C++ instead of the Dalvik C, and with a new runtime; It looks that it can compile to two banckends: one called "Quick" and other called "Portable" I think "Quick" is a complete home backed Jit, while "Portable" is LLVM based So probably (im guessing from fast source code study): This VM can JIT from bytecode to native while running (the Quick backend) and can run a already native payload using the LLVM backend.. The native payload probably will be very optimized since is AOT, and the Quick, since is JIT will probably have lower optimizations (as a runtime compiled code) (and we can assume that, the Dalvik VM is getting obsolete) Edit: adding more observations.. They have created a very sophisticated retargatable compiler that deliver into a SSA based IR and from there it goes to the backends that i have cited earlier
- devx 13y ago
  If it's LLVM, that pretty much opens the door for running Native Client apps on Android, and possibly even merging Android with ChromeOS, right?
  - oscargrouch 13y ago
    Thats a good guess.. theres a way to be sure of it.. The bitcode from Pnacl is different from the LLVM one.. But the "portable" backend naming scheme maybe could mean they will use the PNacl-LLVM instead of the pure LLVM one.. I wonder how Chrome could glue with this.. but if the Nacl/Pnacl uses the PPAPI api, in this hypotethical scenario they would replace the PPAPI runtime with a runtime compatible with ART.. it can be done, and the final c++ application source code would look like the java one.. edit: This could also mean the ndk applications will be first class citizens and wont need to rely on a java shim + native bindings.. I think that is more likely than the ChromeOS integration scenario

wehadfun 13y ago

So what is dalvik?

wmf 13y ago
Dalvik is the JVM[1] in Android. [1] Ignore the pedants saying otherwise; it walks like a duck and quacks like a duck.
- Zigurd 13y ago
  Some people will complain that it is not a JVM at all, since it interprets Dalvik bytecode, not Java bytecode. You must run the Android toolchain, which translates Java bytecodes to Dalvik bytecodes, to produce code that runs on Dalvik.
- eropple 13y ago
  If it actually did walk or quack like a duck, you'd be right--but it doesn't. It does not support the Java bytecode format; this is why Groovy, Rhino/LiveConnect, etc. don't work (and you can't do compile-time weaving, further limiting it). It does not support a recognized class library profile. There is a JVM specification and Dalvik does not conform to it: that means it's not a JVM. It isn't pedantic to say that Dalvik isn't a JVM, because it's not. RoboVM isn't a JVM, either. Supporting Java does not a JVM make.
  - Zigurd 13y ago
    > this is why Groovy, Rhino/LiveConnect, etc. don't work You were doing pretty good up to there. The Android toolchain does not compile to Dalvik bytecode. It translates from Java bytecode to Dalvik bytecode. So any language that compiles to Java bytecode could be used to write Android apps. There are many projects to bring other JVM languages to Android.
    - eropple 13y ago
      I am well aware of how Android's dexer tools work and that non-Java languages work on Dalvik; I use Scala on Android regularly. groovyc builds legal Java bytecode and (as of 2012, at least--since the advent of dexmaker this may have changed) fails when you try to run the dexed output on Android (RTCG). Rhino will work as an embedded runtime on Android with optimizations disabled--in which case it runs in fully interpreted mode--but fails when you enable optimizations or when you attempt to use LiveConnect (runtime class construction). And this is because Dalvik doesn't understand Java bytecode. It's not conformant to either J2SE or J2ME and these are examples of libraries that puke because of its nonconformance. That's all I'm saying.

donpdonp 13y ago

With a hostile owner of Java, it seems strategic to begin porting to a new runtime. I'm a little surprised its written in C++ and not go. Every step away from the JVM instruction set and disk formats is a harder case to make for patent/copyright infringement.

mscottmcbee 13y ago
Go is still very young. Doesn't make sense to write such a critical piece of software with it quite yet.
- devx 13y ago
  Yeah, they probably want to wait until Go 2.0 or something, before they commit Android to supporting Go (and support only 64-bit apps while they're at it, since from what I hear Go handles 64-bit much better than 32-bit anyway). So maybe in 2-3 years. But I do think they should do it eventually, and move away completely from Java, because I think Java is a pain to learn, especially for new programmers who want to make Android apps. Being able to write Go apps for Android could make Android that much more attractive to developers. In the meantime, this transition to ART apps, will be a huge benefit for users, as their apps will run better, especially on lower-end devices, which KitKat also addresses.
  - binarycrusader 13y ago
    Go isn't a panace either, especially when it comes to dealing with OS-level threads and goroutines.
- mortdeus 13y ago
  Go might be young but the underlying compiler suite is derived from Ken Thompson's c compiler written for plan9 ~25 years ago. Also taking into consideration that the people developing Go have an impressive history of innovation; its not an uncommon by the time somebody actually finishes developing that critical software, for the compilers and runtime to receive vast improvements via new useful diagnostic tools and optimizations.

AsymetricCom 13y ago

I can't wait for someone else to invest effort in making this a stable and secure runtime!

devx 13y ago

Someone benchmarked Dalvik vs ART, and it seems it's already 2x faster, and the performance is much more consistent: https://docs.google.com/spreadsheet/ccc?key=0AnE-DX9Fbr9KdFZtRlhQaWxmVG5XdDR3TFR1Q3JONnc&usp=sharing#gid=0 https://docs.google.com/spreadsheet/ccc?key=0AnE-DX9Fbr9KdFZ... Since this is still probably in alpha mode, I assume it could get even faster with further optimization.

prlin 13y ago
Any explanation of the giant spike for ART? GC misbehaving?

bitwize 13y ago

Pretty much tacit acknowledgement that Dalvik was a huge design mistake. Funny how Apple got the runtime right in 2007 and now, more than six years later, Google is still struggling with it.

amaranth 13y ago
I know you're trolling here but I'm pretty sure Apple has gone through at least two similarly large changes in their toolchain since launching the iPhone. And this isn't the first change Android has had. Over time you figure out better ways to do things.
- dottrap 13y ago
  Actually, the iPhone Obj-C runtime has undergone very little changes since the launch of the iPhone. Apple had already debuted Obj-C 2.0 (which was the most significant change) in OS X 10.5 , before the iPhone launch. Apple's clang/llvm transition was also already underway, but this had more to do with building more integrated developer tools and not having to deal with gcc, not as much the runtime. ARC, perhaps the other big new thing you were thinking of, is again just a developer tool that was enabled by the transition to clang. Fundamentally, it is simply the compiler now being smart enough to inject retains/releases automatically when compiling your code instead of you doing it manually. Again, the impact of this is for developers, not end user (runtime) experience.
- pjmlp 13y ago
  iOS has been fully native from day one. Microsoft dropped the JIT model from Windows Phone 7 and moved to fully native starting with Windows Phone 8.
chubs 13y ago
Actually, apple got the runtime right in the 80's :) Objective-C hasn't really changed all that much since then. It really is 'less is more'.

jithesh 13y ago

G had to do it. Compare Windows Phone 8 to Android - Dual core WP8 phones were better or equal in performance compared to quad core Androids! Had compared Lumia920 with SGS3 few months back.

vidarh 13y ago
My pet peeve with Android is drawing apps. I bought a ZTE Open with FirefoxOS, and the first thing that struck me is that the very first drawing app I tried on a low end phone like that totally trounced every (I've tested at least two dozen) drawing app I've tested on my far faster Android phone. On every single one of them, the brush ends up lagging ridiculously far behind my finger even with quite slow strokes, while on the FirefoxOS phone, I hardly noticed the lag unless I did fast sweeps or used a stylus (there is lag there but usually small enough that if using a finger, my fingertip obscures it)
pjmlp 13y ago
On Windows Phone 8 everything is native, even .NET code.

pjmlp 13y ago

So Google does acknowledge that Dalvik's JIT does not cut it.