SIMD.js : la programmation parall�le s�invite dans JavaScript

Version imprimable

04/11/2014, 14h58
Hinault Romaric

SIMD.js : la programmation parall�le s�invite dans JavaScript

SIMD.js : la programmation parall�le s�invite dans JavaScript
Mozilla pr�sente les �volutions de l�API

Le gain de performances qu�apportent les architectures multiprocesseurs n�est pas encore exploit� par le langage JavaSctipt qui ne permet pas de pratiquer la programmation parall�le.

Plusieurs g�ants de l��cosyst�me de l�IT, dont Intel, Google et Mozilla ont travaill� de concert pour faire du parall�lisme une r�alit� pour les applications JavaScript.

C�est ainsi qu�est n� le projet SIMD.js, une API qui introduit de nouveaux types et fonctions pour permettre aux d�veloppeurs JavaScript de booster les performances de leurs applications, gr�ce � l�exploitation du parall�lisme.

SIMD.js permet aux d�veloppeurs de cr�er de nouvelles classes d�applications de calcul intensif telles que les jeux, des animations, etc. en JavaScript, sans avoir besoin de s�appuyer sur des extensions ou du code natif � non portable �.

L�API repose sur le projet open source d�Intel baptis� SIMD (Single Instruction Multiple Data), qui permet d�acc�l�rer les performances des applications gr�ce � l�utilisation du parall�lisme pour traiter simultan�ment la m�me op�ration sur plusieurs �l�ments de donn�es. SIMD est une technique tr�s populaire pour acc�l�rer le calcul dans les graphiques, l�audio, les codecs, la cryptographie, les simulations en physique et bien plus.

SIMD.js permet donc d�exposer des interfaces de haut niveau SIMD aux applications JavaScript. Actuellement, le projet supporte les plateformes x86 et les plateformes ARM NEON et ESS. Des travaux sont cours pour l��tendre � plusieurs autres plateformes.

� l�origine, le projet est d�riv� de la sp�cification Dart SIMD. Il a �volu� rapidement pour devenir une API plus g�n�rale, avec de nouveaux cas d�utilisation. L�API a �t� approuv�e par le comit� ECMA International TC39, responsable de la standardisation de la norme ECMAscript. Elle pourrait donc �tre prise en compte dans la prochaine sp�cification du langage JavaScript.

Une version de SIMD.js peut �tre test�e dans Firefox Nightly. Le projet est en cours d�examen par l��quipe Internet Explorer de Microsoft et un prototype est en cours de d�veloppement sur une branche de Chrome. Des d�monstrations effectu�es lors de la conf�rence IDF14 sont �galement disponibles en ligne.

:fleche: La sp�cification de l'API SIMD.js

:fleche: Les d�mos de SIMD.js � l'IDF14

Source : Mozilla

Et vous ?

:fleche: Que pensez-vous de SIMD.js ? L�avez-vous test� ?
05/11/2014, 00h13
Xinu2010

Citation:

Envoy� par Hinault Romaric

Le gain de performances qu�apportent les architectures multiprocesseurs n�est pas encore exploit� par le langage JavaSctipt qui ne permet pas de pratiquer la programmation parall�le.

Les web worker ne sont-ils pas une forme de programmation parall�le ?
05/11/2014, 07h32
sekaijin

lorsque Romaric dit que JS ne permet pas la programmation parall�le il parle du langage.

le langage d�fini par la norme ecmascript ne contient rien permettant de faire du multi processing.

Js est utilis� dans le navigateur qui lui impl�mente la norme HTML 5et celle-ci contient les webworker
ceux-ci sont impl�ment� au niveau du navigateur. comme le pr�vois la norme ecmascript js est alors compl�t� d'objets de l'environnement d'ex�cution en premier lieur le DOM qui est pr�sent au travers de l'objet document. le navigateur pr�sent au travers de l'objet navigator et la fen�tre pr�sente au travers de l'objet window etc...

ni document ni navigator ni window ne sont du javascript. il ne font pas partit du langage pas plus que la fonction toto que tu pourrait d�finir dans un script. il l'utilise mais ne font pas partit du langage.

On sais depuis longtemps que les langage type JS sont bien adapt� � une utilisation en parall�le. cela est du � la gestion des port�e de variables au closures et � la capacit� � passer des fonction en param�re.

