Design: Y aura-t-il un compilateur JS -> WASM ?

Les navigateurs auront toujours une machine virtuelle JavaScript native à côté de wasm. Il n'y a aucune raison de compiler JS en wasm car vous devrez également inclure un vm javascript complet. Le code résultant serait énorme et plus lent que la VM JS fournie nativement.

Il existe une tâche post MVP pour ajouter des éléments tels que l'ajout d'un accès au GC à partir du code wasm afin que les langages de script puissent être implémentés pour wasm.

JS → wasm n'aura vraiment de sens qu'une fois que wasm prendra en charge GC, et très probablement aussi la compilation JIT, qui est encore assez éloignée. Cela équivaudrait en gros à implémenter le moteur JS dans wasm ! J'en ai parlé récemment et @BrendanEich m'a accusé d'avoir été repris par horse_js.

Pour être clair, le but de wasm n'est pas de _remplacer_ JavaScript, c'est de le compléter. Ce n'est donc pas vraiment un objectif pour le moment de supporter JS → wasm, mais les fonctionnalités que nous voulons implémenter le permettront. Je ne suis pas sûr que ce soit si utile du point de vue d'un développeur, cependant. Vous pouvez obtenir une réduction de taille, mais c'est à peu près tout. Du point de vue d'un navigateur, il peut être intéressant d'implémenter le moteur JS dans wasm d'un point de vue purement sécuritaire.

@jfbastien je t'ai battu de 2 secondes ;)

Mais ta réponse est meilleure. Je suis excité pour GC et JIT dans wasm. J'aime créer mes propres langages et les exécuter sur le Web.

Et que diriez-vous de prendre en charge des variantes telles que asm.js ou TypeScript/ES7 ? Ces
les versions de Javascript promettent un certain niveau de garanties de type.

J'imagine que le besoin de JIT le serait moins, mais GC reste très
nécessaires pour ces langues. Aurait une {saveur typée JS} -> WASM make
c'est plus faisable ?

W : http://bguiz.com

Le 24 juin 2015 à 09h44, Tim Caswell [email protected] a écrit :

@jfbastien https://github.com/jfbastien tu m'as battu de 2 secondes :P

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/WebAssembly/design/issues/219#issuecomment-114675456 .

Oui, un traducteur asm.js -> wasm est une priorité élevée, et Luke l'a déjà fait
travailler sur un compresseur qui pourrait servir de bon point de départ.

Le mer. 24 juin 2015 à 01h59, Brendan Graetz [email protected]
a écrit:

Et que diriez-vous de prendre en charge des variantes telles que asm.js ou TypeScript/ES7 ? Ces
les versions de Javascript promettent un certain niveau de garanties de type.

J'imagine que le besoin de JIT le serait moins, mais GC reste très
nécessaires pour ces langues. Aurait une {saveur typée JS} -> WASM make
c'est plus faisable ?

W : http://bguiz.com

Le 24 juin 2015 à 09h44, Tim Caswell [email protected] a écrit :

@jfbastien https://github.com/jfbastien tu m'as battu de 2 secondes :P

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
< https://github.com/WebAssembly/design/issues/219#issuecomment -114675456
.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/WebAssembly/design/issues/219#issuecomment-114677789 .

Nous avons discuté avec l'équipe TypeScript de cette possibilité et ils ont manifesté leur intérêt, mais il semble que des progrès soient actuellement en cours pour l'ajout d'objets typés dans JS.

@bguiz : Le moteur JS est le moteur wasm, et il continuera à prendre en charge le langage standard JS en évolution. Pas de soucis là-bas (je ne savais pas si vous pensiez que cela pourrait disparaître. Pas dans un avenir que je puisse prévoir). OTOH, comme d'autres le notent, wasm a besoin de temps pour faire évoluer GC, la prise en charge JIT et d'autres fonctionnalités de langage dynamique, pour devenir une cible de premier ordre pour JS. Même lorsqu'il fait évoluer ces choses, je doute que les moteurs JS/wasm abandonnent leur syntaxe JS et leurs composants intégrés au profit des machines virtuelles JS-in-wasm téléchargées. Nous verrons!

/être

Un traducteur asm.js-to-WebAssembly sera également quelque chose que nous prévoyons d'ajouter à Emscripten .

En ce qui concerne les JS réguliers, je pense que d'autres ont répondu à la question ci-dessus.

Tout l'intérêt de JS est facile à coder et peut faire des choses incroyables : dhteumeuleu ou codepen.io/ge1doot, mais vous pouvez voir la source et c'est facile à pirater.

"wasm" n'est qu'un moyen de vendre plus de jeux et d'autres applications pour google, apple an co. La seule "évolution" c'est qu'il va pouvoir mieux te contrôler sans "pas d'installation", directement depuis le serveur grand frère... Je suis juste étonné qu'ils n'aient pas encore peur de se bouffer les uns les autres...

Il est possible avec l'analyse de code ou les annotations de code de compiler ECMAScript en WebAssembly. Cela ne semble pas être une priorité pour l'équipe WebAssembly, mais cela semble être une excellente idée pour un effort indépendant.

Je viens de commencer à expérimenter un langage de programmation jouet qui pourrait être pertinent : https://github.com/evanw/thinscript. Il utilise une syntaxe de style TypeScript et se compile en WebAssembly. J'ai pensé que je devrais le mentionner parce que cela pourrait être une étude de cas intéressante. J'ai également été agréablement surpris par la facilité de génération de WebAssembly. Beau travail à tous !

Je mettrais cependant les gens en garde contre l'utilisation d'emballages très minces sur le wasm, en général. Par exemple, en feuilletant le code Thinscript, je vois qu'il y a une instruction while qui est abaissée à loop { if (!condition) break; } , ce qui sera moins efficace que if (condition) loop { ...; br_if condition } sur plusieurs moteurs wasm.

Pour moi, ce qui fait de wasm plus qu'un simple JS réchauffé, c'est la possibilité d'une philosophie différente : comme wasm est une cible de compilateur, les compilateurs peuvent effectuer des optimisations avant d'envoyer le code aux clients, afin que nous puissions garder les machines virtuelles côté client plus simples et plus rapide. Cependant, si les enveloppes minces autour de wasm deviennent populaires, il y a un risque que les implémentations côté client finissent par devenir plus volumineuses et plus complexes afin de faire les optimisations qui ne sont pas effectuées.

Oui je suis d'accord. L'une des choses que j'aime le plus à propos de WebAssembly est sa simplicité. Je prévois d'ajouter des optimisations de compilateur et de faire des tests une fois que le langage sera plus complet. Je m'attends à ce que l'inline soit l'une des plus grandes victoires, par exemple, et je ne m'attendrais pas à ce que WebAssembly le fasse pour moi. Je prévois également d'expérimenter avec une cible de code machine et j'utiliserai les mêmes optimisations pour les deux cibles.

Ça a l'air très cool ! Je serai curieux de voir où cela mène.

J'imagine que JS->WASM est plus attrayant pour les serveurs que pour les clients. En tant qu'aperçu de très haut niveau de l'architecture que j'ai en tête...

JavaScript -> WebAssembly -> Tracing Interpreter -> LLVM IR -> Machine Code

Dans cette conception, un mappage clair de WASM à LLVM IR pour le ramasse-miettes serait très souhaitable. La promotion des doubles IEEE aux nombres entiers pourrait être effectuée sous forme de laissez-passer LLVM. La notion de JIT séparés pour le code chaud et chaud pourrait être implémentée en termes de gestionnaires de passes LLVM.

Juste quelques réflexions, n'hésitez pas à supprimer ceci si c'est faux !

La compatibilité entre environnements est un problème sérieux dans l'écosystème JS. Babel essaie de résoudre ce problème en transpilant vers une version plus adoptée d'ES et je suppose que nous pouvons tous dire que c'est plutôt réussi.

Il y a quand même un problème ici. Par exemple, si vous transpilez votre code ES 2016 vers ES5 pour la compatibilité et que votre code s'exécute sur un environnement avec une prise en charge (partielle ou complète) d'ES 2016, vous perdrez les avantages de la prise en charge d'ES 2016 dans votre environnement. .

Si tout le monde transpile son code vers ES5, quel est l'avantage d'avoir la prise en charge d'ES 2016 dans un environnement en premier lieu ?

Un nouveau projet appelé « babel-preset-env » tente de lutter contre ce problème en ciblant les environnements par leurs versions. L'idée sous-jacente est que (1) vous lui demandez de cibler des versions spécifiques ou les "dernières versions X" des navigateurs, (2) il détermine le plus petit dénominateur commun des fonctionnalités et (3) n'autorise que les transpilations nécessaires. Cela aide, mais ne peut malheureusement pas résoudre le problème.

