Romain Guy au LyonJUG pour parler performance et Android

Ce n'est pas tous les jours que le Jug accueille une pointure internationale. Romain Guy est ingénieur Google et il a grandement contribué à la mise en place d'Andoid notamment sur les couches graphiques et certaines applications du SDK. Basé dans la Silicon Valley, il a rejoint l'équipe travaillant sur la robotique. Comme ce projet est secret chez Google il n'a pas été plus loin sur le sujet.

Romain a fait ses études à l'INSA Lyon et le Jug affichait salle comble malgré le fait que la session se déroule un vendredi soir. Beaucoup d'étudiants étaient présents dans la salle, peut être pour savoir comment un français avait pu se faire connaître par un mastodonte comme Google.




Romain est un habitué des conférences et ça se voit tout de suite (même avec une crève et le décalage horaire...)

La session s'est déroulée en deux parties. Une première partie sur les performances et une seconde partie avec questions ouvertes sur Google, Android...

Les performances

Dans un projet nous avons toujours tendance a décaler le problème des performances à la fin, voir juste avant la mise en production. Sauf que si ces problèmes sont importants ou s'ils remettent en cause l'architecture, ce n'est pas possible de revenir dessus avant une autre release majeure.

Même si Romain ne l'a pas dit c'est un peu l'histoire d'Android. Les performances n'ont pas été un sujet primordial au départ et la volonté était surtout de proposer un système aussi riche que ce que faisait Apple avec son IOS. Aujourd'hui les choses sont en train de changer car Google comme Apple savent très bien que les performances et les améliorations de l'autonomie des téléphones seront des atouts majeurs pour prendre ou garder le leadership sur le marché des devices.

Quand on parle de performances nous pensons souvent à la latence (le temps d'affichage ou d’exécution). Mais sur des applications grand public d'autres points sont importants comme la scalabilité. La scalabilité correspond à l'augmentation des instances, mais aussi à l'augmentation des fonctionnalités. Sur Android des problèmes sont apparus quand les fonctionnalités se sont démultipliées. Les anciens téléphones n'étaient pas capable de suivre.

Les ressources matérielles sont primordiales et souvent non prises en compte. Il est vrai que ceci dépend du contexte. Sur un téléphone plus le CPU sera sollicité plus la batterie se déchargera vite (même s'il faut garder à l'esprit que la plus grosse consommation de la batterie est lié à l'écran quand ce dernier est allumé). Mais au delà d'un téléphone, l'optimisation des ressources peut être aussi importante au niveau des applications serveurs, et notamment si ces dernières sont installées dans le cloud (les tarifs sont appliqués en fonction des ressources utilisées).

Au niveau d'Android, la direction avait demandé à l'équipe d'augmenter considérablement les performances pour la version Jelly Bean (4.1). L'objectif initial était de faire un x 100 sur les performances (project butter). Quand on est devant un objectif aussi ambitieux, il est difficile de savoir par où commencer. Et c'est encore plus vrai lorsqu'aucun goulet d'étranglement ne se distingue, que tout a déjà été passé en revu, que tout semble optimisé...

Dans les problèmes de performances il n'existe pas de recette miracle. Les solutions viennent d'elles mêmes et sont parfois bizarres et non intuitives. Pour illustrer ceci, Romain a pris l'exemple du code pour calculer une multiplication de matrice de 1024 par 1024. Cette opération est assez courante dans les applications graphiques 2D ou 3D.

Une multiplication de deux matrices consiste en une imbrication de 3 boucles. Dans un test de performances, le contexte d'exécution est très important car les résultats peuvent être différents d'une machine à l'autre (architecture du processeur, mémoire, puissance...).

Le calcul initial du code en Java prenait 10,6 sec. Mais en Java la JVM effectue beaucoup d'optimisation que l'on ne peut pas connaître. Il a donc réécrit son code en C++ pour bénéficier des outils bas niveaux, permettant par exemple de savoir l'utilisation du processeur, de la RAM et des différents caches (L1, L2 ou L3).

L'exécution du programme C++ est dans le même ordre de grandeur en 9,6 sec (une application exécutée sur une JVM est capable de se rapprocher des performances d'une application native). Si ce calcul se fait en 10 secondes, la machine a exécuté 6 mips (mips = million d'instruction par seconde). Son IBook étant capable de faire 8000 mips on peut voir que l'on peut s'améliorer.

En analysant les couches basses pour voir ce que le processeur faisait au niveau de la mémoire et du cache, Romain a améliorer les performances en cassant son algorithme de départ pour mieux et moins utiliser la mémoire. En gros après plusieurs optimisations le code devient 40 fois plus rapide.

L'exemple n'est pas plus intéressant qu'un autre et c'est pourquoi je n'ai pas montrer de code. Ce qui est important c'est la démarche. Nous avions un algorithme de départ qui n'était pas performant. La solution ici (j'insiste pour dire que ce n'est pas une règle générale et que chaque cas est différent) était de casser cet algorithme correct et optimisé pour s'adapter au processeur de la machine pour qu'il utilise moins de mémoire.

Il est intéressant de noter que les processeurs sont de plus en plus puissants et que les accès mémoires sont lents. En ordre de grandeur si une opération prend

• une unité sur  un processeur elle prendra
• 3 unités sur un cache L1
• 9 sur un cache L2
• 43 sur un cache L3
• 360 en RAM 

Lorsque nous avons besoin de revoir les performances d'une application, les problèmes sont souvent beaucoup plus simples et liés à notre code. Dans le cas d'une application Android vous pouvez utiliser Systrace qui permet de faire un état des lieux du système.

La partie question/réponse

Je ne relate ici que celles qui m'intéressaient.

Pourquoi faire des applications natives plutôt que des applications web ? 

C'était intéressant d'avoir le point de vue d'un ancien membre de l'équipe Android. Je suppose qu'une personne de l'équipe Chrome aurait défendu le web. Romain lui croit aux applications natives car il est illusoire de penser qu'un seul outil puisse générer des applications qui puissent utiliser correctement toutes les ressources et être performantes. Web GL est très bien mais il est loin des performances que l'on peut avoir en Open GL. Toutes les couches d'abstraction apportent de la simplification, mais rajouter des couches va toujours à l'encontre des performances. 

Pourquoi avoir choisi le langage Java sous Android ?

Il y a plusieurs raisons. La première c'est que Google voulait attirer le maximum de gens vers la plate-forme. Java a plusieurs atouts qui vont dans ce sens

• une forte communauté
• de nombreux outils gratuits
• un langage performant et qui a l'avantage d'être lisible même s'il est parfois un peu verbeux

Les applications en Java sont plus accessibles que des applications en C++ ou Scala par exemple. Après si l'on veut des performances (dans les jeux par exemple), vous avez toujours la possibilité de faire du C. 

Avec Groovy qui peut maintenant être utilisé, les développeurs ont le choix entre plusieurs langages. 

Est il toujours possible de participer à Android ?
Romain a été clair sur le sujet. Oui Android est un projet Open Source pour une bonne partie et ça ne devrait pas changer dans le futur. Tout le monde peut contribuer. 

Le système via pull request est primordial chez Google. Google utilise plusieurs outils dont Gerrit par exemple pour faire de la revue de code en interne. C'est une pratique essentielle pour détecter des bugs ou des problèmes d'architecture en amont. De plus faire du code review permet de voir comment les autres ont résolu des problèmes et permet de s'améliorer soi même. 

Voila merci Romain d'avoir participé au LyonJug