Slashdot Mirror
Swiss Firm Claims Boost In Android App Performance
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."
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 /.
The power of open source.
... allowing them to implement certain optimizations specific to each architecture. But I don't see any indication of that. Anyone know where the big speedup came from? Myriad's press release just sounds like Chuck Norris decided to dabble in software development ... they just looked at Android and it became three times faster.
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. 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
My work here is dung.
Back in my day, manufacturers used to slap a turbo button on the front of the case.
And we liked it that way.
Now get off my lawn!
[Fuck Beta]
o0t!
Check his wiki, this guy is the real deal. He is the architect of the BeOS file system, something that still hasn't been surpassed in flexibility and efficiency - the crown jewel of the BeOS code. Trolltech's QT also improved a lot under his reign. I would say that this guy knows a lot about writing optimized code, and Google should be very happy that he's turned his attention to Android. If I were Google, I'd be thinking hard about buying out this plucky little startup from Switzerland.
How to build a flawed API in Java...
If a library's performance depends strongly on GC performance, then the programmers should refactor their code to reuse existing objects rather than building new ones all the time.
The absolute worst thing you can do in an object oriented language, which is intended to be used in an object oriented way, is to instance objects without the instancing of them initializing them. The original Java Mail API did this, and it was a steaming pile because of that. I would probably go so far as to suggest that any object oriented language which permitted this was not designed correctly. To reuse the objects, you'd have to be able to reinitialize them, which is basically the same thing.
The typical problem with Java programs and garbage collectors is chasing force-zeroing of pages because they release the memory back to the system, and their security model requires that the memory be zeroed before it is reused by the program. Being a little bit time lazy about doing your GC to reclaim the memory on behalf of the system rather than on behalf of the program you are running almost always results in significant performance improvements in things like Physics engines. In other words, you want a little intentional latency between the time you collect the garbage, and the time you deliver it to the dump.
One of the most obvious recent offenders is Apache Lucene , specifically , which works just great, if you don't do the finalize() and cause the objects to be collected way too early.
So the problem usually boils down to a greedy garbage collector, which is a problem in the JVM, not the library code.
Of course on tiny platforms, the JVM footprint gets pretty large, so you'd also need to gather and LRU the freed heap to avoid it growing out of control from the latency; so you'd need a high water mark as well as a timed delay.
Personally, I really hate garbage collection as a paradigm, especially the garbage collection in Objective C. It claims to be optional, but isn't: as soon as you have one framework that doesn't do an explicit release of an object, your program is forever after addicted to the garbage collector, and slowly accumulates leaks which are "fixed" by the garbage collector, until what you have left is code you can't reuse without also doing garbage collection, infecting any project you bring it into.
-- Terry
Several things come to mind. First, my Nexus One, like the iPhone, burns about 85% of it's power on the display. If it weren't for the display, it could play music and keep the receiver active, and probably do a few more things and have the battery last for days. So, we're really only talking about the last 15%. Second, many applications run in compiled C, like webkit, the network stack, the map application, speech synthesis, 3D rendering, etc. These apps are going to probably be the similar on both phones in terms of efficiency. So, in Java, a lot of what we're really talking about is the code that pops up pretty windows. It's hard for me to imagine that takes much power.
I expect big advances in the future. Low power displays will be huge. After that, maybe we should revisit the JVM.
Celebrate failure, and then learn from it - Nolan Bushnell