Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Swiss Firm Claims Boost In Android App Performance

kdawson posted more than 4 years ago | from the sixty-fps-here-we-come dept.

Cellphones 132

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

cancel ×

132 comments

Sorry! There are no comments related to the filter you selected.

Another JVM (4, Insightful)

BadAnalogyGuy (945258) | more than 4 years ago | (#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:Another JVM (2, Interesting)

Anonymous Coward | more than 4 years ago | (#31079532)

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.

Re:Another JVM (0)

Anonymous Coward | more than 4 years ago | (#31079582)

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.

Re:Another JVM (1)

binarylarry (1338699) | more than 4 years ago | (#31079612)

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.

Re:Another JVM (2, Informative)

martin-boundary (547041) | more than 4 years ago | (#31079754)

That's a design flaw in the physics engine. If a library's performance depends strongly on GC performance, then the programmers should refactor their code to reuse existing objects rather than building new ones all the time.

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

Re:Another JVM (2, Insightful)

Vector7 (2410) | more than 4 years ago | (#31079980)

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.

How to build a flawed API in Java... (5, Informative)

tlambert (566799) | more than 4 years ago | (#31080142)

How to build a flawed API in Java...

If a library's performance depends strongly on GC performance, then the programmers should refactor their code to reuse existing objects rather than building new ones all the time.

The absolute worst thing you can do in an object oriented language, which is intended to be used in an object oriented way, is to instance objects without the instancing of them initializing them. The original Java Mail API did this, and it was a steaming pile because of that. I would probably go so far as to suggest that any object oriented language which permitted this was not designed correctly. To reuse the objects, you'd have to be able to reinitialize them, which is basically the same thing.

The typical problem with Java programs and garbage collectors is chasing force-zeroing of pages because they release the memory back to the system, and their security model requires that the memory be zeroed before it is reused by the program. Being a little bit time lazy about doing your GC to reclaim the memory on behalf of the system rather than on behalf of the program you are running almost always results in significant performance improvements in things like Physics engines. In other words, you want a little intentional latency between the time you collect the garbage, and the time you deliver it to the dump.

One of the most obvious recent offenders is Apache Lucene , specifically , which works just great, if you don't do the finalize() and cause the objects to be collected way too early.

So the problem usually boils down to a greedy garbage collector, which is a problem in the JVM, not the library code.

Of course on tiny platforms, the JVM footprint gets pretty large, so you'd also need to gather and LRU the freed heap to avoid it growing out of control from the latency; so you'd need a high water mark as well as a timed delay.

Personally, I really hate garbage collection as a paradigm, especially the garbage collection in Objective C. It claims to be optional, but isn't: as soon as you have one framework that doesn't do an explicit release of an object, your program is forever after addicted to the garbage collector, and slowly accumulates leaks which are "fixed" by the garbage collector, until what you have left is code you can't reuse without also doing garbage collection, infecting any project you bring it into.

-- Terry

Re:How to build a flawed API in Java... (1)

martin-boundary (547041) | more than 4 years ago | (#31081734)

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.

Re:How to build a flawed API in Java... (1)

xophos (517934) | more than 4 years ago | (#31082980)

A functional language might qualify, but is there a true functional language ( one without mutable objects ) which one could label object oriented?

Re:Another JVM (1)

fredrik70 (161208) | more than 4 years ago | (#31079834)

to be fair, all primitive types like int, float, etc are stored on the stack and not the heap, only objects are

Re:Another JVM (1)

Brian Feldman (350) | more than 4 years ago | (#31080222)

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.

Re:Another JVM (0)

Anonymous Coward | more than 4 years ago | (#31083190)

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

Re:Another JVM (2, Insightful)

Nadaka (224565) | more than 4 years ago | (#31080238)

Not really. This is actually one of the places that java has dramatically improved over the last decade. Most optimized VMs have a heap that uses stack like mechanisms that have reduced the real cost of instantiating an object to about 60 machine instructions vs c++ using 100 to 300. Also, because of how objects are arranged, recently created objects can be reclaimed at virtually no cost. I would link to a couple articles, but the bookmarts are at home and I am on my work machine.

Re:Another JVM (1)

binarylarry (1338699) | more than 4 years ago | (#31080318)

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.

Re:Another JVM (3, Insightful)

Nadaka (224565) | more than 4 years ago | (#31080996)

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 (1)

binarylarry (1338699) | more than 4 years ago | (#31081622)

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.

Re:Another JVM (1)

Nadaka (224565) | more than 4 years ago | (#31081886)

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.

Re:Another JVM (1)

CaptnMArk (9003) | more than 4 years ago | (#31083180)

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.

Re:Another JVM (3, Insightful)

WaywardGeek (1480513) | more than 4 years ago | (#31080882)

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 (0)

Anonymous Coward | more than 4 years ago | (#31081076)

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.

Java vs Objective C - is iPhone always faster? (1)

Rob Y. (110975) | more than 4 years ago | (#31079658)

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?

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

outZider (165286) | more than 4 years ago | (#31079886)

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:Java vs Objective C - is iPhone always faster? (0)

Anonymous Coward | more than 4 years ago | (#31080102)

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?

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

binarylarry (1338699) | more than 4 years ago | (#31080324)

Shhh, he's a PHP codah and you're just going to confuse him.

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

egomaniac (105476) | more than 4 years ago | (#31081624)

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.

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

cbhacking (979169) | more than 4 years ago | (#31083498)

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.

JIT can be faster (0)

Anonymous Coward | more than 4 years ago | (#31083572)

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.

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

Xest (935314) | more than 4 years ago | (#31083680)

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.

Re:Java vs Objective C - is iPhone always faster? (2, Informative)

Lunix Nutcase (1092239) | more than 4 years ago | (#31080160)

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

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

outZider (165286) | more than 4 years ago | (#31080950)

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.

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

Lunix Nutcase (1092239) | more than 4 years ago | (#31081212)

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.

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

Anonymous Coward | more than 4 years ago | (#31082274)

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.

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

NoOneInParticular (221808) | more than 4 years ago | (#31082676)

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.

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

larry bagina (561269) | more than 4 years ago | (#31080046)

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.

Re:Java vs Objective C - is iPhone always faster? (3, Informative)

jo42 (227475) | more than 4 years ago | (#31080232)

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

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

Dog-Cow (21281) | more than 4 years ago | (#31080588)

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

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

larry bagina (561269) | more than 4 years ago | (#31081686)

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

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

cbhacking (979169) | more than 4 years ago | (#31083518)

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

Re:Java vs Objective C - is iPhone always faster? (4, Interesting)

WaywardGeek (1480513) | more than 4 years ago | (#31080954)

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.

Re:Another JVM (1)

Tumbleweed (3706) | more than 4 years ago | (#31080216)

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.

Re:Another JVM (1)

dumael (1172411) | more than 4 years ago | (#31081924)

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.

Slashvertisements ahoy! (2, Funny)

Monkeedude1212 (1560403) | more than 4 years ago | (#31079530)

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

Re:Slashvertisements ahoy! (1)

joocemann (1273720) | more than 4 years ago | (#31081036)

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 (4, Insightful)

eldavojohn (898314) | more than 4 years ago | (#31079534)

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.

Re:Behold (-1, Flamebait)

Anonymous Coward | more than 4 years ago | (#31079572)

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.

Gee, it's almost as if this is like all the other press releases that corporations put out that make huge promises that they never deliver. But, no, in this case it really must be real! I mean they wouldn't lie, right!?! RIGHT!?!?!

Well... (3, Informative)

msauve (701917) | more than 4 years ago | (#31079968)

they are a founding member of the OHA [openhandsetalliance.com] , 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:plucky little startup from Switzerland (1, Informative)

Anonymous Coward | more than 4 years ago | (#31081136)

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

Benoit Schillings is the Chuck Norris of code. (5, Informative)

Dr. Spork (142693) | more than 4 years ago | (#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.

Re:Benoit Schillings is the Chuck Norris of code. (4, Informative)

dozer (30790) | more than 4 years ago | (#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.

Re:Benoit Schillings is the Chuck Norris of code. (0)

Anonymous Coward | more than 4 years ago | (#31082664)

Actually OpenBFS is now better...

Re:Benoit Schillings is the Chuck Norris of code. (1)

robi5 (1261542) | more than 4 years ago | (#31083048)

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 (3, Funny)

ScrewMaster (602015) | more than 4 years ago | (#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:Behold (1, Interesting)

Anonymous Coward | more than 4 years ago | (#31079916)

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

Re:Behold (0)

Anonymous Coward | more than 4 years ago | (#31079942)

apparently (and unsurprisingly) they have something similar in the pipeline for an update already.

Re:Behold (1)

CannonballHead (842625) | more than 4 years ago | (#31079996)

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

Re:Behold (1)

HotBBQ (714130) | more than 4 years ago | (#31080156)

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

WaywardGeek (1480513) | more than 4 years ago | (#31081022)

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.

Blah. (1)

James_Duncan8181 (588316) | more than 4 years ago | (#31079558)

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]

Re:Blah. (1)

Tacvek (948259) | more than 4 years ago | (#31080112)

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.

faster slow is still slow shit (-1, Flamebait)

Anonymous Coward | more than 4 years ago | (#31079560)

'droid suxors!

Re:faster slow is still slow shit (1)

binarylarry (1338699) | more than 4 years ago | (#31079622)

droid does?

Turbo! (4, Funny)

TubeSteak (669689) | more than 4 years ago | (#31079574)

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!

Re:Turbo! (0)

Anonymous Coward | more than 4 years ago | (#31079720)

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.

Re:Turbo! (1)

martin-boundary (547041) | more than 4 years ago | (#31079820)

Not true! You had to turn it off if you wanted to play Buck Rogers Planet of Zoom [wikipedia.org]

Re:Turbo! (0)

Anonymous Coward | more than 4 years ago | (#31080014)

Not true! I had a program to slow the computer down to whatever speed I wanted to.

Re:Turbo! (1)

ircmaxell (1117387) | more than 4 years ago | (#31080290)

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

Re:Turbo! (1)

amRadioHed (463061) | more than 4 years ago | (#31080704)

It was only too fast because of poor programming practices. They assumed a certain MHz processor and so faster CPUs threw off their timing.

Re:Turbo! (1)

WinterSolstice (223271) | more than 4 years ago | (#31079830)

I used to play Sopwith - and yes, it worked. That plane is impossible to control if you're running above about 12MHz :)

Re:Turbo! (0)

Anonymous Coward | more than 4 years ago | (#31081738)

sudo apt-get install sopwith

you too can play again

Re:Turbo! (1)

hufman (1670590) | more than 4 years ago | (#31082408)

Where does it install the Turbo button?

Re:Turbo! (1)

fredrik70 (161208) | more than 4 years ago | (#31079858)

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

Re:Turbo! (1)

IMightB (533307) | more than 4 years ago | (#31080372)

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

Re:Turbo! (1)

pclminion (145572) | more than 4 years ago | (#31079730)

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.

Re:Turbo! (1)

some_guy_88 (1306769) | more than 4 years ago | (#31082202)

Do elaborate.

Re:Turbo! (0)

Anonymous Coward | more than 4 years ago | (#31079756)

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

Re:Turbo! (1)

Tumbleweed (3706) | more than 4 years ago | (#31080244)

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.

Re:Turbo! (0)

Anonymous Coward | more than 4 years ago | (#31080772)

I thought this joke was a repeat.. checked, yes.

Kuchichaestli (2, Interesting)

Pahroza (24427) | more than 4 years ago | (#31079728)

Nur i de Schwiiz!

Hopp Schwiiz!

Re:Kuchichaestli (1)

Cryacin (657549) | more than 4 years ago | (#31079880)

Trottle

Re:Kuchichaestli (0)

Anonymous Coward | more than 4 years ago | (#31083148)

Ha!
Helvetische Schluchtenscheisser :-p

Proof? (1)

Mark19960 (539856) | more than 4 years ago | (#31079832)

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:Proof? (2, Informative)

binarylarry (1338699) | more than 4 years ago | (#31079860)

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.

Any technologically savvy want to enlighten me? (1)

fuzzyfuzzyfungus (1223518) | more than 4 years ago | (#31079862)

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?

Re:Any technologically savvy want to enlighten me? (1)

jabbathewocket (1601791) | more than 4 years ago | (#31080064)

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.

Re:Any technologically savvy want to enlighten me? (0)

Anonymous Coward | more than 4 years ago | (#31080438)

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.

Re:Any technologically savvy want to enlighten me? (1)

binarylarry (1338699) | more than 4 years ago | (#31080482)

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.

Re:Any technologically savvy want to enlighten me? (3, Informative)

Tacvek (948259) | more than 4 years ago | (#31080138)

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.

Re:Any technologically savvy want to enlighten me? (1)

Fnord (1756) | more than 4 years ago | (#31080162)

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.

Re:Any technologically savvy want to enlighten me? (1)

a_ghostwheel (699776) | more than 4 years ago | (#31080564)

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.

Re:Any technologically savvy want to enlighten me? (1)

Fnord (1756) | more than 4 years ago | (#31080658)

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:Any technologically savvy want to enlighten me? (0, Troll)

codepunk (167897) | more than 4 years ago | (#31080800)

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?

Re:Any technologically savvy want to enlighten me? (1)

binarylarry (1338699) | more than 4 years ago | (#31080892)

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

Re:Any technologically savvy want to enlighten me? (0)

Anonymous Coward | more than 4 years ago | (#31082698)

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.

Re:Any technologically savvy want to enlighten me? (1)

DrXym (126579) | more than 4 years ago | (#31083092)

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 is this needed? (0, Troll)

codepunk (167897) | more than 4 years ago | (#31080770)

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.

Re:Why is this needed? (1)

SoftwareArtist (1472499) | more than 4 years ago | (#31080878)

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.

Re:Why is this needed? (1)

paul248 (536459) | more than 4 years ago | (#31081914)

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 (3, Interesting)

AntiRush (1175479) | more than 4 years ago | (#31080890)

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.

Java hardware acceleration was discarded (2, Interesting)

kriston (7886) | more than 4 years ago | (#31081850)

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.

Re:Java hardware acceleration was discarded (1)

pddo (969282) | more than 4 years ago | (#31082306)

Or is it really not java? Sun/Oracle may be seeing google in court soon over that one...
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>