Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Administrateur systèmes et réseaux
    Inscrit en
    juin 2016
    Messages
    707
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

    Informations professionnelles :
    Activité : Administrateur systèmes et réseaux
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : juin 2016
    Messages : 707
    Points : 21 518
    Points
    21 518

    Par défaut Le WebAssembly serait moins performant que le code natif

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

    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.

    Nom : Capture du 2019-01-31 02-20-02.png
Affichages : 4455
Taille : 81,3 Ko

    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
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre éclairé
    Profil pro
    Inscrit en
    novembre 2009
    Messages
    349
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : novembre 2009
    Messages : 349
    Points : 681
    Points
    681

    Par défaut

    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"??

  3. #3
    Membre expert

    Homme Profil pro
    Développeur .NET
    Inscrit en
    novembre 2010
    Messages
    1 744
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : novembre 2010
    Messages : 1 744
    Points : 3 548
    Points
    3 548

    Par défaut

    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.

  4. #4
    Rédacteur/Modérateur

    Avatar de SpaceFrog
    Homme Profil pro
    Développeur Web Php Mysql Html Javascript CSS Apache - Intégrateur - Bidouilleur SharePoint
    Inscrit en
    mars 2002
    Messages
    38 290
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 69
    Localisation : Royaume-Uni

    Informations professionnelles :
    Activité : Développeur Web Php Mysql Html Javascript CSS Apache - Intégrateur - Bidouilleur SharePoint
    Secteur : Industrie

    Informations forums :
    Inscription : mars 2002
    Messages : 38 290
    Points : 65 585
    Points
    65 585
    Billets dans le blog
    1

    Par défaut

    A quand une étude pour se rendre compte que les frameworks ne sont pas plus rapides que le Javascript Natif ?
    Ma page Developpez - Mon Blog Developpez
    Président du CCMPTP (Comité Contre le Mot "Problème" dans les Titres de Posts)
    Deux règles du succès: 1) Ne communiquez jamais à quelqu'un tout votre savoir...
    Votre post est résolu ? Alors n'oubliez pas le Tag


    réalisations :www.oxygen-translations.fr|www.saftair.fr| www.ouestisol.fr | www.sistac-alizay.fr | www.acoustishop.fr | www.litt.fr | www.ouestventil.fr
    Humour

  5. #5
    Membre régulier
    Homme Profil pro
    Développeur Java / JEE / JavaScript
    Inscrit en
    juillet 2012
    Messages
    35
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Java / JEE / JavaScript
    Secteur : Service public

    Informations forums :
    Inscription : juillet 2012
    Messages : 35
    Points : 74
    Points
    74

    Par défaut

    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).

  6. #6
    Membre du Club
    Profil pro
    Inscrit en
    juin 2009
    Messages
    21
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2009
    Messages : 21
    Points : 49
    Points
    49

    Par défaut Analyse incomplète

    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.

  7. #7
    Membre averti
    Profil pro
    Inscrit en
    septembre 2009
    Messages
    179
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2009
    Messages : 179
    Points : 448
    Points
    448

    Par défaut

    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.

  8. #8
    Membre averti
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    mars 2011
    Messages
    96
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mars 2011
    Messages : 96
    Points : 352
    Points
    352

    Par défaut

    Il faut tout de même remarquer une différence significative des perfs entre Firefox et Chrome, Firefox étant plus rapide. Ca veut dire qu'il y a une nette marge de progression pour Chrome et ce serait intéressant d'avoir l'avis de Mozilla s'ils ont aussi de potentiels gains de perf à venir sur Firefox. C'est juste une "photo" des perfs à un instant t et on peut raisonablement penser qu'il y aura des améliorations à l'avenir. Ceci dit x1.5 pour Firefox c'est déjà pas mal du tout je trouve.

  9. #9
    Rédacteur/Modérateur

    Avatar de SpaceFrog
    Homme Profil pro
    Développeur Web Php Mysql Html Javascript CSS Apache - Intégrateur - Bidouilleur SharePoint
    Inscrit en
    mars 2002
    Messages
    38 290
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 69
    Localisation : Royaume-Uni

    Informations professionnelles :
    Activité : Développeur Web Php Mysql Html Javascript CSS Apache - Intégrateur - Bidouilleur SharePoint
    Secteur : Industrie

    Informations forums :
    Inscription : mars 2002
    Messages : 38 290
    Points : 65 585
    Points
    65 585
    Billets dans le blog
    1

    Par défaut

    c'est pas du code
    désolé, je voulais plutot parler de Bibliothques ...
    Ma page Developpez - Mon Blog Developpez
    Président du CCMPTP (Comité Contre le Mot "Problème" dans les Titres de Posts)
    Deux règles du succès: 1) Ne communiquez jamais à quelqu'un tout votre savoir...
    Votre post est résolu ? Alors n'oubliez pas le Tag


    réalisations :www.oxygen-translations.fr|www.saftair.fr| www.ouestisol.fr | www.sistac-alizay.fr | www.acoustishop.fr | www.litt.fr | www.ouestventil.fr
    Humour

  10. #10
    Membre averti
    Profil pro
    Inscrit en
    septembre 2009
    Messages
    179
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2009
    Messages : 179
    Points : 448
    Points
    448

    Par défaut

    Citation Envoyé par ParseCoder Voir le message
    Il faut tout de même remarquer une différence significative des perfs entre Firefox et Chrome, Firefox étant plus rapide. Ca veut dire qu'il y a une nette marge de progression pour Chrome et ce serait intéressant d'avoir l'avis de Mozilla s'ils ont aussi de potentiels gains de perf à venir sur Firefox. C'est juste une "photo" des perfs à un instant t et on peut raisonablement penser qu'il y aura des améliorations à l'avenir. Ceci dit x1.5 pour Firefox c'est déjà pas mal du tout je trouve.
    Mozilla a fait beaucoup plus d'effort que Google pour rendre l’exécution du WASM rapide. Il y a pas mal d'articles très bien rédigé (en anglais) et illustré pour ceux que ça intéresse sur hack.mozilla

  11. #11
    Membre émérite
    Homme Profil pro
    Développeur informatique
    Inscrit en
    avril 2017
    Messages
    642
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : avril 2017
    Messages : 642
    Points : 2 838
    Points
    2 838

    Par défaut

    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...

  12. #12
    Membre confirmé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    mars 2011
    Messages
    167
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 27
    Localisation : France, Gard (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : mars 2011
    Messages : 167
    Points : 583
    Points
    583

    Par défaut

    Citation Envoyé par Greg-dev Voir le message
    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).
    Tout dépend de ta vison de celui-ci, si tu préfères juste l'utiliser sans comprendre son fonctionnement, quitte à faire un "code" non optimisé, en effet, c'est "un outil de travail".
    Par contre si tu veux l'utiliser tel que l'avais prévue les développeurs, ou que tu souhaites l'améliorer, c'est bel et bien du code.

    Un framework (qui est un ensemble de bibliothèques), n'est que du code permettant de soulager les développeurs en évitant qu'il est à écrire un algorithme quasiment identique dans chacun de ces projets.

  13. #13
    Membre régulier
    Homme Profil pro
    Développeur Web
    Inscrit en
    avril 2012
    Messages
    38
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : avril 2012
    Messages : 38
    Points : 98
    Points
    98

    Par défaut

    Haha, je vois que je suis pas le seul à avoir tiqué sur le titre Lapalissien ;-)

  14. #14
    Nouveau Candidat au Club
    Homme Profil pro
    Développeur informatique
    Inscrit en
    février 2019
    Messages
    1
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : février 2019
    Messages : 1
    Points : 1
    Points
    1

    Par défaut Il y a du progrès: Doom 3 tourne dans les navigateurs maintenant

    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.

Discussions similaires

  1. Réponses: 1
    Dernier message: 28/03/2013, 04h50
  2. Atom d'Intel moins performants que les puces ARM ?
    Par Gordon Fowler dans le forum Actualités
    Réponses: 4
    Dernier message: 10/11/2010, 05h41
  3. Réponses: 30
    Dernier message: 20/07/2009, 15h35
  4. Réponses: 0
    Dernier message: 16/07/2009, 16h49
  5. Wifi : XP moins performant que 2000 Pro ?
    Par argoet dans le forum Hardware
    Réponses: 4
    Dernier message: 03/01/2007, 09h30

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo