Design: pThreads cualquier ETA?

En algún momento en los próximos trimestres es probablemente tan preciso como cualquiera puede decir. Pero reserve el rastreador de problemas para presentar problemas.

Este proyecto no tiene una lista de correo u otro foro, por lo que el rastreador de problemas es el único lugar donde las personas pueden hacer preguntas sobre el proceso de diseño. Es valioso tener un lugar donde las personas puedan hacer preguntas, por lo tanto, animo a las personas a que continúen usando el rastreador de problemas para hacer preguntas.

@sunfishcode , bastante justo, pero luego sugiero que creemos esa lista. No creo que un rastreador de problemas sea un sustituto adecuado para eso.

Existe la lista pública w3 . Sin embargo, no experimenta un tráfico muy pesado. También hay un IRC, creo. Creo que estuvo en el sitio web en algún momento, pero sería bueno si ambos estuvieran directamente vinculados en la sección de la comunidad del sitio web. Abriría un problema, pero no estoy seguro de qué vías preferirían estar ~expuestas~ vinculadas al público

Instrucciones aquí:

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

Hemos estado guiando a la gente a usar github. No a todo el mundo le gusta, pero es mejor tener un lugar que muchos.

Hola @rossberg-chromium y gracias por tu oportuna respuesta.

Pero reserve el rastreador de problemas para presentar problemas.

Como señaló @jfbastien , pregunté aquí porque parece el mejor lugar para hacerlo de manera estándar.
Además, la compatibilidad con subprocesos es una característica de diseño que es decisiva para webAssembly .
Más que el contexto del logotipo y "¿Por qué no está implementado en Java?" veo planteados como problemas.

Si me equivoco, por favor dígame dónde seguir la implementación de memoria/hilo compartido.
Debe ser un proceso abierto, así que me gustaría tener mi opinión.

--R

@RobertoMalaesta estamos de acuerdo en que los subprocesos son muy importantes, pero hacerlo bien era más importante que meterlos en el producto mínimamente viable de WebAssembly. Nuestro razonamiento es simple: asm.js ha tenido éxito sin esta función.

Los subprocesos son definitivamente una función decisiva para algunas aplicaciones importantes, pero no lo son para todas las aplicaciones. Lo mismo ocurre con GC, manejo de excepciones de costo cero, llamadas de seguimiento garantizadas, etc.

Elegir hacer un MVP significa que no hacemos felices a todos en el primer lanzamiento. También significa que algunas personas pueden usar WebAssembly antes de que tengamos todo diseñado, especificado e implementado.

Dicho esto, esperamos adoptar más o menos el enfoque JavaScript SharedArrayBuffer en WebAssembly. Muchos de nosotros hemos estado involucrados con esa especificación desde el principio. Agregaría capacidades de bajo nivel similares a las que tiene C ++, además de una API similar a futex. Tiene espacio para crecer con más ordenamientos de memoria que coherencia secuencial. Hay trabajo en curso para crear un modelo de memoria formal para ello.

SAB se encuentra en la "etapa 4" en TC39, lo que significa que está terminado, listo para enviarse y listo para usarse. Espero que adoptarlo en WebAssembly no sea demasiado difícil.

@jfbastien gracias por la información esclarecedora.

Dicho esto, esperamos adoptar más o menos el enfoque JavaScript SharedArrayBuffer en WebAssembly.(...)
SAB se encuentra en la "etapa 4" en TC39, lo que significa que está terminado, listo para enviarse y listo para usarse. Espero que adoptarlo en WebAssembly no sea demasiado difícil.

Estupendo. Estoy ansioso por cansarlo con una gran cantidad de código C ++ que simplemente se muere de hambre por enhebrar.
Usualmente uso WebWorkers en mis aplicaciones TS/JS y permítanme decir que no soy un fanático de ellos, pero podrían ser un primer comienzo.

los subprocesos son muy importantes, pero hacerlos bien era más importante que meterlos en el producto mínimamente viable de WebAssembly. Nuestro razonamiento es simple: asm.js ha tenido éxito sin esta función.

Comprenda completamente las necesidades de un MVP para salir rápido (creo que esa fue la razón para dejar AST para pasar a estar basado en pilas) y el cuidado que necesita para planificar pasos adicionales.

Los subprocesos son definitivamente una función decisiva para algunas aplicaciones importantes, pero no lo son para todas las aplicaciones. Lo mismo ocurre con GC, manejo de excepciones de costo cero, llamadas de seguimiento garantizadas, etc.

