La spécification WebAssembly Core est désormais un standard web officiel

**p3ga5e** · 24/03/2016, 16h18

Bien évidemment que cela ne tuera pas JavaScript, les WebAssembly serviront, surtout, à remplacer les plugins natif Netscape et ActiveX qui sont désormais bloqué par les navigateurs !

Je me pose des questions sur l’interopérabilité entre WebAssemblies et l’interpréteur JavaScript ! Car actuellement je galère à porter une librairie C de physiques avec Emscripten, si la compilation ne pose pas de problème (Emscripten et totalement compatible avec gcc

), l’export d’une API utilisable en JavaScript est une entreprise long et fastidieuse.

Il faut bien comprendre que Emscripten ne permet d’exporter que les fonctions avec des signatures simple (avec ccall et cwrap) mais pas les structures et objet (qui en c/c++ sont les mêmes choses). Du coup cela oblige à créer un Wrappeur d’objet JavaScript pour chaque structure.

Pour exemple : voici la définition de la structure Mass :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
struct dMass {
  dReal mass;
  dVector4 c;
  dMatrix3 I;
 
#ifdef __cplusplus
  dMass()
    { dMassSetZero (this); }
  void setZero()
    { dMassSetZero (this); }
  void setParameters (dReal themass, dReal cgx, dReal cgy, dReal cgz,
		      dReal I11, dReal I22, dReal I33,
		      dReal I12, dReal I13, dReal I23)
    { dMassSetParameters (this,themass,cgx,cgy,cgz,I11,I22,I33,I12,I13,I23); }
  void setSphere (dReal density, dReal radius)
    { dMassSetSphere (this,density,radius); }
  void setCapsule (dReal density, int direction, dReal a, dReal b)
    { dMassSetCappedCylinder (this,density,direction,a,b); }
  void setCappedCylinder (dReal density, int direction, dReal a, dReal b)
    { setCapsule(density, direction, a, b); }
  void setBox (dReal density, dReal lx, dReal ly, dReal lz)
    { dMassSetBox (this,density,lx,ly,lz); }
  void adjust (dReal newmass)
    { dMassAdjust (this,newmass); }
  void translate (dReal x, dReal y, dReal z)
    { dMassTranslate (this,x,y,z); }
  void rotate (const dMatrix3 R)
    { dMassRotate (this,R); }
  void add (const dMass *b)
    { dMassAdd (this,b); }
#endif
};

Je dois donc compter la taille en octet, afin de pouvoir l’allouer sur le tas de la LLVM ici :

1 (réel mass) +4 (vecteur c)+ 3*4 (matrice3x4 I ) = 17 réel = 17 * 4 octets

Les réels sont des flottants de simple précision encoder sur 4 octets

