3 ms·

In addition to OpenGL differences (which given how much the graphics hardware in these devices differs should probably be expected), 2.2 is going to be a really

In addition to OpenGL differences (which given how much the graphics hardware in these devices differs should probably be expected), 2.2 is going to be a really big compatibility break. 2.2 is the first OS version who's JVM (Dalvik) has a JIT compiler. The Android team is down-playing the performance gain, but benchmarks have shown that 2.1 Dalvik's performance is terrible and if the new Dalvik is even remotely competitive with other JIT-ing JVM's now, Android 2.1 and earlier are going to seem CPU-starved compared to Android going forward from 2.2. That's a good thing, if you can count on most (many?) handsets being upgraded to 2.2. That's unlikely, though.

alphamerik 16y ago
I have been using JIT on my ADP1 with 2.1, and it hasn't broken anything. Performance is great, 3.5mflops in linpack vs 2.4mflops. But I am confused, why do you think there is a compatibility break?
- CountSessine 16y ago
  A compatibility break in that if you program something with a heavy CPU burden like a bunch of image FFTs or belief networks (as many of us have done on iPhone), you can't rely on a pre-2.2 device to complete the task in a reasonable amount of time. For anything CPU intensive, do you recode it in java or do you keep limping along with the C++ NDK?
  - blocke 16y ago
    When you say "compatibility break" I hear "your 1.5 to 2.1 apps won't run on 2.2" not "2.2's increased performance enables a new class of applications that won't work on phones with an older OS". I'm not seeing the problem here...
    - CountSessine 16y ago
      For a developer targetting a new feature in a new release of the Android OS, it's a huge problem. If I want to make a program targetting a new feature in the iPhone OS, I can do that confident that 99% of all iPhones will be upgraded to $(CURRENT_OS_VERSION)+1 within a couple of months of the upgrade being available. It's simple. Everyone is on 3.1.3 - I don't have to worry about missing a big chunk of the market and reworking my code to accomodate old OS versions. So do I recode my FFTs in Java and say goodbye to anyone running pre-2.2 until the carriers/handset makers get around to upgrading everyone in a couple of years time, or do I keep my code in it's little C++ NDK ghetto, safe from testing and rapid enhancements that Java would bring? It's so frustrating that Google has fixed this problem NOW, but between carrier indifference and custom-'enhancement' inertia at handset makers, it's going to take forever for 2.2 to be a legitimate development target. This is a solved problem in iPhone-land.
      - alphamerik 16y ago
        So by compatibility break you mean that you are pissed that Android can run at any processor speed? I have news for you, in iPhone-land the phones in a couple years will be faster too. :)
blocke 16y ago
I've seen nothing indicating a compatibility break. Do you have any proof?
- ergo98 16y ago
  They seem to mean "because it's so much faster, it will make the slower ones looks worse", which is an odd idea for compatibility breakage. I suppose it means apps might start doing that much more, thus performing so bad on old devices that they become unusable.

alphamerik 16y ago

I have been using JIT on my ADP1 with 2.1, and it hasn't broken anything. Performance is great, 3.5mflops in linpack vs 2.4mflops. But I am confused, why do you think there is a compatibility break?

CountSessine 16y ago
A compatibility break in that if you program something with a heavy CPU burden like a bunch of image FFTs or belief networks (as many of us have done on iPhone), you can't rely on a pre-2.2 device to complete the task in a reasonable amount of time. For anything CPU intensive, do you recode it in java or do you keep limping along with the C++ NDK?
- blocke 16y ago
  When you say "compatibility break" I hear "your 1.5 to 2.1 apps won't run on 2.2" not "2.2's increased performance enables a new class of applications that won't work on phones with an older OS". I'm not seeing the problem here...
  - CountSessine 16y ago
    For a developer targetting a new feature in a new release of the Android OS, it's a huge problem. If I want to make a program targetting a new feature in the iPhone OS, I can do that confident that 99% of all iPhones will be upgraded to $(CURRENT_OS_VERSION)+1 within a couple of months of the upgrade being available. It's simple. Everyone is on 3.1.3 - I don't have to worry about missing a big chunk of the market and reworking my code to accomodate old OS versions. So do I recode my FFTs in Java and say goodbye to anyone running pre-2.2 until the carriers/handset makers get around to upgrading everyone in a couple of years time, or do I keep my code in it's little C++ NDK ghetto, safe from testing and rapid enhancements that Java would bring? It's so frustrating that Google has fixed this problem NOW, but between carrier indifference and custom-'enhancement' inertia at handset makers, it's going to take forever for 2.2 to be a legitimate development target. This is a solved problem in iPhone-land.
    - alphamerik 16y ago
      So by compatibility break you mean that you are pissed that Android can run at any processor speed? I have news for you, in iPhone-land the phones in a couple years will be faster too. :)

blocke 16y ago

I've seen nothing indicating a compatibility break. Do you have any proof?

ergo98 16y ago
They seem to mean "because it's so much faster, it will make the slower ones looks worse", which is an odd idea for compatibility breakage. I suppose it means apps might start doing that much more, thus performing so bad on old devices that they become unusable.