Le WebAssembly serait moins performant que le code natif
Le WebAssembly serait moins performant en termes de rapidité que le code natif,
selon les résultats d'une étude
Le WebAssembly serait moins performant en termes de rapidité que le code natif,
selon les résultats d'une étude
“Mind the gap : Analyzing of the performance of WebAssembly vs. Native code” en français “Attention aux lacunes : Analyse des performances de WebAssembly par rapport au code natif”, c’est le titre d’un rapport publié ce 25 janvier par une équipe composée de quatre professeurs de l’université de Massachusetts. Dans ce document, ils mettent en évidence certaines lacunes qu’ils ont observées dans l’utilisation de WebAssembly pour produire du bytecode en compilant des langages de haut niveau tels que le C ou le C++. WebAssembly, abrégé WASM, est une norme développée par un groupe de travail, le W3C WebAssembly, pour le développement d’application Web.
Il est conçu pour compléter le JavaScript avec des performances supérieures. Le standard consiste en un bytecode, sa représentation textuelle et un environnement d'exécution dans une sandbox compatible avec JavaScript. Il peut être exécuté dans un navigateur Web et en dehors. Le bytecode est généralement produit en compilant un langage de haut niveau. Parmi les premiers langages supportés figurent Rust, le C et C++. Les navigateurs Web compilent le bytecode en langage machine avant de l'exécuter. Sa première version a été présentée en juin 2015 et sa dernière version, la version 1.0, date d’octobre 2017.
Aujourd'hui, tous les navigateurs modernes notamment Chrome, Firefox, Safari, Edge, les navigateurs mobiles ainsi que Node.js le prennent en charge. L'un des objectifs clés de WebAssembly est la parité des performances avec le code natif. Cependant, à travers le rapport publié ce vendredi, ces professeurs estiment que contrairement à ce que beaucoup croient, l’exécution d’applications plus grandes ou plus substantielles (applications avec un grand nombre de lignes de code) compilées avec WebAssembly n’est généralement pas possible. Pour eux, cela est dû au fait que les API Unix standard ne sont pas disponibles dans l’environnement d’un navigateur Web, l’inexistence d’autres services tels que les systèmes d’entrée/sorties (E/S) synchrones de fichiers, etc.
L’équipe a voulu relever un défi pour voir les performances de WebAssembly dans le cas d’applications plus lourdes. Ils ont dit avoir mis en place une extension de Browsix qu’ils appellent Browsix-WASM pour tenter d’exécuter des applications Unix compilées avec WebAssembly. Browsix est conçu pour apporter Unix aux navigateurs, explique sa page GitHub. C’est un framework exclusivement JavaScript qui apporte l’essence d’Unix aux navigateurs. Browsix met à la disposition des applications Web des fonctionnalités Unix essentielles (notamment des canaux, des processus, des signaux, des sockets et un système de fichiers partagé) et étend les exécutions JavaScript pour les programmes C, C ++, Go et Node.js afin qu'elles puissent être exécutées sous un environnement Unix dans les navigateurs.
Il fournit également un shell de type POSIX qui facilite la composition d'applications pour le traitement parallèle de données via des canaux. Les résultats issus des différents tests de performances de WebAssembly par rapport au code natif montrent des lacunes dans les performances de WebAssembly. Malgré l’environnement Unix mis en place, la vitesse d’exécution est ralentie d’environ 50 % pour Firefox et d’environ 89 % s’agissant de Chrome. Un extrait du résumé des résultats des analyses est le suivant :
« Les applications compilées pour WebAssembly s'exécutent en moyenne de 50 % pour Firefox et 89 % pour Chrome, avec des ralentissements maximaux de 2,6x dans le cas de Firefox et 3,14x pour Chrome. Nous avons remarqué que les causes de cette dégradation de performances sont dues en partie à des optimisations manquantes et à des problèmes de génération de code, tandis que d'autres sont inhérentes à la plate-forme WebAssembly. Nous avons constaté un écart de performances important, principalement le fait que les applications compilées pour WebAssembly tournent moins vite ».
Il ne s’agit là que d’un aspect des diverses insuffisances qu’ils ont soulignées dans leur étude. Vous pouvez avoir accès à toutes les informations sur les résultats des tests et d’autres conclusions dans le rapport. Pour certains internautes, l'inconvénient majeur de l'approche WebAssembly est qu'il faut plus de temps pour exécuter un module WebAssembly et la vitesse d’exécution n’est pas encore ce qu’il faut. Ils expliquent que cela serait dû au fait que le format intermédiaire de WebAssembly doit être compilé dans l'architecture cible avant de pouvoir s'exécuter en mode natif.
D’après un autre, WASM sera la valeur par défaut pour toutes les applications Web non triviales dans les prochaines années (en supposant que l'accès au DOM soit traité). Pour le moment il fait mieux que JavaScript, témoigne-t-il. Selon lui, c'est juste une façon plus rationnelle et plus performante de produire du JavaScript. Toujours dans la même logique d’autres voient WebAssembly remplacer rapidement des framework comme Electron. Ce qu’ils disent est que, même avec la popularité d’Electron, si la rapidité de WebAssembly monte à environ 80 % au minimum, il deviendrait facilement le langage multiplateforme de la grande majorité des applications de bureau.
Par contre pour le mobile, ces derniers pensent que beaucoup de choses ne vont pas avancer de ce côté si Apple ne revoit pas sa façon de faire. « Nous serons toujours retardés par Apple et sa réticence à adopter les technologies Web. Nous sommes en 2019 et nous ne pouvons même pas afficher d'ajout à la bannière de l'écran d'accueil », s’insurgent-ils.
Source : Rapport de l'étude
Et vous ?
Que pensez-vous des résultats de cette recherche ?
Voir aussi
Répondre avec citation
Envoyé par SpaceFrog
c'est censé t'aider à développer plus rapidement (si c'est un bon framework biensur).
: comparer C++ compilé pour le CPU avec C++ compilé en bytecode pour WASM qui lui-même compile en binaire pour le CPU, évidemment c'est perdu d'avance.
), ...?
Partager