Swiss Firm Claims Boost In Android App Performance

← Back to Stories (view on slashdot.org)

Swiss Firm Claims Boost In Android App Performance

Posted by kdawson on Tuesday February 9, 2010 @10:53AM 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."

132 comments

Min score:

Reason:

Sort:

Another JVM by BadAnalogyGuy · 2010-02-09 10:55 · 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 /.
1. Re:Another JVM by Anonymous Coward · 2010-02-09 10:57 · Score: 2, Interesting
  
  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.
2. Re:Another JVM by Anonymous Coward · 2010-02-09 11:01 · Score: 0
  
  To be honest the GC on the standard Android handsets is so poor any improvement is a good thing. If the GC is better then it will increase the performance of libraries such as JBox2D and other physics libraries since most generate alot of garbage.
3. Re:Another JVM by binarylarry · 2010-02-09 11:04 · Score: 1
  
  It'd be great if you could allocate values on the stack with Java.
  Heap only allocation of objects really hurts performance for physicsy stuff and other types of calculations that create a lot of garbage.
  
  --
  Mod me down, my New Earth Global Warmingist friends!
4. Re:Another JVM by martin-boundary · 2010-02-09 11:18 · Score: 2, Informative
  
  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.
5. Re:Another JVM by fredrik70 · 2010-02-09 11:23 · Score: 1
  
  to be fair, all primitive types like int, float, etc are stored on the stack and not the heap, only objects are
  
  --
  if (!signature) { throw std::runtime_error("No sig!"); }
6. Re:Another JVM by Vector7 · 2010-02-09 11:38 · Score: 2, 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.
7. Re:Another JVM by Tumbleweed · 2010-02-09 12:03 · Score: 1
  
  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.
8. Re:Another JVM by Brian+Feldman · 2010-02-09 12:04 · Score: 1
  
  to be fair, all primitive types like int, float, etc are stored on the stack and not the heap, only objects are
  Mostly wrong. That is true only if they are stack variables rather than class or instance variables, and only if they are not arrays (which are also primitives). Everything else is a reference to a heap object.
  
  --
  Brian Fundakowski Feldman
9. Re:Another JVM by Nadaka · 2010-02-09 12:05 · Score: 2, 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.
10. Re:Another JVM by binarylarry · 2010-02-09 12:14 · Score: 1
  
  Actually wrong, reclaiming memory is done automatically when the stack frame goes away. So if a given variable only exists within the stack frame, it's going to be smarter to allocate on the stack than the heap.
  
  --
  Mod me down, my New Earth Global Warmingist friends!
11. Re:Another JVM by WaywardGeek · 2010-02-09 13:21 · Score: 3, 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.
  
  --
  Celebrate failure, and then learn from it - Nolan Bushnell
12. Re:Another JVM by Nadaka · 2010-02-09 13:32 · Score: 3, 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
13. Re:Another JVM by Anonymous Coward · 2010-02-09 13:42 · Score: 0
  
  The heap is not nearly as expensive in Java as it is in C, it's basically just a pointer bump in the young gen, same mechanism as the stack really. The stack wins in some cases because it can't get fragmented. Modern JVMs do escape analysis and they will use the stack if they can.
14. Re:Another JVM by binarylarry · 2010-02-09 15:06 · Score: 1
  
  Thanks for the link, but you really ought to research what you wrote, it's very, very incorrect.
  Tips: Learn the difference between stack and heap, learn what malloc does, learn that garbage collection is never, ever free
  Yes, jvms are starting to do escape analysis but OpenJDK ~6 and Dalvik don't.
  
  --
  Mod me down, my New Earth Global Warmingist friends!
15. Re:Another JVM by Nadaka · 2010-02-09 15:57 · Score: 1
  
  No its not incorrect, you are just reading into it things that just are not there. I know the difference between stack and heap. I am not saying that heap faster than the stack or that the two are the same. I am saying that underneath the hood java does not exclusively use the heap for objects (for some JVMs) and in the standard case where it does use the heap, it is vastly more efficient than most people assume (faster than c/c++ use of the heap).
  That article is 5 years old and JVM's have been using escape analysis for a long time.
16. Re:Another JVM by dumael · 2010-02-09 16:06 · Score: 1
  
  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.
