5 ms·

Nexus One running Android Froyo 2.2 is 450% faster than Eclair 2.1

75 points by archon810 16y ago

drivebyacct 16y ago
JIT, Flash, and defragmentation all in one release!? Call me intrigued!
megablast 16y ago
This is great, but they only ran one test on the device, Linpack. Just keep this in mind, the phone will not be 4.5x faster, with the new OS.
jbellis 16y ago
I understand why Google would want to use Java in their app platform. But if they didn't have the resources to get JIT working before now, wouldn't gcj (or hell, write your own java-to-machine-code compiler, clearly Google isn't scared of writing compilers) have been better than using a non-JITed VM?
- Daishiman 16y ago
  The point of using a VM was to abstract away from specific processor targets, since embedded processors run from ARM to PowerPC, MIPS, x86, and others (and multiple variants of each processor, support additional instruction sets). This allows OEMs to produce an x86 port of stuff while keeping 95% of all apps which don't need native compilation.
  - nimrody 16y ago
    Well, you could always ship software in platform neutral code and make the final transition to native code when they are installed (either with something like gcj or use some intermediate representation like LLVM does).
    - wgren 16y ago
      That is basically what JIT is. Why reinvent the wheel when they can use the resources that has been poured into JVM research?
      - jbellis 16y ago
        Except they can't, really. Dalvik is completely unrelated to Hotspot or any other JVM out there. (Remember that Android doesn't run Java class files natively, it's first compiled into dex.)
        wgren 16y ago
        Right you are jbellis. Had forgotten that Dalvik isn't just a small JVM but a completely different architecture (register based, etc). But anyway, what nimrody suggested is what they are doing - using platform neutral Dalvik bytecode and then transition to native through JIT.
    - theBobMcCormick 16y ago
      I think that would have it's own complexities. You'd have to ship each phone with a compiler and related toolchain. You'd also end up with two copies of each application installed on the users phone (one in the neutral format and one native). Sound like kind of a messy approach. Really, the existing non-jit'ed Dalvik VM runs fast enough. If you think about it, their decision to ship a non-JIT VM and enhance the platform with JIT later is very much like Apple's approach with the iPhone of initially shipping the product without cut-and-paste and without any native API for third party apps, but then enhancing the platform later by adding those (and many other) features later. Both companies shipped when they had a platform that was "good enough", then have kept iterating and improving.
- s3graham 16y ago
  It's not quite that obvious. Compared to desktop/server where almost any jit is a win, there's substantial pressure on memory usage and battery life. An interpreter can do better on whole-system performance for both of those, without special care for when to run the jit, and how it's implemented. I'm looking forward to seeing Bill Buzbee's talk on the JIT at I/O (of the most excellent http://www.homebrewcpu.com/ http://www.homebrewcpu.com/ incidentally! :)
- ergo98 16y ago
  >But if they didn't have the resources to get JIT working before now, wouldn't gcj (or hell, write your own java-to-machine-code compiler, clearly Google isn't scared of writing compilers) have been better than using a non-JITed VM? The Dalvik VM uses its own bytecode and all, so they would have to heavily modify anything existing. Ultimately Android has been a work in progress. JIT is something that everyone has been asking for since day one, but there just aren't enough resources -- Apple is a $220 billion dollar company that is significantly hinged on the iPhone OS. The Android project, while relied upon by a lot of companies, is largely the work of Google that sees little to no revenue from it (their primary motivation, purportedly, was simply to ensure that there were options in the market).
  - cpr 16y ago
    Clarification: their primary motivation is so that they could ensure that at least some part of the mobile market could run their ads, they realizing that mobile is the future, and that ads are currently their only real source of income.
    - ergo98 16y ago
      Absolutely true. As a business they don't want to be in a position where they can be cut out of the ecosystem. That's actually an interesting facet of Android -- much was made recently about one of the open handset partners replacing Google with another search engine, but that's exactly how the platform is supposed to work. Google has no free in to all of the platform, beyond the add-ons like Google Mail that the partners would almost certainly want on the phone.
mehta 16y ago
Cached link: http://webcache.googleusercontent.com/search?q=cache:http://www.androidpolice.com/2010/05/11/exclusive-androidpolice-coms-nexus-one-is-running-android-2-2-froyo-how-fast-is-it-compared-to-2-1-oh-only-about-450-faster/&hl=en&strip=1 http://webcache.googleusercontent.com/search?q=cache:http://... Scroll to the middle of the page for article.
- archon810 16y ago
  The servers were indeed melting after engadget, gizmodo, HN, and reddit all ganged up on us simultaneously but the fires have been put out and we're now happily serving anyone interested. For the curious ones, when the reqs/s number reached about 220 and the server melted, I had to figure out a new solution. No problem, as I have selected Linode to be our VPS provider and was able to upgrade from a 360MB RAM Linode to a 1080MB one in about 15 minutes of downtime. Some apache tweaking was needed, of course, but now we're pushing all the traffic that is required with quite a bit of room to grow. Thanks for all the upvotes.
justinph 16y ago
I'd like to see some real world usage rather than synthetic and (mostly) meaningless benchmarks. That said, this sounds awesome. Maybe the final bump that'll push me to ditch my 2G iPhone.
- malkia 16y ago
  But then again a lot of the game code is similar pretty much to such benchmarking code - for example skinning, physics, collision detection, FFT.
  - CitizenKane 16y ago
    While that's true, a small piece of code can likely be JITed once and then will essentially become cached. I'm guessing that real world applications will have more overhead from JITing thus the performance likely won't be quite as good. Still, even if performance increased by 2x - 3.5x or so that would be a huge win.
- newhouseb 16y ago
  Agreed, Linpack on ARM sounds ridiculous since ARM by definition doesn't have a true FPU (ignoring VFP and NEON). Then again, maybe it means more on ARM because it's an indication of low level software optimizations rather than actual hardware, and might be more relevant for applications that don't actually require floating point math.
technomancy 16y ago
The author is rather confused about what's going on here. > Things are starting to finally come together. Flash and huge performance gains, all in the same release. Flash is CPU hungry, so Android makes everything about the environment more efficient. Adding JIT improves the speed of the Dalvik VM. But unless Adobe threw away their existing Flash codebase for the Android port, Flash is going to run as native code on the device, which is entirely outside the Dalvik VM. So these speed improvements will not affect Flash performance at all.
- archon810 16y ago
  Thank you for clarifications, everyone (including Cyanogen himself). I've updated the article to reflect these.
- not_an_alien 16y ago
  Exactly. Same for the system as a whole. It should be a nice boost for Apps/games available in the market though. Weird that they didn't have JIT until now.
- zwetan 16y ago
  Flash is certainly running as native code on the device as they do CPU and GPU optimization see http://tv.adobe.com/watch/flash-camp-san-francisco/flash-player-101-internals/ http://tv.adobe.com/watch/flash-camp-san-francisco/flash-pla... for more details also because Google is part of the Open Screen Project http://www.openscreenproject.org/partners/current_partners.html http://www.openscreenproject.org/partners/current_partners.h... those same CPU and GPU optimization could benefit Android itself (not only Flash) those partners are about being open to each others, exactly the opposite of you know who ;)
buster 16y ago
Wow.. i knew that many people cried for JIT, but now seeing numbers.. i hope the update will be released soon! Hopefully at Google I/O?
- not_an_alien 16y ago
  They said they'll release Flash at Google I/O, and they already got their Froyo cast for the Google offices, so... yeah, I'm leaning on the 'yes' side for Android 2.2 available at Google I/O.
ericz 16y ago
The improved feature set and performance of 2.2 is great and all but let's not forget Android's real problem: most of the Android handsets on the market won't see 2.2 until way after release. The segmentation of the operating system among different devices really inhibits much of its potential.
- pyre 16y ago
  True, but there are plenty of people yet to get an Android phone. These people will probably end up with a newer model that has all of these bells and whistles. I'm not really sure that Android has reached a 'critical mass' yet. Sure it's starting to out-pace the iPhone, but it still has huge potential for growth in the market. That these improvements are coming now, means that it will only help Android to grow (as the new handsets will come with v2.2 and all of the improvements). That said, it would be nice if the carrier-branded Android handsets bothered to update more regularly...
  - joubert 16y ago
    Who pushes updates? The carrier, handset maker, or Google? Or do hey all have to agree?
    - wgren 16y ago
      The handset maker verifies that the update works with their models and customizations, and they makes the new files available to the MNO (Mobile Network Operator). The MNO then decide if/when the OTA push happens.
      - joubert 16y ago
        maybe there's no data avail, but I wonder what the median update lag is from the time Google pushes out an OS update.
        msg 16y ago
        I've been on T mobile for a year and my G1 is still running Android 1.6. I can't complain, because the phone is weak sauce and at least everything needed for turn by turn navigation is supported.
pkulak 16y ago
JIT is nice, but it's not going to really matter. Anything that needs performance is already natively compiled. So, this should make your tip calculator scream! It may mean that from now on devs can use Java where they had to use the native API before.
- s3graham 16y ago
  That's not true. Much of the UI toolkit is in Java and normal interaction frame rate suffers without a lot of care and fiddly caching tricks.
leecho0 16y ago
I'm curious, how much faster would it run if these tests were written in native code?

75 points by archon810 16y ago

JIT, Flash, and defragmentation all in one release!? Call me intrigued!

This is great, but they only ran one test on the device, Linpack. Just keep this in mind, the phone will not be 4.5x faster, with the new OS.

jbellis 16y ago

I understand why Google would want to use Java in their app platform. But if they didn't have the resources to get JIT working before now, wouldn't gcj (or hell, write your own java-to-machine-code compiler, clearly Google isn't scared of writing compilers) have been better than using a non-JITed VM?

Daishiman 16y ago
The point of using a VM was to abstract away from specific processor targets, since embedded processors run from ARM to PowerPC, MIPS, x86, and others (and multiple variants of each processor, support additional instruction sets). This allows OEMs to produce an x86 port of stuff while keeping 95% of all apps which don't need native compilation.
- nimrody 16y ago
  Well, you could always ship software in platform neutral code and make the final transition to native code when they are installed (either with something like gcj or use some intermediate representation like LLVM does).
  - wgren 16y ago
    That is basically what JIT is. Why reinvent the wheel when they can use the resources that has been poured into JVM research?
    - jbellis 16y ago
      Except they can't, really. Dalvik is completely unrelated to Hotspot or any other JVM out there. (Remember that Android doesn't run Java class files natively, it's first compiled into dex.)
      - wgren 16y ago
        Right you are jbellis. Had forgotten that Dalvik isn't just a small JVM but a completely different architecture (register based, etc). But anyway, what nimrody suggested is what they are doing - using platform neutral Dalvik bytecode and then transition to native through JIT.
  - theBobMcCormick 16y ago
    I think that would have it's own complexities. You'd have to ship each phone with a compiler and related toolchain. You'd also end up with two copies of each application installed on the users phone (one in the neutral format and one native). Sound like kind of a messy approach. Really, the existing non-jit'ed Dalvik VM runs fast enough. If you think about it, their decision to ship a non-JIT VM and enhance the platform with JIT later is very much like Apple's approach with the iPhone of initially shipping the product without cut-and-paste and without any native API for third party apps, but then enhancing the platform later by adding those (and many other) features later. Both companies shipped when they had a platform that was "good enough", then have kept iterating and improving.
s3graham 16y ago
It's not quite that obvious. Compared to desktop/server where almost any jit is a win, there's substantial pressure on memory usage and battery life. An interpreter can do better on whole-system performance for both of those, without special care for when to run the jit, and how it's implemented. I'm looking forward to seeing Bill Buzbee's talk on the JIT at I/O (of the most excellent http://www.homebrewcpu.com/ http://www.homebrewcpu.com/ incidentally! :)
ergo98 16y ago
>But if they didn't have the resources to get JIT working before now, wouldn't gcj (or hell, write your own java-to-machine-code compiler, clearly Google isn't scared of writing compilers) have been better than using a non-JITed VM? The Dalvik VM uses its own bytecode and all, so they would have to heavily modify anything existing. Ultimately Android has been a work in progress. JIT is something that everyone has been asking for since day one, but there just aren't enough resources -- Apple is a $220 billion dollar company that is significantly hinged on the iPhone OS. The Android project, while relied upon by a lot of companies, is largely the work of Google that sees little to no revenue from it (their primary motivation, purportedly, was simply to ensure that there were options in the market).
- cpr 16y ago
  Clarification: their primary motivation is so that they could ensure that at least some part of the mobile market could run their ads, they realizing that mobile is the future, and that ads are currently their only real source of income.
  - ergo98 16y ago
    Absolutely true. As a business they don't want to be in a position where they can be cut out of the ecosystem. That's actually an interesting facet of Android -- much was made recently about one of the open handset partners replacing Google with another search engine, but that's exactly how the platform is supposed to work. Google has no free in to all of the platform, beyond the add-ons like Google Mail that the partners would almost certainly want on the phone.

mehta 16y ago

Cached link: http://webcache.googleusercontent.com/search?q=cache:http://www.androidpolice.com/2010/05/11/exclusive-androidpolice-coms-nexus-one-is-running-android-2-2-froyo-how-fast-is-it-compared-to-2-1-oh-only-about-450-faster/&hl=en&strip=1 http://webcache.googleusercontent.com/search?q=cache:http://... Scroll to the middle of the page for article.

archon810 16y ago
The servers were indeed melting after engadget, gizmodo, HN, and reddit all ganged up on us simultaneously but the fires have been put out and we're now happily serving anyone interested. For the curious ones, when the reqs/s number reached about 220 and the server melted, I had to figure out a new solution. No problem, as I have selected Linode to be our VPS provider and was able to upgrade from a 360MB RAM Linode to a 1080MB one in about 15 minutes of downtime. Some apache tweaking was needed, of course, but now we're pushing all the traffic that is required with quite a bit of room to grow. Thanks for all the upvotes.

justinph 16y ago

I'd like to see some real world usage rather than synthetic and (mostly) meaningless benchmarks. That said, this sounds awesome. Maybe the final bump that'll push me to ditch my 2G iPhone.

malkia 16y ago
But then again a lot of the game code is similar pretty much to such benchmarking code - for example skinning, physics, collision detection, FFT.
- CitizenKane 16y ago
  While that's true, a small piece of code can likely be JITed once and then will essentially become cached. I'm guessing that real world applications will have more overhead from JITing thus the performance likely won't be quite as good. Still, even if performance increased by 2x - 3.5x or so that would be a huge win.
newhouseb 16y ago
Agreed, Linpack on ARM sounds ridiculous since ARM by definition doesn't have a true FPU (ignoring VFP and NEON). Then again, maybe it means more on ARM because it's an indication of low level software optimizations rather than actual hardware, and might be more relevant for applications that don't actually require floating point math.

technomancy 16y ago

The author is rather confused about what's going on here. > Things are starting to finally come together. Flash and huge performance gains, all in the same release. Flash is CPU hungry, so Android makes everything about the environment more efficient. Adding JIT improves the speed of the Dalvik VM. But unless Adobe threw away their existing Flash codebase for the Android port, Flash is going to run as native code on the device, which is entirely outside the Dalvik VM. So these speed improvements will not affect Flash performance at all.

archon810 16y ago
Thank you for clarifications, everyone (including Cyanogen himself). I've updated the article to reflect these.
not_an_alien 16y ago
Exactly. Same for the system as a whole. It should be a nice boost for Apps/games available in the market though. Weird that they didn't have JIT until now.
zwetan 16y ago
Flash is certainly running as native code on the device as they do CPU and GPU optimization see http://tv.adobe.com/watch/flash-camp-san-francisco/flash-player-101-internals/ http://tv.adobe.com/watch/flash-camp-san-francisco/flash-pla... for more details also because Google is part of the Open Screen Project http://www.openscreenproject.org/partners/current_partners.html http://www.openscreenproject.org/partners/current_partners.h... those same CPU and GPU optimization could benefit Android itself (not only Flash) those partners are about being open to each others, exactly the opposite of you know who ;)

buster 16y ago

Wow.. i knew that many people cried for JIT, but now seeing numbers.. i hope the update will be released soon! Hopefully at Google I/O?

not_an_alien 16y ago
They said they'll release Flash at Google I/O, and they already got their Froyo cast for the Google offices, so... yeah, I'm leaning on the 'yes' side for Android 2.2 available at Google I/O.

ericz 16y ago

The improved feature set and performance of 2.2 is great and all but let's not forget Android's real problem: most of the Android handsets on the market won't see 2.2 until way after release. The segmentation of the operating system among different devices really inhibits much of its potential.

pyre 16y ago
True, but there are plenty of people yet to get an Android phone. These people will probably end up with a newer model that has all of these bells and whistles. I'm not really sure that Android has reached a 'critical mass' yet. Sure it's starting to out-pace the iPhone, but it still has huge potential for growth in the market. That these improvements are coming now, means that it will only help Android to grow (as the new handsets will come with v2.2 and all of the improvements). That said, it would be nice if the carrier-branded Android handsets bothered to update more regularly...
- joubert 16y ago
  Who pushes updates? The carrier, handset maker, or Google? Or do hey all have to agree?
  - wgren 16y ago
    The handset maker verifies that the update works with their models and customizations, and they makes the new files available to the MNO (Mobile Network Operator). The MNO then decide if/when the OTA push happens.
    - joubert 16y ago
      maybe there's no data avail, but I wonder what the median update lag is from the time Google pushes out an OS update.
      - msg 16y ago
        I've been on T mobile for a year and my G1 is still running Android 1.6. I can't complain, because the phone is weak sauce and at least everything needed for turn by turn navigation is supported.

pkulak 16y ago

JIT is nice, but it's not going to really matter. Anything that needs performance is already natively compiled. So, this should make your tip calculator scream! It may mean that from now on devs can use Java where they had to use the native API before.

s3graham 16y ago
That's not true. Much of the UI toolkit is in Java and normal interaction frame rate suffers without a lot of care and fiddly caching tricks.

leecho0 16y ago

I'm curious, how much faster would it run if these tests were written in native code?