KitKat's ART

[Ranveer Aggarwal]

One of the most underrated, yet innovative features of Android 4.4 KitKat is the ART (Android Runtime) which Google had been working on secretly since past two years before rolling it out on it's latest Nexus phone. 

The reason that Android underperformed on low hardware (as compared to Windows and Apple counterparts) was due to Dalvik, the bulky and outdated runtime environment which has been on the go since the beginning.

Dalvik uses what’s called JIT, or Just In Time, as the compiler. This basically compiles the app on your device each time you open it up. While this does allow for a variety of devices to run it, it’s bulky. In a nutshell, it works for the software, but not the hardware. 

ART will take that compiling and do it ahead of time, which is why it replaces JIT with AOT (Ahead Of Time!). This will essentially turn the app into a native one, rather than create a virtual machine each time it’s opened. Doing so should (in theory) boot apps quicker, and run them a bit more efficiently.

What does this mean? Lesser lagging and more battery life.

So the question here is what does this mean for the developers? Would they have to make changes in their existing source codes to optimize their apps on this new environment? There have been multiple reports of people being unable to launch apps after switching (Yes! There is a switch!) to ART.

Moreover, wont the fully compiled code use more storage space than what it previously used?

[Pritam Baral]

1) ART isn't finished product. It's not marketed as such either. Expect crashes. (It says so right on the switch too!)

2) Dalvik isn't slow because it is bulky or outdated. It is slow (if you really want to call it that) because it's a VM. Every VM incurs an overhead simply because of the added layer. The best VMs today can run code at 2x (slow) w.r.t. native.

3) Android isn't slow due to Dalvik. Look at the actual stats and benchmarks. You never hit the performance gap between native and VM in regular use. Android is slow (in use) more because of its massively multitasking nature, and because stupid apps abuse this right and hog the system (I'm looking at you Facebook..)

(Sidenote: if you hate apps hogging up your phone, but can't live without fat apps, look into Greenify. Requires root.)

4) JIT is great, JIT is awesome, JIT hardly affects 2% of the code. That 2% being really busy code.[1]

5) You can't have pre-compiled Android app binaries, simply because Android isn't a single, unified runtime (like iOS or Windows Phone). Android runs on all sorts of hardware (more differentiation than just arm v7, v7a, v8... x86). There has to be a single, unified bytecode that gets translated to hardware specific code after install. Already done with Dalvik.

6) Thanks to point above, developer workflows shouldn't change. Current developer workflow doesn't involve dalvik anyway. As long as ART is able to read bytecode for dalvik, in other words, as long as ART doesn't necessitate a new bytecode format, app developers shouldn't have to worry a thing.

7) ART's benchmarks show 2x speed improvements. Note that Dalvik is 4x slower than native, although the gap isn't noticeable in regular use. [2]

8) ART actually has two compiler backends, both Ahead-of-Time. And one of them is based on LLVM! (The new rockstar in the world of compilers) LLVM, with its more modular design, has managed to evolve at a very fast rate and take on the big guns (GCC, cl.exe) in a very short amount of time. Although most of LLVM's strengths seem inapplicable here.

9) ART is awesome! Strikes a good balance between portability and performance. But ART is not very innovative. There have been many successful attempts at speeding up Dalvik in the past, and evidence suggests ART itself might be from a group called Flexycore that Google bought.



[1]: http://dl.google.com/googleio/2010/android-jit-compiler-androids-dalvik-vm.pdf (Page 9.)
[2]: https://docs.google.com/spreadsheet/ccc?key=0AnE-DX9Fbr9KdFZtRlhQaWxmVG5XdDR3TFR1Q3JONnc&usp=sharing#gid=0

 

Regards,
Chhatoi Pritam Baral

--
--
The website for the club is http://stab-iitb.org/wncc
To post to this group, send email to wncc...@googlegroups.com
 
---
You received this message because you are subscribed to the Google Groups "Web and Coding Club IIT Bombay" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wncc_iitb+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Dilawar Singh]

In short, they are trying to do what cython does with python programs.

--
Dilawar
NCBS Bangalore
EE, IIT Bombay

[Dilawar Singh]

What the hell is Ahead-Of-Time? Its some sort of Rajnikanth thingy?

--
Dilawar
NCBS Bangalore
EE, IIT Bombay

