Frank Denis ha vuelto a ejecutar su benchmark de libsodium en WebAssembly para 2026, probando el mismo código de criptografía en C contra entornos de ejecución lanzados en junio de 2024, 2025 y 2026. El objetivo es aburrido y útil: ¿están los entornos de ejecución mejorando realmente, no solo en un microbenchmark llamativo, sino en una carga de trabajo criptográfica real?
**Qué se probó**
WebAssembly (WASM) es un formato binario portátil que permite que el código compilado en C o Rust se ejecute en un entorno de aislamiento (sandbox). Un "runtime" es el motor que ejecuta un módulo .wasm, con un papel similar al de V8 para JavaScript, pero diseñado específicamente para WASM. libsodium es una biblioteca de criptografía ampliamente utilizada; su suite de benchmarks cubre operaciones con mucha aritmética donde el soporte del conjunto de instrucciones es fundamental.
Denis compiló libsodium a WebAssembly con cuatro niveles de características: baseline (sin extras), lime1, lime1+simd128 y lime1+simd128+wide_arithmetic, y luego ejecutó cada uno contra el código nativo x86-64 en un AMD Ryzen AI 9 HX 470. Los resultados se expresan como la ralentización relativa al nativo: 2.0× significa "el doble de lento". Cuanto menor sea el número, mejor.
**Resultados año tras año**
Wasmtime mejoró cada año: 2.67× nativo en 2024, 2.54× en 2025, 2.41× en 2026. Node también mejoró lentamente, de 8.60× a 7.95×. Wazero se mantuvo básicamente plano en aproximadamente 4.7–4.8×. WAMR en modo AOT ya estaba cerca del rendimiento nativo en 2025 y se mantuvo allí en 1.57–1.59×. Wasmer retrocedió en el lanzamiento de 2025 antes de recuperarse en 2026. El resultado de Bun en 2026 fue unas tres veces más rápido que su resultado de 2025, aunque todavía queda por detrás de Node en esta carga de trabajo. WAVM produjo el baseline de 2026 más rápido, pero no existe una comparación justa de 2024 o 2025.
Este gráfico ilustra la trayectoria de mejora año tras año discutida en la sección de resultados, mostrando cómo cambió el runtime más rápido a través de los lanzamientos.
El gráfico de baseline proporciona los datos de comparación fundamentales, ilustrando cómo evolucionó el rendimiento sin extras de cada motor año tras año.
**Las variantes de características importan más que la marca del runtime**
Para los lanzamientos de 2026, añadir wide_arithmetic fue el cambio más importante:
- Wasmtime 46.0.0: 2.41× → 1.46× nativo - Wasmer 7.1.0: 2.08× → 1.33× nativo
Solo Wasmtime y Wasmer pudieron ejecutar la compilación completa de wide_arithmetic entre los lanzamientos estables probados; WAMR la rechazó con un error de opcode no soportado. lime1 y simd128 por sí solos mostraron efectos inconsistentes, a veces ayudando, a veces perjudicando, a veces perdiéndose en el ruido.
Este desglose explica por qué la selección de características importó más que la marca del runtime, mostrando qué motores soportaban el conjunto de instrucciones wide_arithmetic que proporcionó las mayores mejoras.
**Fallos y advertencias**
No todas las ejecuciones se completaron. Bun 1.2.17 falló en un benchmark en baseline; Node 22.3.0 falló en varios tests de Argon2 y Scrypt hasta que se le dio un límite explícito de memoria lineal de 64 MiB, un umbral de modo de memoria de V8, no un simple ajuste de "más memoria ayuda". WAMR 2.1.0 (el espacio de 2024) no pudo compilar estos módulos en AOT en absoluto. Los benchmarks muy pequeños con tres iteraciones son ruidosos. Estos resultados son específicos para la criptografía estilo libsodium en una máquina; las cargas de trabajo del mundo real pueden diferir.
**Conclusión**
Para la criptografía intensiva en CPU en WebAssembly, la elección del runtime sigue siendo muy importante. La brecha entre el mejor resultado completo de 2026 (Wasmer con wide_arithmetic a 1.33× nativo) y el peor (Bun baseline a 8.77× nativo) es grande. El soporte de características, especialmente wide_arithmetic, puede cambiar un runtime de "bastante bueno" a "sorprendentemente cercano al nativo". Los runtimes principales no están estancados, pero el rendimiento de WebAssembly no es un solo número; depende del runtime, su versión, las características habilitadas y la carga de trabajo.
La clasificación captura el hallazgo central del artículo sobre la gran brecha de rendimiento entre los mejores y peores resultados de 2026 en diferentes runtimes.