La fonction constructrice d’instance de Mass, exporté en JavaScript, nécessite l’écriture suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
/**************                                   Mass API                                   *********************/
	var sizeOfMass = (1+4+4*3)*4;
	var dMassSetZero = Module.cwrap('dMassSetZero',null,['number']);
	var dMassSetParameters = Module.cwrap('dMassSetParameters',null,['number', 'number', 'number', 'number', 'number', 'number', 'number', 'number', 'number', 'number', 'number']);
	var dMassSetSphere = Module.cwrap('dMassSetSphere',null,['number', 'number', 'number']);
	var dMassSetSphereTotal = Module.cwrap('dMassSetSphereTotal',null,['number', 'number', 'number']);
	var dMassSetCapsule = Module.cwrap('dMassSetCapsule',null,['number', 'number', 'number', 'number', 'number']);
	var dMassSetCapsuleTotal = Module.cwrap('dMassSetCapsuleTotal',null,['number', 'number', 'number', 'number', 'number']);
	var dMassSetCylinder = Module.cwrap('dMassSetCylinder',null,['number', 'number', 'number', 'number', 'number']);
	var dMassSetCylinderTotal = Module.cwrap('dMassSetCylinderTotal',null,['number', 'number', 'number', 'number', 'number']);
	var dMassSetBox = Module.cwrap('dMassSetBox',null,['number', 'number', 'number', 'number', 'number']);
	var dMassSetBoxTotal = Module.cwrap('dMassSetBoxTotal',null,['number', 'number', 'number', 'number', 'number']);
	var dMassAdjust = Module.cwrap('dMassAdjust',null,['number', 'number']);
	var dMassTranslate = Module.cwrap('dMassTranslate',null,['number', 'number', 'number', 'number']);
	var dMassRotate = Module.cwrap('dMassRotate',null,['number', 'number']);
	var dMassAdd = Module.cwrap('dMassAdd',null,['number', 'number']);
 
	ODE.Mass = function ()
	{
		var pointer = arguments[0] ||  Module._malloc(sizeOfMass);
		this.getPointer = function() { return pointer;}
		this.destroy = function() { return Module._free(pointer); }
		this.setZero = function() { dMassSetZero(pointer); return this;}
		this.setParameters = function( mass,cgx, cgy, cgz, I11, I22, I33, I12, I13, I23) {  dMassSetParameters(pointer, mass,cgx, cgy, cgz, I11, I22, I33, I12, I13, I23); return this;}
		this.setSphere = function(density, radius) { dMassSetSphere(pointer,density, radius); return this;}
		this.setSphereTotal = function(total_mass, radius) { dMassSetSphereTotal(pointer,total_mass, radius); return this;}
		this.setCapsule = function(density, direction, a, b) { dMassSetCapsule(pointer, density, direction, a, b); return this;}
		this.setCapsuleTotal = function(total_mass, direction, a, b) { dMassSetCapsuleTotal(pointer, total_mass, direction, a, b); return this;}
		this.setCylinder = function(density, direction, a, b) { dMassSetCylinder(pointer, density, direction, a, b); return this;}
		this.setCylinderTotal = function(total_mass, direction, a, b) { dMassSetCylinderTotal(pointer, total_mass, direction, a, b); return this;}
		this.setBox = function(density, lx, ly, lz) { dMassSetBox(pointer, density, lx, ly, lz); return this;}
		this.setBoxTotal = function(total_mass, lx, ly, lz) { dMassSetBoxTotal(pointer, total_mass, lx, ly, lz); return this;}
		this.adjust = function(newmass) { dMassAdjust(pointer, newmass); return this;}
		this.translate = function(x,y,z) {  dMassTranslate(pointer, x,y,z); return this;}
		this.rotate = function(rotation) { dMassRotate(mass, rotation.getPointer()); return this;}
		this.add = function(mass) { dMassAdd(pointer, mass.getPointer()); return this;}
	}

Ainsi en javascript il est possible de soit créer une instance de Mass par new ODE.Mass() ; ou de caster une zone mémoire en tant que Mass par new ODE.Mass(pointer) ;

Mais cela peut encore se complexifier, en effet les données membre de la structure ne sont pas exposer a l’objet JavaScript, pour cela il faut donc ajouter ceci au constructeur Mass :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
Object.defineProperty(this,"mass",{
	enumerable : true,
	get : function(){ return  Module.getValue(pointer,'float');},
	set : function(val) { Module.setValue(pointer,val,'float');	}
});
 
this.c = new ODE.Vector4(pointer+4);
this.I = new ODE.Matrix3(pointer+4+4*4);

De plus un problème persiste avec cette méthode de wrapping, en effet ces feignasses de scripteurs ( dont je fais partie ), non pas pour habitude de se poser des question à propos de la gestion Mémoire. Or ici il est nécessaire d’appeler la méthode destroy avant la collecte du ramasse miettes, afin d’éviter tous Memory leak …

Bref je vous laisse estimer le tempe qu’il faut pour exporter l’API d’une librairie c/c++ … et j’ai bien peur que tous ce travail soit à pure perte pour un futur export WebAssembly

**DonQuiche** · 24/03/2016, 17h47

Concernant l'interopérabilité JS et webasm, celle-ci sera abordée plus tard, une fois le coeur lui-même terminé. Au menu on trouvera notamment la possibilité de confier des zones mémoires au ramasse-miettes. Cela te facilitera la vie.

