6 ms·

Neat. On Android it's easy to believe Dalvik/ART generated code leaves more performance on the table compared to other platforms. Another "what's different thi

by zurn 12y ago

Neat. On Android it's easy to believe Dalvik/ART generated code leaves more performance on the table compared to other platforms. Another "what's different this time" point: compared to Transmeta era, CPUs now typically have idle core(s) waiting for work to do. This may enable more ambitious optimizations as you're not constantly stealing cycles from the app. Does anyone have a link to the paper?

higherpurpose 12y ago
Why do you lump Dalvik and ART together? The whole point of ART is that it's compiled to native code, is it not? Therefore it's "not leaving anything on the table". Not sure why I'm being downvoted: > The big paradigm-shift that ART brings, is that instead of being a Just-in-Time (JIT) compiler, it now compiles application code Ahead-of-Time (AOT). The runtime goes from having to compile from bytecode to native code each time you run an application, to having it to do it only once, and any subsequent execution from that point forward is done from the existing compiled native code. http://www.anandtech.com/show/8231/a-closer-look-at-android-runtime-art-in-android-l http://www.anandtech.com/show/8231/a-closer-look-at-android-... That sounds like native code compilation to me.
- fulafel 12y ago
  Dalvik and ART both generate native code. ART does it at app install time and Dalvik, being a JIT, does it at app runtime. He was speculating about quality of the generated native code, not its existence. Google has been very quiet about ART generated code quality. I haven't found any benchmarks that would compliment its performance either. It's probably better than Dalvik but worse than mature optimizing compilers.
  - on_and_off 12y ago
    I don't think they have been very quiet about ART. They had a whole I/O session and they recently dedicated a whole dev backstage podcast to ART and its future evolution (btw, some nice things are planned : suppression of the 65k limit, code hot-swap, ...).
- pjmlp 12y ago
  Some people have problems to distinguish between languages and the multiple ways they can be implemented. The fact that ART makes use of dex bytecode as portable executable format[0] complicates the matter for those not versed in compiler design. So people see bytecode and think managed, when a bytecode format doesn't have anything to do with being interpreted or compiled to native code. [0] An old idea that goes back to the mainframe days and used by quite a few other languages.
- nb1981 12y ago
  Native does not always (or even often) equal optimal. Plenty will still be left on the table.
  - malkia 12y ago
    20 or more years ago there was a peephole optimizer that looked at generated Turbo Pascal (and other not so advanced (for their time) compilers) and rearranged instructions, removed holes, replaced instructions with better set (turns out some of the "macro"-instructions were not that fast). Nowadays calling a .so/.dylib/.dll function, or accessing a thread-local variable also generates lots of cruft code that could possibly get optimized once the data is loaded. It won't always work (shared libraries can't be unloaded, but with enough hints, or assumptions that this would never be done, one can gain some benefits). On the negative this may reduce the code-sharing across processes.
Symmetry 12y ago
The paper is here, free with registration and I haven't been spammed (yet). http://www.tiriasresearch.com/downloads/nvidia-charts-its-own-path-to-armv8/ http://www.tiriasresearch.com/downloads/nvidia-charts-its-ow... In general CPUs have idle cores, but this looks like it's supposed to be a dual core setup so that's going to be less of a factor. I think the main idea is that you only have to do the optimization once but you run the code many times, which is an improvement from Transmeta where you threw out your optimizations when the process ended.

by zurn 12y ago

higherpurpose 12y ago

Why do you lump Dalvik and ART together? The whole point of ART is that it's compiled to native code, is it not? Therefore it's "not leaving anything on the table". Not sure why I'm being downvoted: > The big paradigm-shift that ART brings, is that instead of being a Just-in-Time (JIT) compiler, it now compiles application code Ahead-of-Time (AOT). The runtime goes from having to compile from bytecode to native code each time you run an application, to having it to do it only once, and any subsequent execution from that point forward is done from the existing compiled native code. http://www.anandtech.com/show/8231/a-closer-look-at-android-runtime-art-in-android-l http://www.anandtech.com/show/8231/a-closer-look-at-android-... That sounds like native code compilation to me.

fulafel 12y ago
Dalvik and ART both generate native code. ART does it at app install time and Dalvik, being a JIT, does it at app runtime. He was speculating about quality of the generated native code, not its existence. Google has been very quiet about ART generated code quality. I haven't found any benchmarks that would compliment its performance either. It's probably better than Dalvik but worse than mature optimizing compilers.
- on_and_off 12y ago
  I don't think they have been very quiet about ART. They had a whole I/O session and they recently dedicated a whole dev backstage podcast to ART and its future evolution (btw, some nice things are planned : suppression of the 65k limit, code hot-swap, ...).
pjmlp 12y ago
Some people have problems to distinguish between languages and the multiple ways they can be implemented. The fact that ART makes use of dex bytecode as portable executable format[0] complicates the matter for those not versed in compiler design. So people see bytecode and think managed, when a bytecode format doesn't have anything to do with being interpreted or compiled to native code. [0] An old idea that goes back to the mainframe days and used by quite a few other languages.
nb1981 12y ago
Native does not always (or even often) equal optimal. Plenty will still be left on the table.
- malkia 12y ago
  20 or more years ago there was a peephole optimizer that looked at generated Turbo Pascal (and other not so advanced (for their time) compilers) and rearranged instructions, removed holes, replaced instructions with better set (turns out some of the "macro"-instructions were not that fast). Nowadays calling a .so/.dylib/.dll function, or accessing a thread-local variable also generates lots of cruft code that could possibly get optimized once the data is loaded. It won't always work (shared libraries can't be unloaded, but with enough hints, or assumptions that this would never be done, one can gain some benefits). On the negative this may reduce the code-sharing across processes.

Symmetry 12y ago

The paper is here, free with registration and I haven't been spammed (yet). http://www.tiriasresearch.com/downloads/nvidia-charts-its-own-path-to-armv8/ http://www.tiriasresearch.com/downloads/nvidia-charts-its-ow... In general CPUs have idle cores, but this looks like it's supposed to be a dual core setup so that's going to be less of a factor. I think the main idea is that you only have to do the optimization once but you run the code many times, which is an improvement from Transmeta where you threw out your optimizations when the process ended.