7 ms·

Google Acquires Android Performance Startup FlexyCore For A Reported $23 Million

40 points by sciwiz 13y ago

plackemacher 13y ago
I wish I could find more information about them. All I can find are videos showcasing the performance improvements but without any explanation. http://www.youtube.com/user/FlexyCore/videos http://www.youtube.com/user/FlexyCore/videos
- JonSkeptic 13y ago
  From what I can gather, it seems FlexyCore generates more efficient, architecture specific assembly code at build time. This is where the performance gains come from. A little deeper reading shows that it does this through the Dalvik VM, the VM on all Android devices. I think the creator can say it better than me: http://www.youtube.com/watch?v=tEAz9fRoDmA http://www.youtube.com/watch?v=tEAz9fRoDmA
  - nly 13y ago
    So basically it caches the native code produced by the Dalvik VM? I'm surprised Dalvik doesn't already do this.
    - JonSkeptic 13y ago
      Hopefully, it will now.
    - pjmlp 13y ago
      Dalvik's development has been stalled since Android 2.3, no new JIT or GC improvements since them. No more talks about it at Google IO, either. Of course, this is also related to the Oracle's suit against Google. I wonder if this means Google will reinvest in Dalvik, as I am betting KitKat will again only bring more Google APIs and nothing else.
    - ZeroGravitas 13y ago
      Sounds more like AOT compilation from Java to native code to me.
ihsw 13y ago
Lesson learned: create a compelling product for Android developers and Google will acquire you in a heartbeat.
leeoniya 13y ago
wonder if it's similar to Linaro Android [1] [1] http://www.youtube.com/watch?v=F_NR_goi6iA http://www.youtube.com/watch?v=F_NR_goi6iA
VeejayRampay 13y ago
French startup at that. Happy to see that there's at least some innovation going on in this country.
devx 13y ago
Hoping it will appear in Android 5.0. Six months or so should be enough to implement this, right? Also, they should probably acquire these guys, too: http://www.genymotion.com/ http://www.genymotion.com/ The emulator is also one of Android's longstanding problems, and it would be nice if they fixed that once and for all, too. I'm also hoping that with the arrival of powerful ARMv8 hardware in the couple of years, maybe they'll make their SDK for ARM, too, so it doesn't even need to be emulated in x86.
Zigurd 13y ago
This feels like an "acquhire." I haven't yet seen a performance booster get any traction with OEMs. This sounds more-promising than Myriad's idea of replacing the whole VM with their Java VM. Optimization in a battery powered device is tricky. After the initial work on Android's interesting JIT strategy, I have not heard much else about boosting performance. Developers who run into performance limits are stuck "doing it by hand" with native code and Renderscript. Maybe this signals a revival of interest in extracting better performance from Android's runtime environment.
- pjmlp 13y ago
  I certainly hope so. On iOS everything is native. Since Windows Phone 8, Microsoft also went fully native, by pre-compiling MSIL to native code on the Windows Store servers. The devices only have a linker to perform the last step of replacing the symbols by effective addresses on load.
  - Zigurd 13y ago
    Everything being native isn't always a better way. Android's architecture keeps code small, makes sure nobody eats the global heap, shares common bytecode (really, anything) pages across processes, and provides memory-conserving modularity tools within each VM instance's heap. It's a pretty elegant system and the reason there hasn't been a lot of new work on the JIT may be that the JIT is as good as it can be without eating more battery.
    - pjmlp 13y ago
      > Android's architecture keeps code small, makes sure nobody eats the global heap, shares common bytecode (really, anything) pages across processes, and provides memory-conserving modularity tools within each VM instance's heap. Global heap can be controlled by process in many OS, nothing special about VMs. Sharing of code pages between processes has been done in mainstream OS since a few decades. Memory-conserving modularity tools, whatever that might be, aren't VM specific. The only issue you are right about, is that bytecode is much more compact than native code. > ... the reason there hasn't been a lot of new work on the JIT may be that the JIT is as good as it can be without eating more battery. The current JIT is good enough for developers writing CRUD applications, HTML wrappers or the "fart app" of the month. Those of us that care about performance use the NDK anyway.