En revanche tu auras toujours besoin de créer des wrappers mais c'est un problème lié au C++. Ce qu'il te faut c'est un générateur de code qui examine ton code pour créer les wrappers correspondants. En C++ c'est malheureusement tortueux du fait de la gestion mémoire, de la compilation en une seule passe et de l'absence de métadonnées.

**p3ga5e** · 24/03/2016, 21h56

Mais bien sûr laissons la question d’interopérabilité de côté et laissons le champ libre à Unity l’utilisation des WebAssembly a leurs fin personnel !

Attention je ne souhaite pas dénigrer la techno Unity concernant les jeux vidéo c’est le top

, mêmes si leur pseudo JavaScript ne ressemble à rien du vrais JavaScript. Seulement l’interopérabilité avec le navigateur nous ramène 15 ans en arrière, tous comme le vieux flash 7, seuls les échanges de message string sont possibles !
En tout cas si WebAssembly sert uniquement les intérêts d’Unity, je militerai pour la suppression du terme Assembly du nom de la techno, le nom de WebUnity ou WebApplication serait, du coup, plus approprié !

Envoyé par DonQuiche

En C++ c'est malheureusement tortueux du fait de la gestion mémoire, de la compilation en une seule passe et de l'absence de métadonnées.

Pour info Ecmascripten a mis en place un export de métadonnée Objet par WebIDL, mais je n’ai pas réussi à l’utilisé, de plus compiler en C++ ODE fait perdre plus de 60% son API …

**DonQuiche** · 25/03/2016, 04h08

Envoyé par p3ga5e

Mais bien sûr laissons la question d’interopérabilité de côté et laissons le champ libre à Unity l’utilisation des WebAssembly a leurs fin personnel !

WebASM est une initiative de Mozilla, Microsoft et Google.

Unity n'est qu'un des logiciels à l'utiliser et ne contrôle en rien cette techno, pas plus qu'ils ne contrôlent javascript. Même chose pour emscripten qui n'a pas été développé par Unity.

**Aurelien.Regat-Barrel** · 02/11/2016, 16h04

Si j'ai bien suivi c'est l'aboutissement d'une longue rivalité entre Mozilla avec asm.js d'un côté et Google avec Native Client (NaCl puis PNaCl) de l'autre. C'est quand même fort que ces 2 là + Microsoft aient réussi à tomber d'accord!

Ca fait déjà plus d'un an que MS travaille à supporter asm.js, ils en dévoilent l'intérêt et la différence par rapport à JS ici:
https://blogs.windows.com/msedgedev/...CoMVyQsGfRf.97

Sur la page de Web Assembly, ils disent qu'ils comptent par la suite ajouter le support du multi-threading...

**marsupial** · 02/11/2016, 16h32

A l'instar de php, en html5, il existe une balise <system> à sévèrement encadrée donc, oui, on peut parler de web app. Concept ancien du terminal-server. Fort utile et efficace, nécessitant une sécurisation solide du QoS. D'où le cloud, les containers et la réécriture de Libre Office en C/C++ par exemple.

Imaginez les possibilités. Et la mort de C#. Et peut-être de Java côté serveur.
Chrome a gagné. Suivi de Mozilla Quantum.

Vous êtes libres de choisir. Nous, c'est fait.

**23JFK** · 02/11/2016, 19h47

Pour être crédible côté démo, il faudrait donner les spécifications de la machine de test. Parce que sur un vieux duo core ça ne doit autant briller que sur un i7

**Beginner.** · 03/11/2016, 20h32

Salut,

Bon alors je viens de lire ce fil qui a été remonté et je me demande où ça en est cette histoire ?

JS ne servira plus ou j'ai mal compris ? Moi qui commençais à m'y habituer...

Bon j'aime bien aussi le C et c'est vrai que coté consommation mémoire je mettais déjà posé la question pour le JS mais je n'ai pas encore vu quelqu'un s'en préoccuper... Je n'ai pas encore vu quelqu'un dire par exemple ce script consomme tant de mémoire vive ou autres... D'ailleurs je ne sais même pas si c'est possible de le savoir...

