digitalmars.D - [OT] The ART runtime presentation at Google I/O 2014
- Paulo Pinto (16/16) Jun 27 2014 Hi,
- Kagamin (2/2) Jun 28 2014 BTW, how GC compares to RC with respect to battery life? All
- Paulo Pinto (8/10) Jun 28 2014 I don't know, but given the focus to battery life in the upcoming
- w0rp (10/29) Jun 28 2014 I like his focus on the duration of frames per second. If you are
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
BTW, how GC compares to RC with respect to battery life? All those memory scans don't come for free.
Jun 28 2014
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
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 -- PauloI 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