Design: pThreads n'importe quel ETA ?

Un certain temps au cours des deux prochains trimestres est probablement aussi précis que n'importe qui peut le dire. Mais veuillez réserver le suivi des problèmes pour les problèmes de dépôt.

Ce projet n'a pas de liste de diffusion ou d'autre forum, donc le suivi des problèmes est le seul endroit où les gens peuvent poser des questions sur le processus de conception. Il est précieux d'avoir un endroit où les gens peuvent poser des questions, c'est pourquoi j'encourage les gens à continuer à utiliser l'outil de suivi des problèmes pour poser des questions.

@sunfishcode , assez juste, mais je suggère ensuite que nous créions une telle liste. Je ne pense pas qu'un outil de suivi des problèmes soit un substitut approprié à cela.

Il y a la liste publique w3 . Il ne connaît pas de trafic très lourd cependant. Il y a aussi un IRC je crois ? Je pense que c'était sur le site Web à un moment donné, mais ce serait bien si les deux étaient directement liés à la section communautaire du site Web. J'ouvrirais un sujet, mais je ne sais pas quelles voies vous préféreriez tous être ~exposés~ liés au public

Mode d'emploi ici :

• https://github.com/WebAssembly/design/blob/master/Contributing.md
• http://webassembly.org/community/feedback/

Nous avons guidé les gens à utiliser github. Tout le monde n'aime pas ça, mais il vaut mieux avoir un endroit que plusieurs.

Bonjour @rossberg-chromium et merci pour votre réponse rapide.

Mais veuillez réserver le suivi des problèmes pour les problèmes de dépôt.

Comme l'a souligné @jfbastien j'ai demandé ici car cela semble le meilleur endroit pour le faire de manière standard.
En outre, la prise en charge des threads est une fonctionnalité de conception qui est décisive pour webAssembly.
Plus que le contexte du logo et "Pourquoi n'est-il pas implémenté en Java", je vois des problèmes soulevés.

Si je me trompe, dites-moi où suivre l'implémentation de la mémoire partagée / du thread.
Ce devrait être un processus ouvert, alors j'aimerais avoir mon mot à dire.

--R

@RobertoMalatesta, nous convenons que les discussions sont très importantes, mais il était plus important de les faire correctement que de les entasser dans le produit peu viable de WebAssembly. Notre raisonnement est simple : asm.js a connu du succès sans cette fonctionnalité.

Les threads sont certainement une fonctionnalité décisive pour certaines applications importantes, mais pas pour toutes les applications. Il en va de même pour GC, la gestion des exceptions sans coût, les appels de queue garantis, etc.

Choisir de faire un MVP signifie que nous ne rendons pas tout le monde heureux au premier lancement. Cela signifie également que certaines personnes peuvent utiliser WebAssembly avant que tout soit conçu, spécifié et implémenté.

Cela étant dit, nous nous attendons à adopter plus ou moins l'approche JavaScript SharedArrayBuffer dans WebAssembly. Beaucoup d'entre nous ont été impliqués dans cette spécification depuis ses débuts. Cela ajouterait des fonctionnalités de bas niveau similaires à celles de C++, ainsi qu'une API de type futex. Il a de la place pour se développer avec plus de commandes de mémoire que la cohérence séquentielle. Il y a des travaux en cours pour créer un modèle de mémoire formel pour cela.

SAB est à "l'étape 4" dans TC39, ce qui signifie que c'est fait, prêt à être expédié et prêt à être utilisé. Je m'attends à ce que son adoption dans WebAssembly ne soit pas trop difficile.

@jfbastien merci pour l'info perspicace.

Cela étant dit, nous nous attendons à adopter plus ou moins l'approche JavaScript SharedArrayBuffer dans WebAssembly.(...)
SAB est à "l'étape 4" dans TC39, ce qui signifie que c'est fait, prêt à être expédié et prêt à être utilisé. Je m'attends à ce que son adoption dans WebAssembly ne soit pas trop difficile.

Super. J'ai hâte de le fatiguer avec beaucoup de code C++ qui manque simplement de threading.
J'utilise régulièrement WebWorkers dans mes applications TS/JS et permettez-moi de dire que je n'en suis pas fan, mais ils pourraient servir de premier départ.

les threads sont très importants, mais les faire correctement était plus important que de les entasser dans le produit peu viable de WebAssembly. Notre raisonnement est simple : asm.js a connu du succès sans cette fonctionnalité.

Comprendre pleinement les besoins d'un MVP pour sortir rapidement (je pense que c'était la raison pour laquelle il a abandonné l'AST pour passer à la pile) et le soin dont il a besoin pour planifier les étapes suivantes.

Les threads sont certainement une fonctionnalité décisive pour certaines applications importantes, mais pas pour toutes les applications. Il en va de même pour GC, la gestion des exceptions sans coût, les appels de queue garantis, etc.

