www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - [OT] The ART runtime presentation at Google I/O 2014

reply Paulo Pinto <pjmlp progtools.org> writes:
Hi,

posting this talk here, as Java performance on Android is often 
mentioned in the discussions about GC vs RC performance.

So here you have the Android  team explaining:

- Dalvik GC sucks and is a basic stop the world implementation with 
pauses > 10ms

- ART solves the GC issue by adopting multiple concurrent GC algorithms,
depending on the application state thus reducing the stop down to 3ms. 
More optimizations still to be done until the final release

- JIT compiler optimized for battery life and low power processors, thus 
only very hot methods get actually compiled to native code

- Performance sorted out, by doing AOT compilation on install, similar 
to approach taken by OS/400, Windows Phone 8

https://www.youtube.com/watch?v=EBlTzQsUoOw



--
Paulo
Jun 27 2014
next sibling parent reply "Kagamin" <spam here.lot> writes:
BTW, how GC compares to RC with respect to battery life? All 
those memory scans don't come for free.
Jun 28 2014
parent Paulo Pinto <pjmlp progtools.org> writes:
Am 28.06.2014 14:42, schrieb Kagamin:
 BTW, how GC compares to RC with respect to battery life? All those
 memory scans don't come for free.

I don't know, but given the focus to battery life in the upcoming Android release I would say it should be good enough. My S3 with Dalvik can last almost two days with occasional network usage. My older Android phone, an operator specific model running 2.2, can last almost four days. -- Paulo
Jun 28 2014
prev sibling parent "w0rp" <devw0rp gmail.com> writes:
On Saturday, 28 June 2014 at 06:23:25 UTC, Paulo Pinto wrote:
 Hi,

 posting this talk here, as Java performance on Android is often 
 mentioned in the discussions about GC vs RC performance.

 So here you have the Android  team explaining:

 - Dalvik GC sucks and is a basic stop the world implementation 
 with pauses > 10ms

 - ART solves the GC issue by adopting multiple concurrent GC 
 algorithms,
 depending on the application state thus reducing the stop down 
 to 3ms. More optimizations still to be done until the final 
 release

 - JIT compiler optimized for battery life and low power 
 processors, thus only very hot methods get actually compiled to 
 native code

 - Performance sorted out, by doing AOT compilation on install, 
 similar to approach taken by OS/400, Windows Phone 8

 https://www.youtube.com/watch?v=EBlTzQsUoOw



 --
 Paulo

I like his focus on the duration of frames per second. If you are aiming for 60FPS, you are aiming for a time period of about 16ms to 17ms per frame. So he mentions the current Dalvik GC occupying about 10ms for a collection in most cases, leading to a single dropped frame, and a near full memory case leading to about 50ms and above, leading to a few dropped frames. So when thinking about optimising GC, aiming for a collection time small enough to fit comfortably inside a frame seems like a good way to think about it.
Jun 28 2014