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

Comments

Another JVM

[BadAnalogyGuy]

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

Re:Another JVM

[Anonymous Coward]

There was a comment on one of the Android sites saying that a similar performance improvement was already in the Android tree but was too alpha-y to make it to any production builds.

Re:Another JVM

[martin-boundary]

That's a design flaw in the physics engine. 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.

Keep a list of dead objects, and refill the variables to resurrect whatever's needed. The initial cost of heap allocation can be amortized to nothing that way, for long running program components. As a result, the GC won't be needed, and your performance will be independent of the GC algorithm.

Re:Another JVM

[Vector7]

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

[Nadaka]

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

[WaywardGeek]

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

[Nadaka]

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

Re:Another JVM

[hey!]

There's nothing wrong with using Java on a resource constrained device. It works fine for most applications, although maybe not for realistic physics simulations.

Even relatively inattentive Java coding (with respect to constructing objects inadvertently) works fine for most things you'd want to do on a most devices you're likely to encounter. It's the usual thing, if you look at your code, only a tiny fraction of it tends to be performance critical.

Now I can't tell you how many hours I've spent dealing with messes created by crappy resource pooling implementations. The irony is that these were all classic examples of premature optimization. Competent programmers make things clear and correct first, then worry about fast. These incompetent implementations were from programmers who worried too much about the performance constraints of the platform and bent over backward trying to shoehorn in every optimization they could think of before ever getting a single jot of performance data. So they ended up with a buggy mess. After ripping all those optimizations out, including the resource pooling, I found that things ran *faster*, although that was less important than the fact the software was *correct*.

Now I agree that if I *were* writing something that had to be very fast (and something like a scientific simulation or cryptanalysis utility that can never be fast enough), and heap based object allocation and garbage collection were going to be a bottleneck, I'd choose something like C++ instead. It's purely a matter of optimizing programmer time either way. I don't want to have to waste my time worrying about optimization.

Slashvertisements ahoy!

[Monkeedude1212]

Towards thee I roll, thou all-destroying but unconquering Virtual Machine.

Behold

[eldavojohn]

The power of open source.

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

Re:Behold

[ScrewMaster]

Myriad's press release just sounds like Chuck Norris decided to dabble in software development

No, he gave Dalvik a roundhouse kick to the garbage collector.

Re:Behold

[WaywardGeek]

There are plenty of reasons a 3X speed improvement could be had. For example, optimizing memory layout for cache performace could do it. If one system had a heap that randomly scatters objects through memory, and the other packs like-fields of objects together in dense arrays, inner loop cache performace can be improved greatly. I saw a factor of 17X in one case. It's amazing to me how few programmers today bother getting down to this all-important performance bottleneck.

Turbo!

[TubeSteak]

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!

Kuchichaestli

[Pahroza]

Nur i de Schwiiz!

Hopp Schwiiz!

Re:Proof?

[binarylarry]

No, anyone following the Dalvik VM and android knows it was barely optimized out of the gate.

Google's team has said they are going to optimize the vm as development progresses.

Benoit Schillings is the Chuck Norris of code.

[Dr. Spork]

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.

Re:Benoit Schillings is the Chuck Norris of code.

[dozer]

You're thinking of Dominic Giampolo. Benoit wrote the App Kit and tons of good bits in the rest of BeOS but he didn't have much to do with the filesystem.

Well...

[msauve]

they are a founding member of the OHA, and claim to have 10% market share ("one out of ten phones in the market today") with their Jbed Java Mobile platform.

So, it's not like it's some startup with no experience in that market, trying to make a name for itself. In fact, they would seem to have more to lose than gain by making overzealous claims.

Re:Any technologically savvy want to enlighten me?

[Tacvek]

Google did not miss anything. They were well aware that Dalvik was largly unoptimized. They have been working on creating a JIT compiler for Dalvik, while this other company has been working on other improvements.

How to build a flawed API in Java...

[tlambert]

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

Re:How to build a flawed API in Java...

[GooberToo]

The absolute worst thing you can do in an object oriented language,

Perhaps you misunderstand the subject. Caching, memoizing, and/or object pools are all extremely common optimizations. On Android, its the ONLY way you're going to see a video game sustain reasonable FPS. End of discussion.

Its easy to re-initialize an object's state to allow for re-use after it has been instantiated. When the object's life is done, rather than free it, you simply return it to a pool. When a new object of that type is required, you re-initiate an existing instance, remove it from the pool, and return it. This way the object never needs to go through the garbage collector.

Even in languages without a garbage collector (C++), these optimizations are still fairly common and their use almost always increases performance. Additionally, their use in of themselves are never a bad idea unless the system you're on is extremely constrained by memory which prevents the creation of pools and/or caches.

Re:Java vs Objective C - is iPhone always faster?

[Lunix Nutcase]

You seem to be conflating VMs and runtime environments with JIT compilation. So according to your logic if I JIT compile C code it will somehow run slower than AOT compiled C code? How does that make any sense?

Re:Java vs Objective C - is iPhone always faster?

[jo42]

...you can always write the performance sensitive guts of your iPhone app in C or C++ if the Objective-C run time proves to be the bottleneck in your particular case. After all it is GCC that compiles the Obj-C/C/C++ code on that platform...

Just in Time Compiling

[AntiRush]

I imagine a big part of the speed increase comes from JIT - something that the current Dalvik implementation on Android doesn't do. There is, however, an experimental JIT branch. It would be nice to see how Myriad's stacks up to it. This test claims about a 3x increase in speed by enabling the existing JIT features.

Re:Java vs Objective C - is iPhone always faster?

[WaywardGeek]

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.

Java hardware acceleration was discarded

[kriston]

Java hardware acceleration was discarded by the Android platform.
Imagine if someone were to translate Dalvik into a bytecode that is compatible with the inbuilt Java acceleration of most mobile-market processors.
The fact that Android uses Dalvik instead of Java throws away an important hardware-based performance boost of native Java acceleration.