+ Répondre à la discussion Actualité déjà publiée
  1. #41
    Membre actif
    Homme Profil pro
    Développeur Java
    Inscrit en
    février 2006
    Messages
    338
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : Enseignement

    Informations forums :
    Inscription : février 2006
    Messages : 338
    Points : 213
    Points
    213

    Par défaut

    Oui c'est le moteur unity dans la démo.
    Par contre j'aimerais bien moi aussi savoir comment ça marche.

  2. #42
    Expert éminent
    Avatar de sekaijin
    Homme Profil pro
    Urbaniste
    Inscrit en
    juillet 2004
    Messages
    3 943
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Urbaniste
    Secteur : Santé

    Informations forums :
    Inscription : juillet 2004
    Messages : 3 943
    Points : 8 241
    Points
    8 241

    Par défaut

    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.
    1. Lecture du flux de caractères du code source.
    2. Regroupement en "mot" des éléments du langage.
    3. Analyse syntaxique
    4. Analyse sémantique
    5. Production binaire
    6. 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

  3. #43
    Membre confirmé
    Homme Profil pro
    Développeur Web
    Inscrit en
    octobre 2009
    Messages
    180
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Nouvelle-Zélande

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : octobre 2009
    Messages : 180
    Points : 460
    Points
    460

    Par défaut

    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 !
    Désolé pour les rétines, clavier QWERTY

  4. #44
    Membre confirmé Avatar de badaze
    Homme Profil pro
    Chef de projets info
    Inscrit en
    septembre 2002
    Messages
    335
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets info
    Secteur : Transports

    Informations forums :
    Inscription : septembre 2002
    Messages : 335
    Points : 546
    Points
    546

    Par défaut

    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 ?

  5. #45
    Membre régulier Avatar de maitredede
    Homme Profil pro
    Pisseur de code
    Inscrit en
    mai 2006
    Messages
    54
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Nouvelle-Calédonie

    Informations professionnelles :
    Activité : Pisseur de code

    Informations forums :
    Inscription : mai 2006
    Messages : 54
    Points : 73
    Points
    73

    Par défaut

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

  6. #46
    Nouveau membre du Club
    Homme Profil pro
    Chef de projet MOA
    Inscrit en
    mai 2015
    Messages
    8
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projet MOA
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : mai 2015
    Messages : 8
    Points : 27
    Points
    27

    Par défaut 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...

  7. #47
    Membre expérimenté
    Profil pro
    Développeur
    Inscrit en
    mars 2012
    Messages
    1 061
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur
    Secteur : Communication - Médias

    Informations forums :
    Inscription : mars 2012
    Messages : 1 061
    Points : 1 675
    Points
    1 675

    Par défaut

    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.
    Si la réponse vous a aidé, pensez à cliquer sur +1

  8. #48
    Expert éminent Avatar de Uther
    Homme Profil pro
    Inscrit en
    avril 2002
    Messages
    3 474
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : avril 2002
    Messages : 3 474
    Points : 8 019
    Points
    8 019

    Par défaut

    Citation Envoyé par hotcryx Voir le message
    Donc WebAssembly est lié à WebGL?
    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.

    Citation Envoyé par sekaijin Voir le message
    On voit que les étapes les plus coûteuses sont les 3 premières.
    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.

    Citation Envoyé par nhugodot Voir le message
    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?)
    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é.

  9. #49
    Membre expérimenté
    Profil pro
    Développeur
    Inscrit en
    mars 2012
    Messages
    1 061
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur
    Secteur : Communication - Médias

    Informations forums :
    Inscription : mars 2012
    Messages : 1 061
    Points : 1 675
    Points
    1 675

    Par défaut

    comme tout les programmes, le WebAssembly peut se désassembler et les code obtenu sera probablement plus lisible que du JavaScript brouillé.
    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.
    Rien à voir avec du byte code.
    Si la réponse vous a aidé, pensez à cliquer sur +1

  10. #50
    Membre confirmé Avatar de badaze
    Homme Profil pro
    Chef de projets info
    Inscrit en
    septembre 2002
    Messages
    335
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets info
    Secteur : Transports

    Informations forums :
    Inscription : septembre 2002
    Messages : 335
    Points : 546
    Points
    546

    Par défaut

    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.

  11. #51
    Expert éminent Avatar de Uther
    Homme Profil pro
    Inscrit en
    avril 2002
    Messages
    3 474
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : avril 2002
    Messages : 3 474
    Points : 8 019
    Points
    8 019

    Par défaut

    Citation Envoyé par badaze Voir le message
    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.

  12. #52
    Expert éminent
    Avatar de sekaijin
    Homme Profil pro
    Urbaniste
    Inscrit en
    juillet 2004
    Messages
    3 943
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Urbaniste
    Secteur : Santé

    Informations forums :
    Inscription : juillet 2004
    Messages : 3 943
    Points : 8 241
    Points
    8 241

    Par défaut

    Citation Envoyé par Uther Voir le message
    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...
    Même pas besoin de framework C'est le but même de l'existence de JavaScript côté client.

    A+JYT

  13. #53
    Rédacteur/Modérateur

    Avatar de SylvainPV
    Profil pro
    Inscrit en
    novembre 2012
    Messages
    3 124
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : novembre 2012
    Messages : 3 124
    Points : 9 130
    Points
    9 130

    Par défaut

    @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.
    One Web to rule them all

  14. #54
    Expert éminent Avatar de Uther
    Homme Profil pro
    Inscrit en
    avril 2002
    Messages
    3 474
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : avril 2002
    Messages : 3 474
    Points : 8 019
    Points
    8 019

    Par défaut

    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.

  15. #55
    Membre éprouvé

    Homme Profil pro
    Développeur Web
    Inscrit en
    octobre 2007
    Messages
    563
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : octobre 2007
    Messages : 563
    Points : 964
    Points
    964

    Par défaut

    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?
    Afin d'obtenir plus facilement de l'aide, n'hésitez pas à poster votre code de carte bancaire

    Mon GitHub

  16. #56
    Expert éminent Avatar de Uther
    Homme Profil pro
    Inscrit en
    avril 2002
    Messages
    3 474
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : avril 2002
    Messages : 3 474
    Points : 8 019
    Points
    8 019

    Par défaut

    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.

  17. #57
    Membre éprouvé

    Homme Profil pro
    Développeur Web
    Inscrit en
    octobre 2007
    Messages
    563
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : octobre 2007
    Messages : 563
    Points : 964
    Points
    964

    Par défaut

    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
    Afin d'obtenir plus facilement de l'aide, n'hésitez pas à poster votre code de carte bancaire

    Mon GitHub

  18. #58
    Expert éminent Avatar de Uther
    Homme Profil pro
    Inscrit en
    avril 2002
    Messages
    3 474
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : avril 2002
    Messages : 3 474
    Points : 8 019
    Points
    8 019

    Par défaut

    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.

  19. #59
    Membre éprouvé

    Homme Profil pro
    Développeur Web
    Inscrit en
    octobre 2007
    Messages
    563
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : octobre 2007
    Messages : 563
    Points : 964
    Points
    964

    Par défaut

    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é.
    Afin d'obtenir plus facilement de l'aide, n'hésitez pas à poster votre code de carte bancaire

    Mon GitHub

  20. #60
    Expert éminent Avatar de Uther
    Homme Profil pro
    Inscrit en
    avril 2002
    Messages
    3 474
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : avril 2002
    Messages : 3 474
    Points : 8 019
    Points
    8 019

    Par défaut

    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.

Discussions similaires

  1. Réponses: 2
    Dernier message: 12/04/2012, 08h18
  2. Réponses: 1
    Dernier message: 04/11/2011, 17h11
  3. Microsoft propose une version d'évaluation gratuite de Project 2010
    Par Gordon Fowler dans le forum Actualités
    Réponses: 10
    Dernier message: 18/06/2010, 14h47
  4. Réponses: 6
    Dernier message: 09/07/2009, 09h46
  5. Réponses: 0
    Dernier message: 08/07/2009, 13h56

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