En tant qu'utilisateur de longue date d'emscripten, j'aimerais voir WebAssembly plus découplé des limites de la pile d'applications Javascript :

Wasm devrait seulement 1) viser les performances les plus élevées et 2) fournir des sockets, de la mémoire/des threads, GDI, fs avec une norme Posix/Unix/BSD. De cette façon, il s'agirait d'une fine couche de type système d'exploitation à la fois intégrable dans les appareils mobiles en tant que plate-forme cible unifiée et dans les serveurs pour concourir pour les applications déployables dans le cloud.

Est-ce la direction que prend wasm sur un avenir à long terme ou je rate complètement le coche ?

Merci encore pour votre travail,

Robert

Wasm est définitivement découplé de certaines limites de pile en raison de la façon dont nous séparons les locaux de ce qu'un compilateur tel que LLVM doit mettre dans la mémoire accessible à l'utilisateur.

Avec les threads, surtout s'ils ne sont pas basés sur Worker, vous y obtiendrez plus de puissance.

Cela étant dit, il serait bon d'avoir plus de détails sur vos idées précises. Quel est le cas d'utilisation, comment le contournez-vous en C++ et comment les implémentations wasm le feraient-elles ?

Je ne m'attends pas à ce que vous trouviez toutes les réponses ! Juste ce qui me vient à l'esprit maintenant. Fwiw C++ propose des limites de pile. Découvrez le sous-groupe SG14.

Désolé pour les petits détails, je suis sous un 👶🌯. Je répondrai mieux plus tard !

Désolé pour les petits détails, je suis sous un :baby:: burrito:. Je répondrai mieux plus tard !

Vous êtes sous un bébé burrito? MDR

@qwertie

Vous êtes sous un bébé burrito? MDR

Littéralement, un bébé enveloppé.

Bonjour @jfbastien ,

il serait bon d'avoir plus de détails sur vos idées précises. Quel est le cas d'utilisation, comment le contournez-vous en C++ et comment les implémentations wasm le feraient-elles ?

Généralement mon cas d'utilisation est sur la construction de logiciels de simulation, sur la partie calcul la limite étant uniquement la machine, grâce aux technologies C++, C/OpenCL et GPUs.

Sur le front-end, la pile HTML5 + CSS + Javascript + Typescript s'est avérée être un moyen valide, éprouvé et portable de développer des applications complexes de taille moyenne à grande.

_ La pile Web JS (avec l'ajout d'un langage structuré comme Typescript ) est si bonne ces jours-ci que je ne ressens pas le besoin de recourir à emscripten ou d'essayer wasm pour la plupart des applications._

Je suis presque entièrement d'accord sur les objectifs de haut niveau et les cas d'utilisation de Webassembly et encore plus sur le document Non-Web Embeddings .

_ W ebAssembly sera une technologie pertinente (du moins pour moi) si elle permet d'être plus rapide (à l'os d'une application C native plus, disons 5 % de surcharge) d'utiliser plus de mémoire et plus librement, d'avoir des ports/sockets entièrement implémentés et permettre d'exécuter des threads comme n'importe quel système d'exploitation normal._

La machine Wasm devrait être de taille très lisse, rapide et prédictive, alors s'il vous plaît, ne vous en tenez pas à un GC : les GC sont le schéma de Ponzi de l'informatique : vous faites des dettes et ne vous souciez pas de l'allocation jusqu'à ce qu'il soit trop tard et que vous perdiez des cycles . De plus, si nous avons une machine à noyau wasm super performante, un GC peut être construit dessus.

Par souci de finesse, je le détacherais progressivement de Javascript. Si j'ai des compilateurs natifs dans n'importe quel langage, je n'ai pas besoin de scripts et, de toute façon, je pourrais intégrer un Duktape/Lua/n'importe quoi simplement en compilant dans les sources C.