On Thu, Nov 07, 2013 at 04:02:41PM +0530, Pritam Baral wrote:
>1) ART isn't finished product. It's not marketed as such either. Expect
>crashes. (It says so right on the switch too!)
>
>2) Dalvik isn't slow because it is bulky or outdated. It is slow (if you
>really want to call it that) because it's a VM. Every VM incurs an overhead
>simply because of the added layer. The best VMs today can run code at 2x
>(slow) w.r.t. native.
>
>3) Android isn't slow due to Dalvik. Look at the actual stats and
>benchmarks. You never hit the performance gap between native and VM in
>regular use. Android is slow (in use) more because of its massively
>multitasking nature, and because stupid apps abuse this right and hog the
>system (I'm looking at you Facebook..)
>(Sidenote: if you hate apps hogging up your phone, but can't live without
>fat apps, look into Greenify. Requires root.)
>
>4) JIT is great, JIT is awesome, JIT hardly affects 2% of the code. That 2%
>being really busy code.[1]
>
>5) You can't have pre-compiled Android app binaries, simply because Android
>isn't a single, unified runtime (like iOS or Windows Phone). Android runs
>on all sorts of hardware (more differentiation than just arm v7, v7a, v8...
>x86). There has to be a single, unified bytecode that gets translated to
>hardware specific code after install. Already done with Dalvik.
>

>6) Thanks to point above, *developer workflows shouldn't change*. Current

>developer workflow doesn't involve dalvik anyway. As long as ART is able to
>read bytecode for dalvik, in other words, as long as ART doesn't
>necessitate a new bytecode format, app developers shouldn't have to worry a
>thing.
>

>7) ART's benchmarks show *2x* speed improvements. Note that Dalvik is 4x

>slower than native, although the gap isn't noticeable in regular use. [2]
>
>8) ART actually has two compiler backends, both Ahead-of-Time. And one of
>them is based on LLVM! (The new rockstar in the world of compilers) LLVM,
>with its more modular design, has managed to evolve at a very fast rate and
>take on the big guns (GCC, cl.exe) in a very short amount of time. Although
>most of LLVM's strengths seem inapplicable here.
>
>9) ART is awesome! Strikes a good balance between portability and
>performance. But ART is not very innovative. There have been many
>successful attempts at speeding up Dalvik in the past, and evidence
>suggests ART itself might be from a group called Flexycore that Google
>bought.
>
>
>
>[1]:
>http://dl.google.com/googleio/2010/android-jit-compiler-androids-dalvik-vm.pdf(Page
>9.)
>[2]:
>https://docs.google.com/spreadsheet/ccc?key=0AnE-DX9Fbr9KdFZtRlhQaWxmVG5XdDR3TFR1Q3JONnc&usp=sharing#gid=0
>
>
>
>

>*Regards, Chhatoi Pritam Baral*

[Mayank Singhal]

> What the hell is Ahead-Of-Time? Its some sort of Rajnikanth thingy?

A Java AOT compiler will convert ByteCode into Machine code before the code is actually required. Doesn't seem that Rajnikanth-y.

Mayank Singhal

email to wncc_iitb+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
--
The website for the club is http://stab-iitb.org/wncc
To post to this group, send email to wncc...@googlegroups.com

---
You received this message because you are subscribed to the Google Groups "Web and Coding Club IIT Bombay" group.

To unsubscribe from this group and stop receiving emails from it, send an email to wncc_iitb+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
--
The website for the club is http://stab-iitb.org/wncc
To post to this group, send email to wncc...@googlegroups.com

--- You received this message because you are subscribed to the Google Groups "Web and Coding Club IIT Bombay" group.

To unsubscribe from this group and stop receiving emails from it, send an email to wncc_iitb+unsubscribe@googlegroups.com.

[$udhi :)]

On Thursday, November 7, 2013 5:32:41 AM UTC-5, chhatoipritam wrote:

7) ART's benchmarks show 2x speed improvements. Note that Dalvik is 4x slower than native, although the gap isn't noticeable in regular use. [2]

 

Was looking at the benchmark and couldn't help but notice the large spike for ART at 62000. Any insights on that? Or just an outlier/error?

Cheers,

-Sudhi

[Dilawar Singh]

Then you are anyway delaying the execution of application. Can't see a reason
why this is not a better JIT.

--
Dilawar
NCBS Bangalore
EE, IIT Bombay

>>> http://dl.google.com/googleio/2010/android-jit-compiler-
>>> androids-dalvik-vm.pdf(Page
>>> 9.)
>>> [2]:
>>> https://docs.google.com/spreadsheet/ccc?key=0AnE-
>>> DX9Fbr9KdFZtRlhQaWxmVG5XdDR3TFR1Q3JONnc&usp=sharing#gid=0
>>>
>>>
>>>
>>>

>>>> email to wncc_iitb+...@googlegroups.com.

>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>
>>>>
>>> --
>>> --
>>> The website for the club is http://stab-iitb.org/wncc
>>> To post to this group, send email to wncc...@googlegroups.com
>>>
>>> ---
>>> You received this message because you are subscribed to the Google Groups
>>> "Web and Coding Club IIT Bombay" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an