40 points by sciwiz 13y ago

I wish I could find more information about them. All I can find are videos showcasing the performance improvements but without any explanation. http://www.youtube.com/user/FlexyCore/videos http://www.youtube.com/user/FlexyCore/videos

JonSkeptic 13y ago
From what I can gather, it seems FlexyCore generates more efficient, architecture specific assembly code at build time. This is where the performance gains come from. A little deeper reading shows that it does this through the Dalvik VM, the VM on all Android devices. I think the creator can say it better than me: http://www.youtube.com/watch?v=tEAz9fRoDmA http://www.youtube.com/watch?v=tEAz9fRoDmA
- nly 13y ago
  So basically it caches the native code produced by the Dalvik VM? I'm surprised Dalvik doesn't already do this.
  - JonSkeptic 13y ago
    Hopefully, it will now.
  - pjmlp 13y ago
    Dalvik's development has been stalled since Android 2.3, no new JIT or GC improvements since them. No more talks about it at Google IO, either. Of course, this is also related to the Oracle's suit against Google. I wonder if this means Google will reinvest in Dalvik, as I am betting KitKat will again only bring more Google APIs and nothing else.
  - ZeroGravitas 13y ago
    Sounds more like AOT compilation from Java to native code to me.

ihsw 13y ago

Lesson learned: create a compelling product for Android developers and Google will acquire you in a heartbeat.

leeoniya 13y ago

wonder if it's similar to Linaro Android [1] [1] http://www.youtube.com/watch?v=F_NR_goi6iA http://www.youtube.com/watch?v=F_NR_goi6iA

VeejayRampay 13y ago

French startup at that. Happy to see that there's at least some innovation going on in this country.

devx 13y ago

Hoping it will appear in Android 5.0. Six months or so should be enough to implement this, right? Also, they should probably acquire these guys, too: http://www.genymotion.com/ http://www.genymotion.com/ The emulator is also one of Android's longstanding problems, and it would be nice if they fixed that once and for all, too. I'm also hoping that with the arrival of powerful ARMv8 hardware in the couple of years, maybe they'll make their SDK for ARM, too, so it doesn't even need to be emulated in x86.

Zigurd 13y ago

This feels like an "acquhire." I haven't yet seen a performance booster get any traction with OEMs. This sounds more-promising than Myriad's idea of replacing the whole VM with their Java VM. Optimization in a battery powered device is tricky. After the initial work on Android's interesting JIT strategy, I have not heard much else about boosting performance. Developers who run into performance limits are stuck "doing it by hand" with native code and Renderscript. Maybe this signals a revival of interest in extracting better performance from Android's runtime environment.

pjmlp 13y ago
I certainly hope so. On iOS everything is native. Since Windows Phone 8, Microsoft also went fully native, by pre-compiling MSIL to native code on the Windows Store servers. The devices only have a linker to perform the last step of replacing the symbols by effective addresses on load.
- Zigurd 13y ago
  Everything being native isn't always a better way. Android's architecture keeps code small, makes sure nobody eats the global heap, shares common bytecode (really, anything) pages across processes, and provides memory-conserving modularity tools within each VM instance's heap. It's a pretty elegant system and the reason there hasn't been a lot of new work on the JIT may be that the JIT is as good as it can be without eating more battery.
  - pjmlp 13y ago
    > Android's architecture keeps code small, makes sure nobody eats the global heap, shares common bytecode (really, anything) pages across processes, and provides memory-conserving modularity tools within each VM instance's heap. Global heap can be controlled by process in many OS, nothing special about VMs. Sharing of code pages between processes has been done in mainstream OS since a few decades. Memory-conserving modularity tools, whatever that might be, aren't VM specific. The only issue you are right about, is that bytecode is much more compact than native code. > ... the reason there hasn't been a lot of new work on the JIT may be that the JIT is as good as it can be without eating more battery. The current JIT is good enough for developers writing CRUD applications, HTML wrappers or the "fart app" of the month. Those of us that care about performance use the NDK anyway.