L’équipe de Google annonce le support des threads WebAssembly dans Chrome 70
pour tester l'exécution des tâches en parallèle dans le navigateur avec Wasm

Depuis 2015, WebAssembly, abrégé Wasm, a commencé à faire son chemin dans la sphère du web. Annoncé comme un nouveau type de code capable de compléter et de s’exécuter dans les navigateurs web modernes parallèlement à JavaScript, WebAssembly se présente plus précisément comme un langage de type assembleur de bas niveau avec un format binaire compact fonctionnant avec des performances quasi natives.

Selon le groupe en charge du projet, l’on peut attendre des navigateurs qui exécutent le code Wasm qu’ils exécutent le code beaucoup plus vite que JavaScript et avec plus de sécurité. Par ailleurs, vu que Wasm est un standard ouvert, il s’avère plus facile à déboguer et se veut exécutable aussi bien sur le web que dans d’autres environnements comme les shells, les appareils connectés, les applications mobiles et de bureau.

Présentement, les membres de WebAssembly CG représentant 4 navigateurs, notamment Chrome, Edge, Firefox et Webkit ont atteint le consensus du stade initial du produit minimum viable (ou MVP de l’anglais, minimum viable product) avec WebAssembly 1.0, ce qui signifie que la conception de l’API WebAssembly et du format binaire est bouclée dans la mesure où tout travail de conception supplémentaire requerra des conditions particulières préalables.

Nom : WebAssembly.jpeg
Affichages : 3307
Taille : 20,6 Ko

Pour assurer encore plus de performance au bytecode (code compilé avec C/C++, Rust ou d'autres langages), le groupe de la communauté Wasm composée également du W3C a jouté la possibilité d’utiliser les threads avec les navigateurs supportant le code Wasm. Dans Chrome 70 disponible maintenant, l’équipe de développement annonce pour sa part la prise en charge des threads avec le code WebAssembly.

À noter que les threads sont des tâches ou fils exécutés en parallèle lors du traitement des informations par le processeur. Depuis des années, les navigateurs prennent en charge le parallélisme via les web workers qui sont un mécanisme grâce auquel les instructions d’un script JavaScript peuvent être exécutées dans un thread en arrière-plan séparé du thread d’exécution principal d’une application web. Cela a pour avantage qu’un traitement laborieux peut être réalisé dans un thread séparé, permettant au thread principal (généralement l’interface utilisateur) de fonctionner sans blocage ni ralentissement. Toutefois, les web workers ne partagent pas les données mutables entre eux, mais se basent plutôt sur la transmission de messages pour la communication. Et dans le moteur de rendu V8 de Chrome, les données mutables telles que les threads ne sont pas partagées.

Les threads WebAssembly, en revanche, sont des fils pouvant partager la même mémoire Wasm. Le stockage sous-jacent de la mémoire partagée est réalisé avec un objet SharedArrayBuffer, une primitive JavaScript qui permet de partager le contenu d’un seul ArrayBuffer simultanément entre les workers. Chaque thread WebAssembly s’exécute dans un web worker, mais leur mémoire Wasm partagée leur permet de fonctionner de la même manière que sur les plateformes natives. Cela signifie que les applications qui utilisent les threads Wasm sont responsables de la gestion de l’accès à la mémoire partagée, comme dans toute application threadée traditionnelle.

Pour créer et utiliser les threads dans Chrome 70, le développeur devra faire appel à l’API pthreads afin de permettre à son application d’utiliser plusieurs cœurs simultanément pour traiter les données. L’équipe de Chrome précise que pour que le navigateur exécute correctement le code Wasm avec les threads activés, la version 1.38.11 ou ultérieure du SDK emscripten doit être installée et des paramètres supplémentaires doivent être passés au compilateur. En outre, dans le navigateur Chrome 70, si vous souhaitez tester le module WebAssembly, il va falloir activer la prise en charge expérimentale des threads WebAssembly en saisissant chrome://flags dans la barre d’adresse du navigateur.

Nom : WasmThreads2.png
Affichages : 2957
Taille : 23,1 Ko

Puis dans la page qui s’affiche, il va falloir rechercher l’indicateur WebAssembly thread Support et ensuite basculer le paramètre sur Activé.

Nom : WasmThreads3.png
Affichages : 2952
Taille : 22,0 Ko

Une fois cela effectué, vous redémarrez le navigateur et les tests des threads peuvent maintenant commencer.

Vu que Chrome 70 est la première version stable du navigateur à recevoir cette fonctionnalité impémentée de manière expérimentale, l’équipe de Chrome attend des retours de la part des développeurs.

Source : Google

Et vous ?

Avez-vous testé cette fonctionnalité dans Chrome ? Qu’en pensez-vous ?

Quelles sont les fonctionnalités que vous souhaiteriez voir ajouter à WebAssembly ?

Voir aussi

Le support de WebAssembly est désormais disponible dans tous les principaux navigateurs Safari et Microsoft Edge emboîtent le pas à Firefox et Chrome
WebAssembly a-t-il pour vocation de remplacer à long terme JavaScript ? Le standard est au centre des discussions des développeurs web
Les modifications dans WebAssembly pourraient rendre inutiles les correctifs apportés à Meltdown et Spectre dans les navigateurs, selon un chercheur
Google, Microsoft et Mozilla proposent une démonstration fonctionnelle de WebAssembly, le projet ambitionne de devenir le code binaire du web
Le projet AssemblyScript compile un sous-ensemble de TypeScript en WebAssembly, il est open source et disponible sous licence Apache 2.0