Nous avons toujours le risque qu'un fournisseur majeur ne se comporte pas et cause les mêmes problèmes que Microsoft causait avec Internet Explorer pendant des années. L'ensemble de l'écosystème est entre les mains de quelques fournisseurs, qui décident quoi mettre en œuvre et quand mettre en œuvre. Ce n'est ni gratuit ni ouvert.

La seule solution est une nouvelle cible de compilation pour JavaScript qui est performante et nécessite beaucoup moins de maintenance (espérons-en aucune) qu'un moteur JS. Lorsque les environnements (navigateurs, Node.js, etc.) commencent à prendre en charge une telle cible, la mise en œuvre de nouvelles fonctionnalités ES devrait devenir la responsabilité des compilateurs et non des fournisseurs de moteurs.

JS -> WASM serait intéressant pour protéger la propriété intellectuelle par l'obscurcissement du code lorsqu'il s'agit d'installations sur site d'applications, disons Electron, sur les serveurs des clients. C'est difficile à croire, mais c'est vrai, il existe de nombreuses petites institutions en Allemagne avec très peu ou pas de connexion Internet, ce qui nécessite des installations sur site, mais leur donner l'intégralité de votre code en texte clair peut être effrayant pour les éditeurs de logiciels.

@Simran-B Wasm a pour principe de conception de prendre en charge un format de texte familier. Notamment, il a une conception de flux de contrôle structurée pour une analyse rapide et est optimisé pour les définitions à usage unique utilisées dans l'ordre de la pile, donc optimisé pour les expressions lisibles. Ainsi, ce n'est pas une cible d'obscurcissement du code, mais les développeurs peuvent émettre leur propre "obscurcissement du code" en plus de cela, mais doivent comprendre que cela devrait avoir un coût en termes d'efficacité de codage et de performances réduites.

Salut à tous, je viens de découvrir WebAssembly, mais en pensant au compilateur JS -> wasm, j'ai imaginé quelque chose comme la compilation Ahead-of-Time d'Angular2, jsut beaucoup plus optimisé (je pense au code machine au lieu de javascript)... Est-ce que cela jamais possible ? Est-ce que ça vaut le coup?

ÉDITER
Je pense aussi, est-ce qu'il y aura jamais une possibilité pour le navigateur d'envoyer un indicateur au client qu'il prend en charge wasm, et ensuite nous pourrons servir une application précompilée au lieu d'un fichier javascript ?

Richard

@ Richard87, vous pourriez considérer l'assemblage Web comme un jeu d'instructions indépendant de la plate-forme avec ses propres conventions d'encodage et d'appel spécialisées. Rien ne dit que vous ne pouvez pas décrire un sous-ensemble de javascript qui serait très facile à transpiler pour fonctionner dans le monde de l'assemblage Web de ces choses, mais l'appliquer serait probablement difficile. L'ensemble de fonctionnalités et la surface d'implémentation ne cessent de croître en javascript, et l'adaptation des bibliothèques et des frameworks existants pour fonctionner dans ce sous-ensemble serait probablement difficile, en particulier compte tenu du manque actuel de récupération de place dans l'assemblage Web, et vous perdriez essentiellement les avantages du javascript existant. code.

Avec l'ajout de primitives de récupération de place dans le webassembly, le sous-ensemble de javascript qu'il serait possible de transpiler sans écrire une grande machine virtuelle s'élargirait, mais à mon avis, il ne serait toujours pas optimal par rapport au simple transpilage à partir d'un plus approprié langage, puisque vos frais généraux en javascript ne seraient que légèrement inférieurs, les frais généraux importants dans les applications Web (le réseau !) en plus de pouvoir dire qu'il utilise quelque chose qui ressemble à du "javascript" (c'est en fait un bateau similaire dans lequel Unity est avec UnityScript, sauf qu'ils l'ont quelque peu adapté pour mieux s'intégrer à leurs sous-systèmes et conventions d'appel en général, en plus d'autres caprices).

Je pense qu'il est extrêmement important pour certains d'entre nous qui regardent Browser et Webgl d'être plus rapides pour les jeux. J'ai l'intention d'apporter un jeu de qualité commerciale dans webgl, mais la technologie actuelle produit tellement de déchets que les images sautent.
Les jeux par navigateur utilisant les moteurs de jeu JS ont presque échoué et Unity a décollé. Je pense que C++ => Wasm est un avantage indu pour ces grands fabricants de frameworks comme Unity qui pourraient compiler leur code en WASM.
Mais qu'en est-il des personnes qui écrivent JS à la main en utilisant Three JS ou Babylon.. Ne pas avoir de chaîne d'outils JS/Asm.js => Wasm signifierait que les grandes applications en Js seraient mortes et que les gens utiliseraient C++ et des backends de génération de code pour produire Wasm. Plus précisément dans les jeux et autres.
Ne pas avoir de backend JS => Wasm est injuste pour les développeurs JS. EMCC alloue également un gros tas lorsqu'il s'exécute et les vitesses sont évidentes à cause de cela, mais les développeurs Js qui écrivent un bon code js ne pouvaient toujours pas atteindre autant de performances en raison de la complexité de l'écriture d'un tel code. Il devrait y avoir un mécanisme pour réutiliser la plupart des choses et la possibilité d'appeler gc plus tôt ou à volonté. Le saut de trame lorsque le GC s'exécute fait que Webgl saute des trames est un gros problème et doit être résolu. Il devrait y avoir un mécanisme pour régler manuellement le code JS mieux que les générateurs de code. comme l'assembly écrit à la main, produit toujours un code beaucoup plus petit et très aligné. Cela devrait être possible en web-assembly.

@metacritical C++ peut compiler vers WASM car de nombreuses personnes mettent beaucoup de travail dans le processus. La même chose pourrait se produire pour JavaScript, mais pour autant que je sache, personne ne tente cela actuellement. Il y a peu de raisons de le faire : les performances resteront inchangées.

Le problème de votre moteur est le ramassage des ordures. Ce problème ne disparaît pas si vous créez un algorithme de récupération de place qui utilise la mémoire linéaire et le code WASM... vous devez éventuellement arrêter le programme pour voir quels objets sont encore en vie et supprimer ceux qui ne le sont pas. La solution est de ne pas créer d'objets indésirables, évitant ainsi au GC de s'exécuter. Vous n'avez pas besoin de WASM pour y parvenir, vous devez retravailler votre moteur.

Le Javascript ultra vierge qui réutilise les tableaux et produit peu de déchets est extrêmement difficile à écrire. Aussi, je pense que Plain Js ne peut pas être compilé en WASM. Asm.js ou Typescript seraient plus faciles à compiler vers WASM en raison de la disponibilité des annotations de type ou des types qu'ils contiennent respectivement.

@metacritical Difficile, mais pas impossible. Même dans les moteurs C++, une grande partie du code concerne la gestion de la durée de vie des objets. Bien que non conventionnel, il n'y a aucune raison pour que vous ne puissiez pas faire la même chose en JavaScript.

Plain JS _pourrait_ être compilé en WASM, mais le compilateur devrait ajouter beaucoup de code d'aide pour activer les fonctionnalités de niveau supérieur de JavaScript telles que la récupération de place, la réflexion, les propriétés, etc. Fondamentalement, tout ce que vous obtenez gratuitement avec le moteur JS intégré au navigateur. TypeScript n'aide pas beaucoup.

En comparaison, ASM.JS serait facile à convertir en WASM. Le sous-ensemble strict de fonctionnalités JS autorisé par ASM.JS est également couvert à 100% par WASM. S'il y avait un gros volume de code écrit en ASM.JS, ce serait un effort valable, mais pour autant que je sache, tous les principaux fichiers ASM.JS sont produits à partir du code source C++, qui peut déjà cibler directement WASM.

En comparaison, ASM.JS serait facile à convertir en WASM.

Correct, et en fait, la principale façon de compiler C++ en wasm aujourd'hui est de le compiler d'abord en asm.js, puis de compiler cet asm.js en wasm en utilisant asm2wasm de Binaryen .

@kripken En regardant les spécifications asm.js, il semble facile d'écrire asm.js manuscrit, ce qui signifie que tout n'est pas perdu pour les programmeurs js, nous pouvons toujours obtenir des binaires WASM en utilisant ce qui précède.

