Swiss Firm Claims Boost In Android App Performance 132
Precision writes to inform us about the Swiss firm Myriad, which claims a 3x boost in Android app performance and longer battery life with a new virtual machine. Myriad says that its technology is 100% compatible with existing Android apps. "The tool is a replacement for the Dalvik virtual machine, which ships as part of the Android platform, and retains full compatibility with existing software. Dalvik Turbo also supports a range of processors including those based on ARM, Intel Atom, and MIPS Architectures."
Another JVM (Score:4, Insightful)
Gimme a break. *Every* JVM company out there claims to have the best performance.
Probably something to do with on the fly optimization of JITted code. Or maybe GC optimization and memory management.
It must be Press Release day here at /.
Behold (Score:5, Insightful)
How very very fortunate for everyone involved (unless the problem was the original Dalvik developer's sleep statements). The article is scant on details and the official press release is also very thin [myriadgroup.com]. My big question is whether or not we'll see this quickly adopted and rolled out by manufacturers who've already released Android. For me, assuming this is bug free, I'd like to see how my Motorolla Droid performs on Dalvik Turbo. Will it be as simple as swap image and reboot to switch between the two? Is anything lost in this transition?
At first glance I was certain that they had compiled and optimized the virtual machine to be specific to an architecture
Re:Another JVM (Score:3, Insightful)
That's called resource pooling, and for small objects it's a workaround for a shitty GC. Why bother using a language with garbage collection if working around the GC makes life more difficult than manual memory management? In C or C++ you can treat small objects (points/vectors] as values and let the language copy them transparently, much like Java does with primitive types, and you'd have the best of both worlds. On PCs, a generational GC can be fast enough to not to noticeably impact real-time animation. On a slower device like a phone that's likely not automatically true, and you might have to specially tune the GC, or use an incremental GC (which sacrifices overall throughput to reduce/eliminate delays), but then I always thought running Java on resource-constrained devices was a bit brain-damaged anyway.
Re:Another JVM (Score:3, Insightful)
Not really. This is actually one of the places that java has dramatically improved over the last decade. Most optimized VMs have a heap that uses stack like mechanisms that have reduced the real cost of instantiating an object to about 60 machine instructions vs c++ using 100 to 300. Also, because of how objects are arranged, recently created objects can be reclaimed at virtually no cost. I would link to a couple articles, but the bookmarts are at home and I am on my work machine.
Re:Another JVM (Score:4, Insightful)
I create objects in C with:
if(freePtr == NULL) {
allocateMoreObjects();
}
object = freePtr;
freePtr = freePtr->nextObject
Now that might be a few instructions, but nowhere near 60. Far more importantly, my objects are allocated out of contigous memory blocks, meaning that cache misses are far more likely to load objects into cache that will be accessed in inner loops. Many geeks still think in terms of machine cycles, rather than L2 cache misses. That's sooo last decade.
Re:Another JVM (Score:4, Insightful)
Not actually. Go back and read what I was saying. The JVM can create an object in its heap far faster than c++ can malloc. In the cases you are talking about, garbage collection in java is also practically free. Also, just because you can not put something on the stack does not mean that java can not do so for you. I made it home from work and have a reference for you.
http://www.ibm.com/developerworks/java/library/j-jtp09275.html