Cet article est issu du blog JavaScript de Mozilla. L’article original a été écrit en anglais par David Anderson.

Depuis le lundi 12 septembre, IonMonkey, notre nouveau compilateur JavaScript à la volée, est arrivé dans Firefox 18. IonMonkey représente un grand pas en avant pour nos performances sur JavaScript et pour notre architecture de compilation. En outre, c’est un projet de longue haleine, lancé depuis plus d’un an par l’équipe dédiée à ce compilateur, et nous sommes hyper excités de le voir arriver.

SpiderMonkey a une histoire chargée en matière de compilateurs à la volée. Cependant, pour chacun d’entre eux, il nous a manqué un composant clé que l’on trouve dans la plupart des compilateurs du marché, comme ceux pour Java ou C++. L’ancien TraceMonkey*, ainsi que le récent JägerMonkey, réalisent tous deux une simple translittération de JavaScript vers du code machine. Il n’y a aucune étape intermédiaire. Le compilateur n’a aucun moyen de prendre du recul et d’analyser le résultat d’une transformation, afin de l’améliorer autant que possible.

IonMonkey fournit une nouvelle architecture qui permet de réaliser des opérations d’optimisation. En voici les trois étapes principales :

— Transformation du code JavaScript en une représentation intermédiaire ;

— Optimisation globale de cette représentation ;

— Transformation de cette dernière en code machine.

Nous sommes particulièrement enthousiastes car cela nous permet non seulement d’avoir de meilleures performances et de simplifier la maintenance, mais cela rend aussi la recherche sur les compilateurs JavaScript plus aisée. Il est désormais possible d’écrire une phase d’optimisation, de la brancher sur le compilateur, et de voir ce qui se passe.

Tests de performances

Ceci dit, comment se comporte IonMonkey vis-à-vis de nos tests de performances ? IonMonkey vise principalement les applications qui sont exécutées pendant une longue période de temps ; JägerMonkey est conservé pour ceux avec une courte durée d’exécution. David Anderson a fait tourner les tests de performances « Kraken » et « Google V8 » sur son ordinateur (un Mac Pro sur lequel tourne Windows 7 Professionnel).

Sur les tests de performances de Kraken, Firefox 17 donne un score de 2602ms, là où Firefox 18 obtient 1921ms, soit environ 26% de gain. Sur l’histogramme suivant, les temps sont convertis en nombre d’exécutions par minute (la plus grande valeur représente le meilleur résultat).

Kraken

Sur le test « Google V8 », Firefox 15 obtient un score de 8474 et Firefox 17 un score de 9511. Firefox 18, de son côté, obtient un score de 10188, ce qui le rend 7% plus rapide que Firefox 17 et 20% plus rapide que Firefox 15. Nous avons encore un long chemin à parcourir : dans les prochains mois, équipés de notre belle architecture, nous allons continuer à travailler dur sur les principaux tests de performances, ainsi que sur les applications réelles.

Google V8

L’équipe

Pour nous, un des aspects les plus cools de IonMonkey vient de l’intense travail d’équipe, extrêmement coordonné, qui a eu lieu. Aux alentours de juin 2011, nous avons défini une sorte de plan et avons déterminé qu’il faudrait environ une année pour le réaliser. Nous avons commencé avec quatre stagiaires — Andrew Drake, Ryan Pearl, Andy Scheff et Hannes Verschore — chacun implémentant des composants critiques de l’infrastructure de IonMonkey que l’on retrouve toujours dans le code final.

Fin août 2011, nous avons commencé à mettre en place l’équipe définitive, qui inclut à présent Jan de Mooij, Nicolas Pierron, Marty Rosenberg, Sean Stangl, Kannan Vijayan et David Anderson (il serait également malvenu d’oublier de citer Chris Leary, un ancien de SpiderMonkey, ainsi qu’Eric Faust, stagiaire pendant l’été 2012). Pendant l’année écoulée, l’équipe s’est concentrée pour faire avancer IonMonkey, en mettant en place son architecture et en s’assurant que sa conception et la qualité de son code étaient ce qu’ils pouvaient faire de mieux, tout ça pour améliorer les performances de JavaScript.

C’est particulièrement gratifiant de voir tout le monde partager le même but et travailler ensemble pour faire d’un projet un succès. Nous pouvons remercier tous ceux qui y ont pris part.

La technique

Au cours des semaines à venir, plusieurs articles vont être publiés sur les principaux composants de IonMonkey, expliquant le fonctionnement de chacun. En bref, ils vont mettre en valeur les techniques d’optimisation actuellement présentes dans IonMonkey :

— Déplacement des invariants de boucle (en anglais Loop-Invariant Code Motion, soit LICM), c.-à-d. déplacer des instructions en dehors des boucles quand cela est possible.

— Indexation globale de valeurs éparpillées (en anglais Sparse Global Value Numbering, soit GVN), c.-à-d. un moyen puissant pour supprimer du code redondant.

— Allocation de registre par examen linéaire (en anglais Linear Scan Register Allocation, soit LSRA), c.-à-d. le même système d’allocation de registre que celui utilisé par la machine virtuelle Java « HotSpot » (et encore récemment par LLVM)

— Élimination de code mort (en anglais Dead Code Elimination, soit DCE), c.-à.d- supprimer des morceaux de code qui ne sont jamais exécutés.

— Analyse d’intervalles (en anglais Range Analysis), c.-à-d. prédire l’étalement des données, ce qui permet de supprimer les tests de dépassement.

Parmi les choses à noter, il faut souligner que IonMonkey fonctionne sur toutes les plateformes prioritaires de Mozilla (Android Arm v7, Linux x86/x64, OS X x86/x64 et Windows x86, voir Tier-1). Le design du compilateur est suffisamment abstrait et nécessite peu de duplications du générateur de code au travers des différentes architectures. Cela signifie qu’une grande partie du compilateur est partagée entre x86, x86-64 et ARM (l’unité centrale utilisée par la plupart des téléphones et tablettes). De manière générale, seule l’interface de l’assembleur est différente. Étant donné que toutes les unités centrales ont des jeux d’instructions différents, ARM étant totalement différent de x86, nous sommes particulièrement fiers de cette réalisation.

Où et quand ?

IonMonkey est activé par défaut dans la version bureau de Firefox 18, qui est, au moment où nous écrivons ces lignes, la version Aurora de Firefox. Il sera également activé sur téléphone mobile prochainement. Firefox 18 sera disponible sur le canal Bêta à partir du 20 novembre, et arrivera en version stable en début d’année prochaine.



* TraceMonkey disposait d’une représentation intermédiaire. Cependant, elle était très limitée. Les optimisations devaient être faites immédiatement et le format des données ne pouvait pas être manipulé après la phase d’optimisation.