L'évolution de JS, c'est-à-dire un langage strictement typé, ne pourrait-elle pas en faire un bon candidat pour JS -> WASM ?
Je pense que TC39 a une proposition d'objet typé. Peut-être que d'autres fonctionnalités pourraient le rendre possible.

@ aruns07 Moins vous autorisez les gens à utiliser de fonctionnalités JavaScript, plus il serait facile de compiler vers WASM, et plus les gens ne voudront probablement pas vivre avec vos restrictions en raison de l'incompatibilité avec leurs bibliothèques préférées.

@Kardax @aruns07 Les gens adorent la commodité d'un langage dynamique. Nous avons besoin de types forts de temps en temps pas tout le temps.

jfbastien a commenté le 24 juin 2015
JS → wasm n'aura vraiment de sens qu'une fois que wasm prendra en charge GC, et très probablement aussi la compilation JIT, qui est encore assez éloignée. Cela équivaudrait en gros à implémenter le moteur JS dans wasm !

D'après le lien suivant :
https://lists.w3.org/Archives/Public/public-webassembly/2017Feb/0002.html
Consensus WebAssembly et fin de l'aperçu du navigateur

Maintenant, 2 ans après votre première réponse, WebAssembly est désormais pris en charge par les principaux navigateurs Web.
Il n'est donc pas équivalent d'implémenter le moteur JS dans wasm.
Les avantages de js -> wasm ne sont pas seulement la prise en charge de GC, mais également une taille de code plus petite et une exécution plus rapide, en particulier dans le domaine du développement d'applications hybrides telles que Ionic2 qui produit généralement un fichier JS d'environ 10 Mo, ce qui fait que le temps de chargement de l'application dépasse 5 secondes (chaque analyse de 2 Mo de JS = 1 seconde)

@jfbastien Alors merci de poster votre réponse mise à jour sur JS -> wasm transpiler ?

Dans le cadre de mon mémoire de maîtrise, j'essaie d'écrire un Transpiler à partir d'un sous-ensemble de JavaScript vers WebAssembly. Au début, il sera limité à TypeScript, mais d'autres variantes typées comme Flow pourraient être prises en charge à l'avenir.

Cependant, le but n'est pas d'implémenter le langage JavaScript complet car, dans ce cas, je serais confronté aux mêmes problèmes que les implémentations JIT aujourd'hui, et par conséquent, aucune accélération ne peut être attendue (plus certainement, mon implémentation serait 100 fois plus lente ! ). Ce sera un sous-ensemble tel que défini par SoundScript

Mon objectif est plus de permettre à des parties spécifiques d'une application d'être compilées en WebAssembly sans que le développeur ait besoin de quitter son environnement de développement familier ou d'utiliser un autre langage de programmation. Par conséquent, il sera davantage destiné à accélérer les performances des parties cruciales d'une application et non comme un transpiler à usage général qui accepte toute application JavaScript existante.

Je suis assez curieux de savoir quelles seront mes conclusions car je vois les avantages et les inconvénients d'une telle approche. Faites-moi savoir si vous avez des commentaires.

@Mohsen7s ma réponse reste précise : la version MVP de WebAssembly ne prend pas en charge les capacités GC et JIT qui permettent d'implémenter une machine virtuelle JavaScript rapide. Un interpréteur est tout à fait possible, avec des astuces intelligentes, il peut être assez bon, mais pas autant que ce que font les implémentations natives.

C'est inhérent à notre approche de « produit minimal viable » : expédiez d'abord quelque chose qui fonctionne pour certains cas d'utilisation, puis ajoutez des fonctionnalités pour répondre à d'autres cas d'utilisation. Veuillez consulter le fil suivant pour une discussion similaire sur MVP et les "fonctionnalités futures" manquantes : https://github.com/WebAssembly/design/issues/992#issuecomment -281735235

Laissant de côté les discussions techniques sur ce qui peut et ne peut pas être mis en œuvre actuellement, je suis étonné que JS -> WASM ne soit pas l'objectif numéro 1 tant du point de vue philosophique que marketing - je ne vois pas comment vous obtiendrez jamais l'adhésion du développeur jusqu'à ce que ce soit le cas. Si tous ces développeurs front/back-end/full-stack avec des compétences JS capables de travailler dans n'importe quel marché vertical voulaient à la place passer leur temps à apprendre le C++ qui est utilisé dans un sous-ensemble considérablement plus petit d'industries, alors ils l'auraient déjà fait donc - je sais, je parle comme un seul. Je ne peux pas m'empêcher de penser que toute cette discussion est un peu une chambre d'écho et que ceux qui défendent l'absence d'un compilateur trouveraient qu'il serait mieux de passer leur temps à parler aux gens sur le charbon en leur demandant ce qu'ils veulent vraiment.

@BossLevel

Laissant de côté les discussions techniques sur ce qui peut et ne peut pas être mis en œuvre actuellement, je suis étonné que JS -> WASM ne soit pas l'objectif numéro 1 tant du point de vue philosophique que marketing - je ne vois pas comment vous obtiendrez jamais l'adhésion du développeur jusqu'à ce que ce soit le cas. Si tous ces développeurs front/back-end/full-stack avec des compétences JS capables de travailler dans n'importe quel marché vertical voulaient à la place passer leur temps à apprendre le C++ qui est utilisé dans un sous-ensemble considérablement plus petit d'industries, alors ils l'auraient déjà fait donc - je sais, je parle comme un seul.

Les navigateurs peuvent déjà exécuter JavaScript efficacement. Les navigateurs ne peuvent pas exécuter les cas d'utilisation prévus aussi efficacement. Pour couronner le tout, WebAssembly a des aspirations non Web.

Cette discussion, ainsi que https://github.com/WebAssembly/design/issues/992#issuecomment -281735235, illustrent la variété des objectifs de différentes personnes. Aucun n'a tort ! MVP doit simplement prioriser qui est servi en premier.

Je ne peux pas m'empêcher de penser que toute cette discussion est un peu une chambre d'écho et que ceux qui défendent l'absence d'un compilateur trouveraient qu'il serait mieux de passer leur temps à parler aux gens sur le charbon en leur demandant ce qu'ils veulent vraiment.

C'était tout l'intérêt de former un groupe communautaire W3C. Nous pensons que c'est réussi, comme nous l'avons entendu de nombreux développeurs intéressés. Certains ne sont pas intéressés par MVP, mais s'intéressent aux futures fonctionnalités .

@jfbastien

Les navigateurs peuvent déjà exécuter JavaScript efficacement.

Ha, j'essaie d'écrire un jeu HTML5 massivement multijoueur capable de fonctionner à un FPS décent sur un téléphone mobile moyen depuis 2008 et je n'y suis toujours pas ! Et étant donné que lorsque je passe un contrat pour payer les factures, je suis extrêmement bien récompensé, je suis à peu près certain que mon manque de progrès n'est pas dû à la qualité de mon code.

C'était tout l'intérêt de former un groupe communautaire W3C

Ha encore - combien de développeurs du monde réel connaissez-vous qui rejoignent un groupe communautaire ? Les développeurs qui le font sont généralement des évangélistes, etc. qui sont bien informés, oui, mais ont moins ressenti la douleur du développement réel.

Et je suis désolé, je ne veux vraiment pas rabaisser qui que ce soit sur cette page/impliqué/au W3C. Comme vous le dites, c'est une discussion, et c'est mon point de vue de première ligne.

Je m'excuse d'y revenir comme un chien s'inquiétant d'un os, mais pendant mon absence, j'ai pensé à une meilleure façon de faire valoir mon point de vue. Dans votre prochaine newsletter/événement communautaire ou tout autre moyen dont vous disposez pour recueillir des commentaires, posez cette question aux développeurs Web (vos clients) :

Afin de faire passer les performances basées sur un navigateur au niveau supérieur, vous devrez apprendre une autre langue ; serait-ce acceptable ?

Parce que c'est fondamentalement la question qui a déjà (à mon avis, délétère) répondue par certains sur cette page.

Et enfin ( promis ;-) ) @jfbastien , si :

Pour couronner le tout, WebAssembly a des aspirations non Web.

pourquoi s'appelle-t-il « WebAssembly » ?

@BossLevel Je pense voir d'où vous venez. Je ne peux pas parler au nom des personnes qui font l'évangélisation, mais je crois comprendre que différents évangélistes ont été en contact avec des développeurs "natifs" traditionnels qui s'intéressent à WebAssembly. De votre point de vue, cela n'est peut-être pas évident, mais au minimum, je peux signaler l'intérêt de Unity comme un signe de développeurs "sérieux". Ces personnes publient également sur github, sous leur propre nom, mais les affiliations ne sont pas toujours apparentes. Ce n'est pas à moi de parler pour eux.