Pour l'instant c'est pour le C/C++ mais il y aura d'autres langages c'est ça ? Peut-être le JS et Java aussi alors ?

**EddiGordo** · 04/11/2016, 08h35

Bonjour,

Envoyé par Beginner.

D'ailleurs je ne sais même pas si c'est possible de le savoir...

Je ne sais pas pour IE, Firefox, Opera ou Safari, mais dans Chrome, tu as un gestionnaire de tâches.
Un petit shift + ESC et tu sais tout ce qu'il y a à savoir. Et même, si tu en veux plus, sur bouton droit tu peux ajouter une colonne qui te permettra de connaitre l'utilisation mémoire de tes scripts javascript.

**marsupial** · 04/11/2016, 09h51

Pour l'instant c'est pour le C/C++ mais il y aura d'autres langages c'est ça ? Peut-être le JS et Java aussi alors ?

Mozilla a créé un transpileur inverse (Javascript vers C/C++). Dans tous les cas, la qualité du code sera à débugger lors du passage vers le web assembly.
Mais on pourrait le faire en direct sans passer par le C/C++, ce qui serait une étape de moins donc un gain de temps : Javascript vers web assembly.

Pour Java, demande à Oracle de rendre Sun ou alors OpenJDK.

Reste que l'assembleur ARM et x86 diffèrent, donc MS continue avec ARM et l'amélioration de la communication réseau. (source ziff davis )
Mais il existe un assembleur générique amplement suffisant pour l'essentiel des softs permettant de s'affranchir des spécificités matériels

NB : Pour rappel, Kernhigan et Ritchie ont créé le C sur une base de compréhensibilité par l'être humain alors qu'UNIX avait été écrit en assembleur lié au matériel d'où les multiples erreurs de conversion lors de cast/autres de variables.

**Beginner.** · 04/11/2016, 17h52

Merci à vous deux pour vos réponses.

Sinon personne ne sait où en est ce projet ? Je n'ai pas l'impression que cela fasse beaucoup de "bruits", se pourrait-il qu'il soit abandonné ?

**SylvainPV** · 04/11/2016, 18h38

C'est de l'open-source, tu peux suivre tous les travaux ici : https://github.com/WebAssembly

Comme tu peux le constater, il y a des mises à jour très régulières, la dernière il y a 3 minutes. Donc non c'est loin d'être abandonné

**Beginner.** · 04/11/2016, 19h29

Ok merci.

**stopviolence** · 17/11/2016, 19h11

Mon rêve se réalise, je vais pouvoir faire des stack collision dans le navigateur !!!

**Stéphane le calme** · 01/03/2017, 11h38

Les principaux navigateurs peuvent déjà livrer des versions avec WebAssembly activé par défaut,
en attendant les spécifications de la première version

Étant donné que les applications Web gagnent de plus en plus en complexité, les éditeurs de navigateurs ont apporté de nombreuses optimisations à leur moteur d’exécution JavaScript, afin d’en améliorer les performances. Toutefois, pour ne pas évoluer de façon dispersée, ils se sont mis ensemble pour tirer parti du meilleur de leurs précédents investissements pour développer une solution qui pourra bénéficier d’une large prise en charge.

C’est ainsi qu’est né le projet WebAssembly, qui est soutenu par Google, Mozilla, Microsoft et des développeurs du moteur de rendu Web Webkit. WebAssembly est un format binaire pour la compilation d’applications pour le Web.

En novembre 2016, Google, Mozilla et Microsoft ont annoncé la disponibilité d’une WebAssembly Browser Preview. Cette étape a marqué entre autres :

une RC pour le design MVP (terme qui désigne la plus petite entité productible, utilisable et vendable dans le domaine informatique) qui inclut notamment la sémantique, le format binaire et l'API JS ;
des implémentations compatibles et stables de WebAssembly dans V8 et SpiderMonkey, dans les builds de développement de Chakra et en progression dans JavaScriptCore ;
une chaîne d'outils de travail pour les développeurs qui veulent compiler des modules WebAssembly à partir de fichiers sources C / C ++.

Conformément à sa feuille de route, la WebAssembly Community Group a annoncé hier être arrivé la fin de cette étape.

