Oui c'est le moteur unity dans la démo.
Par contre j'aimerais bien moi aussi savoir comment ça marche.
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
Discussion :
Oui c'est le moteur unity dans la démo.
Par contre j'aimerais bien moi aussi savoir comment ça marche.
Pour répondre à cette question il faut revenir au fondement des langages et des compilateurs/interprètes.
Que ce soit un compilateur et une exécution ou une interprétation le processus est semblable.
On part d'un code source dans un langage, et on abouti à un binaire exécuté par le processeur.
La différence entre compilation/exécution et interprétation se situe dans le temps. À quel moment, on fait certaines actions pour passer du code source au binaire*?
Pour faire simple ce processus passe par plusieurs étapes.
- Lecture du flux de caractères du code source.
- Regroupement en "mot" des éléments du langage.
- Analyse syntaxique
- Analyse sémantique
- Production binaire
- Exécution.
Dans le cas d'un compilateur/exécution les étapes 1 à 5 sont faites à la compilation.
Dans le cas d'un interprète elles sont faites à l'exécution.
Pour passer d'une étape à une autre il y a échange d'information dans une structure dédiée.
Entre l'étape 3 et l'étape 4 la structure communément utilisée est un Arbre Syntaxique Abstrait: AST.
Cet arbre représente l'ensemble du code qui devra être exécuté. Sa production contient une représentation de tout le code source.
mais il peut subir de nombreuse modification (les compilateurs sont les champions de l'optimisation)
par exemple
Supprimer le code mort.
Supprimer les tests inutiles.
etc.
L'arbre étant une structure simple son parcours pour faire l'analyse sémantique est facilité. Ce processus consiste à définir ce que doit faire le programme.
Il existe plusieurs façons de définir ce que produit cette étape.
La dernière étape est la production du binaire. Qui là encore va utiliser la structure simple produite par l'analyse sémantique pour travailler.
Cette étape va grandement dépendre du processeur cible.
On voit que les étapes les plus coûteuses sont les 3 premières.
Ce que propose WASM c'est une définition commune de l'AST.
Cette définition commune permet beaucoup de choses.
La première est que de nombreux langages peuvent être analysés et produire un AST conforme.
La deuxième est que l'analyseur sémantique ne dépend plus que de l'AST. on peut donc produire du code pour de nombreuses cibles. De nombreux acteurs peuvent proposer un producteur alternatif.
WASM va un cran plus loin en affichant la volonté de définir un format binaire universel pour enregistrer cet arbre dans un flux (fichier)
Cela permet de séparer la phase d'analyse de la phase de production.
Cette dernière peut donc être faite dans le navigateur.
Les avantages par rapport à une interprétation sont que la coûteuse analyse et déjà faite. Les optimisations de code peuvent être déjà faites. Le format de l'AST est compact (mieux sur le net). La structure est très basique donc facile à lire (pour une machine). La production de code machine est facilité.
Comment cela s'intègre dans le navigateur*? Le navigateur possède plusieurs moteurs le premier est le moteur d'interprétation du HTML qui passe du code html svg xml au DOM le second est le moteur JavaScript qui relie le code js au DOM.
Ce moteur est un compilateur à la volée. Il conserve dans sa mémoire les blocs de code qu'il a déjà interprété. Ces deux moteurs accèdent au du code natif du navigateur. Pour cela une table de point d'entrée est conservée dans le moteur js. Ce qui permet à du js d'invoquer les fonctions d'un plug-in par exemple.
L'arrivée de WASM ne remet pas tout ça en cause. Elle le complète.
Le moteur WASM va prendre en charge les AST. il va finir la compilation (étape 4 et 5) et ajouter des points d'entrées dans la table. Le code WASM sera vu par le moteur JS comme du code natif ce qu'il est réellement.
Toute la finesse du moteur va résider dans sa stratégie.
Il peut par exemple compiler tout l'AST dès la réception mais cela peut prendre du temps (si l'AST est très gros).
Il peut ne compiler qu'une partie et remettre à plus tard (lors d'une activation d'une portion de code) le reste.
il peut profiter des temps de faible activité
etc.
Pour faire très bref WASM est appliquer le principe de la compilation en reportant sur le client la dernière phase qui le production de code.
Il ne s'agit pas comme dans la JVM de byteCode le compilateur java compile comme le compilateur C mais pour un processeur idéal qui n'existe pas. La JVM exécute ce code en simulant ce processeur et suivant le contexte le bytecode lui-même compilé à la volé en code machine.
Pour finir tout AST peut être interprété (on fait des interprètes C ou C++ par exemple) il en va de même avec WASM.
A+JYT
Superbe explication ! Pour un dev web comme moi qui ne traite qu'avec du très haut niveau et qui va sûrement devoir toucher a WASM ça va m’être très utile comme point de départ pour mes recherches. Merci !
De ce que j'ai compris on pourra écrire des web assemblies à partir de langages de plus haut niveau du moment qu'il existe un "compilateur" (je mets exprès entre guillemets) qui génère du code web assembly.
Questions
Qu'en est-il de la sécurité ? Est-ce que les web assemblies auront accès au système de fichiers des PC qui les exécutent par exemple ?
Est-ce que les navigateurs pourront être paramétrés pour ne pas les exécuter ?
Pour ce qui est de la sécurité, vu que la conversion de l'AST vers le binaire est laissé au choix du navigateur, il va pouvoir mettre l'accent sécurité sur les instructions dangereuses. Par exemple, quand un programme voudra lire une variable en mémoire, la méthode de "lecture de mémoire" ne permettra pas de sortir de la zone allouée au javascript de la page. De la même manière, "écrire une variable en mémoire" ne permettra pas d'écrire en dehors de cette zone, empêchant du même coup les "buffer overflow" qui permettent entre autre "l'exécution de code arbitraire".
WASM = optimisation
Un grand merci à l'explication complète!
J'ajoute que le code WebAssembly état binaire, compressé, il est plus petit donc rapide de charger une page web type SPA, lourde, webapp, et que ça va alléger notre 4G (ou 3G en Inde low cost par exemple)
Que cela permet aussi d'être sécurisé car un pirate interceptant la communication ne pourra lire le code comme il peut le faire avec tout script (donc dont JavaScript /ES) et injecter du code (vers le navigateur ou le serveur) (ai je bien compris?)
Bref, plus rapide, plus sécurisé, on a tout gagné.
Liberté:
Et bien sûr, on va voir enfin poindre sans doute du Ruby PHP et Python POUR NAVIGATEUR, à la place de JS... Tous les frameworks vont pouvoir devenir full-stack enfin: vu le plaisir et la facilité de Ruby, l'écosystème PHP, ou l'universalité de Python, versus la Javascript fatigue, ça va drôlement changer les choses, et on pourra enfin faire un site web avec son language préféré.
Manque une brique dans cet écosystème néanmoins: les apps smartphones:
en mobile, on veut une app plus qu'une page web (idiot mais ok...), et le dev d'apps se faisant en natif Swift pour iOS ou Java pour Android, avec néanmoins une alternative type JS via React Native de Facebook (ce que nous faisons chez nous, merci FB!) qui ensuite et porté sur iOS ou Android (ou Web tout court...), quid de WebAssembly ici sur les apps?
Je vois un futur de WebApps en progressive web apps (très belle techno balbutiante!) donc bien sur le moteur web... Webkit... aïe, Apple fait encore des siennes et n'est pas partie prenante de WebAssembly (fuck la pomme, grrrr...) et son Safari ne le supportera pas. On revient avec le problème: comment faire du natif iOS sans Swift (ni Objective-C), sans JS (que Safari, lui, supporte...)? Ah mais je me trompe peut-être, Safari est sur Webkit et donc ... ça marcherait? J''ai un doute...
Un dernier point: WASM vs Java et les IoT:
Java était "code once, run anywhere" grâce à sa JVM sur donc un "CPU virtuel idéal". Ok ok... Mais là nous avons donc une autre techno assez similaire, en tout cas qui vise aussi à l'universalité (run anywhere) MAIS qui casse le gros problème de Java: Java lui-même (et ces mossieurs d'Oracle...): on peut ENFIN coder en tout language, et viser cette machine virtuelle (WebAssembly) universelle (on peut sûrement la porter ailleurs que sur un navigateur Web, tiens! Un embedded device? Automobile, GPS, etc.?)
Il serait intéressant de faire un comparatif de performance non pas JS versus WASM mais WASM versus Java JVM!!! En avez vous? Kill java...? ;-)
Avec les IoT qui déboulent (et leur non sécurité..., et leurs réseaux lents type SigFox à 3-5 SMS par jour, leur micro CPU lent, faible mémoire, etc.) WASM pourrait être un bon remplaçant à Java (qui a été d'ailleurs exactement fait pour ça, des micro-programmes téléchargeables! Je faisais des apps java sur SIM 16K envoyées par bouts de code par SMS en 98... c'est dire! Minitel était un superordinateur à côté...)
Les années 20 (2020... ;D) vont être prometteuses...
Si le code peut être compilé en assemblies, je crains la venue de petits virus... (mieux cachés).
JS ne va pas disparaître puisqu'il restera en amont, ni TrueScript, ni Java, un langage très portable et accessible par définition.
Pas directement, mais il est fort probable que les utilisateurs de WebGL auront tout intérêt a utiliser WebAssembly pour profiter de meilleures performance et de langages plus habituels.Envoyé par hotcryx
En fait tout dépend le niveau d'optimisation voulu. Si un veut un code très optimisé les dernières étapes sont de loin les plus couteuses.
Je pense que les moteur WASM essaieront d'optimiser ça un peu comme les moteur JIT Javascript actuels, en faisant d'abord une compilation rapide et mais optimisée histoire de démarrer rapidement. Puis ils feront une compilation plus optimisée pour le code qui nécessite plus de performances.
Ce point là est faux : comme tout les bytecodes/binaires, le WebAssembly peut se désassembler et les code obtenu sera probablement plus lisible que du JavaScript brouillé.
Cacher le code n'a jamais amélioré la sécurité.
Si le code est compilé (et pas interprèté) en C, C++, oui tu pourras le déassambler mais ce sera très très obscur.comme tout les programmes, le WebAssembly peut se désassembler et les code obtenu sera probablement plus lisible que du JavaScript brouillé.
Rien à voir avec du byte code.
Donc on va s'orienter vers des pages web qui ne contiendront plus que les balises html, head et body + le chargement des web assemblies qui génèreront le html via le DOM. Ce sont les éditeurs qui vont être contents.
On ne pourra plus voir les techniques utilisées. Dommage.
Pour info, ils n'y a pas besoin de WebAssembly pour faire des pages entièrement basées sur la manipulation du DOM : c'est déjà ce que font des frameworks populaires comme ReactJS. A terme WebAssembly permettrait de faire ça, comme JavaScript le permet déjà, mais ça n'est clairement pas son but premier. D'ailleurs, la première version qui vient d'être acceptée ne permet pas encore de le faire directement.
Le but est surtout de remplacer avantageusement les codes lourds en JavaScript (jeux, animation,...) qui de toute façon sont le plus souvent déjà à base de JavaScript généré et très difficilement lisibles.
WebAssembly n'apporte rien qui ne soit déjà fait faisable (et déjà fait) avec JavaScript. Il aura juste de meilleures performances en temps de chargement et en vitesse d’exécution.
Même pas besoin de framework C'est le but même de l'existence de JavaScript côté client.
A+JYT
@sekaijin: ton explication ne me paraît pas claire. Ce que tu décris est davantage le fonctionnement des compilateurs vers WASM que WASM lui-même.
WASM n'est pas un moteur ni un compilateur, c'est un format (deux en fait, une version binaire et une version texte). Il existe et existera de nombreux compilateurs de différents langages source vers ce format. L'existence d'au moins deux compilateurs différents est requise pour passer l'étape de Minimum Viable Product, mais leur implémentation ne fait pas partie des spécifications WASM.
Aussi le code WASM n'est pas un AST. Les AST sont les produits de l'analyse syntaxique du langage source, et donc propre à ce langage. Un compilateur C++ --> WASM utilisera un AST C++, un compilateur Python --> WASM un AST Python etc. D'ailleurs le format de l'AST n'est pas standardisé, on peut imaginer deux compilateurs du même langage avec deux formats d'AST différents. Du côté de WASM, il n'y a aucun AST puisque le format reçu par les navigateurs sera binaire. L'implémentation dans les navigateurs est simplement un décodeur, pas un compilateur: il ne "produit pas de code" à cette étape. Toutes les étapes qui utilisent l'AST à des fins d'optimisation sont faites en amont par le compilateur, et non pas par le navigateur.
Vous avez tous les deux raison :
- Sur le fond WebAssembly fournit une abstraction intermédiaire entre le langage et le binaire comme les bytecode classiques (Java, LLVM, ...)
- Sur la forme le WebAssembly se présente comme un AST dans le sens ou il est constitué sous forme d'arbre plutôt que d'une suite d'instructions.
Par contre le WebAssembly n'est pas l'AST du langage d'origine mais de l'AST d'un langage intermédiaire standard.
Pitite question...
WASM, ok... mais j'me demande quand même pourquoi on pense directement à d'autres langages que le JS... après tout, il pourrait, lui aussi, être compilé et ça faciliterait grandement son adoption par la communauté des développeurs, puisqu'ils le connaissent déjà, non?
JavaScript est déjà compilé par les moteurs web actuels en utilisant le plus d'optimisation spécifiques possible. Utiliser WebAssembly n'apporterait rien.
Le problème c'est que c'est un langage qui comme son nom l'indique a été conçu pour faire du script. Il a donc des points intrinsèquement problématiques pour des applications a grandes performances (GC, typage dynamique,...). Le but de WebAssemby est justement de permettre de reposer sur des base de plus bas niveau.
Ben, justement... à mon sens, il pourrait te permettre de développer en JS... et de te convertir le tout en plus bas level, afin d'éviter la phase JIT
Sauf que "convertir le tout en plus bas level" ne veux pas dire grand chose. Être "bas niveau" c'est gérer manuellement les détails comme l'allocation mémoire, les types, ... Or JavaScript de par sa conception se doit de gérer tout cela automatiquement.
Convertir automatiquement un code qui n'a pas a gérer la mémoire, c'est justement la définition du haut niveau.
Le JIT en soi n'est pas forcément du haut niveau. on peut faire du JIT en C++. Le WebAssembly ne permettra de toute façon pas de s'affranchir de l'étape de compilation vu que ça reste une représentation intermédiaire. La représentation est certes optimisée pour une compilation plus rapide. Mais vu toute les optimisations que font déjà les moteurs JavaScript actuels sur ces points avec généralement trois niveaux de compilation/interprétation suivant le besoin de prioritaire entre vitesse de compilation et performance, WebAssemby n'apportera certainement pas de gains visibles.
Hum... mon incompréhension relève sans doute du fait de ma méconnaissance des langages de bas niveau...
Mais, à mon sens, sachant que ces optimisations sont connues, sachant aussi comment le JS est interprété et exécuté par un langage de plus bas niveau, je ne vois pas trop ce qui empêcherait de faire tout cela avant, de compiler le tout et de l'envoyer à WASM.
Je pense notamment à l'opcode, en PHP, qui fonctionne un peu sur le même principe, même si je ne sais pas si cet opcode est réellement déjà compilé.
Rien ne l’empêche de le faire, mais ça revient à refaire ce que les moteur JS actuels font déjà eux mêmes, sans doute mieux. On ne gagnera rien en performance.
Répondre avec citation
Partager