Ha, j'essaie d'écrire un jeu HTML5 massivement multijoueur capable de fonctionner à un FPS décent sur un téléphone mobile moyen depuis 2008 et je n'y suis toujours pas ! Et étant donné que lorsque je passe un contrat pour payer les factures, je suis extrêmement bien récompensé, je suis à peu près certain que mon manque de progrès n'est pas dû à la qualité de mon code.

Je ne voulais pas dire que l'écriture rapide de JavaScript est facile. Ce que je voulais dire, c'est : WebAssembly ne facilite pas l'optimisation de JavaScript. Au contraire, il permet aux navigateurs de consommer un format mieux adapté pour générer des performances fiables. Cela permet également à TC39 de se concentrer sur l'amélioration de JavaScript lui-même, et pas seulement sur JavaScript en tant que cible de compilation.

Ha encore - combien de développeurs du monde réel connaissez-vous qui rejoignent un groupe communautaire ? Les développeurs qui le font sont généralement des évangélistes, etc. qui sont bien informés, oui, mais ont moins ressenti la douleur du développement réel.

Et je suis désolé, je ne veux vraiment pas rabaisser qui que ce soit sur cette page/impliqué/au W3C. Comme vous le dites, c'est une discussion, et c'est mon point de vue de première ligne.

Votre point de vue est en effet valable, et je pense qu'il est clair que de votre point de vue, je dis quelque chose qui est difficile à croire. Nous devrions mieux communiquer cela (ou bon, peut-être que je me trompe :wink:).

Afin de faire passer les performances basées sur un navigateur au niveau supérieur, vous devrez apprendre une autre langue ; serait-ce acceptable ?

Parce que c'est fondamentalement la question qui a déjà (à mon avis, délétère) répondue par certains sur cette page.

Je vois votre inquiétude, mais j'espère qu'elle ne se révélera pas vraie. Encore une fois, je me trompe peut-être. À mon avis, WebAssembly amène de nouveaux développeurs sur cette plate-forme, des développeurs qui ont eu de mauvaises expériences avec le Web dans le passé ou qui ont entendu des histoires d'horreur. À son tour, cela aide les développeurs JavaScript qui souhaitent utiliser du code "traditionnel" (ce que certains appellent "legacy") à utiliser ce code : nous voulons que WebAssembly soit facilement utilisable à partir de JavaScript. Pour y parvenir, cela doit être aussi simple que d'utiliser npm (ce qui... n'est pas toujours facile !).

Je suis un peu confiant que cela se produira en raison des commentaires que nous avons vus sur Twitter, Hacker News, Reddit et diverses conférences. Encore une fois, peut-être que je me trompe et que j'écoute des chambres d'écho. Au minimum, j'ai eu des discussions très prometteuses lors de conférences avec des personnes ayant des connaissances en C++ ainsi qu'en JavaScript.

Dans le même temps, TC39 essaie vraiment d'améliorer JavaScript. Je crois que c'est le cas ces dernières années, en particulier avec ES6.

Mais votre point demeure : peut-être que les développeurs voudront bien connaître JavaScript ainsi que des langages plus "WebAssembly-friendly" tels que C++ ou Rust. Je ne sais pas dans quelle direction les choses vont se passer.

pourquoi s'appelle-t-il « WebAssembly » ?

Ha! C'est une merveilleuse question. J'ai une conférence intitulée "WebAssembly : ni Web ni assemblage". Je vais devoir le donner publiquement pour pouvoir exprimer ce que je pense du nom :grin:

Alors je vais vous garder accroché à celui-là.

Je lis ici deux envies :

1. Une représentation binaire de JavaScript standard pour des temps de chargement rapides.
2. Quelque chose pour combler l'écart de performances entre le C++ compilé en natif et le JavaScript standard.

Le point 2 fait l'objet de recherches permanentes et d'investissements massifs de la part de nombreuses entreprises. Si vous regardez les mesures de performance des moteurs JavaScript au cours des 15 dernières années, cela fonctionne aussi... l'écart se réduit.

Le point 1 n'est travaillé par personne, pour autant que je sache. C'est extrêmement compliqué et de plus en plus difficile à mesure que JavaScript continue d'évoluer à un rythme rapide. WebAssembly est très strict et relativement simple, et il a encore fallu des années pour se développer.

@jfbastien - merci beaucoup pour votre réponse réfléchie et attentionnée :)

Donc quelques points illustratifs, sans ordre particulier :

1) Un bon exemple que je vois de toute cette discussion et mon point de vue sur la direction que vous devriez prendre, réside avec NodeJS - une API JS/front-end à un back-end C++ - vous obtenez la facilité d'utilisation/familiarité, etc. d'une part et la vitesse d'autre part.
2) Je m'en tiens à Node, en 2008, lorsque je me suis lancé dans ma propre odyssée personnelle ;-) J'ai d'abord regardé à la fois PHP et Java pour le back-end (je revenais au développement après une décennie passée du côté obscur de la gestion informatique et les soldes ;-) !) mais je les ai rapidement réduits pour la simple et bonne raison que je voulais n'avoir qu'à apprendre une langue, et bien apprendre celle-là ! Une histoire personnelle que je connais, mais je doute que je sois le seul développeur à ressentir cela, en particulier ceux qui travaillent pour eux-mêmes, pas pour un centime de l'entreprise pendant qu'ils apprennent la langue.
3) Je n'ai délibérément pas googlé les chiffres avant de faire mon prochain point (en effet, je ne sais même pas si je le pourrais), mais je serai prêt à parier que l'adoption de l'ASM était faible. Je sais que j'ai été très excité quand j'ai vu la démo initiale, mais en apprenant qu'il n'y avait pas de compilateur, je l'ai immédiatement rejeté. Demander à un développeur Web qui fait partie de la plus grande communauté de développeurs de la planète (JS) avec une vaste gamme d'API, de bibliothèques, de ressources, de didacticiels, de frameworks, etc. en ne leur fournissant pas un moyen de faire potentiellement cette première étape (c'est-à-dire un compilateur), vous manquez une astuce évidente de votre part. J'irais même jusqu'à parier que le développement en Shading langage (GLSL) a connu plus de croissance que l'ASM maintenant que vous pouvez a) l'écrire directement dans d'excellents frameworks comme Pixi.js et Three.js et b) jouer avec directement sur des sites comme ShaderToy .
4) L'industrie des jeux/jeux en général. Je peux parler d'expérience ici car a) j'écris des jeux (pas encore sortis !) depuis 9 ans et b) j'ai siégé au conseil d'administration de TIGA (l'association professionnelle des développeurs de jeux du Royaume-Uni) pendant 2 ans. Croyez-moi, je pense que le nombre de développeurs de jeux qui voulaient migrer vers le Web pourrait probablement être compté sur une main - les développeurs de jeux sont déjà dans l'industrie qu'ils aiment et prennent même un salaire/travaillent de longues heures malgré cela, donc ces ne devrait pas être le public cible de WA. Oui, leurs employeurs sont toujours à la recherche de nouveaux supports sur lesquels porter leurs jeux, mais ne nous leurrons pas, à l'exception du mobile (où le code natif gagne malheureusement haut la main et c'est ce que je veux que WASM corrige), le Web est toujours le parent pauvre du PC/console tant en termes de performances que de monétisation.
5) Inversement, alors que la scène des codeurs/indépendants n'est pas au zénith d'il y a quelques années, il existe un grand nombre de développeurs Web qui ont envie de créer un jeu Web pendant leur temps libre. Et bien que je ne veuille pas me lancer ouvertement dans la politique et que je ne frappe en aucun cas les gars d'Unity (j'ai eu affaire à un certain nombre d'entre eux et c'est un excellent produit), personnellement, je pense que vous devriez vous occuper des intérêts des multiples petits gars, pas le seul gros (cela a un sens à la fois philosophique et commercial).

J'ai hâte de voir ta conférence @jfbastien :)

@RyanLamansky - Je pense que vous faites une distinction raisonnable. En ce qui concerne:

Le point 1 n'est travaillé par personne, pour autant que je sache. C'est extrêmement compliqué et de plus en plus difficile à mesure que JavaScript continue d'évoluer à un rythme rapide.

