Nexus One running Android Froyo 2.2 is 450% faster than Eclair 2.1 | Hacker News Reader

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

androidpolice.com

75 pointsarchon81038 comments

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.

Thank you for clarifications, everyone (including Cyanogen himself). I've updated the article to reflect these.

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-pla... for more details

also because Google is part of the Open Screen Project 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 ;)

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.

Cached link: http://webcache.googleusercontent.com/search?q=cache:http://...

Scroll to the middle of the page for article.

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.

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?

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.

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).

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.

That is basically what JIT is. Why reinvent the wheel when they can use the resources that has been poured into JVM research?

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.)

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.

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/ incidentally! :)

>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).

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.

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.

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.

I still can't help feeling that the initial underpowered Android devices also did a lot of damage; I read so many reports of slow/jerky/unresponsive UI, and now have heard complaints from friends who bought recent (up to and including the HTC Incredible) Android phones about basic stuff like the phone app having performance issues, that the whole brand's a bit tainted at this point.

What Android needs, more than anything else, is a year or so of rock-solid performance from the popular devices, or else that bad reputation's really going to stick.

You hit the nail on the head. I bought the HTC Hero 6 months ago and it is really, really laggy at times. I wish I'd bought an iPhone. To insult to insury, HTC has been delaying updating it to 2.1 for months now, all whilst claiming that the update is 'ready in February/March/April/...'.

Yes, Apple behaves like a paranoid control freak, but they get stuff done.

From what I've heard, the 2.1 update for Hero is not HTC's fault, but Sprint's.

That said, HTC cranks out more Android phones than god, so I can imagine they'd potentially drop the ball on supporting old phones to get new ones to market, if it is indeed them with the holdup.

BTW, May 21st is the latest "release day" now.

I'm on T-Mobile Germany; is T-Mobile also dragging its heels?

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...

Who pushes updates? The carrier, handset maker, or Google? Or do hey all have to agree?

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.

maybe there's no data avail, but I wonder what the median update lag is from the time Google pushes out an OS update.

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.

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.

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.

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.

But then again a lot of the game code is similar pretty much to such benchmarking code - for example skinning, physics, collision detection, FFT.

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.

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?

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.

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

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.

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.

JIT, Flash, and defragmentation all in one release!?

Call me intrigued!

Reply on news.ycombinator.com