17. Re:Another JVM by CaptnMArk · 2010-02-09 20:36 · Score: 1
  
  IME, GC can only be faster if you can afford to 2x the RAM (physical, because virtual more or less doesn't work for GC, unlike malloc/free) and you have problems with fragmentation in malloc/free program (but going to 2x RAM will more or less solve it there too).
  Please don't say that GC allocation is fast without accounting for freeing too, otherwise you are just moving the bottleneck where it cannot be easily accounted for.
18. Re:Another JVM by Anonymous Coward · 2010-02-09 20:38 · Score: 0
  
  ah, yes, was only talking about creating and passing primitives around. Of course in classes they will end up on the heap.
  Well, that'sthe good thing with c# where you can have simple structs and keep them off the heap
19. Re:Another JVM by Astrath · 2010-02-10 01:14 · Score: 1
  
  3x performance increase sounds entirely reasonable, I guess they are using this magic thing called JIT. I still can't wrap my head around the fact that Google to this day has the most basic, worst garbage collector in the whole wide world of virtual machines, and doesn't seem to care about performance. But as has already been mentioned here, they are at least working on a JIT compiler. Just seems to take them forever. And while you are at it Google, why not at add an incremental garbage collector or however this thing is called. And how about introducing a stack for temporary objects, so not every time I do: drawString("Score: " + score); the garbage collector kicks in and freezes the whole app for 200ms?
20. Re:Another JVM by hey! · 2010-02-10 02:30 · Score: 3, Informative
  
  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.
  
  --
  Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
21. Re:Another JVM by SaltedBliss · 2010-02-10 06:58 · Score: 1
  
  The author should be more specific as to the developer name, Myriad Group. The JVM is not likely to be available for general download real soon, but I'm certainly willing to experiment with it on Moto Droid when it is.
  
  --
  SaltedBliss Salt Lake City, UT
22. Re:Another JVM by AndrewStephens · 2010-02-11 13:05 · Score: 1
  
  Ummm, what happens when you need to deallocate objects?
  The advantage Java has over C/C++ is that it can do pretty much what you describe while maintaining the ability to reclaim memory when objects are no longer needed. An old style heap requires extra accounting overhead to allow for deallocations - something your example doesn't include.
  
  --
  sheep.horse - does not contain information on sheep or horses.
23. Re:Another JVM by Lally+Singh · 2010-02-17 11:50 · Score: 1
  
  This was introduced with Java 1.6 update 10. If the compiler notices that the object isn't passed outside of a function (called escape analysis), it'll be allocated on its stack.
  
  --
  Care about electronic freedom? Consider donating to the EFF!
Slashvertisements ahoy! by Monkeedude1212 · 2010-02-09 10:57 · Score: 2, Funny

Towards thee I roll, thou all-destroying but unconquering Virtual Machine.
1. Re:Slashvertisements ahoy! by joocemann · 2010-02-09 13:37 · Score: 1
  
  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 by eldavojohn · 2010-02-09 10:58 · Score: 4, Insightful

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.

--
My work here is dung.
1. Re:Behold by ScrewMaster · 2010-02-09 11:28 · Score: 3, Funny
  
  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.
  
  --
  The higher the technology, the sharper that two-edged sword.
2. Re:Behold by Anonymous Coward · 2010-02-09 11:30 · Score: 1, Interesting
  
  The question is... is Google going to accept the new VM? Or is this going to be a fork of the original code?
3. Re:Behold by Anonymous Coward · 2010-02-09 11:34 · Score: 0
  
  apparently (and unsurprisingly) they have something similar in the pipeline for an update already.
4. Re:Behold by CannonballHead · 2010-02-09 11:40 · Score: 1
  
  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..
5. Re:Behold by HotBBQ · 2010-02-09 11:56 · Score: 1
  
  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.
6. Re:Behold by WaywardGeek · 2010-02-09 13:35 · Score: 2, Interesting
  
  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.
  
  --
  Celebrate failure, and then learn from it - Nolan Bushnell
Blah. by James_Duncan8181 · 2010-02-09 10:59 · Score: 1

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

--
"To any truly impartial person, it would be obvious that I am right."
1. Re:Blah. by Tacvek · 2010-02-09 11:53 · Score: 1
  
  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.
  
  --
  Stylish sheet to fix many problems in Slashdot's D3: https://gist.github.com/801524
Turbo! by TubeSteak · 2010-02-09 11:00 · Score: 4, Funny

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!
1. Re:Turbo! by Anonymous Coward · 2010-02-09 11:14 · Score: 0
  
  and nobody turned it off ever, so we have know idea if it actually worked, but we liked it that way....
  Now get off my lawn.
2. Re:Turbo! by pclminion · 2010-02-09 11:16 · Score: 1
  
  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.
3. Re:Turbo! by Anonymous Coward · 2010-02-09 11:18 · Score: 0
  
  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!
  i remember the turbo button!
  i was convinced it did something.. :(
4. Re:Turbo! by martin-boundary · 2010-02-09 11:23 · Score: 1
  
  Not true! You had to turn it off if you wanted to play Buck Rogers Planet of Zoom
5. Re:Turbo! by WinterSolstice · 2010-02-09 11:23 · Score: 1
  
  I used to play Sopwith - and yes, it worked. That plane is impossible to control if you're running above about 12MHz :)
  
  --
  An operating system should be like a light switch... simple, effective, easy to use, and designed for everyone.
6. Re:Turbo! by fredrik70 · 2010-02-09 11:25 · Score: 1
  
  oooh, I remember my mate's 486DX2, with turbo 66MHz, without 33, all neatly displayed on a little LED panel on the front, ah, those where the days.....
  Where're my slippers...?
  
  --
  if (!signature) { throw std::runtime_error("No sig!"); }
7. Re:Turbo! by Anonymous Coward · 2010-02-09 11:42 · Score: 0
  
  Not true! I had a program to slow the computer down to whatever speed I wanted to.
8. Re:Turbo! by Tumbleweed · 2010-02-09 12:06 · Score: 1
  
  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.
9. Re:Turbo! by ircmaxell · 2010-02-09 12:11 · Score: 1
  
  I remember that! The goslow DOS command...
  
  I find it quite ironic that a 16mhz 80286 processor was "too fast" for some programs, and required a cpu scaling program to slow the effective cpu speed to run correctly... It puts things into perspective to think that 16mhz was "too fast" at one point in time...
  
  --
  If a man isn't willing to take some risk for his opinions, either his opinions are no good or he's no good
10. Re:Turbo! by IMightB · 2010-02-09 12:23 · Score: 1
  
  I still have my 486 case, with the turbo button. The backside of the button has a dense set of jumpers that with a little (a lot) of dicking around you could make it say 00-99 for each speed (button on/off).
11. Re:Turbo! by amRadioHed · 2010-02-09 12:56 · Score: 1
  
  It was only too fast because of poor programming practices. They assumed a certain MHz processor and so faster CPUs threw off their timing.
  
  --
  We hope your rules and wisdom choke you / Now we are one in everlasting peace
12. Re:Turbo! by Anonymous Coward · 2010-02-09 13:04 · Score: 0
  
  I thought this joke was a repeat.. checked, yes.
13. Re:Turbo! by Anonymous Coward · 2010-02-09 15:23 · Score: 0
  
  sudo apt-get install sopwith
  you too can play again
14. Re:Turbo! by some_guy_88 · 2010-02-09 17:00 · Score: 1
  
  Do elaborate.
15. Re:Turbo! by hufman · 2010-02-09 17:44 · Score: 1
  
  Where does it install the Turbo button?
Re:faster slow is still slow shit by binarylarry · 2010-02-09 11:06 · Score: 1

droid does?

--
Mod me down, my New Earth Global Warmingist friends!
Java vs Objective C - is iPhone always faster? by Rob+Y. · 2010-02-09 11:09 · Score: 1

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?

--
Posted from my Android phone. Oh, I can change this? There, that's better...
1. Re:Java vs Objective C - is iPhone always faster? by outZider · 2010-02-09 11:28 · Score: 1
  
  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.
  
  --
  - oZ
  // i am here.
2. Re:Java vs Objective C - is iPhone always faster? by larry+bagina · 2010-02-09 11:45 · Score: 1
  
  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.
  
  --
  Do you even lift?
  These aren't the 'roids you're looking for.
3. Re:Java vs Objective C - is iPhone always faster? by Anonymous Coward · 2010-02-09 11:51 · Score: 0
  
  Native code is generally(eight thousand asterisks here) faster than VM/Sandboxed/JITd/whatever code.
  This sentence makes no sense. A JIT compiler produces compiled native code. So how can native code run faster than.... native code?
4. Re:Java vs Objective C - is iPhone always faster? by Lunix+Nutcase · 2010-02-09 11:57 · Score: 2, 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?
5. Re:Java vs Objective C - is iPhone always faster? by jo42 · 2010-02-09 12:05 · Score: 3, Informative
  
  ...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...
6. Re:Java vs Objective C - is iPhone always faster? by binarylarry · 2010-02-09 12:15 · Score: 1
  
  Shhh, he's a PHP codah and you're just going to confuse him.
  
  --
  Mod me down, my New Earth Global Warmingist friends!
7. Re:Java vs Objective C - is iPhone always faster? by Dog-Cow · 2010-02-09 12:42 · Score: 1
  
  Actually, C and ObjC use the LLVM compiler now. I think C++ still uses gcc.
8. Re:Java vs Objective C - is iPhone always faster? by outZider · 2010-02-09 13:28 · Score: 1
  
  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.
  
  --
  - oZ
  // i am here.
9. Re:Java vs Objective C - is iPhone always faster? by WaywardGeek · 2010-02-09 13:29 · Score: 4, Interesting
  
  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
10. Re:Java vs Objective C - is iPhone always faster? by Lunix+Nutcase · 2010-02-09 13:59 · Score: 1
  
  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.
11. Re:Java vs Objective C - is iPhone always faster? by egomaniac · 2010-02-09 15:06 · Score: 1
  
  This sentence makes no sense. A JIT compiler produces compiled native code. So how can native code run faster than.... native code?
  That's like saying "assembly code shouldn't be faster than C++ code, since they both end up as machine code". Generally speaking, the closer to the metal a language is, the more performance you can squeeze out of it. That's not to say that assembly is automatically faster than C, which is automatically faster than Java... but ninety-nine times out of a hundred a well-coded assembly program will be faster than the equivalent well-coded C program, which will in turn be faster than the equivalent well-coded Java program.
  Modern JVMs and CPUs are fast enough that most of the time the difference isn't a big deal, just as modern C compilers are fast enough that we seldom bother with assembly anymore. But to argue that "there shouldn't be a difference because it's all just machine code anyway" is clearly absurd.
  
  --
  ZFS: because love is never having to say fsck
12. Re:Java vs Objective C - is iPhone always faster? by larry+bagina · 2010-02-09 15:15 · Score: 1
  
  By default they still use gcc though there is an option to use clang (llvm-g++ for c++) or llvm-gcc.
  
  --
  Do you even lift?
  These aren't the 'roids you're looking for.
13. Re:Java vs Objective C - is iPhone always faster? by Anonymous Coward · 2010-02-09 17:21 · Score: 0
  
  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.
  You know officially don't know what you're talking about.
14. Re:Java vs Objective C - is iPhone always faster? by NoOneInParticular · 2010-02-09 18:59 · Score: 1
  
  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.
15. Re:Java vs Objective C - is iPhone always faster? by cbhacking · 2010-02-09 21:45 · Score: 1
  
  There is one counter-point to that, though: JIT compilers can take advantage of very specific features of your processor (not just things like instruction set extensions; I'm talking about stuff such as the exact size of your cache lines) to optimize exactly for your system. The resulting code probably won't run as well on another computer (might not run at all) but it works great on *your* computer and that's what matters.
  Of course, there's no reason that a standard C compiler or whatever can't do similar optimizations, but in general, pre-compiled code targets a very general processor design. A lot of binaries I see target only i586, some are even i386, and even among those targeting i686 there's so many processors today, most with the same instruction sets but with widely varying caches, bus bandwidths, and support for things like branch prediction, that it's entirely possible that a good JIT can produce code that runs faster on your system than a good compiler targeting a generic member of your processor family.
  
  --
  There's no place I could be, since I've found Serenity...
16. Re:Java vs Objective C - is iPhone always faster? by cbhacking · 2010-02-09 21:51 · Score: 1
  
  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 is nearly 100%, Objective-C is up there too).
  
  --
  There's no place I could be, since I've found Serenity...
17. Re:Java vs Objective C - is iPhone always faster? by Xest · 2010-02-09 22:29 · Score: 1
  
  What you say is true, but the key term is "well-coded", there are very few developers that could really produce a hand coded assembly program that runs better than something compiler optimized nowadays.
  Further, the issue you have with C compilers and such was covered by the other poster to you- they compile to a generic x86 platform, whilst JIT will compile for the specific processor on the system it is running, this means that there are many circumstances in which Java apps will actually outperform C apps, at least post-JIT compilation of course!
  "Modern JVMs and CPUs are fast enough that most of the time the difference isn't a big deal, just as modern C compilers are fast enough that we seldom bother with assembly anymore."
  I disagree with this though, the point is that on most modern systems there isn't really a difference at all, for the above mentioned reason that JIT compiled code will nearly always at least match generically pre-compiled C, if not surpass it. You're right in general though, the argument that it shouldn't be difference because it's all machine code is false, because not all machine code is created equally, it's just important to realise also that JIT compiled apps need not be any less efficient than C compiled apps.
  That's why to answer the original question above, the answer would be no, there will be no real performance difference between Android and the iPhone for this reason.
18. Re:Java vs Objective C - is iPhone always faster? by GooberToo · 2010-02-10 01:34 · Score: 1
  
  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 battery life, when compared to something like an iPhone.
  The good news for Android devices is that all that I'm aware of allow for interchangeable batteries which means you can always swap out batteries to stay on the run. Furthermore, many phones have alternate battery models with increased capacity. For example, the G1 has batteries with double their stock capacity.
19. Re:Java vs Objective C - is iPhone always faster? by xouumalperxe · 2010-02-11 00:52 · Score: 1
  
  A JIT compiler produces compiled native code. So how can native code run faster than.... native code?
  Think of how long it takes to compile an average piece of software. Now think of the time the JIT compiler can afford to spend on compiling the intermediate representation. Sure, the IR makes life much easier, but you still can't afford to go all-out with optimisations that your average stand-alone compiler can (and will) do.
Kuchichaestli by Pahroza · 2010-02-09 11:15 · Score: 2, Interesting

Nur i de Schwiiz!
Hopp Schwiiz!
1. Re:Kuchichaestli by Cryacin · 2010-02-09 11:27 · Score: 1
  
  Trottle
  
  --
  Science advances one funeral at a time- Max Planck
2. Re:Kuchichaestli by Anonymous Coward · 2010-02-09 20:29 · Score: 0
  
  Ha!
  Helvetische Schluchtenscheisser :-p
3. Re:Kuchichaestli by Anonymous Coward · 2010-02-10 00:26 · Score: 0
  
  Bünzli :-P
4. Re:Kuchichaestli by Anonymous Coward · 2010-02-10 10:16 · Score: 0
  
  Schwiiizerdütsch ischs geilste
Proof? by Mark19960 · 2010-02-09 11:23 · Score: 1

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.
1. Re:Proof? by binarylarry · 2010-02-09 11:26 · Score: 2, Informative
  
  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.
  
  --
  Mod me down, my New Earth Global Warmingist friends!
Any technologically savvy want to enlighten me? by fuzzyfuzzyfungus · 2010-02-09 11:26 · Score: 1

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 Dalvik comes along, and now somebody is claiming 3X speedup. What could Google have missed, or not had time/resources to implement that some random outfit did? Was Dalvik unexpectedly perversely bad for some reason? Was there some untapped java-optimization-fu floating around out there? Did somebody just put out a press release about their own horribly unstable version of what is currently in Google's "unstable" branch?
1. Re:Any technologically savvy want to enlighten me? by jabbathewocket · 2010-02-09 11:46 · Score: 1
  
  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.
2. Re:Any technologically savvy want to enlighten me? by Tacvek · 2010-02-09 11:55 · Score: 3, Informative
  
  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.
  
  --
  Stylish sheet to fix many problems in Slashdot's D3: https://gist.github.com/801524
3. Re:Any technologically savvy want to enlighten me? by Fnord · 2010-02-09 11:57 · Score: 1
  
  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 2.0 came with android 2.0, that didn't happen.
  These guys probably tacked on a JIT, and good for them. It needs it.
4. Re:Any technologically savvy want to enlighten me? by Anonymous Coward · 2010-02-09 12:29 · Score: 0
  
  Uh, what? Have you used an Android handset?
  Performance isn't bad, and regardless, increasing performance by 300% is *always* saying a lot, *especially* if what you're improving is too slow.
5. Re:Any technologically savvy want to enlighten me? by binarylarry · 2010-02-09 12:34 · Score: 1
  
  It's slower than an iPhone.
  Now, I have an android handset and I prefer it overall to the iPhone. But the iPhone is a better performer overall.
  Once dalvik becomes more mature and has optimizations in place like these, it will be a much closer race.
  
  --
  Mod me down, my New Earth Global Warmingist friends!
6. Re:Any technologically savvy want to enlighten me? by a_ghostwheel · 2010-02-09 12:41 · Score: 1
  
  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.
7. Re:Any technologically savvy want to enlighten me? by Fnord · 2010-02-09 12:50 · Score: 1
  
  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.
8. Re:Any technologically savvy want to enlighten me? by codepunk · 2010-02-09 13:08 · Score: 0, Troll
  
  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?
  
  --
  
  Got Code?
9. Re:Any technologically savvy want to enlighten me? by binarylarry · 2010-02-09 13:22 · Score: 1
  
  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).
  
  --
  Mod me down, my New Earth Global Warmingist friends!
10. Re:Any technologically savvy want to enlighten me? by Anonymous Coward · 2010-02-09 19:03 · Score: 0
  
  Java is only slow because they use one single thread for all gui-handling. So it's only swing/awt gui-apps that are slow. Somehow they still havn't realized that it's the one thing that sucks, and instead they checked in the SwingWorker util class to add even more mess to the problem.
11. Re:Any technologically savvy want to enlighten me? by DrXym · 2010-02-09 20:18 · Score: 1
  
  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.
12. Re:Any technologically savvy want to enlighten me? by viralburn · 2010-02-10 00:26 · Score: 1
  
  Update your firmware (ROM-Version:2.73.405.5 if you have an HTC Hero) .... i saw a huge increase in performance after the update.
13. Re:Any technologically savvy want to enlighten me? by Issarlk · 2010-02-10 02:01 · Score: 1
  
  According to a rant I read in an android app, Android doesn't have a JIT. It's what makes the 3x as fast possible. Some lesser smartphone with a Java with JIT run apps faster than Androids.
14. Re:Any technologically savvy want to enlighten me? by 91degrees · 2010-02-10 02:22 · Score: 1
  
  Well, you can usually make any code faster. Google presumably felt their JVM was good enough for the current release, and certainly not worth the man hours it would take to make it faster. It probably is if there are a lot of calls to natively compiled code.
  
  Other people clearly have a different idea of what "good enough" is. However, for Google to reach this sort of speed it sounds like they'd need a total rewrite. Their resources are better spent elsewhere.
  
  Another point to consider is that although Google has many extremely intelligent people, it doesn't have a monopoly on extremely intelligent people.
Benoit Schillings is the Chuck Norris of code. by Dr.+Spork · 2010-02-09 11:27 · Score: 5, Informative

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.
1. Re:Benoit Schillings is the Chuck Norris of code. by dozer · 2010-02-09 11:44 · Score: 4, Informative
  
  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.
2. Re:Benoit Schillings is the Chuck Norris of code. by Anonymous Coward · 2010-02-09 18:56 · Score: 0
  
  Actually OpenBFS is now better...
3. Re:Benoit Schillings is the Chuck Norris of code. by robi5 · 2010-02-09 20:06 · Score: 1
  
  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?
4. Re:Benoit Schillings is the Chuck Norris of code. by Anonymous Coward · 2010-02-10 03:13 · Score: 0
  
  “the BeOS file system, something that still hasn't been surpassed in flexibility and efficiency - the crown jewel of the BeOS code.”
  That's the funniest thing I've read all day.
  The Be File System (BeFS to all the people who already had a perfectly good filesystem called BFS, but named BFS by its oblivious author) is a quick hack. The book about the filesystem openly admits this. It was a race against time to replace the even worse system used in prior versions of BeOS which genuinely tried to treat the filesystem as a database**
  At every step there were nasty compromises in BeFS, dodges that cause problems its (few remaining) users still suffer today.
  Let's pick a nice easy one - deleting files. The simple-but-slow transaction handling code in BeFS can't do a file unlink operation safely, in some cases you'll replay the journal after a crash and there will be an inconsistency, a file exists and yet other metadata about the file is missing. The result is you can't delete it using unlink(). Did Be allocate someone to create a more robust journalling system for the next version? Nope, they added the hilarious "forcerm" command to the OS as a workaround.
  ** The performance of this earlier system will surprise no-one who has worked on a failed project to do such a thing - it was so awful as to strangle the rest of the OS.
  Now that you've put the idea of BeFS as a "crown jewel" into my head I have the perfect image - BeOS is a cupcake made by a primary school kid, slightly grey in appearance because they didn't wash all the paint off their hands before mixing the inrgedients, and burnt crispy on one side. There's no sugar in it, because the kid insisted (despite protests from the supervising adult) that it would be better without. And on the top? The jewel on the crown? A slightly sticky chewy sweet the toddler found in their pocket.
  Now, who wants to try a bite?
5. Re:Benoit Schillings is the Chuck Norris of code. by renoX · 2010-02-10 03:57 · Score: 1
  
  >Now, who wants to try a bite?
  Even if you're right, what's depressing is that BeOS was the most responsive system I've ever used on a PC..
  Which means that even if BeOS is bad, the other are *worst*..
6. Re:Benoit Schillings is the Chuck Norris of code. by sandGorgons · 2010-02-10 07:02 · Score: 1
  
  http://www.birdhouse.org/beos/bible/bos/int_schillings.html
  Benoit wrote, what is referred to by Wikipedia, as OFS (Old Be File System) which was then replaced by BFS.
7. Re:Benoit Schillings is the Chuck Norris of code. by xiong.chiamiov · 2010-02-10 13:06 · Score: 1
  
  Check his wiki
  
  Hmm, I didn't know that Benoit Schillings owned the English Wikipedia.
  
  --
  have you read the Moderation Guidelines Addendum?
8. Re:Benoit Schillings is the Chuck Norris of code. by Anonymous Coward · 2010-02-11 05:00 · Score: 0
  
  Maybe wikipedia is not up-to-date with respect to his current employer ?
Well... by msauve · 2010-02-09 11:37 · Score: 3, Informative

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.

--
"National Security is the chief cause of national insecurity." - Celine's First Law
How to build a flawed API in Java... by tlambert · 2010-02-09 11:55 · Score: 5, Informative

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
1. Re:How to build a flawed API in Java... by martin-boundary · 2010-02-09 15:23 · Score: 1
  
  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.
  
  I think you'd have to fail every object oriented language in existence in that case. It's trivial to formally define a "dead" state for an object, which can be entered when the object is no longer needed. The moment you try to "resurrect" it, you'll face this exact problem, whereas the underlying language itself only sees a long lived object.
  Of course, the normal programmer convention for initialization in languages such as Java is that an object knows how to and is expected to initialize itself correctly, so why not extend this convention to resurrection as well?
  That said, with a physics engine in particular I would be much more worried about numerical accuracy and performance than object oriented design. But a wasteful design would make me think twice about using it for realtime projects.
2. Re:How to build a flawed API in Java... by xophos · 2010-02-09 19:56 · Score: 1
  
  A functional language might qualify, but is there a true functional language ( one without mutable objects ) which one could label object oriented?
3. Re:How to build a flawed API in Java... by Lord+Pillage · 2010-02-09 23:56 · Score: 0, Redundant
  
  Lua might fit that definition. Then again, it might not, as I'm certainly no expert at it.
  
  --
  try { Signature mysig = new CleverAttempt(); } catch(NonCleverSignatureException e) { postanyway(); }
4. Re:How to build a flawed API in Java... by whatajoke · 2010-02-10 02:15 · Score: 1
  
  Personally, I really hate garbage collection as a paradigm
  Yeah, We all absolutely love languages which buffer overflow and reference dangling pointers.
  
  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.
  Addicted like programmers are addicted to a file system? You can always manage your data on the raw disk blocks directly if you want.
5. Re:How to build a flawed API in Java... by GooberToo · 2010-02-10 12:01 · Score: 2, Informative
  
  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.
6. Re:How to build a flawed API in Java... by K.+S.+Kyosuke · 2010-02-14 08:06 · Score: 1
  
  "Personally, I really hate garbage collection as a paradigm"
  That's like "hating virtual memory as a paradigm." It's one particular implementation technique for one particular abstraction (i.e., an abstraction of infinitely large memory, where you don't care about objects you don't need anymore). So, do you "hate virtual memory as a paradigm" as well?
  
  --
  Ezekiel 23:20
7. Re:How to build a flawed API in Java... by GooberToo · 2010-02-17 12:18 · Score: 1
  
  Personally, I really hate garbage collection as a paradigm
  Yeah, We all absolutely love languages which buffer overflow and reference dangling pointers.
  Those are orthogonal issues. For example, such issues are even possible in Java. Furthermore, languages like C and C++ have garbage collectors available and such issues can still exist. Even more so, using things like smart pointers in C++ can completely alleviate the issue.
Why is this needed? by codepunk · 2010-02-09 13:04 · Score: 0, Troll

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.

--

Got Code?
1. Re:Why is this needed? by SoftwareArtist · 2010-02-09 13:20 · Score: 1
  
  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. It just hasn't been released yet. Once it is, Android applications should become several times faster.
  
  --
  "I'm too busy to research this and form an educated opinion, but I do have time to tell everyone my uninformed opinion."
2. Re:Why is this needed? by paul248 · 2010-02-09 16:05 · Score: 1
  
  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.
Just in Time Compiling by AntiRush · 2010-02-09 13:21 · Score: 3, Interesting

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:plucky little startup from Switzerland by Anonymous Coward · 2010-02-09 13:51 · Score: 1, Informative

Plucky little start-up indeed.. They were called Esmertec in a previous life, and have been around a long time (in mobile phone years). I believe they provide(d) the java implementation for a large share of Sony Ericsson handsets They merged with another company, purple labs, which also came out of a whole host of mobile phone software companies, including the Openwave client software division..
Java hardware acceleration was discarded by kriston · 2010-02-09 15:49 · Score: 2, Interesting

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.

--
Kriston
1. Re:Java hardware acceleration was discarded by pddo · 2010-02-09 17:29 · Score: 1
  
  Or is it really not java? Sun/Oracle may be seeing google in court soon over that one...
JIT can be faster by Anonymous Coward · 2010-02-09 22:05 · Score: 0

Unlike a C compiler, a JIT has runtime type information and statistics. That makes it potentially faster than Objective-C and even C. For example, Java JITs routinely inline method calls that in Objective-C always have to go through dispatch logic.
Make It Run Real Java by Doc+Ruby · 2010-02-10 01:59 · Score: 1

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.

--
--
make install -not war
1. Re:Make It Run Real Java by farble1670 · 2010-02-10 08:33 · Score: 1
  
  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.
2. Re:Make It Run Real Java by Doc+Ruby · 2010-02-12 09:31 · Score: 1
  
  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?
  
  --
  --
  make install -not war
3. Re:Make It Run Real Java by farble1670 · 2010-02-12 14:45 · Score: 1
  
  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 libraries that exist out there.
  
  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 VM would need to know how to execute the swing bytecode, which dalvik VM does not.
4. Re:Make It Run Real Java by Doc+Ruby · 2010-02-13 04:39 · Score: 1
  
  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 standard JVM at all?
  I can't see anyone else saying that the Dalvik VM can run Java bytecode. Only that it runs .dex binaries, which are not Java bytecode. Lots of people are saying that it doesn't run Java bytecode.
  BTW, you don't compile using the JVM, you compile with javac or some other compiler. Which typically runs on some regular host, like x86. The JVM has nothing to do with the bytecode until runtime of the compiled bytecode.
  Where are you getting the idea that the Dalvik VM runs direct Java bytecode?
  
  --
  --
  make install -not war
5. Re:Make It Run Real Java by farble1670 · 2010-02-13 05:31 · Score: 1
  
  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 single .dex file. Duplicate strings and other constants used in multiple class files are included only once in the .dex output to conserve space. Java bytecode is also converted into an alternate instruction set used by the Dalvik VM. An uncompressed .dex file is typically a few percent smaller in size than a compressed .jar (Java Archive) derived from the same .class files."
  in other words, while dalvik doesn't run java bytecode directly, it is a 1-1 conversion process from java bytecode to dalvik dex and the SDK does that conversion process for you. you can import and .jar file into an eclipse android project and use it in your android app.
6. Re:Make It Run Real Java by Doc+Ruby · 2010-02-13 07:24 · Score: 1
  
  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 SW developer to include Android in their "Java" development platform. To the consumer, the main point of Java bytecode files in distribution is that they "just work" on their HW, even though it's different from what it was developed on. You just click a link and it runs. Converting JAR to .dex excludes Android from the market (even for free apps).
  That's the most important point, but the one that makes it clear you're talking from ignorance rather than expertise is that you don't really understand even the basics of bytecodes, classes and libraries. The Swing library doesn't have special instructions. The Swing binaries are Java bytecodes just like every other Java bytecode executable, the same as any other bytecode package. If they're in scope of the local VM, whether distributed with the browser, preinstalled in the classpath, or downloaded at runtime, the VM can execute the bytecode if they're compatible with the VM's instruction set.
  AFAICT, the Dalvik VM does not execute java bytecode instructions, only its own .dex instructions. Thanks for wasting my time.
  
  --
  --
  make install -not war
7. Re:Make It Run Real Java by farble1670 · 2010-02-13 08:45 · Score: 1
  
  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 know whether there is no equiv dex for the swing bytecode, or maybe there is an equiv, it can be converted, but the dalvik VM can't run it. regardless, you can't get swing on android. swing is just an example of one part the JDK that you can't run on android. there are others.
  i think your dog is due for another kicking.
Apps by suzieque · 2010-02-10 09:05 · Score: 1

I find apps spluttered around everywhere, it would be good for someone to aggregate mobile apps that are universal for each handset rather than the current mish mash.
Videos online by Anonymous Coward · 2010-02-17 07:59 · Score: 0

The marketing department of the company put some videos online:
http://www.youtube.com/user/myriadgroupmarketing