Sur un plan tout à fait personnel, en tant que personne qui écrit du JS 8 heures par jour depuis 2008, j'aimerais beaucoup voir l'évolution de JS s'arrêter un moment et laisser tout le monde se rattraper ! J'ai toujours travaillé sur un principe de développement pour le plus petit dénominateur commun, c'est-à-dire que s'il n'a pas de support à 100%, cela ne se produit pas (IE6/7/8/9 à part ;-) ). Et nous nous trouvons donc dans la position ridicule de nous concentrer sur les modèles ES6 à la mode et les cas d'utilisation supposés alors que nous n'avons même pas une prise en charge à 100% du navigateur pour ES5 sur les ordinateurs de bureau et mobiles. Le langage fonctionne clairement tel quel (malgré ses faiblesses admises) comme le démontre sa part de marché, alors que diriez-vous, en tant que communauté de développeurs, de passer les prochaines années à apprendre à écrire un code efficace et optimal avec ce que nous avons plutôt que encore une fois réinventer la roue avec un nouveau code hipster (désolé, je me lance dans la diatribe ;-)) ?

Je pense qu'il est probablement temps que j'aie mon manteau ;-)

@RyanLamansky J'ai eu l'impression que WebAssembly ne serait qu'une nouvelle cible pour votre processus de création de bundle, et tout à coup, tout ira plus vite. Ce n'est clairement pas le cas. WebAssembly a un cas d'utilisation cible très spécifique et n'aura probablement pas grand-chose à offrir au développeur Web typique avec une grande base de code JS pleine de logique métier.