Como usuario de emscripten desde hace mucho tiempo, me gustaría ver a WebAssembly más desvinculado de los límites de la pila de aplicaciones de Javascript:

Wasm solo debe 1) apuntar al máximo rendimiento y 2) proporcionar sockets, memoria/hilos, GDI, fs con algún estándar Posix/Unix/BSD. De esa manera, sería una capa delgada similar a un sistema operativo que se puede integrar en dispositivos móviles como una plataforma de destino unificada y en servidores para competir por aplicaciones implementables en la nube.

¿Es esta la dirección a la que se dirige Wasm en un futuro a largo plazo o me estoy perdiendo el tren por completo?

Gracias de nuevo por tu trabajo,

roberto

Wasm definitivamente está desacoplado de algunos límites de pila debido a cómo separamos los locales de lo que un compilador como LLVM necesita colocar en la memoria accesible para el usuario.

Con subprocesos, especialmente si no están basados ​​en Worker, obtendrá más poder allí.

Dicho esto, sería bueno obtener más detalles sobre sus ideas precisas. ¿Cuál es el caso de uso, cómo se soluciona en C++ y cómo lo harían las implementaciones de wasm?

¡No espero que encuentres todas las respuestas! Justo lo que se me ocurre ahora. Fwiw C++ tiene alguna propuesta para los límites de pila. Consulte el subgrupo SG14.

Perdón por los detalles bajos, estoy bajo un 👶🌯. ¡Responderé mejor más tarde!

Perdón por los detalles bajos, estoy debajo de un :bebé:: burrito:. ¡Responderé mejor más tarde!

¿Estás debajo de un burrito de bebé? Jajaja

@qwertie

¿Estás debajo de un burrito de bebé? Jajaja

Literalmente, un bebé envuelto.

Hola @jfbastien ,

sería bueno obtener más detalles sobre sus ideas precisas. ¿Cuál es el caso de uso, cómo se soluciona en C++ y cómo lo harían las implementaciones de wasm?

Generalmente mi caso de uso es en la construcción de software de simulación, en la parte computacional el límite es solo la máquina, gracias a las tecnologías C++, C/OpenCL y GPU.

En el front-end, la pila HTML5+CSS+Javascript+Typescript ha demostrado ser una forma válida, comprobada y portátil de desarrollar aplicaciones complejas medianas y grandes.

_ JS Web Stack (con la adición de un lenguaje estructurado como Typescript) es tan bueno en estos días que no siento la necesidad de recurrir a emscripten o probar wasm para la mayoría de las aplicaciones._

Estoy casi completamente de acuerdo con los objetivos de alto nivel y los casos de uso de ensamblaje web y aún más con el documento de incrustaciones no web .

_ W ebAssembly será una tecnología relevante (al menos para mí) si permite ser más rápido (hasta la médula de una aplicación C nativa más, digamos un 5 % de sobrecarga) usar más memoria y con más libertad, tener puertos/sockets completamente implementados y permite ejecutar subprocesos como lo hace cualquier sistema operativo normal._

La máquina Wasm debe tener un tamaño muy elegante, ser rápida y predictiva, así que no se apegue a ella. . Además, si tenemos una máquina con núcleo wasm de superrendimiento, entonces se puede construir un GC encima de ella.

En aras de la destreza, lo separaría progresivamente de Javascript. Si tengo compiladores nativos en cualquier idioma, entonces no necesito secuencias de comandos y, de todos modos, podría incrustar un Duktape/Lua/lo que sea simplemente compilando en las fuentes C.

En algún lugar del sitio de Mozilla vi documentos sobre la implementación de la manipulación DOM nativa de wasm: no creo que sea muy útil ya que la manipulación DOM es inherentemente secuencial y es uno de los aspectos que más tiempo consume de la pila HTML5/CSS/JS: si Escribo wasm multiproceso súper rápido solo para que mis cambios de DOM se serialicen esperando en la cola, luego todo el rendimiento desaparece y es mejor transpilar algo de Typescript que usar C / C ++. En este caso, preferiría el acceso directo a OpenGL (al principio con alguna implementación de WebGL y luego OpenGL nativo). Acceder a la tarjeta gráfica resultará útil para ofrecer capacidades de GPU/CUDA con poca o ninguna sobrecarga.
(Solo fui a verificar esto y obtuve el problema n. ° 273 que aborda esto)