A+JYT
05/11/2014, 08h44
MikeRowSoft

Je l'ai pas test�. Mais je sais d'exp�rience que le parall�lisme de processus est beaucoup plus MIMD ou MISD. Le SIMD �tant utile principalement lorsque l'on souhaite faire des historiques d'�tats des attributs en m�moires. Se qui permet par exemple de revenir gr�ce � une pile � un �tat pr�c�dent d'un attribut du programme juste avant qu'il ne bogue par exemple. La suite est facile � deviner.
05/11/2014, 09h41
rt15
Il me semble que l'article peut porter � confusion.

A priori ce n'est pas une librairie con�ue pour exploiter "les architectures multiprocesseurs". Ce n'est pas une librairie de parall�lisme au sens de plusieurs threads s'ex�cutant sur n coeurs ou n processeurs.
Cette librairie n'a absolument rien � voir avec les web workers.

C'est une librairie... SIMD. Single Instruction, Multiple Data. Il suffit de regarder la page du projet pour s'en convaincre.

Comme son nom l'indique, �a permet de faire la m�me op�ration sur plusieurs donn�es. En gros on peut faire :
Code:

1 2 3 i = i * 2 + 1; j = j * 2 + 1; k = k * 2 + 1;
En "une seule instruction". Mais tout �a est r�alis� par un seul thread. Ce type d'op�ration est support� depuis bien longtemps par les processeurs (Y compris mono coeurs) via des extensions au jeu d'instruction telles que SSE et MMX.

(En fait �a ressemble beaucoup au parall�lisme des cartes graphiques, qui malgr� une fr�quence moindre, sont plus rapides pour des calculs sp�cifiques car ils sont r�alis�s en parall�le).

Les avantages est que �a permet de faire certains calculs plus vite. Mais il faut que ces calculs rentre dans le moule du jeu d'instruction du processeur et donc dans le moule de SIMD.js dans ce cas pr�cis.
Bref c'est r�serv� � certains cas d'usage pas forc�ment tr�s courant en javascript.
05/11/2014, 14h28
MikeRowSoft

Je dirais plut�t qu'en utilisant comme langage de compr�hension syst�me l'assembleur c'est d'avoir pr�par� un certain nombres d'informations et de les trait�s sur les m�mes cycles d'horloges (ou pas) en parall�le dans des registres diff�rents.

Apr�s les librairies comme MPI offre une plus vaste approche en proposant de sortir du syst�me local pour avoir une vision de "grappes" (cluster) ou r�seaux de communications entre syst�mes (entit�s) de traitements et biblioth�ques d'informations qui fonctionnent sous des m�thodes de parall�lisme (syst�me distribu� il me semble).

Mais l� c'est pas vraiment du graphique mais plut�t du Super Calculateur de base CPU pur et dur. CPU qui � vraiment de grave lacune avec un FPU qui s'essouffle face au GPGPU.
07/11/2014, 21h35
Invit�

http://fr.wikipedia.org/wiki/Streaming_SIMD_Extensions

(sifflement), la vache, il aura fallut tant d'ann�es pour que les langage de haut niveaux s'int�ressent � l'exploitation en profondeur du CPU ?

Blague a part, a quant l'exploitation de l'AVX 2 ?

PS: vous avez 15 ans de retard compt� � ce jour :mouarf: :mouarf:
09/11/2014, 19h51
ishraam

Whoaa... T.T
Cet article est du grand n'importe quoi, clairement l'auteur n'a rien compris au sujet, et m�lange tout.
S�rieusement, il ne faut pas laisser ce contenu, les lecteurs vont en ressortir plus b�tes qu'avant lecture ^^'.

Par contre, rt15 lui a bien compris de quoi il s'agit, et ses explications sont justes ^.^
Merci � lui de relever le niveau, et d'apporter des corrections.

SIMD, c'est du parall�lisme d'instructions.
Donc �a se joue au niveau du CPU, au niveau d'un core et de ses registres.
Ca existait d�j� sur les CPU mono-core.
Rien � voir avec "les architectures multiprocesseurs", rien � voir avec ce qu'on appelle la "programmation parall�le", rien � voir avec le fait d'avoir plusieurs threads, rien � voir avec les WebWorkers, etc.

