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

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

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.

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!

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