Compilateur optimisant - l'évolution de l'art

Android logo mwc 2,015 barcelona 3

La langue d'Android est de Java et Java est légèrement différente pour d'autres langages de programmation traditionnels populaires en ce qu'il compile à un code intermédiaire (souvent connu comme bytecode) et non à la machine-code natif de la plate-forme cible. Par conséquent, pour exécuter un programme Java sur une plate-forme vous avez besoin d'un environnement de temps d'exécution.

Avant Android 5.0, Dalvik est l'environnement d'exécution d'Android. Il a utilisé un Just-In-Time (JIT) qui a compilé des parties du bytecode chaque fois que le programme a été exécuté, juste à temps pour qu'il puisse être utilisé. Cependant tout a changé avec Android 5.0 Lollipop et la libération de ART.

Le Runtime Android (ART) a apporté de nombreuses améliorations à la performance de l'application, la collecte des ordures, et le développement / débogage, en déplaçant loin de juste-à-temps (JIT) Code compilation de Dalvik pour mixte avant-des-temps (AOT) compilation. ART a été offert à l'origine comme une option de développeur dans KitKat, mais officiellement remplacé Dalvik comme compilateur par défaut avec le lancement d'Android Lollipop.

Toutefois, afin de faciliter un mouvement vif au-dessus de Dalvik à ART, Android Lollipop fait usage d'un compilateur connu comme 'Quick', qui est vraiment une version de AOT du compilateur JIT Dalvik.



Tout en offrant des améliorations plus Dalvik, Quick est pas à la fine pointe de la technologie de compilateur. Pour améliorer encore les choses, ARM et Google travaillent en étroite collaboration sur un nouveau 'Optimisation' compilateur pour Android, qui propose plus à technologies de pointe, y compris un soutien entièrement optimisé pour AArch64 backend ARM. Le nouveau compilateur permettra également de nouvelles optimisations pour être facilement ajoutés dans les prochaines versions.

L'optimisation du compilateur optimise à la fois pour AArch32 et AArch64 (32 et 64 bits) séparément, en fonction de la plate-forme. ARM sont fait beaucoup de travaux sur AArch64, tandis que Google développe le backend AArch32.

Vs rapide compilateur d'optimisation

Contrairement rapide, l'optimisation est entièrement reconstruit à partir de zéro afin de produire une qualité de code à travers une gamme d'optimisations. Ceci est accompli par des changements à la représentation intermédiaire (RI), au lieu d'utiliser deux niveaux IR comme dans rapide, optimisation utilise un seul. En appliquant des transformations IR progressivement, Optimisation devrait être mieux à éliminer code mort, peut ajouter dans le pliage constante, et la numérotation de valeur mondiale.

Une autre amélioration importante est livré sous la forme d'une meilleure allocation de registre. Rapide a un algorithme très simple, qui vise la vitesse plutôt que la complexité, mais il en résulte beaucoup de registres étant déversées dans la pile. Optimisation se déplace de manière linéaire de numérisation allocation de registres, ce qui est légèrement plus lent au moment de la compilation, mais offre une meilleure performance d'exécution. La technologie minimise les déversements de registre en effectuant 'analyse vivacité »pour mieux évaluer quels registres sont en utilisation active à tout moment. Avec moins de registres d'économiser sur la pile et une meilleure utilisation des registres disponibles, il ya moins de code à exécuter, ce qui signifie une plus grande performance.



Optimisation registre exemple d'attributionUn exemple donné à Tech Day ARM à Londres la semaine dernière montre comment l'utilisation de trois variables peut être réduite à seulement deux registres, en réalisant que «c 'est en fait inutile. Si vous regardez de près le schéma, vous verrez que l'étape 3 est "c = b * b» et l'étape 4 est "b = c + 1". Cela peut effectivement être optimisé pour "b = b * b» et «b = b + 1" et vous obtiendrez exactement le même résultat, mais le code sera plus rapide que seulement deux registres sera utilisé plutôt que 3.

Développement de l'optimisation est toujours en cours, mais il montre déjà des améliorations significatives dans les performances, jusqu'à 40 pour cent en un indice de référence. Le seul inconvénient est une augmentation de 8 pour cent de la vitesse de compilation et une augmentation de 10 pour cent de la taille du fichier, en raison de métadonnées supplémentaire utilisé par le compilateur. Bien que ceux-ci pourraient être réduits à l'avenir.

Optimisation vs Benchmark rapide

Si tout cela vous a demandais quand vous serez en mesure de bénéficier de l'optimisation, la réponse est plus tôt que vous ne le pensez. Optimisation est maintenant le compilateur par défaut pour les applications dans le secteur du PSBA, bien que rapide est encore utilisé pour certaines méthodes et la compilation de l'image de démarrage. Correctifs pour soutenir et optimiser les architectures spécifiques, tels que le Cortex-A53 ou A57 Cortex-, sont également dans les œuvres.

Nous espérons entendre beaucoup plus sur les plans pour l'optimisation au Google I / O 2015, qui aura lieu du 28 maie à 29e à San Francisco.




» » » Compilateur optimisant - l'évolution de l'art