Mais comme vous le notez, il existe des lacunes dans le cycle de vie de développement basé sur JS pour des applications Web plus typiques orientées métier :
1) Les gros bundles JS ont une surcharge d'analyse significative et fournissent généralement un obscurcissement insuffisant.
2) Le code JS standard ne contient pas les annotations de type (et peut-être d'autres astuces) nécessaires pour effectuer des optimisations de code JIT/natif.

Cela suggère qu'une solution possible est une version correctement typée et annotée de JS qui donne au développeur des chemins d'optimisation plus déterministes et transparents, et une version binaire pré-analysée de cette version du langage.

Les commentaires et la documentation indiquent que WASM fonctionne en plus de JS et utilise le même moteur JS de navigateurs (optimisé). https://developer.mozilla.org/en-US/docs/WebAssembly

Je ne comprends pas vraiment cette question.

Désolé de poser une question stupide et de faire un commentaire stupide : est-ce que la question et le commentaire de l'équipe Webassembly signifient que Webassembly is FASTER than Javascript? I do not see performance comparison for WebAssembly Code and similar Javascript Code? je ne vois que des pensées subjectives. Quelqu'un peut-il expliquer cela? Si Webasembly est plus rapide que Javascript, alors pourquoi ne pas fournir un transpiler ? Si Javascript n'est pas possible, pourquoi pas le code ES7/TS ? Pourquoi y a-t-il tant de secret autour de ça ?

@ganeshkbhat La version initiale de WASM n'est guère plus qu'un encodage binaire compact d'asm.js, qui est un sous-ensemble très strict de JavaScript. Il ne s'exécute pas plus rapidement que asm.js à moins que des entiers 64 bits ne soient utilisés, car ceux-ci doivent être émulés dans asm.js.

Il existe des propositions pour ajouter des fonctionnalités à WASM qui le rapprocheraient de JavaScript en termes de capacité (récupération de données, intégration DOM, threads), mais il n'est pas prévu d'ajouter l'ensemble complet de fonctionnalités JavaScript. Il est donc probable qu'un transpileur JS->WASM n'existera jamais. Au lieu de cela, de nouvelles applications et bibliothèques seront créées, conçues pour fonctionner dans les limites de WASM. Aujourd'hui, c'est C et C++, où les restrictions de langage s'alignent bien avec WASM et asm.js.

Il n'y a pas de secret ni de magie. Wasm est "plus rapide que JavaScript" car c'est un langage beaucoup plus simple et beaucoup plus proche du matériel. JavaScript est un langage compliqué qui doit faire beaucoup de choses coûteuses lors de son exécution. Cela ne serait pas magiquement plus rapide en le compilant en code natif via Wasm au lieu de directement.

@ganeshkbhat actuellement, il n'est pas possible d'allouer des objets dans asm.js / webassembly. Dans asm.js et webassembly, toutes les opérations JavaScript utiliseront un grand typedarray pour stocker et charger leurs valeurs. La création d'objets JavaScript (par exemple var obj = {a: 1, b: 'test'} ) et de tableaux (par exemple var a = []; ) n'est pas possible dans webassembly car il n'y a pas encore de support d'objet. Il s'agit d'une décision de conception du produit minimal viable prise pour obtenir une prise en charge de l'assemblage Web dans tous les principaux navigateurs dès que possible.

Dans une future version, le support GC est prévu pour l'assemblage Web. Nous (développeurs de LeaningTech.com ) travaillons sur une proposition de prise en charge d'objets dans l'assemblage Web, mais cela prendra un certain temps avant d'arriver en tant que spécification et implémentation dans tous les principaux navigateurs. Jusque-là, il n'est pas possible de transpiler JavaScript (et CoffeeScript, TypeScript, etc.) en webassembly. Lorsque la proposition est acceptée, il devrait être possible de transpiler un plus grand sous-ensemble de JavaScript , mais il ne prendra

Sûr. Attendez-vous à un meilleur support pour JS ici. Je pense vraiment qu'il peut être soutenu. L'écriture d'un transpileur est ce qui pourrait être nécessaire pour les langages de support de type.

D'après ce que j'ai lu à propos de webassembly, il cible principalement les navigateurs Web et dans ce domaine, il ne semble pas très attrayant d'avoir js -> compilateur webassembly. Mais je peux imaginer exécuter webassembly dans des environnements sans navigateur. Ce n'est pas tout à fait vrai car in peut également fonctionner dans nodejs, mais je vois que c'est un vrai potentiel dans les environnements nodejs dans quelque chose comme vertx - polyglot permettant d'exécuter des modules écrits dans n'importe quel langage, qui peuvent être compilés en webassembly. Je peux imaginer qu'il sera extrêmement difficile de faire quelque chose comme ça. Cela nécessitera de nombreuses fonctionnalités comme GC, peut-être même une sorte de VM pour être implémentée, mais rien n'est impossible. Rappelez-vous que beaucoup de gens étaient également sceptiques à propos d'asm.js et regardez-le aujourd'hui.

Pour tous ceux qui sont enthousiastes (comme moi) à l'idée de compiler js -> webassembly, il pourrait y avoir un chemin indirect et très cahoteux à travers js -> c -> webassembly en utilisant le transpiler du projet

@mauron85 Les environnements d'exécution non-navigateur et non-JavaScript sont définitivement une considération de la conception, c'est juste que seule l'API JS existe aujourd'hui.

Pour ma part, j'ai expérimenté un système .NET JIT et je ne vois pas d'obstacles réels autres que le temps, et je suis sûr qu'il y en a d'autres qui cherchent également à intégrer WASM dans leurs plateformes préférées. Je suis certain que dans quelques années, il y aura des runtimes non-JavaScript de haute qualité pour WebAssembly, la seule question ouverte est de savoir dans quelle mesure ils seront officiellement approuvés par l'équipe WebAssembly.

IMO, l'un des avantages de la capacité de compilation de JavaScript -> WebAssembly est que les développeurs/mainteneurs des bibliothèques et outils Javascript seraient probablement en mesure de publier leurs API dans deux formats :

1. dans JS (tel qu'il est actuellement) que les utilisateurs peuvent utiliser pour les navigateurs et les nœuds
2. WASM comme bibliothèque compilée qui pourrait être plus efficace.

Et ceci sans avoir à réécrire leur code JS existant en C/C++, s'ils veulent libérer les avantages de performances de WASM dans leurs bibliothèques JS.
Ainsi, les développeurs de bibliothèques seraient toujours en mesure de développer et de maintenir en Javascript et de produire deux sorties pour deux cibles différentes à la fois en JS et en WASM.

Et l'utilisation de la bibliothèque de versions WASM compilée serait certainement plus efficace pour les utilisateurs, car tout ce qu'ils ont à faire est d'utiliser l'API exposée à partir de la bibliothèque et ils ne se soucieront évidemment pas de savoir si elle est écrite en WASM ou non. Mais les performances seraient certainement améliorées.

WASM comme bibliothèque compilée qui pourrait être plus efficace

Pourquoi? Pourquoi une goutte de javascript transpilerait-elle l'assemblage Web (le pire des cas, y compris une grande partie du temps d'exécution d'un moteur javascript dans ce binaire ; le meilleur des cas, y compris une couche construite au-dessus du futur wasm GC intégré, qui entraîne de toute façon sa propre surcharge ? ) exécuter plus vite que ce javascript lancé à un jit dédié à... exécuter javascript ?

D'accord, vous voulez dire que ce serait encore plus lent avec plus de frais généraux ?

Il y a peut-être quelque chose que je n'ai pas bien compris. Comment les trucs compilés C/C++/Rust -> WebAssembly vraiment efficaces et même s'il y a un support JS -> WASM à l'avenir qui causerait des frais généraux ? Est-ce juste parce que JS est un langage dynamique et que C, C++ et Rust ne le sont pas ? Ou est-ce parce que JS n'est par nature pas un langage entièrement compilé mais ces autres langages le sont ?

Je suppose qu'il est peu probable que la compilation de JS vers WASM améliore des performances durables ; cependant, cela peut améliorer la taille du code et le temps d'analyse en raison du codage binaire, qui est toujours utile.

Je pense que nous pouvons simplement définir un codage binaire pour JS et ignorer la mémoire linéaire, etc. pour le moment. C'est simple et polyremplissable.

@kabirbaidhya Le principal problème avec JS -> WASM en ce moment est que vous ne pouvez pas créer un ramasse-miettes efficace à l'intérieur car il n'y a aucun moyen d'analyser la pile pour voir quels objets sont vivants. Cela signifie que vous devrez placer une copie de toutes les références d'objets dans la mémoire linéaire (le tas) et la garder synchronisée, dégradant sérieusement les performances. Il manque également de multi-threading en mémoire partagée, de sorte que la récupération de place en arrière-plan est impossible. Les futures versions de WASM pourront puiser dans le moteur de récupération de place du navigateur hôte, éliminant ce problème.

L'autre obstacle majeur à JS -> WASM est le fait que presque tous les objets sont entièrement dynamiques. WASM s'attend intrinsèquement à ce que tout soit purement statique, des couches de mappage complexes, une émulation et une génération de code dynamique seraient donc nécessaires pour approcher les performances JS standard. Heureusement, TypeScript aide à cela, donc un sous-ensemble strict de TypeScript peut être en mesure de cibler WASM dans une certaine mesure. Je sais qu'il y a au moins une personne qui essaie de construire ça.

C/C++ fonctionne bien avec la première version de WASM en raison du fait que les limitations de WASM sont étroitement alignées sur les limitations matérielles natives, que C/C++ est conçu pour cibler.

FWIW, il existe un excellent diaporama sur la façon dont V8 gère l'arithmétique JavaScript : https://docs.google.com/presentation/d/1wZVIqJMODGFYggueQySdiA3tUYuHNMcyp_PndgXsO1Y/edit

tl; dr c'est juste _un_ exemple où la réalité est beaucoup plus difficile qu'il n'y paraît et dans la pratique n'est pas très significative puisque la machine virtuelle native peut (et fera probablement) un travail meilleur et plus rapide car elle est vraiment native et a accès à les ressources et les API ne le seront jamais - et (probablement) plus important encore, des années d'itération.

Cela ne veut pas dire qu'un _sous-ensemble_ de JS/TypeScript ne pourrait pas proliférer avec succès, comme ThinScript , TurboScript , etc. Ils

Je pense toujours que ce sont de bonnes questions à poser, et continuer à poser. Il est essentiel que nous comprenions tous les cas d'utilisation et l'avenir de WebAssembly, ainsi que les non-objectifs.

Le 6 avril 2017 à 00h36, Ryan Lamansky [email protected] a écrit :

L'autre obstacle majeur à JS -> WASM est le fait que presque tous les objets
sont entièrement dynamiques. WASM s'attend intrinsèquement à ce que tout soit purement
couches de mappage statiques, donc complexes, émulation et génération de code dynamique
serait nécessaire pour approcher les performances JS standard. Heureusement,
TypeScript aide avec cela, donc un sous-ensemble strict de TypeScript peut être en mesure de
cibler WASM dans une certaine mesure. Je sais qu'il y a au moins une personne qui essaie de
construire ça.

Malheureusement, je doute que TypeScript aide à cet égard. Pour englober
L'héritage de JS, son système de types est si profondément et fondamentalement malsain que
il n'y a pas de sous-ensemble "strict" intéressant. Par exemple, un tel sous-ensemble serait
besoin d'exclure toute notion de sous-typage de TS, ce qui le rendrait assez
bien inutile dans son domaine.

Il y a eu de bons articles de recherche, comme par exemple sur SafeTypeScript, mais pas
seulement sont-ils plus restreints, ils nécessitent également des quantités substantielles de
une comptabilité et des contrôles supplémentaires coûteux au cours de l'exécution, allant à l'encontre de l'objectif de
la discussion (et étant effectivement une langue différente de JS/TS).

Peut-être que je n'obtiens rien, mais l'une des idées de WebAssembly est de charger directement l'AST pour éviter le temps d'analyse de js, non ?

Donc, si nous avons un outil qui compile js dans ce format ast et le transmet au navigateur, ne gagnera-t-il pas à éviter le temps d'analyse ?

@agnivade , c'est un AST pour un langage complètement différent, beaucoup plus bas niveau.

Si vous deviez compiler JS sur Wasm hors ligne, alors oui, vous n'auriez pas besoin d'analyser côté client (juste décoder). Dans le même temps, parce que JS est si compliqué, la taille du code augmenterait considérablement, probablement d'un facteur 5 ou plus, ce qui représente un coût beaucoup plus élevé. (Et cela ne tient même pas compte du fait que vous auriez probablement également besoin d'inclure une implémentation complète d'un système d'exécution de machine virtuelle JS dans Wasm, ce qui représente facilement des mégaoctets de code.)

De plus, sans une représentation des sources, vous ne pouvez pas implémenter la plupart des optimisations dynamiques qui sont cruciales pour obtenir JS presque rapidement. Ces optimisations reposent sur la recompilation du code source original et sa spécialisation en fonction des informations de profilage. Un Wasm AST déjà compilé ne permet pas cela, vous auriez besoin d'un AST du programme source d'origine.

@rossberg-chromium - Merci beaucoup. Cela éclaircit beaucoup de choses ! Un doute cependant -

Et cela ne tient même pas compte du fait que vous auriez probablement également besoin d'inclure une implémentation complète d'un système d'exécution JS VM dans Wasm, ce qui représente facilement des mégaoctets de code.

Pourquoi auriez-vous besoin du système d'exécution VM ? Le navigateur lui-même n'est-il pas le runtime de la VM ? Je veux juste que le code soit au format AST afin que le navigateur puisse facilement commencer à l'exécuter. Je comprends que la taille nette augmentera car le langage lui-même est complexe et nous ne pouvons pas mettre en œuvre des optimisations dynamiques. Mais pourquoi avons-nous besoin de regrouper le runtime de la VM lui-même, alors que nous avons le navigateur pour cela ?

@agnivade , sans optimisations dynamiques, JavaScript sera lent, et je veux dire _vraiment_ lent, comme 100 fois plus lent, peut-être pire.

Par "runtime", je ne veux pas dire des trucs de navigateur comme le DOM, mais la prise en charge du langage JS nu, c'est-à-dire des choses comme le ramasse-miettes, les représentations d'objets, les primitives et les bibliothèques de base, etc. C'est assez énorme pour JavaScript, et vous voudriez besoin d'une réimplémentation de tout cela à l'intérieur de Wasm.

Et bien sûr, vous auriez également besoin d'une couche d'interface avec le DOM.

Ok je pense que je comprends un peu mieux les choses maintenant. je pensais que le

ramasse-miettes, représentations d'objets, primitives et bibliothèques de base, etc.

peut être utilisé à partir du navigateur lui-même. Et je peux simplement laisser le navigateur charger l'AST et faire son travail habituel. Mais maintenant, je me rends compte que tout doit être emballé à l'intérieur de WASM lui-même.

Un bytecode de langage de script universel serait cependant intéressant ! Une cible de compilation conçue pour transporter et exécuter efficacement des programmes écrits dans des langages de type ramassé dynamiquement, avec tous les cas extrêmes bizarres des langages populaires (javascript, ruby, python, lua) couverts (dans certains cas) d'opcodes et de structures spéciaux, etc.

@distransient , vous voulez donc la folie combinatoire de tous les langages de script ? Je suis optimiste qu'il serait possible pour l'humanité de rassembler les ressources d'ingénierie pour spécifier et mettre en œuvre cela efficacement d'ici 2050. :)

Ceux qui sont intéressés par la compilation de TypeScript en WebAssembly à l'aide de LLVM. Découvrez ce projet de portée. https://github.com/MichaReiser/speedy.js
On dirait que cette discussion est sans fin...