Tant qu'on n'a pas coder en utilisant les instructions SIMD, il est tr�s difficile de comprendre la complexit� du truc.
Et effectivement, c'est vieux comme "techno", mais �a r�ponds � des besoins tellement sp�cifiques, avec masse de calcul (assez similaires) � faire (et sur des donn�es lin�aires, bien organis�es, et align�es en m�moire selon la machine), que �a n'avait pas sa place dans JS jusqu'� r�cemment.

Ce qui est dommage ce n'est pas tant que les langages de haut niveau ne s'int�ressent pas au bas niveau hardware, car comme dit, sans besoin r�el �a n'avait aucun sens, mais plut�t que les dev eux ne se renseigne pas plus.
Du moins � mon sens ^^
10/11/2014, 10h05
mdiam

(hors sujet ?) langages de haut niveau et hardware

ishraam:
> ...Ce qui est dommage ce n'est pas tant que les langages de haut niveau
> ne s'int�ressent pas au bas niveau hardware...

Julia (http://julialang.org) est un langage r�cent dont la premi�re communication officielle date de f�vrier 2012 (d�but des travaux en 2009).

Julia est gratuit, multi-plateforme, bas� sur LLVM (comme le compilateur c++ `Clang` : et on peut y ins�rer de l'assembleur), d�velopp� essentiellement par le MIT et orient� scientifique. Julia est inspir� de Matlab, Ruby, Python,... tout en �tant compatible avec la notion de copi�-coll� !

Julia int�gre nativement les tableaux multidimensionnels et l'alg�bre lin�aire et dispose d'une communaut�e tr�s active autour le l'optimisation et des math�matiques appliqu�es en g�n�ral.

Julia est un langage dynamique typ�, compil� � la vol�e, non orient� objet au sens classique mais qui supporte la notion de "multi-dispach" de m�thodes, g�n�ralisant ainsi la notion d'objets et de m�thodes virtuelles. Ses possibilit�s d'introspection et sa caract�ristique homoiconique (comme TCL ;-) lui permette de proposer un syst�me de macro puissant.

Accessoirement, la page d'accueil de Julia (tableau comparatif des performances) montre que les performances de certaines machines Javascript sont loin d'�tre ridicules devant d'autre langages dit "classiques".

-- Maurice
10/11/2014, 12h31
p3ga5e

Citation:

Envoy� par ishraam

SIMD, c'est du parall�lisme d'instructions.
Donc �a se joue au niveau du CPU, au niveau d'un core et de ses registres.
Ca existait d�j� sur les CPU mono-core.
Rien � voir avec "les architectures multiprocesseurs", rien � voir avec ce qu'on appelle la "programmation parall�le", rien � voir avec le fait d'avoir plusieurs threads, rien � voir avec les WebWorkers, etc.

Certes les instructions SSE et MMX date du XXe si�cle, a une �poque o� les CPUs �taient mono-core et les cartes graphiques ne s�occupaient pas encore du pipeline g�om�trique :D

Mais je suppose qu�elles ont �volu�s avec les architectures, et j�ai constat� sur mes kernels (micro-programme blind� d�instruction SIMD), une parall�lisassions des calculs efficace sur des architectures multi-cores, avec le Pixel Bender Runtime de Flash Player 10 (qui a �t� abandonn�e depuis version 11 :aie: )

Pour moi le type de "programmation parall�le" est avant tout d�utiliser un paradigme de type kernel/pipeline, donc ce type de programmation est d�j� partiellement disponible, sur navigateur, via WebGL, qui permet, en d�tournant un peu l�API, de parall�liser d�autre chose que de la rasterisation graphique , cf : les SoundShader de ShaderToy !

Ensuite je pense que l�API SIMD.js sera surtout utilis� pour am�liorer les performances les portages des librairies de simulation physique �crite en C/assembleurs et compil� par une LLVM type Emscripten

Citation:

Envoy� par mdiam

Accessoirement, la page d'accueil de Julia (tableau comparatif des performances) montre que les performances de certaines machines Javascript sont loin d'�tre ridicules devant d'autre langages dit "classiques".

Attention, car si les moteurs JavaScripts sont devenu aussi rapide que Java ou DotNet, une fois embarqu� dans un navigateur, on d�chante rapidement ! Je remarque un facteur 10 quand je passe du code de NodeJS (moteur V8) � Chrome (moteur V8 �galement)