Obtén información para llevar aplicaciones con subprocesos múltiples escritas en otros lenguajes a WebAssembly.
La compatibilidad con subprocesos de WebAssembly es una de las incorporaciones de rendimiento más importantes de WebAssembly. Te permite ejecutar partes de tu código en paralelo en núcleos separados o el mismo código en partes independientes de los datos de entrada, escalarlo a tantos núcleos como tenga el usuario y reducir significativamente el tiempo de ejecución general.
En este artículo, aprenderás a usar subprocesos de WebAssembly para llevar a la Web aplicaciones multiproceso escritas en lenguajes como C, C++ y Rust.
Cómo funcionan los subprocesos de WebAssembly
Los subprocesos de WebAssembly no son una función independiente, sino una combinación de varios componentes que permite que las apps de WebAssembly usen paradigmas de subprocesos múltiples tradicionales en la Web.
Web Workers
El primer componente son los Workers normales que conoces y te encantan de JavaScript. Los subprocesos de WebAssembly usan el constructor new Worker
para crear subprocesos subyacentes nuevos. Cada subproceso carga una unión de JavaScript y, luego, el subproceso principal usa el método Worker#postMessage
para compartir el WebAssembly.Module
compilado y un WebAssembly.Memory
compartido (consulta a continuación) con esos otros subprocesos. Esto establece la comunicación y permite que todos esos subprocesos ejecuten el mismo código de WebAssembly en la misma memoria compartida sin volver a pasar por JavaScript.
Los Web Workers existen desde hace más de una década, se admiten ampliamente y no requieren ninguna marca especial.
SharedArrayBuffer
La memoria de WebAssembly se representa con un objeto WebAssembly.Memory
en la API de JavaScript. De forma predeterminada, WebAssembly.Memory
es un wrapper alrededor de un ArrayBuffer
, un búfer de bytes sin procesar al que solo puede acceder un solo subproceso.
> new WebAssembly.Memory({ initial:1, maximum:10 }).buffer
ArrayBuffer { … }
Para admitir varios subprocesos, WebAssembly.Memory
también obtuvo una variante compartida. Cuando se crea con una marca shared
a través de la API de JavaScript o por el binario de WebAssembly, se convierte en un wrapper alrededor de un SharedArrayBuffer
. Es una variación de ArrayBuffer
que se puede compartir con otros subprocesos y leer o
modificar de forma simultánea desde cualquier lado.
> new WebAssembly.Memory({ initial:1, maximum:10, shared:true }).buffer
SharedArrayBuffer { … }
A diferencia de postMessage
, que se usa normalmente para la comunicación entre el subproceso principal y los trabajadores web, SharedArrayBuffer
no requiere copiar datos ni esperar a que el bucle de eventos envíe y reciba mensajes.
En cambio, todos los cambios ven los cambios casi al instante, lo que lo convierte en un objetivo de compilación mucho mejor para las primitivas de sincronización tradicionales.
SharedArrayBuffer
tiene un historial complicado. Inicialmente, se envió en varios navegadores a mediados de 2017, pero se tuvo que inhabilitar a principios de 2018 debido al descubrimiento de vulnerabilidades de Spectre. El motivo particular era que la extracción de datos en Spectre se basa en ataques de tiempo, que miden el tiempo de ejecución de un fragmento de código en particular. Para dificultar este tipo de ataque, los navegadores redujeron la precisión de las APIs de tiempo estándar, como Date.now
y performance.now
. Sin embargo, la memoria compartida, combinada con un simple contador que se ejecuta en un subproceso separado también es una forma muy confiable de obtener tiempos de alta precisión y es mucho más difícil de mitigar sin limitar significativamente el rendimiento del tiempo de ejecución.
En cambio, Chrome 68 (mediados de 2018) volvió a habilitar SharedArrayBuffer
aprovechando el aislamiento de sitios, una función que coloca diferentes sitios web en diferentes procesos y dificulta mucho más el uso de ataques de canal lateral como Spectre. Sin embargo, esta mitigación aún se limitaba solo a Chrome para computadoras, ya que el aislamiento de sitios es una función bastante costosa y no se podía habilitar de forma predeterminada para todos los sitios en dispositivos móviles con poca memoria, ni otros proveedores la habían implementado.
En la actualidad, Chrome y Firefox implementan el aislamiento de sitios y tienen una forma estándar para que los sitios web habiliten la función con los encabezados COOP y COEP. Un mecanismo de habilitación voluntaria permite usar el aislamiento de sitios incluso en dispositivos de baja potencia, en los que habilitarlo para todos los sitios web sería demasiado costoso. Para habilitarlo, agrega los siguientes encabezados al documento principal en la configuración del servidor:
Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin
Una vez que habilites esta opción, obtendrás acceso a SharedArrayBuffer
(incluida WebAssembly.Memory
respaldada por una SharedArrayBuffer
), temporizadores precisos, medición de memoria y otras APIs que requieren un origen aislado por motivos de seguridad. Consulta Cómo hacer que tu sitio web sea "aislado de varios orígenes" con COOP y COEP para obtener más información.
Operaciones atómicas de WebAssembly
Si bien SharedArrayBuffer
permite que cada subproceso lea y escriba en la misma memoria, para una comunicación correcta, debes asegurarte de que no realicen operaciones en conflicto al mismo tiempo. Por ejemplo, es posible que un subproceso comience a leer datos de una dirección compartida mientras otro subproceso le escribe, por lo que el primer subproceso obtendrá un resultado dañado. Esta categoría de errores se conoce como condiciones de carrera. Para evitar las condiciones de carrera, debes sincronizar esos accesos de alguna manera.
Aquí es donde entran en juego las operaciones atómicas.
Los atómicos de WebAssembly son una extensión del conjunto de instrucciones de WebAssembly que permite leer y escribir pequeñas celdas de datos (por lo general, números enteros de 32 y 64 bits) de forma "atómica". Es decir, de una manera que garantice que no haya dos subprocesos que lean o escriban en la misma celda al mismo tiempo, lo que evita esos conflictos a un nivel bajo. Además, los elementos atómicos de WebAssembly contienen dos tipos de instrucciones más: "wait" y "notify", que permiten que un subproceso entre en suspensión ("wait") en una dirección determinada en una memoria compartida hasta que otro subproceso lo active a través de "notify".
Todas las primitivas de sincronización de nivel superior, incluidos los canales, los mutexes y las cerraduras de lectura y escritura, se basan en esas instrucciones.
Cómo usar subprocesos de WebAssembly
Detección de atributos
Los elementos atómicos de WebAssembly y SharedArrayBuffer
son funciones relativamente nuevas y aún no están disponibles en todos los navegadores compatibles con WebAssembly. Puedes encontrar qué navegadores admiten las nuevas funciones de WebAssembly en el plan de trabajo de webassembly.org.
Para garantizar que todos los usuarios puedan cargar tu aplicación, deberás implementar la mejora progresiva compilando dos versiones diferentes de Wasm: una con compatibilidad con subprocesos y otra sin ella. Luego, carga la versión compatible según los resultados de la detección de funciones. Para detectar la compatibilidad con subprocesos de WebAssembly durante el tiempo de ejecución, usa la biblioteca wasm-feature-detect y carga el módulo de la siguiente manera:
import { threads } from 'wasm-feature-detect';
const hasThreads = await threads();
const module = await (
hasThreads
? import('./module-with-threads.js')
: import('./module-without-threads.js')
);
// …now use `module` as you normally would
Ahora, veamos cómo compilar una versión multiproceso del módulo de WebAssembly.
C
En C, en particular en sistemas similares a Unix, la forma común de usar subprocesos es a través de los subprocesos POSIX que proporciona la biblioteca pthread
. Emscripten
proporciona una implementación compatible con la API de
la biblioteca pthread
compilada sobre Web Workers, memoria compartida y operaciones atómicas, de modo que el mismo código pueda
funcionar en la Web sin cambios.
Veamos un ejemplo:
example.c:
#include <stdio.h>
#include <unistd.h>
#include <pthread.h>
void *thread_callback(void *arg)
{
sleep(1);
printf("Inside the thread: %d\n", *(int *)arg);
return NULL;
}
int main()
{
puts("Before the thread");
pthread_t thread_id;
int arg = 42;
pthread_create(&thread_id, NULL, thread_callback, &arg);
pthread_join(thread_id, NULL);
puts("After the thread");
return 0;
}
Aquí, los encabezados de la biblioteca pthread
se incluyen a través de pthread.h
. También puedes ver algunas funciones cruciales para controlar los subprocesos.
pthread_create
creará un subproceso en segundo plano. Se necesita un destino para almacenar un controlador de subproceso, algunos atributos de creación de subprocesos (aquí no se pasa ninguno, por lo que es solo NULL
), la devolución de llamada que se ejecutará en el subproceso nuevo (aquí thread_callback
) y un puntero de argumento opcional para pasar a esa devolución de llamada en caso de que quieras compartir algunos datos del subproceso principal. En este ejemplo, compartiremos un puntero para una variable arg
.
Se puede llamar a pthread_join
más adelante en cualquier momento para esperar a que el subproceso finalice la ejecución y obtener el resultado que devuelve la devolución de llamada. Acepta el identificador de subproceso asignado anteriormente, así como un puntero para almacenar el resultado. En este caso, no hay resultados, por lo que la función toma un NULL
como argumento.
Para compilar código con subprocesos con Emscripten, debes invocar emcc
y pasar un parámetro -pthread
, como cuando compilas el mismo código con Clang o GCC en otras plataformas:
emcc -pthread example.c -o example.js
Sin embargo, cuando intentes ejecutarlo en un navegador o en Node.js, verás una advertencia y, luego, el programa se bloqueará:
Before the thread
Tried to spawn a new thread, but the thread pool is exhausted.
This might result in a deadlock unless some threads eventually exit or the code
explicitly breaks out to the event loop.
If you want to increase the pool size, use setting `-s PTHREAD_POOL_SIZE=...`.
If you want to throw an explicit error instead of the risk of deadlocking in those
cases, use setting `-s PTHREAD_POOL_SIZE_STRICT=2`.
[…hangs here…]
¿Qué pasó? El problema es que la mayoría de las APIs que consumen mucho tiempo en la Web son asíncronas y dependen del bucle de eventos para ejecutarse. Esta limitación es una distinción importante en comparación con los entornos tradicionales, en los que las aplicaciones suelen ejecutar operaciones de E/S de forma síncrona y de bloqueo. Consulta la entrada de blog sobre Cómo usar APIs web asíncronas desde WebAssembly si quieres obtener más información.
En este caso, el código invoca de forma síncrona a pthread_create
para crear un subproceso en segundo plano y, luego, realiza otra llamada síncrona a pthread_join
que espera a que el subproceso en segundo plano termine la ejecución. Sin embargo, los Web Workers, que se usan en segundo plano cuando este código se compila con Emscripten, son asíncronos. Lo que sucede es que pthread_create
solo programa un nuevo subproceso de trabajador para que se cree en la siguiente ejecución del bucle de eventos, pero luego pthread_join
bloquea de inmediato el bucle de eventos para esperar a ese trabajador y, de esta manera, evita que se cree. Es un ejemplo clásico de un interbloqueo.
Una forma de resolver este problema es crear un grupo de trabajadores con anticipación, antes de que el programa siquiera comience. Cuando se invoca pthread_create
, puede tomar un trabajador listo para usar del grupo, ejecutar la devolución de llamada proporcionada en su subproceso en segundo plano y devolver el trabajador al grupo. Todo esto
se puede hacer de forma síncrona, por lo que no habrá ningún interbloqueo, siempre y cuando el grupo sea lo suficientemente
grande.
Esto es exactamente lo que Emscripten permite con la opción -s
PTHREAD_POOL_SIZE=...
. Permite especificar una cantidad de subprocesos, ya sea una cantidad fija o una expresión de JavaScript, como navigator.hardwareConcurrency
, para crear tantos subprocesos como núcleos tenga la CPU. La última opción es útil cuando tu código puede escalar a una cantidad arbitraria de subprocesos.
En el ejemplo anterior, solo se crea un subproceso, por lo que, en lugar de reservar todos los núcleos, basta con usar -s PTHREAD_POOL_SIZE=1
:
emcc -pthread -s PTHREAD_POOL_SIZE=1 example.c -o example.js
Esta vez, cuando lo ejecutes, todo funcionará correctamente:
Before the thread
Inside the thread: 42
After the thread
Pthread 0x701510 exited.
Sin embargo, hay otro problema: ¿ves ese sleep(1)
en el ejemplo de código? Se ejecuta en la devolución de llamada del subproceso, es decir, fuera del subproceso principal, por lo que debería estar bien, ¿no? Bueno, no lo es.
Cuando se llama a pthread_join
, este debe esperar a que finalice la ejecución del subproceso, lo que significa que, si el subproceso creado realiza tareas de larga duración (en este caso, duerme 1 segundo), el subproceso principal también deberá bloquearse durante el mismo período hasta que se recuperen los resultados. Cuando se ejecute este código JS en el navegador, bloqueará el subproceso de IU durante 1 segundo hasta que se devuelva la devolución de llamada del subproceso. Esto genera una experiencia del usuario deficiente.
Hay algunas soluciones para esto:
pthread_detach
-s PROXY_TO_PTHREAD
- Custom Worker y Comlink
pthread_detach
En primer lugar, si solo necesitas ejecutar algunas tareas fuera del subproceso principal, pero no necesitas esperar los resultados, puedes usar pthread_detach
en lugar de pthread_join
. Esto hará que la devolución de llamada del subproceso se ejecute en segundo plano. Si usas esta opción, puedes desactivar la advertencia con -s
PTHREAD_POOL_SIZE_STRICT=0
.
PROXY_TO_PTHREAD
En segundo lugar, si compilas una aplicación de C en lugar de una biblioteca, puedes usar la opción -s
PROXY_TO_PTHREAD
, que descargará el código principal de la aplicación en un subproceso independiente, además de los subprocesos anidados creados por la aplicación. De esta manera, el código principal puede bloquearse de manera segura en cualquier momento sin congelar la IU.
Por cierto, cuando usas esta opción, tampoco tienes que crear previamente el conjunto de subprocesos. En su lugar, Emscripten puede aprovechar el subproceso principal para crear nuevos trabajadores subyacentes y, luego, bloquear el subproceso auxiliar en pthread_join
sin interbloqueo.
Comlink
En tercer lugar, si trabajas en una biblioteca y aún necesitas bloquear, puedes crear tu propio trabajador, importar el código generado por Emscripten y exponerlo con Comlink al subproceso principal. El subproceso principal podrá invocar cualquier método exportado como función asíncrona y, de esa manera, también evitará bloquear la IU.
En una aplicación simple, como el ejemplo anterior, -s PROXY_TO_PTHREAD
es la mejor opción:
emcc -pthread -s PROXY_TO_PTHREAD example.c -o example.js
C++
Todas las mismas advertencias y lógicas se aplican de la misma manera a C++. Lo único nuevo que obtienes es acceso a APIs de nivel superior, como std::thread
y std::async
, que usan la biblioteca pthread
que se analizó anteriormente.
Por lo tanto, el ejemplo anterior se puede volver a escribir en C++ más idiomático de la siguiente manera:
example.cpp:
#include <iostream>
#include <thread>
#include <chrono>
int main()
{
puts("Before the thread");
int arg = 42;
std::thread thread([&]() {
std::this_thread::sleep_for(std::chrono::seconds(1));
std::cout << "Inside the thread: " << arg << std::endl;
});
thread.join();
std::cout << "After the thread" << std::endl;
return 0;
}
Cuando se compile y ejecute con parámetros similares, se comportará de la misma manera que el ejemplo de C:
emcc -std=c++11 -pthread -s PROXY_TO_PTHREAD example.cpp -o example.js
Resultado:
Before the thread
Inside the thread: 42
Pthread 0xc06190 exited.
After the thread
Proxied main thread 0xa05c18 finished with return code 0. EXIT_RUNTIME=0 set, so
keeping main thread alive for asynchronous event operations.
Pthread 0xa05c18 exited.
Rust
A diferencia de Emscripten, Rust no tiene un destino web especializado de extremo a extremo, sino que proporciona un destino wasm32-unknown-unknown
genérico para la salida genérica de WebAssembly.
Si se pretende usar Wasm en un entorno web, cualquier interacción con las APIs de JavaScript se deja a las bibliotecas y herramientas externas, como wasm-bindgen y wasm-pack. Lamentablemente, esto significa que la biblioteca estándar no reconoce a los trabajadores web, y las APIs estándar, como std::thread
, no funcionarán cuando se compilen en WebAssembly.
Por suerte, la mayoría del ecosistema depende de bibliotecas de nivel superior para controlar el procesamiento en varios subprocesos. En ese nivel, es mucho más fácil abstraer todas las diferencias de plataforma.
En particular, Rayon es la opción más popular para el paralelismo de datos en Rust. Te permite tomar cadenas de métodos en iteradores normales y, por lo general, con un cambio de una sola línea, convertirlos de una manera en la que se ejecuten en paralelo en todos los subprocesos disponibles en lugar de de forma secuencial. Por ejemplo:
pub fn sum_of_squares(numbers: &[i32]) -> i32 {
numbers
.iter()
.par_iter()
.map(|x| x * x)
.sum()
}
Con este pequeño cambio, el código dividirá los datos de entrada, calculará x * x
y las sumas parciales en subprocesos en paralelo y, al final, sumará esos resultados parciales.
Para adaptarse a las plataformas sin std::thread
que funcione, Rayon proporciona hooks que permiten definir una lógica personalizada para generar subprocesos y salir de ellos.
wasm-bindgen-rayon aprovecha esos hooks para generar subprocesos de WebAssembly como Web Workers. Para usarla, debes agregarla como dependencia y seguir los pasos de configuración que se describen en los documentos. El ejemplo anterior tendrá el siguiente aspecto:
pub use wasm_bindgen_rayon::init_thread_pool;
#[wasm_bindgen]
pub fn sum_of_squares(numbers: &[i32]) -> i32 {
numbers
.par_iter()
.map(|x| x * x)
.sum()
}
Una vez hecho esto, el JavaScript generado exportará una función initThreadPool
adicional. Esta función creará un grupo de trabajadores y los reutilizará durante el ciclo de vida del programa para cualquier operación de varios subprocesos que realice Rayon.
Este mecanismo de grupo es similar a la opción -s PTHREAD_POOL_SIZE=...
en Emscripten que se explicó antes y también debe inicializarse antes del código principal para evitar interbloqueos:
import init, { initThreadPool, sum_of_squares } from './pkg/index.js';
// Regular wasm-bindgen initialization.
await init();
// Thread pool initialization with the given number of threads
// (pass `navigator.hardwareConcurrency` if you want to use all cores).
await initThreadPool(navigator.hardwareConcurrency);
// ...now you can invoke any exported functions as you normally would
console.log(sum_of_squares(new Int32Array([1, 2, 3]))); // 14
Ten en cuenta que las mismas restricciones sobre el bloqueo del subproceso principal también se aplican aquí. Incluso el ejemplo de sum_of_squares
aún debe bloquear el subproceso principal para esperar los resultados parciales de otros subprocesos.
Puede ser una espera muy corta o larga, según la complejidad de los iteradores y la cantidad de subprocesos disponibles, pero, para mayor seguridad, los motores del navegador impiden de forma activa el bloqueo del subproceso principal por completo, y ese código arrojará un error. En su lugar, debes crear un trabajador, importar el código generado por wasm-bindgen
allí y exponer su API con una biblioteca como Comlink al subproceso principal.
Consulta el ejemplo de wasm-bindgen-rayon para ver una demostración de extremo a extremo que muestra lo siguiente:
- Detección de atributos de subprocesos
- Compilar versiones de un solo subproceso y de varios subprocesos de la misma app de Rust
- Carga el JS+Wasm que genera wasm-bindgen en un trabajador.
- Usa wasm-bindgen-rayon para inicializar un grupo de subprocesos.
- Usar Comlink para exponer la API de Worker al subproceso principal
Casos de uso del mundo real
Usamos subprocesos de WebAssembly de forma activa en Squoosh.app para la compresión de imágenes del cliente, en particular, para formatos como AVIF (C++), JPEG-XL (C++), OxiPNG (Rust) y WebP v2 (C++). Gracias solo al procesamiento en varios subprocesos, observamos aceleraciones coherentes de 1.5 a 3 veces (la proporción exacta difiere según el códec) y pudimos aumentar esas cifras aún más combinando subprocesos de WebAssembly con WebAssembly SIMD.
Google Earth es otro servicio notable que usa subprocesos de WebAssembly para su versión web.
FFMPEG.WASM es una versión de WebAssembly de una cadena de herramientas multimedia FFmpeg popular que usa subprocesos de WebAssembly para codificar videos de manera eficiente directamente en el navegador.
Hay muchos más ejemplos interesantes sobre cómo usar los subprocesos de WebAssembly. Asegúrate de revisar las demostraciones y de usar tus propias aplicaciones y bibliotecas multiproceso en la Web.