@rossberg-chromium j'ai dit que ce serait "intéressant", pas facile ni joli 😉

Un bytecode de langage de script universel serait intéressant...

Alors que WASM évolue progressivement pour éventuellement prendre en charge des choses comme Python, nous pourrions avoir un support de première classe pour le développement de langages de script pour le Web beaucoup plus tôt que WASM ne peut le fournir, si nous abordions le problème de l'autre côté en même temps.

Il devrait être relativement simple pour les moteurs JavaScript d'exposer leur capacité à exécuter des AST JavaScript, et les AST qu'ils ont acceptés pourraient être standardisés (même s'ils sont immédiatement convertis en un format intermédiaire non standard en interne).

Nous pourrions simplement combiner un format AST (comme estree ) et un format de sérialisation (comme JSON) pour créer un nouveau format de fichier avec une nouvelle extension. Si les navigateurs prenaient en charge le format dans les balises de script et ainsi de suite, alors des langages comme TypeScript et CoffeeScript seraient simplement compilés pour analyser les arborescences, et le navigateur le prendrait à partir de là. Les langues transpilées n'auraient pas besoin de générer de code, et les cartes de source ne seraient plus nécessaires non plus, car les informations lexicales seraient basées sur la source réelle.

Une fois la prise en charge de base établie, la norme pourrait évoluer progressivement pour répondre à WASM au milieu, en ajoutant simplement de nouveaux types de nœuds. Il y a des choses simples pour commencer, comme des nœuds explicites add et concat , ou peut-être l'ajout de nouveaux types de données, comme DEC64.

Au fur et à mesure que WASM prend en charge les langages de script, en ajoutant des éléments tels que GC, l'exécution d'AST se déplacerait vers le bas, étendant la sémantique JavaScript pour inclure des fonctionnalités d'autres langages de haut niveau, afin qu'un ensemble plus large de langages de script puisse se compiler en une sorte de JavaScript abstrait .

Le 25 mai 2017 à 02h57, Carl Smith [email protected] a écrit :
>

Il y a des problèmes qu'il faudrait régler, mais il serait
relativement simple pour les moteurs JavaScript d'exposer leur support interne
pour l'exécution des AST JavaScript, et les AST qu'ils acceptent doivent être
standardisé (même si l'AST est immédiatement converti en non standard,
formats intermédiaires en interne).

Seulement pour une définition beaucoup plus large de « relativement simple » que vous avez probablement
avoir à l'esprit... ;)

Par rapport à WASM, c'est simple.

@bguiz Par exemple :

• Vous ne pouvez pas traduire nativement JS en ASM, car son architecture est différente.
• Vous ne pouvez pas manipuler le DOM à partir d'ASM, car vous n'avez pas accès à ses ressources au niveau du processeur.

Le moteur Google V8 compile déjà le JavaScript directement en code machine natif, en compilant l'ensemble de la tâche d'exécution, avant de l'exécuter.

Il serait donc totalement inutile d'avoir un pipeline WASM alternatif du côté client.

D'un autre côté, WASM a été présenté avec une démo de Mandelbrot, puis il présente en premier lieu une démo Unity "Tanks", mais je doute fort que dessiner des pixels avec ASM->CPU (même avec une double précision SSE) puisse être plus rapide que WebGL->GPU, car comme le dit cette communauté, le GPU n'est pas dans le champ d'application. Et alors?

@ivanherczeg Ouah ! Où cette communauté dit-elle que le GPU n'est pas conforme aux spécifications ?

@SephReed

Nous avons déjà des tensions dues aux différences de bikeshed entre arm et x86. Je pense que l'ajout d'un autre ensemble de cibles matérielles créerait plus de tension : plus d'opérations devraient soit être lentes en raison des coûts d'émulation pour obtenir une sémantique uniforme sur toutes les cibles, soit plus d'opérations devraient avoir un comportement indéfini pour permettre à tout le monde de fonctionner rapidement. Je pense qu'il n'est pas rentable d'envisager le GPU pour le moment (ou jamais).

-Fil

https://github.com/WebAssembly/design/issues/273#issuecomment -123094583

Le runtime C# a été porté sur wasm et était un prototype entièrement fonctionnel remplaçant complètement JS. Cela signifie donc qu'à l'avenir, vous pouvez vous attendre à ce que les runtimes émergent pour remplacer JS sur les navigateurs et écrire des applications Web côté client en Java, C# ou même C++ avec une déclaration disant "Le code s'exécutera plus rapidement près du natif" , "Le code compilé est plus rapide que la VM" ou quoi que ce soit sans l'aide de JavaScript.

S'il vous plaît regarder cette vidéo de ce que j'essaie de dire.

WebASM a été introduit pour compléter JS pour ne pas prendre complètement le relais, remplaçant le langage de première classe.

Dans un avenir proche, vous pouvez vous attendre à des pages Web livrées à partir d'un serveur compilé nativement

https://github.com/ballercat/walt

@Steakeye Très sympa :) Je vais jouer - merci beaucoup pour la mise en évidence :)

vous pouvez compiler JS en WebAssembly en utilisant NectarJS . Démo : http://nectar-lang.com/ choisissez dans la liste déroulante WebAssembly

Intéressant, la démo NectarJS utilise emscripten, vous pouvez le voir dans la sortie asm.js. Il semble qu'il compile statiquement JS en quelque chose - probablement C ou LLVM IR - puis l'exécute via emscripten.

La sortie wasm utilise également emscripten (peut être vu en inspectant le binaire), mais il semble utiliser une ancienne version car il émet des binaires wasm 0xd, qui ne s'exécutent pas dans les machines virtuelles modernes. Il vous envoie également simplement le wasm, pas le JS, il n'est donc pas exécutable de toute façon. Dans tous les cas, il est très possible que cela fasse la même chose que pour asm.js, en exécutant simplement emscripten avec le drapeau pour la sortie wasm activé.

La démo a une limite de 300 octets sur l'entrée, il est donc difficile de lui fournir un programme du monde réel pour avoir une idée de la puissance de leur analyse, ce qui est la vraie question avec une approche statique comme celle-ci. En général, les recherches universitaires sur ce sujet suggèrent le scepticisme.

Leurs démos compilées pour Windows plantent simplement pour moi 🤕

Je suis d'accord avec le scepticisme de @kripken ici. Je pense que JS arbitraire ne peut pas être raisonnablement converti en WebAssembly. Tout outil qui prétend atteindre cet objectif travaille probablement sur un sous-ensemble traitable du langage JS, ou abandonne les performances d'exécution.

JS est un langage extrêmement dynamique. Des opérations d'exécution imprévisibles peuvent modifier de manière significative et globale la sémantique du code. Cela signifie qu'un compilateur Ahead-Of-Time (ou hors ligne) ne peut que supposer le pire et générer un code générique très inefficace qui peut gérer tous les cas possibles. Par exemple, prenons le code JS suivant :

var a = {prop1: 1};
func(a);

pourrait être converti (en pseudo-wasm) en ce

i32.const 42
call $CreateJSValFromStrTable ;; Returns prop1
i32.const 1
call $CreateJSValFromInt
call $CreateJSObj1 ;; Consume a JS string and a JS value to make an object
call $_func

Maintenant, c'est loin de ce que nous pouvons raisonnablement considérer comme "compiler" et cela ressemble plus au déroulement d'un interprète. Il est bien sûr également possible d'exécuter un interpréteur JS compilé sur Wasm, mais ce ne serait guère un gain de performances.

Les moteurs JS tels que V8 et Spidermonkey peuvent exécuter le code JS aussi rapidement qu'ils le font en le compilant juste à temps. En faisant la compilation JIT, ils peuvent observer quelle est la véritable sémantique prévue pour un morceau donné de JS et générer du code rapide pour ce cas spécifique, tout en faisant bien sûr attention à détecter tout changement dans l'environnement qui pourrait invalider les hypothèses actuelles.

D'accord. Cependant, cela ne me dérangerait pas d'utiliser un sous-ensemble JavaScript. Ou peut-être une variante typée, qui réduirait probablement le dynamisme et permettrait de générer un code plus efficace.

Y a-t-il des nouvelles sur le front du "mode fort" BTW?

@Simran-B, nous avons depuis longtemps abandonné le mode fort, pour les raisons résumées ici . Le point à retenir est qu'il est pratiquement impossible de resserrer la sémantique JavaScript sans perdre l'interopérabilité avec le code existant.

