Mozilla expérimente le parallélisme avec son moteur JavaScript SpiderMonkey
Pour accélérer la puissance matérielle
Le 2015-03-04 08:44:11, par Michael Guilloux, Chroniqueur Actualités
L'éditeur de navigateur Mozilla a récemment partagé sur son blog des actions menées pour expérimenter le parallélisme avec son moteur JavaScript SpiderMonkey.
La firme précise avant tout que le parallélisme auquel elle fait allusion ne fait pas référence à la concurrence relative aux programmes qui répondent aux événements simultanés. « Le modèle de concurrence asynchrone de JavaScript est populaire et réussi », a déclaré Dave Herman, chercheur principal et directeur de la stratégie de Mozilla Research. Il affirme qu'avec les générateurs ES6, et la synntaxe async/await à venir, le modèle de JavaScript se porte de mieux en mieux.
Il s'agit donc d'essayer d'autres genres d'expériences pour tirer pleinement parti des capacités matérielles disponibles. Mozilla veut adopter une « approche de bas niveau, évolutionniste, à l'extension de Java avec des primitives plus flexibles et puissantes pour le parallélisme.»
« Entre la sortie prochaine d’ES6 et la concurrence acharnée pour la performance JIT, ce sont des moments excitants pour JavaScript », a déclaré Herman. « Mais une zone où JavaScript reste toujours en retard est le parallélisme - exploiter l'accélération matérielle en exécutant plusieurs calculs simultanément. »
L'idée est de « débloquer la puissance qui se cache à l'intérieur de nos appareils: GPU, instructions SIMD, et plusieurs cœurs de processeur. » A déclaré Herman. « Avec l'émergence de WebGL 2.0 et les normes SIMD, le web fait des progrès significatifs sur les deux premiers. Et les web workers font partie du chemin vers le parallélisme multicœur. »
L'une des pistes explorées, les web workers, fournissent un moyen pour le contenu web d'exécuter des scripts dans les threads de fond. Cependant, comme l'a signifié Herman, « les workers sont, de par leur conception, fortement isolés: ils ne peuvent communiquer que via postMessage. »
L'autre possibilité qui s'offrait à Mozilla était de reprendre ce qui a été fait dans le projet Nashorn : «transformer JavaScript en un modèle de données entièrement multi-thread », a dit Herman. Cette possibilité présente toutefois une insuffisance. « À moins que votre programme Java hôte prenne soin de synchroniser vos scripts, vos applications JavaScript perdent toutes les garanties de run-to-completion. » A-t-il ajouté.
Pour mettre en oeuvre le parallélisme avec JavaScript, Mozilla expérimente donc l'API SharedArrayBuffer dans SpiderMonkey. l'API permettra d'introduire de nouvelles formes de blocage pour les workers, ainsi que la possibilité que certains objets puissent être sujets à des data races, a expliqué Herman.
L’éditeur de navigateur aurait par ailleurs, en collaboration avec Intel Labs, exploré la piste des API de parallélisme déterministe. « Le but de ces expériences était de trouver des abstractions de haut niveau qui pourraient permettre des accélérations parallèles sans les pièges de threads », a déclaré Herman. Mais cette approche s'avère complexe, « car il est difficile de trouver des modèles de haut niveau qui sont suffisamment généraux pour s'adapter à une grande variété de programmes parallèles. » A-t-il dit.
Source : Blog Mozilla
Et vous?
La firme précise avant tout que le parallélisme auquel elle fait allusion ne fait pas référence à la concurrence relative aux programmes qui répondent aux événements simultanés. « Le modèle de concurrence asynchrone de JavaScript est populaire et réussi », a déclaré Dave Herman, chercheur principal et directeur de la stratégie de Mozilla Research. Il affirme qu'avec les générateurs ES6, et la synntaxe async/await à venir, le modèle de JavaScript se porte de mieux en mieux.
Il s'agit donc d'essayer d'autres genres d'expériences pour tirer pleinement parti des capacités matérielles disponibles. Mozilla veut adopter une « approche de bas niveau, évolutionniste, à l'extension de Java avec des primitives plus flexibles et puissantes pour le parallélisme.»
« Entre la sortie prochaine d’ES6 et la concurrence acharnée pour la performance JIT, ce sont des moments excitants pour JavaScript », a déclaré Herman. « Mais une zone où JavaScript reste toujours en retard est le parallélisme - exploiter l'accélération matérielle en exécutant plusieurs calculs simultanément. »
L'idée est de « débloquer la puissance qui se cache à l'intérieur de nos appareils: GPU, instructions SIMD, et plusieurs cœurs de processeur. » A déclaré Herman. « Avec l'émergence de WebGL 2.0 et les normes SIMD, le web fait des progrès significatifs sur les deux premiers. Et les web workers font partie du chemin vers le parallélisme multicœur. »
L'une des pistes explorées, les web workers, fournissent un moyen pour le contenu web d'exécuter des scripts dans les threads de fond. Cependant, comme l'a signifié Herman, « les workers sont, de par leur conception, fortement isolés: ils ne peuvent communiquer que via postMessage. »
L'autre possibilité qui s'offrait à Mozilla était de reprendre ce qui a été fait dans le projet Nashorn : «transformer JavaScript en un modèle de données entièrement multi-thread », a dit Herman. Cette possibilité présente toutefois une insuffisance. « À moins que votre programme Java hôte prenne soin de synchroniser vos scripts, vos applications JavaScript perdent toutes les garanties de run-to-completion. » A-t-il ajouté.
Pour mettre en oeuvre le parallélisme avec JavaScript, Mozilla expérimente donc l'API SharedArrayBuffer dans SpiderMonkey. l'API permettra d'introduire de nouvelles formes de blocage pour les workers, ainsi que la possibilité que certains objets puissent être sujets à des data races, a expliqué Herman.
L’éditeur de navigateur aurait par ailleurs, en collaboration avec Intel Labs, exploré la piste des API de parallélisme déterministe. « Le but de ces expériences était de trouver des abstractions de haut niveau qui pourraient permettre des accélérations parallèles sans les pièges de threads », a déclaré Herman. Mais cette approche s'avère complexe, « car il est difficile de trouver des modèles de haut niveau qui sont suffisamment généraux pour s'adapter à une grande variété de programmes parallèles. » A-t-il dit.
Source : Blog Mozilla
Et vous?
-
UtherExpert éminent séniorSauf que là on parle de SpiderMonkey, donc de javascript coté client. EdgeJS c'est une technologie coté serveur.le 04/03/2015 à 11:55
-
FlyersWebMembre à l'essaiEn attendant des avancés significatives pourquoi ne pas utiliser une autre alternative comme C# qui gère le parallélisme (plutôt pas mal) avec EdgeJSle 04/03/2015 à 11:20