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)