« Les membres WebAssembly CG représentant les quatre navigateurs Chrome, Edge, Firefox et WebKit, sont parvenus à un consensus sur le fait que la conception de la première API WebAssembly et le format binaire sont complets dans la mesure où aucun autre travail de conception n’est possible sans expérience de mise en œuvre et usage. Ceci marque la fin de la Browser Preview et indique que les navigateurs peuvent commencer à livrer WebAssembly par défaut. Dès lors, les fonctionnalités futures seront conçues pour assurer la compatibilité ascendante », a déclaré Luke Wagner, un ingénieur travaillant pour le compte de Mozilla et membre de la WebAssembly Community Group.

Il a expliqué que le consensus inclut une API JavaScript et un format binaire accompagnés d'un interprète de référence. Il est possible de tester WebAssembly à l'aide de la chaîne d'outils Emscripten.

« Les prochaines étapes consisteront à former un groupe de travail du W3C, pour élaborer des spécifications pour la version initiale de WebAssembly et de continuer à travailler sur l’itération des futures fonctionnalités au sein de l’actuel WebAssembly Community Group », a-t-il continué.

Il est important de préciser que développer avec WebAssembly n’implique pas abandonner JavaScript. Comme le note Lin Clark, un ingénieur au sein de l’équipe Mozilla Developer Relations, « les développeurs n'ont pas besoin de choisir entre WebAssembly et JavaScript pour leurs applications. Cependant, nous nous attendons à ce que les développeurs échangent des parties de leur code JavaScript pour du WebAssembly ».

Il a proposé une petite comparaison entre JavaScript et WebAssembly où WebAssembly s’avère plus rapide (et donc plus adapté ?) dans certains cas que JavaScript parce que :

faire de la récupération de données avec WebAssembly prend moins de temps, car il est plus compact que JavaScript, même lorsqu'il est compressé ;
décoder WebAssembly prend moins de temps que l'analyse de JavaScript ;
la compilation et l'optimisation prennent moins de temps avec WebAssembly étant donné que ce dernier est plus proche du code machine que JavaScript et a déjà subi une optimisation côté serveur ;
la réoptimisation n’est pas nécessaire puisque WebAssembly a des types et d'autres informations intégrés, de sorte que le moteur JS n'a pas besoin de spéculer quand il optimise de la façon dont il le fait avec JavaScript ;
l’exécution prend souvent moins de temps étant donné que l’ensemble d’instructions de WebAssembly est plus idéal pour les machines ;
la mémoire est gérée manuellement.

Source : annonce du consensus, comparaison entre WebAssembly et JavaScript

**Lcf.vs** · 01/03/2017, 12h51

Intéressant... mais pas pour demain, alors qu'on doit encore faire du compatible IE.

**tralloc** · 01/03/2017, 13h01

Très bonne nouvelle !

**hotcryx** · 01/03/2017, 13h54

Donc WebAssembly est lié à WebGL?

**michel.bosseaux** · 01/03/2017, 14h46

hotcryx : je ne vois pas ce qui, dans cet article, t'as permis de lier Webassembly (qui se veut un format binaire pour le web, et donc permet d'écrire en n'importe quel langage, compiler vers webassembly pour utiliser ensuite dans le navigateur) avec WebGL, qui concerne la 3D dans le navigateur. Tu es le seul à avoir mentionné WebGL (que ce soit dans l'article ou les commentaires, aucune autre référence n'y est faite).
Les technologies n'ont strictement rien à voir. On peut peut-être imaginer qu'un code au format Webassembly pourra utiliser, si nécessaire, la technologie WebGL si le but est d'afficher de la 3D. Mais à part cela, les buts des deux technologies sont tout à fait différents.

**hotcryx** · 01/03/2017, 16h50

C'était une question

Je sais qu'on ne parle pas de webGL mais il y a un article récent et quand je vois la démo, ça laisse supposer que ce pourrait être du webGL.
N'était ce pas le moteur Unity dans la démo

La spécification WebAssembly Core est désormais un standard web officiel

JavaScript

Discussions similaires

Partager

Partager