Optimización del compilador - la evolución del arte

Previo a Android 5.0, Dalvik era entorno de ejecución de Android. Se utilizó un Just-In-Time (JIT) que compila las porciones del código de bytes cada vez que el programa se ha ejecutado, justo a tiempo para que pueda ser utilizado. Sin embargo todo cambió con Android 5.0 Lollipop y la liberación de ART.

El tiempo de ejecución de Android (ART) trajo un montón de mejoras en el rendimiento de aplicaciones, la recolección de basura, y el desarrollo / depuración, al alejarse de just-in-time (JIT) código de compilación de Dalvik a mixta antes de tiempo (AOT) compilación. ART fue ofrecido originalmente como una opción de desarrollador en KitKat, pero sustituyó oficialmente Dalvik como el compilador por defecto con el lanzamiento de Android Lollipop.

Sin embargo, para facilitar un movimiento ágil el relevo de Dalvik al TAR, Android Lollipop hace uso de un compilador conocido como 'rápido', que es realmente una versión AOT del compilador JIT Dalvik.

Al tiempo que ofrece algunas mejoras sobre Dalvik, rápida no está a la vanguardia de la tecnología de compilación. Para mejorar aún más las cosas, ARM y Google están trabajando estrechamente en un nuevo 'Optimizar' compilador para Android, que cuenta con más modernas tecnologías, incluyendo soporte totalmente optimizado para AArch64 backend de ARM. El nuevo compilador también permitirá nuevas optimizaciones para añadir fácilmente en futuras versiones.

El compilador de optimización optimiza tanto para AArch32 y AArch64 (32 y 64 bits) por separado, dependiendo de la plataforma. ARM están haciendo un montón de trabajo en AArch64, mientras que Google está desarrollando el backend AArch32.

A diferencia de Quick, Optimización está siendo totalmente reconstruido desde cero con el fin de producir la calidad del código superior a través de una serie de optimizaciones. Esto se logra mediante cambios en la representación intermedia (IR), en lugar de utilizar dos niveles de IR como en Quick, optimizando utiliza sólo uno. Mediante la aplicación de transformaciones IR progresivamente, Optimización debe ser mejor en la eliminación de código muerto, se puede añadir en el plegamiento constante, y la numeración de valor global.

Otra mejora importante viene en forma de una mejor asignación de registro. Quick tiene un algoritmo muy simple, que se dirige a la velocidad más que la complejidad, pero esto resulta en una gran cantidad de registros que se derraman a la pila. Optimización deja atrás a Linear Scan Registro de Asignación, que es un poco más lento en tiempo de compilación, pero ofrece un mejor rendimiento en tiempo de ejecución. La tecnología minimiza los derrames de registro mediante la realización de "análisis liveness 'a mejores culos que los registros están en uso activo en cualquier momento. Con menos registros para guardar en la pila y un mejor uso de los registros disponibles, hay menos código a ejecutar, y eso significa un mayor rendimiento.

Un ejemplo dado en el Día Tech de ARM en Londres la semana pasada muestra cómo el uso de tres variables puede reducirse a sólo dos registros, por darse cuenta de que 'c' es realmente innecesario. Si te fijas bien en el diagrama se verá que el paso 3 es "c = b * b" y el paso 4 es "b = c + 1". En realidad, esto puede ser optimizado para "b = b * b" y "b = b + 1" y obtendrá exactamente el mismo resultado, sin embargo, el código será más rápido ya que sólo dos registros se utilizará en lugar de 3.

Desarrollo de optimizar aún está en curso, pero ya muestra mejoras significativas en el rendimiento, de hasta 40 por ciento en un punto de referencia. El único inconveniente es un aumento del 8 por ciento en la velocidad de compilación y un aumento del 10 por ciento en el tamaño del archivo, a causa de metadatos adicionales utilizados por el compilador. Aunque éstos podrían reducirse en el futuro.

Si todo esto se está preguntando cuando será capaz de beneficiarse de Optimización, la respuesta es antes de lo que usted puede pensar. Optimización es ahora el compilador por defecto para aplicaciones en la rama AOSP, aunque rápido todavía se utiliza para algunos métodos y compilar la imagen de arranque. Parches para apoyar y optimizar las arquitecturas específicas, como Cortex-A53 o Cortex-A57, también se encuentran en las obras.

Espero que vamos a oír mucho más acerca de los planes para la optimización en Google I / O 2015, que tendrá lugar del 28 de mayo^º a 29^º en San Francisco.