Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
Cellphones Java

Swiss Firm Claims Boost In Android App Performance 132

Posted by kdawson
from the sixty-fps-here-we-come dept.
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."
This discussion has been archived. No new comments can be posted.

Swiss Firm Claims Boost In Android App Performance

Comments Filter:
  • Another JVM (Score:4, Insightful)

    by BadAnalogyGuy (945258) <BadAnalogyGuy@gmail.com> on Tuesday February 09, 2010 @05:55PM (#31079494)

    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: (Score:2, Interesting)

      by Anonymous Coward

      There was a comment [androidcommunity.com] 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.

    • Does this imply that on more or less identical hardware (latest ARM + similar battery), the iPhone will always run apps faster and will always have better battery life than an Android phone?

      If JIT produces such a noticeable performance boost, does that suggest that the difference between next-gen Android and iPhone will be negligible, or will there always be a significant gap? And if the gap will remain significant, should we care?

      • by outZider (165286)

        It really depends on the operation and the code being run -- bad code is bad code, after all -- but in general, yes. Native code is generally(eight thousand asterisks here) faster than VM/Sandboxed/JITd/whatever code.

        • Re: (Score:3, Informative)

          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?

          • by outZider (165286)

            I've never seen a JIT C compiler, so I can't fairly answer your question. That said, JIT still means there's a step before execution, so likely, yes.

            • I've never seen a JIT C compiler, so I can't fairly answer your question.

              Then you haven't looked very hard.

              That said, JIT still means there's a step before execution, so likely, yes.

              Huh? JITing effects start-up time not execution time.

              • Huh? JITing effects start-up time not execution time.

                Huh? JIT means 'Just In Time'. Compilation does not just happen at startup time, but during execution as well. Advanced JITs (like Sun's hotspot compiler) continuously perform a statistical analysis of where compiled code might make a difference.

      • objective c is compiled BUT sending a message / calling a method goes through a runtime system which allows all kinds of awesome shit but is slower than a direct function call or an indirection table ala C++ virtual functions. Best case, compiled java could beat objective c by flattening out method calls.
        • by jo42 (227475) on Tuesday February 09, 2010 @07:05PM (#31080232) Homepage

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

          • by Dog-Cow (21281)

            Actually, C and ObjC use the LLVM compiler now. I think C++ still uses gcc.

            • By default they still use gcc though there is an option to use clang (llvm-g++ for c++) or llvm-gcc.
            • by cbhacking (979169)

              LLVM is a compiler back-end; it takes low-level instructions and emits assembly. You still need a front end to turn the source into low-level instructions. GCC can do this, for any language that it has a front-end for (lots), and the result is portable to anything LLVM runs on. GCC is actually pretty widely used for this. Clang is a newer compiler, built specifically to use LLVM for the back-end. It may be what you're thinking of, especially since its C++ front-end is still very much a work-in-progress (C i

      • by WaywardGeek (1480513) on Tuesday February 09, 2010 @08:29PM (#31080954) Journal

        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.

      • by GooberToo (74388)

        Does this imply that on more or less identical hardware (latest ARM + similar battery), the iPhone will always run apps faster and will always have better battery life than an Android phone?

        From a performance perspective, no. Android can run native code should a developer decide he wishes to do so.

        As for battery life, maybe. As newer devices come out their efficiency is likely to continue to improve but Android devices always have more work to do because they are more capable devices. This extra capability comes from their native ability to multitask. Included in their ability to multitask is the ability to run applications in the background. This has the effect of a perceived reduction in bat

    • by Tumbleweed (3706) *

      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.

      I don't believe the Dalvik _does_ the JIT.

      • by dumael (1172411)
        Google are currently implementing a JIT for Dalvik. I don't have any experience using it though, as I've been hacking on the garbage collector.
  • by Monkeedude1212 (1560403) on Tuesday February 09, 2010 @05:57PM (#31079530) Journal

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

    • It definitely looks like an advertisement. I was hoping to see some kind of technical comparison where you can see a video demonstrating the differences... nope.. just junk

  • Behold (Score:5, Insightful)

    by eldavojohn (898314) * <eldavojohn@nOsPam.gmail.com> on Tuesday February 09, 2010 @05:58PM (#31079534) Journal
    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 [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 ... 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.
    • by Dr. Spork (142693) on Tuesday February 09, 2010 @06:27PM (#31079872)
      Check his wiki [wikipedia.org], 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.
      • by dozer (30790) on Tuesday February 09, 2010 @06:44PM (#31080038)

        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.

      • by robi5 (1261542)
        Having RTFA it is curious that he is involved with Nokia. Why does the CTO of a large handset maker helps out an emerging large handset provider and its handset making subcontractor, i.e. its competitors?
    • Re:Behold (Score:4, Funny)

      by ScrewMaster (602015) * on Tuesday February 09, 2010 @06:28PM (#31079892)

      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: (Score:1, Interesting)

      by Anonymous Coward

      The question is... is Google going to accept the new VM? Or is this going to be a fork of the original code?

    • they just looked at Android and it became three times faster.

      Is that the power of open source? ;)

      Seriously. "Believe it when I see it" seems to be more the power of open source. If it works, awesome. If not, it's just hype.. open source or closed source..

    • by HotBBQ (714130)
      At work when we switched to Java 6 when it came out our application (electronic surveillance data fusion) saw an 11% speed boost. Apparently the Java 6 JVM had tweaks to double and long primitive handling, which we utilized heavily. My point being it doesn't necessarily have to do with how it is compiled.
    • Re: (Score:3, Interesting)

      by WaywardGeek (1480513)

      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.

  • JIT produces similar improvements in the Google JVM, although it is not currently turned on.

    JIT is indeed faster. I am not shocked that a Googleplex full of PhDs is already moving in this direction. Google details are at http://groups.google.com/group/android-platform/browse_thread/thread/331d5f5636f5f532?pli=1 [google.com]
    • by Tacvek (948259)

      Is there any reason to think the two approaches are mutually exclusive? If like many people think, this involves improvements to the garbage collector, then some of those improvements may well still apply to the JIT, which from the sound of it may have hardly touched the garbage collector at all.

  • Turbo! (Score:5, Funny)

    by TubeSteak (669689) on Tuesday February 09, 2010 @06:00PM (#31079574) Journal

    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!

    • by pclminion (145572)
      One of my favorite things to do (yes, I'm weird) was hammer on that button as the system was trying to POST. Most BIOSes did not handle this very well at all. They would fail in all manner of hilarious ways.
    • by Tumbleweed (3706) *

      Back in my day, manufacturers used to slap a turbo button on the front of the case.
      And we liked it that way.

      There's an app for that.

      Now get off my lawn!

      And for that.

  • Kuchichaestli (Score:3, Interesting)

    by Pahroza (24427) on Tuesday February 09, 2010 @06:15PM (#31079728)

    Nur i de Schwiiz!

    Hopp Schwiiz!

  • Writing up a blurb saying you have something is one thing.... show us some proof, numbers,... something other than
    a claim that you have something.
    I am sure Google went over performance and if it could be made to perform better it would have been done. (I Hope... Google?)
    I can say I have a million dollars, does not mean I do.

    • Re: (Score:2, Informative)

      by binarylarry (1338699)

      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.

  • As I understand it, Dalvik is basically Java, mostly. Sun has, for a long while now; been chipping away at the problem of making Java perform well. For whatever reason, Java applets never seemed to receive any benefit, and have always felt horribly slow; but Java has seen enormous use in both Big Serious Corporate Iron applications and in tiny, embedded dumphone applications. Much of that development has been in the open, either directly OSS or at least visible in comp-sci papers and talks and such.

    Then
    • The claim is not that Google's version of the JavaVM is 3x faster than any other.. But rather that this implmentation of the Google version of the JavaVM is 3x faster than default which is still not saying all that much given the performance issues across the board on androids VM.
    • by Tacvek (948259) on Tuesday February 09, 2010 @06:55PM (#31080138) Journal

      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.

    • by Fnord (1756)

      There was some untapped optimization-fu. Its called JIT. See, google wrote Dalvik, not to be faster than standard java, but to enable a bunch of multi-process memory sharing techniques that aren't possible with standard java. What they didn't do is ever implement a just in time compiler. In fact in ever test done, Dalvik performs as well as Sun Java without JIT enabled, which is vastly slower than with JIT. Their comment at the time was that "maybe we'll implement JIT for Dalvik 2.0". Assuming Dalvik

      • Android 2.0 does support JIT (as an experimental feature) - disabled by default. It is still way too buggy though to be used by general public.
        • by Fnord (1756)

          Oh really, I didn't realize that happened. That's actually pretty cool then, it means there's progress. The brush off google gave when asked about JIT made me think it'd never happen.

    • Re: (Score:1, Troll)

      by codepunk (167897)

      The concept is rather simple actually, everyone tells us that java is as fast as C. This will make it three times faster than C...how cool is that?

      • You can't directly compare Java and C because they're different in practically every way.

        In this case, n "Dalvik Turbo JIT" is 3 times faster than the purely interpreted dalvik VM shipping with android phones.

        The JIT version produces code similar to that generated by a C compiler in some ways (native instructions).

    • by DrXym (126579)
      Dalvik isn't a JVM. It's similar to a JVM but Java byte code is translated during the build phase into a different intermediate byte code. Dalvik byte code is a register oriented code compared to the stack oriented code in the JVM. The runtime sits on top

      It's also fairly nascent and I wouldn't be surprised if there is plenty of room for improvement.

  • Why would this be needed? Everyone tells me java is twice as fast as C? This must make it three times faster than C, impressive.

    • That's in reference to the standard, desktop JVMs which are indeed very very fast. But the Dalvik JVM used by Android devices is completely unrelated to them and, importantly, does not yet have a just-in-time compiler. That makes it much slower than native code.

      That's not due to any fundamental limitation. In fact, they are hard at work on creating a JIT for Dalvik [google.com]. It just hasn't been released yet. Once it is, Android applications should become several times faster.
    • by paul248 (536459)

      Interpreted Java is pretty much always slower than C. Java with a JIT has the potential to be faster than C. That's why they're implementing a JIT.

  • by AntiRush (1175479) on Tuesday February 09, 2010 @08:21PM (#31080890) Homepage
    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 [google.com] claims about a 3x increase in speed by enabling the existing JIT features.
  • by kriston (7886) on Tuesday February 09, 2010 @10:49PM (#31081850) Homepage Journal

    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.

    • by pddo (969282)
      Or is it really not java? Sun/Oracle may be seeing google in court soon over that one...
  • This project looks like it opens the door for a real JVM that runs real Java apps, real Java bytecode, not the Dalvik bytecode that has to be developed for specifically the Android platform. With a real JVM, some Java bytecode already available for download could just work, and porting a lot of the rest should be a lot easier. Which would open up a much larger existing community of developers to target these devices with apps.

    • you can already run "real" java bytecode on android. you can import any JAR into an android app and use it ... with the assumption that the interfaces used by the imported code are implemented in android (android implements a large portion of the JDK).

      what you can't do is make use of any "real" java app UI. you will never be able to do that as android doesn't support swing or any other standard java UI paradigm.

      • by Doc Ruby (173196)

        The Dalvik JVM runs regular Java bytecode? And regular .java code compiles to run on the Dalvik JVM. So what's the difference between the Dalvik JVM and any other one, except the specific code that implements it?

        Are there any open-source implementations of the Swing or other standard Java GUI class libraries, that could be compiled into a JAR, statically linked, and delivered along with the Java app to run on Android under the Dalvik JVM?

        • The Dalvik JVM runs regular Java bytecode?

          yes. it's not the "dalvik JVM", it's dalvik VM. the difference is that it's not a java standard VM. android uses the java language but it is not run on a java VM.

          And regular .java code compiles to run on the Dalvik JVM.

          if you mean to say you can compile using a java standard VM and run on the dalvik VM, then yes ... as long as you are only compiling that subset of the JDK that the dalvik VM understands.

          i don't think there is any guarantee of that ... but i assume it's going to stay that way as it allows android developers to piggy pack on the large amount of java

          • by Doc Ruby (173196)

            The VM, whether JVM or Dalvik VM, doesn't know how to execute Swing libraries, or any other libraries. That's the point of libraries: they're just code for some machine (virtual or otherwise) to execute. So if the Swing GUI library is statically linked into the same JAR as the application, the J/VM has all the bytecode to execute.

            If the Dalvik VM can run the same bytecode files that a JVM can run, and the same .java files can be compiled into that same bytecode, then how is the Dalvik VM different from a st

            • The VM, whether JVM or Dalvik VM, doesn't know how to execute Swing libraries, or any other libraries. That's the point of libraries: they're just code for some machine (virtual or otherwise) to execute. So if the Swing GUI library is statically linked into the same JAR as the application, the J/VM has all the bytecode to execute.

              in the library uses an "instruction set" that the VM doesn't understand, it won't run obviously. it dalvik doesn't implement the instructions related to the swing GUI, it can't execute those. swing isn't like an implementation of a list. the VM hasn't to bridge to the native OS to be able to do things like draw widgets into a graphics window.

              I can't see anyone else saying that the Dalvik VM can run Java bytecode. Only that it runs .dex binaries [wikipedia.org], which are not Java bytecode. Lots of people are saying [google.com] that it doesn't run Java bytecode.

              let me quote from the wikipedia page on the dalvik VM,

              "A tool called dx is used to convert Java .class files into the .dex format. Multiple classes are included in a si

              • by Doc Ruby (173196)

                OK. It's becoming clear to me that you don't really know what you're talking about. You're repeating what you read in the Wikipedia article, and inferring wrong guesses about it.

                If a Java bytecode file requires conversion at all to run on the Dalvik VM, then the Dalvik VM doesn't run Java bytecode. That is not a trivial difference. If I distribute Java bytecode, it will not run on the Dalvik VM. Nearly no one using an Android device is going to go through that coversion process, certainly not enough for a S

                • If a Java bytecode file requires conversion at all to run on the Dalvik VM, then the Dalvik VM doesn't run Java bytecode.

                  sigh. in my first post, i said android can run third party JARs, not dalvik can run JavaVM bytecode. i should have said "use" not "run", sorry. no you can't just copy the JAR onto the phone and run it obviously. from a developer's perspective, it doesn't matter. you import a JAR into your android app project and it works.

                  i agreed with what you said in your last post if you care to read it. you made a silly assumption about being able to port swing to android. i am sorry about that, but you said it.

                  i don't k

No one gets sick on Wednesdays.

Working...