Quelque part sur le site de Mozilla, j'ai vu des documents sur l'implémentation de la manipulation DOM native wasm : je ne pense pas que ce sera très utile car la manipulation DOM est intrinsèquement séquentielle et c'est l'un des aspects les plus chronophages de la pile HTML5/CSS/JS : if J'écris un wasm multithread ultra-rapide uniquement pour que mes modifications DOM soient sérialisées en attente dans la file d'attente, puis toutes les performances ont disparu et il vaut mieux transpiler du Typescript que d'utiliser C/C++. Dans ce cas, je privilégierais l'accès direct à OpenGL (d'abord avec une implémentation WebGL puis OpenGL native). L'accès à la carte graphique s'avérera utile pour offrir des capacités GPU/CUDA avec peu ou pas de surcharge.
(Je suis juste allé vérifier cela et j'ai eu le problème n ° 273 qui s'attaque à cela)

Avoir une minuscule machine wasm partagée par tous les fournisseurs et indépendants pourrait également résoudre le cauchemar du développement mobile, où vous avez au moins 4 chaînes d'outils pour différents systèmes d'exploitation, versions et architectures.
Les fonctionnalités graphiques et de saisie peuvent varier, mais nous serions en mesure de développer un wasm, puis d'interroger les API des fonctionnalités, ou même de déployer la même application sur différents magasins d'applications.
À long terme : il en va de même pour les applications serveur, en atteignant une sorte de consensus sur les installations (protocoles et pools de connexion à la base de données, systèmes de pages jaunes, protocoles et systèmes de messagerie, etc.) et en les regroupant dans des spécifications standard comme l'a fait la plate-forme JEE. (Une grande partie du travail conceptuel a déjà été réalisée au cours des 20 dernières années).

Je ne m'attends pas à ce que vous trouviez toutes les réponses ! Juste ce qui me vient à l'esprit maintenant. Fwiw C++ propose des limites de pile. Découvrez le sous-groupe SG14.

Bien sûr que je vais le faire.

Merci pour votre patience et votre temps.

Rob

En tant que petit ajout, lorsque les threads sont implémentés, ce serait formidable si la taille de la pile pouvait être rendue arbitrairement grande, ou au lieu de cela, si elle pouvait être définie sur au moins 64 Mo. C'est parce que mon cas d'utilisation est une application qui utilise 2 threads, et le thread non principal a besoin d'une assez grande pile.

@jjpe ce serait une demande pour une chaîne d'outils particulière (telle que emscripten) qui cible wasm, plutôt que pour ce référentiel, car il s'agit d'un problème de choix d'implémentation ou d'ABI plutôt que de quelque chose sur la plate-forme wasm en soi. (ainsi, par exemple, vous pouvez ouvrir un problème sur https://github.com/kripken/emscripten/)

Certaines des choses que j'ai proposées dans mon ancien message semblent être incluses dans la dernière proposition de WASI.
Voir:
https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/

On croise les doigts.

--R

FWIW L'état actuel est que Chrome fournit la prise en charge des threads wasm dans la version 74, Firefox a une implémentation qui n'a pas encore été livrée et Emscripten prend en charge les pthreads (https://emscripten.org/docs/porting/pthreads.html) avec était disponible maintenant.

(De plus, WASI est une API d'appel système, qui est principalement orthogonale au fait qu'une intégration wasm ou une chaîne d'outils donnée prenne en charge les threads/atomics).

Existe-t-il des documents sur l'utilisation des API de thread Chrome et Firefox ?

C'est une sorte de combinaison de choses. Le moteur wasm du navigateur implémente l'extension threads/atomics de la spécification wasm (https://github.com/WebAssembly/threads/tree/master/proposals/threads) qui permet d'instancier les mémoires wasm partagées. Sur le Web, vous pouvez créer un Web Worker et envoyer la mémoire (et tous les modules wasm associés) au Worker via postMessage. Ensuite, vous instanciez le module avec la mémoire partagée sur le worker (et sur le thread principal, ou un autre worker) et les instances partagent leur mémoire. L'aperçu de la proposition de spécification (https://github.com/WebAssembly/threads/blob/master/proposals/threads/Overview.md) contient un petit exemple, mais je n'en connais pas d'autres.

Salut @dschuff et merci pour la réponse ci-dessus.
Dans mon ancien message, je faisais référence à un message précédent, impliquant non seulement des pthreads, mais une évolution souhaitable de wasm vers quelque chose de plus proche du noyau que certains d'entre nous suivant et utilisant emscripten depuis 2010 considéraient alors comme une véritable avancée technologique.
Voir : https://github.com/WebAssembly/design/issues/992#issuecomment -285055578 .

Neuf ans après la sortie d'emscripten et près de cinq ans après les annonces de wasm, peu de progrès ont été réalisés dans la transformation de wasm en une technologie de serveur viable.

Malheureusement, parce que nous avons besoin d'une norme pour les applications portables, et la meilleure façon de le faire à mon humble avis aurait été d'implémenter un petit noyau (de type BSD/Linux) avec POSIX Threads et Berkeley Sockets + un système de fichiers virtuel sécurisé autonome (avec les utilisateurs et groupes suffiraient). Je tiens fermement au vieux dicton de H.Spencer : "Ceux qui ne comprennent pas UNIX sont condamnés à le réinventer".

Je veux toujours garder la foi, donc WASI est un pas dans la bonne direction.

--R

PS : 2010 emscripten déchire encore, puisqu'il fonctionne dans le navigateur immortel, l'indicible unkillable utilisé dans la plupart des entreprises et qui verra passer les corps de Firefox et Safari (leurs moteurs au moins).