La API de Integración de Promesas de JavaScript (JSPI) permite que las aplicaciones WebAssembly escritas bajo la suposición de acceso sincrónico a la funcionalidad externa operen sin problemas en un entorno en el que la funcionalidad es asíncrona.
La API de Integración de Promesas de JavaScript (JSPI) para WebAssembly tiene una nueva API, disponible en la versión M126 de Chrome. Hablamos sobre lo que ha cambiado, cómo usarla con Emscripten y cuál es la hoja de ruta para JSPI.
JSPI es una API que permite a las aplicaciones de WebAssembly que usan APIs secuenciales acceder a APIs web que son asíncronas. Muchas APIs web están diseñadas en términos de objetos Promise de JavaScript: en lugar de realizar inmediatamente la operación solicitada, devuelven un Promise para hacerlo. Por otro lado, muchas aplicaciones compiladas a WebAssembly provienen del universo C/C++, dominado por APIs que bloquean al llamador hasta que se completan.
La API de Integración de Promesas JavaScript (JSPI) de WebAssembly está entrando en una prueba de origen con la versión M123 de Chrome. Lo que significa esto es que puedes probar si tú y tus usuarios pueden beneficiarse de esta nueva API.
JSPI es una API que permite que el llamado código secuencial —que ha sido compilado a WebAssembly— acceda a APIs web que son asíncronas. Muchas APIs web están diseñadas en términos de Promises de JavaScript: en lugar de realizar de inmediato la operación solicitada, devuelven un Promise para hacerlo. Cuando la acción finalmente se ejecuta, el administrador de tareas del navegador invoca cualquier callback con el Promise. JSPI se integra en esta arquitectura para permitir que una aplicación WebAssembly se suspenda cuando se devuelve el Promise y se reanude cuando el Promise se resuelve.
Bienvenido al emocionante mundo de V8, donde la velocidad no es solo una característica, sino un estilo de vida. Al despedirnos de 2023, es hora de celebrar los impresionantes logros que V8 ha alcanzado este año.
A través de innovadoras optimizaciones de rendimiento, V8 continúa ampliando los límites de lo que es posible en el paisaje en constante evolución de la Web. Hemos introducido un nuevo compilador de nivel intermedio y hemos implementado varias mejoras en la infraestructura del compilador de nivel superior, el tiempo de ejecución y el recolector de basura, lo que ha resultado en importantes ganancias de velocidad en general.
Un artículo reciente sobre Recolección de Basura en WebAssembly (WasmGC) explica, a un nivel alto, cómo la propuesta de Recolección de Basura (GC) tiene como objetivo brindar mejor soporte a los lenguajes con GC en Wasm, lo cual es muy importante dada su popularidad. En este artículo, profundizaremos en los detalles técnicos de cómo lenguajes con GC como Java, Kotlin, Dart, Python y C# pueden ser trasladados a Wasm. De hecho, existen dos enfoques principales:
¡Estamos implementando las llamadas en cola de WebAssembly en V8 v11.2! En esta publicación, ofrecemos una breve descripción de esta propuesta, demostramos un caso de uso interesante para las corrutinas en C++ con Emscripten y mostramos cómo maneja V8 las llamadas en cola internamente.
Una llamada se encuentra en posición de cola si es la última instrucción ejecutada antes de regresar desde la función actual. Los compiladores pueden optimizar estas llamadas descartando el marco del llamador y reemplazando la llamada con un salto.
Esto es particularmente útil para las funciones recursivas. Por ejemplo, considere esta función en C que suma los elementos de una lista enlazada:
int sum(List* list, int acc) {
if (list == nullptr) return acc;
return sum(list->next, acc + list->val);
}
Con una llamada regular, esto consume un espacio de pila de 𝒪(n): cada elemento de la lista agrega un nuevo marco en la pila de llamadas. Con una lista lo suficientemente larga, esto podría desbordar rápidamente la pila. Al reemplazar la llamada con un salto, la optimización de llamadas en cola convierte efectivamente esta función recursiva en un bucle que utiliza un espacio de pila de 𝒪(1):
V8 tiene dos compiladores para compilar código WebAssembly en código de máquina que luego puede ser ejecutado: el compilador básico Liftoff y el compilador optimizador TurboFan. Liftoff puede generar código mucho más rápido que TurboFan, lo que permite un inicio rápido. TurboFan, por otro lado, puede generar código más rápido, lo que permite un alto rendimiento máximo.
Gracias a trabajos recientes en Chrome y Emscripten, ahora puedes usar hasta 4GB de memoria en aplicaciones de WebAssembly. Esto supera el límite anterior de 2GB. Podría parecer extraño que alguna vez haya existido un límite: después de todo, ¡no se necesitaba trabajo adicional para usar 512MB o 1GB de memoria! Pero resulta que hay algunas particularidades en el salto de 2GB a 4GB, tanto en el navegador como en la cadena de herramientas, que describiremos en esta publicación.
Contamos con un número creciente de compiladores y otras herramientas que generan o manipulan archivos .wasm, y a veces podrías querer echarles un vistazo. Tal vez eres desarrollador de una de estas herramientas, o más directamente, eres programador que trabaja con Wasm y te preguntas cómo luce el código generado, por razones de rendimiento u otras.
Emscripten siempre se ha centrado principalmente en compilar para la Web y otros entornos JavaScript como Node.js. Pero a medida que WebAssembly comienza a ser utilizado sin JavaScript, surgen nuevos casos de uso, y por eso hemos estado trabajando en el soporte para emitir Wasm independiente desde Emscripten, que no depende del runtime de JavaScript de Emscripten. ¡Esta publicación explica por qué eso es interesante!