>>> email to wncc_iitb+...@googlegroups.com.

>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>
>> --
>> --
>> The website for the club is http://stab-iitb.org/wncc
>> To post to this group, send email to wncc...@googlegroups.com
>>
>> --- You received this message because you are subscribed to the Google
>> Groups "Web and Coding Club IIT Bombay" group.
>> To unsubscribe from this group and stop receiving emails from it, send an

>> email to wncc_iitb+...@googlegroups.com.

>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>--
>--
>The website for the club is http://stab-iitb.org/wncc
>To post to this group, send email to wncc...@googlegroups.com
>
>---
>You received this message because you are subscribed to the Google Groups "Web and Coding Club IIT Bombay" group.

>To unsubscribe from this group and stop receiving emails from it, send an email to wncc_iitb+...@googlegroups.com.

[Pritam Baral]

@Dilawar: Its not a JIT. Period. Its a compiler (, well, technically TWO compilers.) The "delaying the execution" bit you talk about happens with every compiler. GCC compiling C/C++ doesn't execute the program, that comes later. Nothing supernatural about the old idea of compiling.

The phrase "Ahead-of-Time" is unnecessary, but when talking about JIT on already compiled code, simply saying "compiling" can be confusing, hence the redundant phrase.

This is also not like Cython. From what I found, Cython generates C code from raw (superset of) Python, which then has to be compiled externally to Cython. ART generates final machine code, from already compiled bytecode. Cython is more comparable to the dex compiler that generates this bytecode than to ART, although I wouldn't agree on it.

@Sudhi: I haven't run the benchmarks myself. There's a link to the source. The spike seems like a compiler error, being consistent across runs.
Obligatory: ART is still alpha software.

 

Regards,
Chhatoi Pritam Baral

email to wncc_iitb+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
--
The website for the club is http://stab-iitb.org/wncc
To post to this group, send email to wncc...@googlegroups.com

---
You received this message because you are subscribed to the Google Groups
"Web and Coding Club IIT Bombay" group.
To unsubscribe from this group and stop receiving emails from it, send an

email to wncc_iitb+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
--
The website for the club is http://stab-iitb.org/wncc
To post to this group, send email to wncc...@googlegroups.com

--- You received this message because you are subscribed to the Google
Groups "Web and Coding Club IIT Bombay" group.
To unsubscribe from this group and stop receiving emails from it, send an

email to wncc_iitb+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
--
The website for the club is http://stab-iitb.org/wncc
To post to this group, send email to wncc...@googlegroups.com

---
You received this message because you are subscribed to the Google Groups "Web and Coding Club IIT Bombay" group.

To unsubscribe from this group and stop receiving emails from it, send an email to wncc_iitb+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
--
The website for the club is http://stab-iitb.org/wncc
To post to this group, send email to wncc...@googlegroups.com

--- You received this message because you are subscribed to the Google Groups "Web and Coding Club IIT Bombay" group.

To unsubscribe from this group and stop receiving emails from it, send an email to wncc_iitb+unsubscribe@googlegroups.com.

[Dilawar Singh]

On Fri, Nov 08, 2013 at 11:00:30AM +0530, Pritam Baral wrote:
>@Dilawar: Its not a JIT. Period. Its a compiler (, well, technically TWO
>compilers.) The "delaying the execution" bit you talk about happens with
>every compiler. GCC compiling C/C++ doesn't execute the program, that comes
>later. Nothing supernatural about the old idea of compiling.

Here is my mental picture of this model.


SOURCE CODE --- compiler et al. ---> ASSEMBLY FOR PROCESSOR
(user run it at t=0)

In C, this is a one step process (more or less). I can now run my application
on processor with some help from Operating System. That is my baseline to
compare other processes of compilation (generation of assembly for processor).
Ultimately all things run on processor.

Here is JIT,

SRC -- compiler ----> VM Byte Code
|
User run it at t=0 in VM
|
|
v
JIT prepares assembly
From byte code to assembly;
so that VM does not run it.
Processor can execute it
faster. Calling it JIT is OK!

Its a two step process by design and one can understand why they are trying to
minimize the time taken by second process or approximate it to one step process.

Ahead-Of-Time; I would expect that "something" (compiler et al.) prepares the
machine code before user try to run it at t=0; If there is no prediction going
on about when user will run the application and they prepare the assembly from
byte-code well before user run it, then calling it Ahead-Of-Time is non-sense;
unless they put (t=0) at the bytecode -> assembly conversion part and not at
"user try to the app".

--
Dilawar