Pour la même raison, je n'ai pas non plus beaucoup d'espoir pour l'idée de concevoir un dialecte "compilable statiquement" de JavaScript ou de TypeScript - ce serait un langage différent qui ne peut pas exécuter le code existant, donc pas grand-chose.

@Simran-B : "Cependant, cela ne me dérangerait pas d'utiliser un sous-ensemble JavaScript. Ou peut-être une variante typée"

Il y a des travaux très intéressants dans cet espace, comme AssemblyScript qui est un sous-ensemble strict de TypeScript qui se compile en WebAssembly, https://github.com/AssemblyScript/assemblyscript

@rossberg : "Je n'ai pas non plus beaucoup d'espoir pour l'idée de concevoir un dialecte "statistiquement compilable" de JavaScript ou TypeScript -- ce serait un langage différent qui ne peut pas exécuter de code existant, donc pas grand chose."

Je pense que le gros potentiel avec des choses comme AssemblyScript n'est pas d'exécuter du code existant (je suis d'accord avec vous, ce ne sera pas faisable en général), mais qu'avoir un langage convivial et familier est une grosse affaire.

À l'heure actuelle, si vous êtes un développeur TypeScript et que vous souhaitez écrire WebAssembly, vous devez utiliser C++ ou Rust. Les deux sont de bonnes langues mais ont aussi des inconvénients. Pour quelqu'un avec cette formation, quelque chose comme AssemblyScript pourrait être le chemin le plus rapide vers la productivité.

Si AssemblyScript peut compiler à la fois en JavaScript et en Assembly, ce serait plutôt idéal. Dans l'attente de ces mises à jour.

De plus, à l'avenir, à moins que quelqu'un ne le fasse en premier, j'essaierai probablement d'écrire un convertisseur TypeScript -> Assembly Script qui parcourt les fichiers, pose les questions qu'il doit poser, puis effectue la conversion. Espérons que ça marche !

@SephReed Oui, il peut compiler en JavaScript, car il existe un compilateur WebAssembly -> asm.js , qui devrait fonctionner avec tout le code WebAssembly.

Voir aussi la rubrique « WebAssembly peut-il être polychargé ? »

Si vous vouliez plutôt dire « est-il possible pour AssemblyScript de compiler en code JavaScript idiomatique ? », alors je dois demander, pourquoi voudriez-vous faire cela alors que WebAssembly / asm.js sont tellement plus rapides que le code JavaScript idiomatique ?

Bien que je suppose que vous devriez pouvoir exécuter le code AssemblyScript via le compilateur TypeScript. Cependant, vous devrez garder certaines choses à l'esprit .

Voir aussi cette section de la documentation AssemblyScript.

Messieurs, veuillez considérer WALT , le langage WebAssembly de type JavaScript.

UPD. Désolé pour la nécroposte

Je vois que beaucoup de gens considèrent ce compilateur "JS -> WASM" comme une bonne idée.

Pour ceux qui ne le trouvent pas utile, comme :

Je ne suis pas sûr que ce soit si utile du point de vue d'un développeur, cependant. Vous pouvez obtenir une réduction de taille, mais c'est à peu près tout. Du point de vue d'un navigateur, il peut être intéressant d'implémenter le moteur JS dans wasm d'un point de vue purement sécuritaire.

S'il vous plaît, voici mon exemple concret de pourquoi c'est important, et pourquoi c'est utile, et pas seulement vous "obtenez une réduction de taille, mais c'est à peu près tout". L'une des fonctionnalités fournies avec WebAssembly est :

<=XXX « ENVIRONNEMENT SABLIER » XXX=>

WebAssembly n'est pas seulement une question de performances. Vous pouvez voir un bon article sur les plugins de l'équipe Figma .

Faire un système de plugin est assez difficile. Vous avez besoin d'un bon moyen d'exécuter du code personnalisé. Vous avez besoin d'un environnement séparé, sûr.

WebAssembly vous donne cela, - un environnement pur sans désordre comme certaines variables globales. AssemblyScript le rend pratique d'une certaine manière, - vous avez presque le même environnement TypeScript, que l'environnement de votre application principale, ce qui est plutôt cool.

Mais voici le problème, "presque le même":

Puis-je utiliser les packages JS de NPM dans mon environnement sécurisé ?

Non.

Eh bien, ce projet WALT est une sorte d'alternative à AssemblyScript. C'est à peine du genre JS, - c'est tapé js. C'est plus comme TS-like. Vous ne pouvez pas compiler/transpiler les bibliothèques js existantes avec cela.

Puis-je utiliser les packages TS de NPM dans mon environnement sécurisé ?

Non.

AssemblyScript est également un langage de type TS. Il peut compiler quelque chose d'écrit en TS s'il est entièrement couvert par des types. Aucune exception. Non, aucun any . Mais souvent les gens ont leurs configurations pas assez strictes ou ils ont quelques @ts-ignore , ou même plus souvent, - ils écrivent des packages en js et fournissent des types séparés dans des fichiers .d.ts - dans tous ces cas, vous ne pourra pas compiler un tel package sur WASM.

@JerryGreen de bons points, mais du côté des performances, je pense en fait que c'est une énorme idée fausse qu'il n'y a pas d'avantages significatifs en

Pourtant , l'occasion dans le monde réel est en fait dans la performance de démarrage, ce qui profite pratiquement tous les sites. Peu semblent parler de la façon dont WebAssembly est considérablement plus rapide en termes de temps de démarrage (par octet), bien au-delà de tout avantage d'exécution. C'est pourquoi, par exemple, gzip sur du contenu textuel, tel que JavaScript, a peu d'impact réel sur PLT - c'est la taille du code compilé qui compte.

Ironiquement, l'industrie est obsédée par le PLT (Page Load Times) et divers marqueurs visuels complets, mais personne ne voit la corrélation entre WebAssembly et ces vecteurs ? JavaScript est responsable de plus de 30 % du temps passé avant ces événements critiques, sur la plupart des sites Web. En fait, la taille des pages et la bande passante ont beaucoup moins d'impact sur les PLT par rapport aux facteurs de performances linéaires, à savoir les temps de démarrage et la latence de JavaScript.

Cela dit, la faisabilité de JS -> WebAssembly n'est pas claire pour moi.

L'approche de @JerryGreen Figma est un cas très spécifique et je suppose que pour la plupart des projets, les iframes ou les domaines sont assez jolis pour l'isolement javascript tiers. Pour les cas particuliers où l'isolement doit être mieux contrôlé et où les performances, la taille et le temps de chargement ne sont pas si importants, vous pouvez toujours compiler QuickJS ou JavaScriptCore vers WebAssembly.

Vous pouvez également utiliser Web Workers et exécuter du code avant votre code non approuvé qui supprime toutes les API auxquelles vous ne souhaitez pas que le code non approuvé ait accès. Pas besoin de WASM dans ce cas @JerryGreen !

Framerate Drops in Three js dans une chose réelle, je ne sais pas si wasm pourrait aider, mais il semble bien que oui, du moins en surface.

Il n'y a aucune raison de compiler JS en wasm car vous devrez également inclure un vm javascript complet. Le code résultant serait énorme et plus lent que la VM JS fournie nativement.

Ne pourrions-nous pas faire toutes les monomorphisations, etc. qui sont effectuées par les machines virtuelles JS via l' optimisation guidée par

Une compilation PGO se compose de deux étapes : une première étape pour créer des binaires instrumentés, puis une deuxième étape pour reconstruire des binaires optimisés à l'aide des informations de profil glanées lors de l'exécution des binaires instrumentés.

La première exécution nous fournirait toutes les informations de type (quelles fonctions sont appelées avec quels arguments typés, etc.), puis nous construisons un binaire optimisé avec toutes les variantes avec lesquelles une fonction est appelée (+ générique avec des arguments dynamiques pour le code non profilé) . Nous n'aurions pas besoin de toute la VM JS.

PGO exigeait une excellente couverture de test de votre programme. Ce n'est pas toujours possible. Mais vous pouvez tracer certaines informations de type lors de l'exécution dans la v8. Voir ce document : https://docs.google.com/document/d/1JY7pUCAk8gegyi6UkIdln6j_AeJqQucZg92advaMJY4/edit#heading =h.xgjl2srtytjt

Nous avons discuté avec l'équipe TypeScript de cette possibilité et ils ont manifesté leur intérêt, mais il semble que des progrès soient actuellement en cours pour l'ajout d'objets typés dans JS.

Pas besoin de types

QuickJS peut-il vraiment être compilé en WASM ?

Oui, Figma utilise QuickJS pour son système de plugin par exemple

Et il est également utilisé dans http://numcalc.com/ .