Cela vaut-il la peine de créer un bytecode web universel ? LLVM est-il la solution ? Qui est le meilleur pour exécuter du code natif dans le navigateur : Mozilla asm.js ou Google pNaCl ? Cet article contient des opinions exprimées sur le web sur ces questions.
Un commentaire par Raniz sur un billet d'ArsTechnica concernant les codecs vidéo écrits en JavaScript a déclenché une série de réactions dans la section des commentaires et sur le web. Raniz a suggéré un "bytecode standard pour les navigateurs ce qui permettrait (probablement) aux développeurs un large éventail de langages à choisir", laissant aux développeurs la possibilité de choisir le langage qu'ils aiment pour la programmation web, sans avoir à utiliser JavaScript. Le bytecode serait, comme la JVM ou le bytecode CLR, une plate-forme commune pour le développement web. L'idée semble intéressante à première vue, et certains ont même suggéré d'utiliser le code binaire de LLVM comme bytecode intermédiaire. Il existe déjà des compilateurs LLVM pour de nombreux langages, y compris ActionScript, Ada, D, Fortran, Haskell, le bytecode Java, Objective-C, Python, Ruby, Rust, Scala et C#.
Le principal problème avec le bytecode LLVM, c'est qu'il dépend de la cible, c’est-à-dire que le bytecode généré pour différentes architectures est différent, contrairement au bytecode Java qui est identique pour les différentes cibles, la JVM prenant soin de générer du code natif pour la machine sur laquelle elle s'exécute. Et il y a une série d'autres problèmes avec un bytecode web universel, certains d'entre eux qui le sont aussi pour LLVM (plus de détails ici), des problèmes relevés par msclrhd dans son commentaire, duquel nous extrayons quelques extraits :
Le problème avec la standardisation sur un bytecode est que vous limitez la façon dont le navigateur permet d'optimiser le code JavaScript...
Vous avez également le problème de savoir quel bytecode standardiser - chaque moteur JavaScript aura un ensemble différent de bytecode avec une sémantique différente. Tous les moteurs devront se mettre d'accord sur le bytecode à utiliser.
Il y a aussi d'autres considérations comme la représentation de chaîne de caractères qui diffère entre les moteurs (V8/Chrome a une variante d'ASCII; Mozilla maintient tout en UTF-16) et la représentation de type (par exemple Firefox a "fatvals" qui sont des types de valeur 64 bits avec 32 bits pour le type et 32 bits pour la valeur; les doubles 64 bits profitent de la représentation des valeurs NaN ...)
Si le bytecode est binaire, vous avez des problèmes "endian", les questions de représentation en virgule flottante, etc.
Alon Zakai, un chercheur de Mozilla travaillant sur Emscripten et asm.js, a écrit tout un billet de blog sur un bytecode web universel, décrivant certaines des difficultés dans la poursuite d'un tel objectif :
Certaines personnes veulent un bytecode, d'autres en veulent un autre, pour des raisons diverses. Certaines personnes aiment juste les langages sur une VM plus qu'une autre. Certaines machines virtuelles de bytecode sont propriétaires ou brevetées ou étroitement contrôlées par une seule société, et certaines personnes n'aiment pas certaines de ces choses. Donc, nous n'avons pas vraiment un candidat pour un bytecode universel unique pour le web. Ce que nous avons est un espoir pour un bytecode idéal - et plusieurs candidats potentiels.
Zakai a également fait une liste des exigences auxquelles un tel bytecode doit répondre :
- Soutenir tous les langages
- Exécuter le code rapidement
- Être une cible de compilation pratique
- Avoir un format compact pour le transfert
- Être normalisé
- Être indépendant de la plateforme
- Être sécurisé
Alors que Zakai ne donne pas beaucoup de chance à un nouveau bytecode pour répondre aux besoins, il voit JavaScript comme le bon candidat : « sans doute JavaScript est déjà très proche de fournir ce qu'on attend d'une VM bytecode, comme indiqué dans les 7 exigences ci-dessus », mentionnant aussi ce qui manque encore dans JavaScript :
À ce stade, les principales pièces manquantes sont, en premier (comme déjà mentionné) améliorer le support de langages qui ne sont pas encore complètement matures, et la seconde, quelques limitations de la plateforme qui affectent les performances, notamment le manque de SIMD et des threads avec partage d'état.
JavaScript peut-il combler les lacunes de SIMD et des threads mutables ? Le temps le dira, et je pense que ces choses demanderaient un effort important, mais je crois qu'il est clair que normaliser JavaScript serait plus simple et plus réaliste que de normaliser un nouveau bytecode complètement.
Après avoir présenté qu'il y avait plus de difficultés à créer une machine virtuelle universelle - conflits de type entre les langages, les questions de garbage collector - Zakai conclut :
Donc je ne pense pas qu'il y ait beaucoup à gagner, techniquement parlant, de considérer un nouveau bytecode pour le web. Le seul avantage évident qu'une telle approche pourrait donner, c'est peut-être une solution plus élégante, si nous avions commencé à partir de zéro et avions conçu une nouvelle solution avec moins d'historiques. C'est une idée séduisante, et en général l'élégance conduit souvent à de meilleurs résultats, mais comme mentionné plus tôt, il n'y aurait probablement pas d'avantages techniques importants à l'élégance dans ce cas particulier - de sorte que ce ne serait élégant que pour l'amour de l'élégance même.
Bien qu'il semble que le bytecode universel n'ait que peu de chances de réussir, il y a toujours au moins deux grandes tentatives d'amener d'autres langages sur le web. Toutes deux ont commencé avec C/C++, mais ces efforts peuvent être relativement facilement étendu à d'autres langages, et, curieusement, les deux utilisent LLVM:
- Mozilla: C/C++ –> LLVM bitcode –> Emscripten –> asm.js –> Navigateur
- Google: C/C++ –> LLVM bitcode –> PNaCl –> Navigateur
asm.js est une tentative de standardisation d'un sous-ensemble de JavaScript qui tournerait dans n'importe quel navigateur, contenant des constructions qui peuvent être mieux optimisées pour la vitesse d'un moteur JavaScript. Emscripten est un autre projet qui génère asm.js pour du bytecode LLVM. Selon Zakai, du code C++ s'exécute dans Firefox via asm.js à 50% la vitesse du code natif, et ils s'attendent à ce que la performance s'améliore au fil du temps.
PNaCl, récemment annoncée par Google et couvert en détail par InfoQ, fait tourner du code C/C++ dans le navigateur dans une sandbox à 80-90% de la vitesse du code natif avec des possibilités d'amélioration, selon David Sehr. Alors que la performance est nettement meilleure que Mozilla, elle arrive à un prix: pNaCl a été en développement pendant plus de 2 ans. Il est assez difficile de traiter les questions "endian", différentes tailles de pointeurs, les différentes représentations en virgule flottante, etc. sur plusieurs architectures. Il serait plus simple pour améliorer Chrome d'inclure les optimisations d'asm.js. Mais, d'autre part, asm.js peut être trop lent, comme yab**uz a commenté :
Je n'utiliserai jamais asm.js. Simplement parce que c'est trop lent sur les navigateurs ne prenant pas en charge asm.js. Epic Citadel à 20 fps sur le dernier Core i7-3770K est une plaisanterie. Plus lent que le player Flash !
JavaScript, un langage créé par Brendan Eich en 10 jours en 1995, a été conçu pour être un langage de script client qui insuffle un certain dynamisme aux pages web statiques de l'époque. Peut-être que personne ne prévoyait le rôle que ce petit langage jouerait presque deux décennies plus tard, en dépit de toutes les critiques et les défauts qu'il portait avec lui. JavaScript est largement utilisé aujourd'hui du côté du client dans tous les principaux navigateurs et il fait une percée côté serveur en particulier en raison de la popularité de Node.js. Et ce n'est pas parce que JavaScript est un langage brillant, mais parce qu'il est si difficile d'amener les principaux acteurs à travailler ensemble sur une meilleure solution et de passer outre tous les rouages de l'industrie du logiciel. Comme HTTP et HTML, JavaScript va prospérer en dépit de ses défauts et le fait que nous savons tous que nous pourrions faire mieux si nous nous mettions d'accord.
Maintenant que nous sommes coincés avec JavaScript, aurons-nous au moins un bytecode web universel ? En avons-nous besoin ? Les tentativces d'exécuter du code écrit dans d'autres langages dans le navigateur, comme asm.js de Mozilla ou pNaCl de Google vont elles être soutenues ? Qui est le meilleur : asm.js ou pNaCl ? Donnez votre avis dans les commentaires.