Yes, I confirm that there's no audio after the 41 minute mark (and no CC available). This occurs during the Q&A session, so the rest of the presentation is available. It's a great overview of ART (default runtime in L), garbage collection, and 64-bit support.
Great session yet, this video has some problems, such as no audio, and video stops... If you could solve this problem Google Developers it would be nice!
Does codegen from ART have profiling stubs to find hot/scorching methods and further do tiered compilation/optimizations on top? Or is ART codegen the final piece of code with no room for runtime modifications?
It depends on the Android release. In the kitkat/lollipop era of this talk, everything was compiled ahead-of-time in part as tricks like self modifying code would dirty pages within the ahead-of-time compiled code thereby increasing the memory footprint. As memory on phones gets to feel like that of laptops, this kind of restriction has been relaxed.
I have a few questions about ART : 1. Does it take more space for the apps than before? 2. In the Q&A part, the lecturers said that the first boot of an app is relatively slow. How could it be ? The app was already compiled and ready to be launched, so why would it be slow ? And how much slower (and compared to what) ? 3. Can you please show us links to the bechmarking tools you've used? Especially the chess-bench, which the video says it got the best boost - I can't find on the play store. 4. About 64bit support, what does it mean for the JNI apps compiling ? Would it make an additional target to compile to?
1) Yes. Probably something around 5-10% bigger (ressources usually take up most of the app size). 2) They talking "first boot time" of Android not of the App. On the first boot after an OTA (or anything else that clears run-time cache) ART will have to compile (dex up he calls it) all installed apps anew. You might have seen that before. A window appears written "Optimizing Application x of N" or so. This process takes now significant longer (~2.5x I think he said). So if that first Android start after update took 60s with dalvik, now it will take ~150s. If you have KitKat, you can try to switch to ART and back. Both times you will have to restart Android and both times the runtime will "optimize" (dex up). You will see that the ART restart will take much longer than the Dalvik one.
Andreas Harder 1. why is that? I mean, now it's compiled to machine code, which takes much less space than byte code (dex files) , no? Also, why can't the play store servers do the compiling itself, and send the device the compiled app together with the APK itself? This way, compiling on the device's side would only be required when you install the APK file as it is, onto another device. 2. oh. so now I wonder: what would happen when you flash a new version of the rom ? Would it take even more than the time it took to boot-up the OS , when you wipe dalvik's cache? would it even need a wiping of any cache? I actually have Kitkat on Galaxy S3 (I9300) with CM11 , but I didn't enable it on a daily basis. I only did it once, to see how things work. I didn't notice any difference, so I switched back (because I prefer that it would be stable and didn't see any advantage yet).
Disclaimer... I am not necessarily an expert. So take my responses with caution. 1) With Dalvik, you had the APK lying around on your device . When you started the App, the Dalvik JIT compiler compiled code fragments on the fly (didn't store them, therefore Just In Time Compiler). With ART, you have the APK on your device plus the ahead of time compiled version. Because this compiled version is now stored on the device and not created on the fly, it takes more space (Note: that's simplified. There is a lot of optimization and caching going on. But that is the general difference between JIT (Just In Time) and AOT (Ahead Of Time) compilers.) Compiled applications are usually smaller because the source is not kept (e.g. you have C++ source code, you compile it, you deploy the binary not the code). In Android however, the source (APK) is kept together with the "compiled" version. An APK is compiled against a certain Environment and Hardware. In order for the play store to compile the file for you, it would need to know all of that. Additionally, the device must still be able to compile the APK in case the Environment is updated (Android) or it is side-loaded onto a completely different device. This effort is unnecessary as we talk about a one time process in the seconds. If you install an app, even with ART you don't realize that any of that happens. Only if 100 apps are dexed up at once, you feel the pain. Additionally, you might want to compile Android for a hardware which Google doesn't want to write a compiler for. 2) I haven't heard anything to that topic yet, but I am pretty sure ART will have a cache too (some store for compile artifacts). And I am pretty sure that this cache will be cleared every time you change your ROM. He actually said that in the video as well. And yes, rebuilding that cache after it has been cleared (new rom, ota, wipe, ...) will take much longer than it has with Dalvik.
Andreas Harder 1. But Dalvik has its own cache too, with dex files and all, so why would a compiled app using ART take more than that? You can even see the files of Dalvik cache (if you have a rooted device) - they all can be found on "/data/dalvik-cache" folder . To make things in perspective: if you look at an APK file like of my tiny app (here: play.google.com/store/apps/details?id=com.lb.app_manager) , which takes 2.3MB (2,471,327 bytes), and you look at what the Dalvik cache, you'd see that its dex file takes about double the size - 4.6MB (4,827,080 bytes)... Do you mean to tell me it will be even larger ? 2. Too bad. so updating will take even longer than it was so far... I wonder if there is a way to make it faster too. Sadly, I don't think Google will work on it anytime in the near future, since Android updates are too rare to consider this a problem.
It seems like there is not much tangible information about that out there. My understanding: - Dalvik does not compile dex, it optimizes it (odex) and puts it into the cache. - ART will create ELF (wherever those are put) which will contain the dex file as well as the compiled code (and more). Coming from there, I can't exclude that creating an optimized dex file might be even larger in size than dex + compiled. I can only rely on the information I can find, which all consistently say that ART will require more storage (compilation more expensive than optimization). Example: forum.xda-developers.com/google-nexus-5/general/dedicated-runtime-thread-art-vs-dalvik-t2516646 "Also since ART precompiles and saves that precompiled code upon installation of apps, it takes up more storage. The increase is about 10-20% of the code in the application. Remember the majority of apps usually comprises media files such as images, videos, sounds... so those components will be unaffected." But maybe those people don't consider dalvik cache to be "storage" and only relate to apk's.
Hello, I'm a 5+year X-android enthusiast and I just wanted to share the prospective from someone who "was" an android enthusiast, I even went as far as to take up learning JAVA & HTML so I could learn to make android apps and I dropped all of that the very moment I realized what android 5.0+ and ART was really all about. ANDROID ART IS A JOKE...They make android ART seem sooo good, and I really looked forward to trying it out when it was first released for the increased smoothness & battery life. The reality of android ART vs the old JIT compiler is actually a very sad situation, JIT is basically = Pocket Computer, and ART is basically = IPhone (not computer like, at all). Android 4.4 and earlier was basically a pocket PC, Where as android 5.0+ IS NOT a pocket pc. Android 5.0+ had all of it's "PC like potential" taken away (They took away "real time" unlimited amount of thinking the CPU used to be able to do, and replaced it with a bunch of bullshit pre-determined iPhone style cache systems that can't do half the stuff that real time computation in a normal computer/JIT compiler is capable of, so they could save power. Removal of JIT compiler and replacing it with ART was a HUGE MISTAKE). I used to use my android 4.4 phone MUCH more than my desktop PC, But after the JIT compiler was removed from android I went back to using my PC. Android 5.0+ IS NO DIFFERENT than an iPhone (except widgets) and you didn't ever use an iPhone to replace your desktop PC experience did you? So why would I wanna use androids iPhone wanna be operating system to replace my PC experience? Oh yeah, I DON'T... (I hate you, google) I support the "google anti trust" If you don't know what this is, go search it online. I NEVER ever thought in a million years I would buy an iPhone ever again, But now I'm actually considering iPhone for my next purchase because of android ART. BTW, If android is "following" iPhone then that must mean that iPhone is a "leader"? I don't know about you guys, but I would rather buy from the leader, Not the follower. Basically all android phones running android 5.0+ & 6.0+ are just UNDER PERFORMING iphones with an android label (a label that is well known for something that android WAS and IS NOT ANYMORE, BUYER BEWARE). R.I.P. Android.
40:50 Dalvik GC in action.
Video gets stuck at this point, damn!
nice one :)
Bahaha, made my night! :D
It seems that the sound is missing from 41:00 onwards.
Yes, I confirm that there's no audio after the 41 minute mark (and no CC available). This occurs during the Q&A session, so the rest of the presentation is available. It's a great overview of ART (default runtime in L), garbage collection, and 64-bit support.
John Miller I wonder what are the questions and answers that were talked about then...
They are showing the effect of how 'Stop The world' GC works, I presume :P
deans4j Good one :)
Yes. There's issues with the video
Sound cuts out at 33:04 and comes back at 33:10 Aha Video freezes at 40:51 and sound is dead until the end.
The video recorder is still running Dalvik I see.
Awesome! Android is pretty smooth already, but its going to become so much smoother! Be worried, ios, windows phone! :-)
Great stuff.
Google Developers sound cuts out in a few places, redacted or what?
room 5 doesn't have a 'whole day' recording?
Great session yet, this video has some problems, such as no audio, and video stops...
If you could solve this problem Google Developers it would be nice!
The Android RunTime runtime? Great talk name!
Will this improve upon preserving the date created and date modified of files/folders when transferring to external storage media ?
I can't believe no one though earlier to dedicate a part of heap to large files.
Does codegen from ART have profiling stubs to find hot/scorching methods and further do tiered compilation/optimizations on top? Or is ART codegen the final piece of code with no room for runtime modifications?
It depends on the Android release. In the kitkat/lollipop era of this talk, everything was compiled ahead-of-time in part as tricks like self modifying code would dirty pages within the ahead-of-time compiled code thereby increasing the memory footprint. As memory on phones gets to feel like that of laptops, this kind of restriction has been relaxed.
I have a few questions about ART :
1. Does it take more space for the apps than before?
2. In the Q&A part, the lecturers said that the first boot of an app is relatively slow. How could it be ? The app was already compiled and ready to be launched, so why would it be slow ? And how much slower (and compared to what) ?
3. Can you please show us links to the bechmarking tools you've used? Especially the chess-bench, which the video says it got the best boost - I can't find on the play store.
4. About 64bit support, what does it mean for the JNI apps compiling ? Would it make an additional target to compile to?
1) Yes. Probably something around 5-10% bigger (ressources usually take up most of the app size).
2) They talking "first boot time" of Android not of the App.
On the first boot after an OTA (or anything else that clears run-time cache) ART will have to compile (dex up he calls it) all installed apps anew. You might have seen that before. A window appears written "Optimizing Application x of N" or so. This process takes now significant longer (~2.5x I think he said). So if that first Android start after update took 60s with dalvik, now it will take ~150s.
If you have KitKat, you can try to switch to ART and back. Both times you will have to restart Android and both times the runtime will "optimize" (dex up). You will see that the ART restart will take much longer than the Dalvik one.
Andreas Harder 1. why is that? I mean, now it's compiled to machine code, which takes much less space than byte code (dex files) , no?
Also, why can't the play store servers do the compiling itself, and send the device the compiled app together with the APK itself? This way, compiling on the device's side would only be required when you install the APK file as it is, onto another device.
2. oh. so now I wonder: what would happen when you flash a new version of the rom ? Would it take even more than the time it took to boot-up the OS , when you wipe dalvik's cache? would it even need a wiping of any cache?
I actually have Kitkat on Galaxy S3 (I9300) with CM11 , but I didn't enable it on a daily basis. I only did it once, to see how things work. I didn't notice any difference, so I switched back (because I prefer that it would be stable and didn't see any advantage yet).
Disclaimer... I am not necessarily an expert. So take my responses with caution.
1) With Dalvik, you had the APK lying around on your device . When you started the App, the Dalvik JIT compiler compiled code fragments on the fly (didn't store them, therefore Just In Time Compiler).
With ART, you have the APK on your device plus the ahead of time compiled version. Because this compiled version is now stored on the device and not created on the fly, it takes more space
(Note: that's simplified. There is a lot of optimization and caching going on. But that is the general difference between JIT (Just In Time) and AOT (Ahead Of Time) compilers.)
Compiled applications are usually smaller because the source is not kept (e.g. you have C++ source code, you compile it, you deploy the binary not the code). In Android however, the source (APK) is kept together with the "compiled" version.
An APK is compiled against a certain Environment and Hardware. In order for the play store to compile the file for you, it would need to know all of that. Additionally, the device must still be able to compile the APK in case the Environment is updated (Android) or it is side-loaded onto a completely different device. This effort is unnecessary as we talk about a one time process in the seconds. If you install an app, even with ART you don't realize that any of that happens. Only if 100 apps are dexed up at once, you feel the pain.
Additionally, you might want to compile Android for a hardware which Google doesn't want to write a compiler for.
2) I haven't heard anything to that topic yet, but I am pretty sure ART will have a cache too (some store for compile artifacts). And I am pretty sure that this cache will be cleared every time you change your ROM. He actually said that in the video as well.
And yes, rebuilding that cache after it has been cleared (new rom, ota, wipe, ...) will take much longer than it has with Dalvik.
Andreas Harder 1. But Dalvik has its own cache too, with dex files and all, so why would a compiled app using ART take more than that?
You can even see the files of Dalvik cache (if you have a rooted device) - they all can be found on "/data/dalvik-cache" folder . To make things in perspective:
if you look at an APK file like of my tiny app (here: play.google.com/store/apps/details?id=com.lb.app_manager) , which takes 2.3MB (2,471,327 bytes), and you look at what the Dalvik cache, you'd see that its dex file takes about double the size - 4.6MB (4,827,080 bytes)...
Do you mean to tell me it will be even larger ?
2. Too bad. so updating will take even longer than it was so far...
I wonder if there is a way to make it faster too. Sadly, I don't think Google will work on it anytime in the near future, since Android updates are too rare to consider this a problem.
It seems like there is not much tangible information about that out there.
My understanding:
- Dalvik does not compile dex, it optimizes it (odex) and puts it into the cache.
- ART will create ELF (wherever those are put) which will contain the dex file as well as the compiled code (and more).
Coming from there, I can't exclude that creating an optimized dex file might be even larger in size than dex + compiled.
I can only rely on the information I can find, which all consistently say that ART will require more storage (compilation more expensive than optimization).
Example:
forum.xda-developers.com/google-nexus-5/general/dedicated-runtime-thread-art-vs-dalvik-t2516646
"Also since ART precompiles and saves that precompiled code upon installation of apps, it takes up more storage. The increase is about 10-20% of the code in the application. Remember the majority of apps usually comprises media files such as images, videos, sounds... so those components will be unaffected."
But maybe those people don't consider dalvik cache to be "storage" and only relate to apk's.
Is there a way to pre-build everithing to oat on KitKat so that to make the first boot time less painful?
Are there other frontends for the compiler besides DEX?
Hello, I'm a 5+year X-android enthusiast and I just wanted to share the prospective from someone who "was" an android enthusiast, I even went as far as to take up learning JAVA & HTML so I could learn to make android apps and I dropped all of that the very moment I realized what android 5.0+ and ART was really all about. ANDROID ART IS A JOKE...They make android ART seem sooo good, and I really looked forward to trying it out when it was first released for the increased smoothness & battery life. The reality of android ART vs the old JIT compiler is actually a very sad situation, JIT is basically = Pocket Computer, and ART is basically = IPhone (not computer like, at all). Android 4.4 and earlier was basically a pocket PC, Where as android 5.0+ IS NOT a pocket pc. Android 5.0+ had all of it's "PC like potential" taken away (They took away "real time" unlimited amount of thinking the CPU used to be able to do, and replaced it with a bunch of bullshit pre-determined iPhone style cache systems that can't do half the stuff that real time computation in a normal computer/JIT compiler is capable of, so they could save power. Removal of JIT compiler and replacing it with ART was a HUGE MISTAKE). I used to use my android 4.4 phone MUCH more than my desktop PC, But after the JIT compiler was removed from android I went back to using my PC. Android 5.0+ IS NO DIFFERENT than an iPhone (except widgets) and you didn't ever use an iPhone to replace your desktop PC experience did you? So why would I wanna use androids iPhone wanna be operating system to replace my PC experience? Oh yeah, I DON'T... (I hate you, google) I support the "google anti trust" If you don't know what this is, go search it online. I NEVER ever thought in a million years I would buy an iPhone ever again, But now I'm actually considering iPhone for my next purchase because of android ART. BTW, If android is "following" iPhone then that must mean that iPhone is a "leader"? I don't know about you guys, but I would rather buy from the leader, Not the follower. Basically all android phones running android 5.0+ & 6.0+ are just UNDER PERFORMING iphones with an android label (a label that is well known for something that android WAS and IS NOT ANYMORE, BUYER BEWARE). R.I.P. Android.
Gaaaaah I really wanted to hear that Q&A.
Lol. Does this mean I can go ahead and load 10k x 10k bitmaps ?
Does anyone know where I can find the slides for this keynote? I need it for 3rd Year project
14:00 Garbage Collection