Le WebAssembly serait moins performant en terme de rapidité que le code natif,
Selon les résultats d'une étude

Le , par Bill Fassinou

220PARTAGES

16  0 
Le WebAssembly serait moins performant en terme 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 évidences 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

WebAssembly a-t-il pour vocation de remplacer à long terme JavaScript ? Le standard est au centre des discussions des développeurs web

WebAssembly : Chrome, Firefox et Edge peuvent déjà livrer des versions de leurs navigateurs avec WebAssembly activé par défaut

Le support de WebAssembly est désormais disponible dans tous les principaux navigateurs, Safari et Microsoft Edge emboîtent le pas à Firefox et Chrome

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de frfancha
Membre éclairé https://www.developpez.com
Le 31/01/2019 à 7:34
Tout devient du code natif avant d'être exécuté, donc plus rapide que du code natif c'est juste impossible, c'est quoi cette"étude"??
8  0 
Avatar de SpaceFrog
Rédacteur/Modérateur https://www.developpez.com
Le 31/01/2019 à 8:38
A quand une étude pour se rendre compte que les frameworks ne sont pas plus rapides que le Javascript Natif ?
3  1 
Avatar de youtpout978
Membre expert https://www.developpez.com
Le 31/01/2019 à 7:45
Je pensais que le but de wasm était d’être plus performant que JS, et de se rapprocher du natif mais pas d’être au niveau du natif.
En tout cas pour ça l’objectif est rempli.
2  1 
Avatar de walfrat
Membre actif https://www.developpez.com
Le 31/01/2019 à 9:42
Il manquerait une comparaison WebAssembly vs VanillaJS pour que cet article soit vraiment pertinent. Si le vanillaJS à un rapport du genre 1/7 par rapport au C++ on peut dire qu'on y a bien gagné.

De plus dire que un truc qui est là que depuis quelques années n'est pas encore aussi rapide que ce que donne un langage compilé dont le compilateur mais aussi les librairies natives ont été optimisé encore et toujours depuis 30 ans ça me paraît un peu normal.

S'ils veulent vraiment rivaliser avec des perfs du natif, il faut un système de compilation à la volée comme le fait la JVM en java. Je ne sais pas si c'est déjà prévu ou si ça ne l'est pas du tout, mais vu que WASM est récent c'est sur que ce n'est pas la première priorité, il faut déjà que le langage marche bien.
1  0 
Avatar de SpaceFrog
Rédacteur/Modérateur https://www.developpez.com
Le 31/01/2019 à 13:03
c'est pas du code
désolé, je voulais plutot parler de Bibliothques ...
1  0 
Avatar de SimonDecoline
Membre expert https://www.developpez.com
Le 31/01/2019 à 19:47
Citation Envoyé par Bill Fassinou Voir le message
Le WebAssembly serait moins performant en terme de rapidité que le code natif,
Sans déconner ? Ohlala comme je suis surpris, je ne m'y attendais pas du tout et c'est vraiment la première fois que j'entends parler de cela...
1  0 
Avatar de BlueScreenJunky
Membre régulier https://www.developpez.com
Le 01/02/2019 à 7:17
Haha, je vois que je suis pas le seul à avoir tiqué sur le titre Lapalissien ;-)
1  0 
Avatar de Gab_CV
Candidat au Club https://www.developpez.com
Le 08/02/2019 à 15:41
C'est certes bien moins performant que du code natif, mais on commence à pouvoir faire des choses plutôt intéressantes en WebAssembly.

J'ai récemment réalisé le portage du moteur de jeu "id Tech 4" (Doom 3) en WebAssembly / WebGL (je voulais voir ce que la techno avait *réellement* dans le ventre, et pas simplement quelques benchmarks très ciblés). Et figurez vous que ça marche plutot bien. Très bien même

Voici le lien vers une démonstration en ligne que vous pouvez tester dans votre navigateur (la démonstration utilise la version Démo de Doom 3):
http://wasm.continuation-labs.com/d3demo/

Et la page du projet, avec pas mal d'informations techniques (en Anglais):
http://www.continuation-labs.com/projects/d3wasm/

ça marche sur la plupart des navigateurs, et tourne à bon rythme sur un PC (30 FPS sur le mien). Sur un Mobile ça fonctionne aussi, par contre ça risque de ramer en fonction du modèle (+ pas possible de jouer car pas de contrôles tactiles)... Sur mon modèle je suis à 3/4 FPS, mais des utilisateurs m'ont rapporté avoir des 30 FPS également.

Perso, depuis que je suis arrivé à bout de ce projet, j'ai la conviction que Javascript ne régnera pas éternellement en maître sur le Web coté client. Encore un peu de temps certes, mais ce n'est plus pour longtemps.
1  0 
Avatar de Greg-dev
Membre régulier https://www.developpez.com
Le 31/01/2019 à 9:12
Citation Envoyé par SpaceFrog Voir le message
A quand une étude pour se rendre compte que les frameworks ne sont pas plus rapides que le Javascript Natif ?
Un framework c'est un outil de travail... c'est pas du code c'est censé t'aider à développer plus rapidement (si c'est un bon framework biensur).
1  1 
Avatar de codec_abc
Membre confirmé https://www.developpez.com
Le 31/01/2019 à 11:57
Tout devient du code natif avant d'être exécuté, donc plus rapide que du code natif c'est juste impossible, c'est quoi cette"étude"??


Dans ce cas là, code natif veut dire code directement exécutable en code machine (sans traduction ni optimisation au runtime). Le WASM est un genre de bytecode Java (en étant plus bas niveau). Donc cela veut dire que pour l'instant un programme C++ compilé de manière "classique" sera plus rapide que le même programme compilé en WASM et exécuté dans un navigateur.

A quand une étude pour se rendre compte que les frameworks ne sont pas plus rapides que le Javascript Natif ?
Le WASM est déjà bien plus rapide que le JS. Exemple. Et puis comme déjà expliqué, WASM n'a pas aujourd'hui de gros framework pour de l'UI (sauf Blazor peut-être) et donc la comparaison n'a pas de sens. Et puis pour comparer 2 frameworks il faut que leurs fonctionnalités et surtout leurs fonctionnements internes soient identique sinon la comparaison est faussé dès le début.
0  0 
Contacter le responsable de la rubrique Accueil

Partenaire : Hébergement Web