Tener una pequeña máquina wasm compartida por todos los proveedores e independientes también podría resolver la pesadilla del desarrollo móvil, donde tiene al menos 4 cadenas de herramientas para diferentes sistemas operativos, versiones y arquitecturas.
Las funciones gráficas y de entrada pueden variar, pero podríamos desarrollar un wasm y luego consultar las API de las funciones, o incluso implementar la misma aplicación en diferentes tiendas de aplicaciones.
A largo plazo: lo mismo con las aplicaciones de servidor, llegando a algún tipo de consenso sobre las instalaciones (Polonias y protocolos de conexión de base de datos, Sistemas de páginas amarillas, Protocolos y sistemas de mensajería, etc.) y empaquetándolos en alguna especificación estándar como lo hizo la plataforma JEE. (Gran parte del trabajo conceptual ya se ha presentado en los últimos 20 años).

¡No espero que encuentres todas las respuestas! Justo lo que se me ocurre ahora. Fwiw C++ tiene alguna propuesta para los límites de pila. Consulte el subgrupo SG14.

Seguro que lo haré.

Gracias por su paciencia y tiempo.

Robar

Como una pequeña adición, cuando se implementan subprocesos, sería genial si el tamaño de la pila pudiera hacerse arbitrariamente grande, o en su lugar, si pudiera establecerse en al menos 64 MB. Esto se debe a que mi caso de uso es una aplicación que usa 2 subprocesos, y el subproceso no principal necesita una pila bastante grande.

@jjpe eso sería una solicitud para una cadena de herramientas en particular (como emscripten) que apunta a wasm, en lugar de este repositorio, porque es un problema de la elección de implementación de una cadena de herramientas o ABI en lugar de algo sobre la plataforma wasm per se. (por ejemplo, podría abrir un problema en https://github.com/kripken/emscripten/)

Algunas de las cosas que propuse en mi mensaje anterior parecen estar incluidas en la última propuesta de WASI.
Ver:
https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/

Cruzando los dedos.

--R

FWIW El estado actual es que Chrome está enviando compatibilidad con subprocesos wasm en la versión 74, Firefox tiene una implementación que aún no se ha enviado y Emscripten tiene compatibilidad con pthreads (https://emscripten.org/docs/porting/pthreads.html) con wasm disponible ahora.

(Además, WASI es una API de llamada al sistema, que es en su mayoría ortogonal a si una incrustación de wasm o cadena de herramientas determinada admite subprocesos/atómicos).

¿Hay algún documento sobre cómo usar las API de subprocesos de Chrome y Firefox?

Es una especie de combinación de cosas. El motor wasm del navegador implementa la extensión threads/atomics a la especificación wasm (https://github.com/WebAssembly/threads/tree/master/proposals/threads) que permite crear instancias de memorias wasm compartidas. En la web, puede crear un trabajador web y enviar la memoria (y cualquier módulo wasm asociado) al trabajador a través de postMessage. Luego, crea una instancia del módulo con la memoria compartida en el trabajador (y en el subproceso principal, u otro trabajador) y las instancias comparten su memoria. La descripción general de la propuesta de especificaciones (https://github.com/WebAssembly/threads/blob/master/proposals/threads/Overview.md) tiene un pequeño ejemplo, pero no conozco otros.

Hola @dschuff y gracias por la respuesta anterior.
En mi mensaje anterior, me refería a uno anterior, que involucraba no solo pthreads, sino también una evolución deseable de wasm hacia algo más similar al kernel que algunos de los que seguimos y usamos emscripten desde 2010 vimos como una tecnología realmente revolucionaria.
Consulte: https://github.com/WebAssembly/design/issues/992#issuecomment -285055578.

Nueve años después del lanzamiento de emscripten y casi cinco años después de los anuncios de wasm, se ha avanzado poco en la transformación de wasm en una tecnología de servidor viable.

Lamentablemente, porque necesitamos un estándar para aplicaciones portátiles, y la mejor manera de hacerlo en mi humilde opinión habría sido implementar un kernel pequeño (similar a BSD/Linux) con POSIX Threads y Berkeley Sockets + un sistema de archivos virtual seguro autónomo (con usuarios y grupos serían suficientes). Me mantengo firme en el viejo dicho de H. Spencer: "Aquellos que no entienden UNIX están condenados a reinventarlo".

Todavía quiero mantener la fe, por lo que WASI es un paso en la dirección correcta.

--R

PD: 2010 emscripten todavía es genial, ya que funciona en el navegador inmortal, el innombrable indestructible utilizado en la mayoría de las empresas y que verá flotar los cuerpos de Firefox y Safari (al menos sus motores).