By Before the official Froyo announcement at I/O, we’d learned that an Adobe employee’s phone was running at ridiculously high speeds. Most outlets quickly chalked this up to the possibility that Google implemented a Just-In-Time compiler for their Dalvik Virtual Machine.
Sure enough, they confirmed our suspicions at the keynote in San Francisco, and we even got a taste of real-world performance (there’s no “theoretical” performance hikes here, folks). We know what JIT does, but I’m sure there are a lot of non-developers out there that can’t understand how it’s able to provide the huge bump in performance for Dalvik.
Technical lead for Android’s Dalvik team – Dan Bornstein – signed in with a blog post over at the Android developers site going into a bit more details about what’s really going on beneath the hood to significantly improve performance of Android (in certain cases) without needing to touch the hardware. Thankfully, he puts it in plain English so you can get – at the least – a pretty basic understanding of what’s going on. Head over there now if you want to learn more about what makes your Froyo so sweet.
This is not the Dalvik Turbo that was showed by Myriad some time ago? That one too promised around 200-300% more performance… If not, imagine adding it to the JIT *_*
You couldn’t possibly have found a better picture, I’m from Iceland so that gave me a pretty good laugh.
Wait what, I looked around and . . it’s actually named after our tiny village? That’s awesome, now I will invite all these geniuses to the fish day party that’s held there. They will surely come.
As I understand it, the only thing they did was to the same thing – implement a JIT compiler. So there’s no combining the two.
I’m pretty sure Davlik Turbo got its speed increase by incorperating a JIT so you wont be able to combine the two and get twice the speed increase I’m afraid.
For those who don’t know, here’s a very basic explanation of what the JIT does:
When writing applications in Java (the standard language used for android) the developer doesn’t actually release software that a computer can understand. The software is created using bytecode. This bytecode then needs to be translated by the computer before it can understand what to do. A JIT (very basically) stores the translation so that it doesn’t need to do it over and over again.
Consider if you were reading a book in a language you didn’t understand. You would need to get a translator to read it to you. If you then decided to re-read a page you would need to get the translator to read it to you again. This takes time as the translator needs to think about what the book says before translating it. There will always be a slight pause, no matter how good the translator. Now imagine that as well as a translator you hire a scribe. As the translator speaks, the scribe writes down the translation. If you then want to re-read a page you no longer need to wait for the translator to give you the translation. You can read directly from what the scribe wrote down the first time it was translated.
In effect, the JIT is a scribe. It’s actually far more complicated than that but it’s not a completely wrong explanation.
No comment @ Gizmodo, who claims the use of Flash in the browser + JIT enhancements = much slower phone? \\\\\ http://gizmodo.com/5546439/speed-tests-show-flash-101-slowing-down-android-22-significantly
Ugh. I put paragraphs in that explanation. I promise. They got stripped.
@ Russell…Dont worry about the paragraph structure, your explanation summed it up perfectly and even I understand it now. Thanks!
Haha, I saw the paragraphs in my news feed. =P
@Russel-
Thanks for the explanation! Does this mean that the first time an application is run, it will run at normal speed, but in subsequent runs the speed will increase?
Thanks a lot Russell your explanation really put it in perspective for me!
@Russell No worries. It was a good explanation. Thanks!
rlwfish – It means that after running a piece of code a couple of times you should see speedup. That is, DURING the first run it will run faster!
Does JIT means that same programs will use more RAM (or swap?). In the wonderful and easy-to-understand example by Russell, the scribe has to “store” the translated pages somewhere, be it RAM or storage, to make them ready to be re-read
According to Dan Bornstein the JIT uses about 100K more per application, which is hardly anything. So you won’t notice a significant memory increase.
@rlwfish: No, the application will run faster first time. The JIT only stores the translation while the application is actually running. When you close it the translation is lost and will need to be done again next time you run the app.
This might sound bad but due to the nature of software it isn’t important. Unlike a book that you read cover to cover software is read in small chunks over and over again so the same piece of code might bw read hundreds of thousands of times during one ‘play’ of the application. The JIT means the translation is only done once, the other few hundred thousand time you can skip the translation step.
JIT compilers are incredibly cool things (if you’re a geek like me). The more powerful ones used in desktops do some truly mindboggling things in the background to get speed improvements – some of them actually rewrite code on the fly to make it run faster. Skynet is almost here ;)
Thought so, a compiled part of a semi-compiled program which usually weights around 1 – 2 megabytes max can’t be that big
@Russell Troywest: Rewritten code @ run time, now, that’s drooooling *_*
@Russell
I thought it’s more like,instead of translating a, say, Chinese-language textbook into generic English, if I were to translate it on-the-spot, specifically for YOU, I can make you understand the text easier and faster and better if I translate it according to your lingo, using terms that you are more familiar with.
Good God, code that can rewrite itself on the fly? Sounds like a black hat’s wet dream to me. Make no mistake: it is VERY COOL but a bit frightening, as well.
Damn recursion
@zefi
I’m not sure exactly which bit of my posts you are referring to zefi so I’m not too sure how to answer sorry, I wouldn’t get too caught up on whether my explanation is entirely accurate or not though – I’m sure if a JIT designer were to read my posts they’d break down and cry at them.
The JIT will compile for the processor it is running against so it does compile for it’s specific situation, which is nice because it can then use tricks that are only available to that specific processor. Using the sse floating point registers on newer x86 processors for instance. I don’t know any specifics for the processors currently being used by android devices. I suspect the android JIT is a fairly basic one though as the processor and memory resources available are relatively low.
The whole idea of using a VM was that code could be run in virtually any instruction set (ie x86) without the need for recompiling. In essence, it compiles at runtime, basically the VM is an Interpreter. If a JIT is capable of utilizing a specific instruction set’s “tricks”, does that mean the JIT must be optimized for the processor it is running on? Wouldn’t that mean a different JIT for every different processor/instruction set that would be made available?
@GODCYPH
I’m probably overstating it a little by saying some of the more powerful JITs can “rewrite code”. They’ll still do exactly what the developer wanted – just in a slightly different order, or in a way that is more efficient than originally coded. I’m not a JIT developer so I only vaguely know what I’m talking about when discussing the more involved details. :) They’re amazingly powerful though.
@GODCYPH
Yes, you’re right, the JIT would need to be coded to know the ‘tricks’ are there. I have absolutely no idea how the android JIT is designed (although if it’s part of the open source package I might try and find some time to go find out). I suspect it doesn’t do anything too clever, but it does need to know what processor it is compiling for to do its job so I guess the information is available to it…
Again, I’m not a JIT designer, I have enough knowledge of how they work to be dangerous and not much more ;)
Þór, that’s a picture of me taken in 2008, just after Fiskidagur that year. I took a vacation during the lull in the time between finishing Android 1.0 and when it got released to the world. I enjoyed seeing the town it its just-post-tourist-season quiescent state.
On the technical side, I have nothing much to add to the conversation here. The “scribe” metaphor is reasonably apt (I’m not crying). But really, you should find Bill and Ben’s talk on YouTube when it gets posted. They did the overwhelming majority of the work on the JIT, and they did a great job explaining it in detail in their talk.