Despidiéndonos de asm.js

 (spidermonkey.dev)
1 puntos por GN⁺ 3 시간 전 | 1 comentarios | Compartir por WhatsApp
  • Desde Firefox 148, la optimización de asm.js en SpiderMonkey quedó desactivada por defecto y el código relacionado se eliminará en futuras versiones
  • asm.js es un subconjunto de JavaScript, así que los sitios existentes seguirán funcionando, pero se ejecutarán por la ruta normal de JIT y perderán sus ventajas de optimización
  • Si se vuelve a compilar contenido asm.js a WebAssembly, se puede obtener una ejecución más rápida y binarios más pequeños
  • asm.js permitió una ejecución casi nativa dentro del contenido web, sin sandbox separado ni APIs alternativas, como respuesta frente a NaCl·PNaCl
  • OdinMonkey, incorporado en Firefox 22 en 2013, hizo posible distribuir en la web proyectos C/C++ como Unity y Unreal, y sentó las bases para WebAssembly

Desactivación de la optimización de asm.js

  • Desde Firefox 148, la optimización de asm.js en SpiderMonkey quedó desactivada por defecto, y en futuras versiones se eliminará todo el código relacionado
  • Los sitios que usan asm.js seguirán funcionando
    • asm.js es un subconjunto de JavaScript común, por lo que el código existente se ejecutará por la ruta normal de JIT como cualquier otro script
    • Sin embargo, se pierden las ventajas de optimización específicas de asm.js
  • Si todavía distribuyes contenido en asm.js, se recomienda volver a compilarlo a WebAssembly
    • Al recompilar a WebAssembly, se puede obtener una ejecución más rápida y binarios más pequeños
    • La tubería de WebAssembly en SpiderMonkey está mucho más desarrollada que la de asm.js
  • Como WebAssembly tuvo éxito y la mayor parte del uso de asm.js ya migró, el costo de mantener ambas rutas al mismo tiempo se volvió alto
    • Sigue requiriendo tiempo de mantenimiento
    • Queda una superficie de ataque adicional dentro de la VM

El papel de asm.js y el cierre de OdinMonkey

  • asm.js fue la respuesta de Mozilla a la pregunta que planteaban NaCl y PNaCl: “¿se puede ejecutar código a velocidad nativa en la web?”
    • El enfoque consistía en tomar un subconjunto estricto y estáticamente tipado de JavaScript, que el motor pudiera reconocer al vuelo, y compilarlo a código nativo
    • Podía mantenerse dentro del contenido web y usar las APIs web existentes, sin sandbox separado, IPC ni APIs alternativas
  • asm.js se incorporó en Firefox 22 en 2013, y permitió que proyectos como Unity y Unreal publicaran sus bases de código C/C++ en la web usando solo tecnologías web estándar
  • El compilador de asm.js se llamaba OdinMonkey, y su eliminación se sigue en el bug Ragnarök bajo el nombre “Twilight of OdinMonkey”
    • BaldrMonkey, nacido de OdinMonkey, es el compilador optimizador de WebAssembly
    • RabaldrMonkey es el compilador baseline de WebAssembly
    • OdinMonkey entra en su etapa final tras 13 años de servicio

Lecturas relacionadas

1 comentarios

 
GN⁺ 3 시간 전
Comentarios en Hacker News

  • asm.js fue la respuesta de Mozilla a la pregunta que plantearon NaCl y PNaCl: “¿cómo ejecutar código a velocidad nativa en la web?”
    Si hubiera sido ahora, Chrome simplemente habría impuesto NaCl y PNaCl, y entonces todos habrían estado quejándose de por qué Safari y Firefox no podían seguir los estándares de la “web”

    • Sigo creyendo que estamos en la línea temporal equivocada. PNaCl murió y, en vez de tener un sucesor digno que llegara a tiempo, terminamos hirviéndonos vivos en una sopa de apps de Electron
      Durante un tiempo pensé seriamente que terminaríamos haciendo todo en el navegador. En cierto sentido, cada vez pasa más, pero la experiencia general se siente peor que nunca. Me gusta WASM y quiero que me guste, pero la velocidad de maduración del ecosistema es increíblemente pobre
      Peor aún, necesitamos ejecutar herramientas de IA no confiables y sus resultados justo dentro de ese tipo de sandbox, pero las empresas están vendiendo exactamente lo contrario: sandboxes alojados y VMs alojadas basadas en JS
      Al final, parece que siempre fue el mismo problema. No había dinero en el sandbox del lado del cliente
    • Según recuerdo, no fue así. Fue un experimento útil en su momento, pero al final no funcionó bien
      Internamente fue útil para aislar el reproductor de Flash, pero las limitaciones del enfoque basado en LLVM pronto se hicieron evidentes para todos los involucrados
    • En realidad, en ese momento sí intentaron básicamente hacer eso. Trataron de sacarlo adelante a través de los comités de estándares web y siguieron el proceso
      Si no recuerdo mal, una razón importante de que fracasara fue que NaCl era una tecnología demasiado “grande” y asm.js una demasiado “pequeña”, así que asm.js llegó a estar listo para producción primero, aunque había empezado varios años después
    • Supongo que quiere decir que Chrome lo habría impuesto, Apple habría ganado tiempo sin decir nada mientras no invertía en el equipo de WebKit, y la gente crédula de internet se habría alineado con Apple
      Pero Apple sí parece haber aumentado su inversión en WebKit en esta década, después de que la presión regulatoria se volviera seria, así que hoy el resultado podría ser distinto
    • La gente se queja cuando hay una función útil para la plataforma web y no existe una alternativa de alta compatibilidad. asm.js y luego Wasm eran precisamente esa alternativa
      Por eso en aquel momento hubo menos quejas, y ahora sí las hay por cosas que Safari no hace porque perjudicarían a la App Store. Por suerte, la UE ahora está intentando corregir un poco a Apple

  • Es triste, pero tiene sentido. Como dato curioso, Figma empezó originalmente como una base de código completamente en C++, y asm.js fue clave para demostrar que una herramienta de diseño podía ejecutarse en el navegador
    El cambio a WebAssembly ocurrió después de conseguir clientes de pago, y la mejora en tiempo de carga también fue bastante grande. asm.js seguía siendo JS, así que el bundle era más grande y había que parsear el código como AST, mientras que WASM no tiene ese problema

    • No entiendo qué tiene de triste. Solo es un objetivo de compilación que en su momento tuvo sentido
      Es como ponerse triste porque ya no exista soporte para i386-unknown-freebsd1
    • Lo triste es que podríamos haber tenido una app de escritorio nativa y limpia de Figma

  • ¿Entonces ya llegó la muerte de asm.js? Nos estamos alejando de la línea temporal de la profecía
    https://www.destroyallsoftware.com/talks/the-birth-and-death...
    Si todavía no la han visto, la recomiendo muchísimo. Dependiendo de cómo se defina “la mejor”, podría ser la mejor charla técnica de todos los tiempos

    • Con la muerte de esta tecnología, el hilo de la profecía se ha roto. Puedes cargar una partida guardada para restaurar el tejido del destino, o seguir resistiendo en el mundo arruinado que tú mismo creaste
    • Vuelvo a ver esa charla dos o tres veces al año. Es un gran ejemplo de cómo dar una presentación y cómo hacer que el deck de diapositivas acompañe bien la exposición, y además hace un repaso sorprendentemente didáctico de la estructura de anillos de privilegio del sistema operativo
      Algún día, después de pasar por la época de guerra y soltar el apego psicológico a paradigmas de programación obsoletos, podremos avanzar a algo más progresista. Claro, eso no significa que tu banco vaya a dejar de correr YavaScript en al menos los próximos 85 años
    • Si reemplazas asm.js por WASM, todavía vas por el camino correcto
    • No hay de qué preocuparse. YavaScript vivirá para siempre
    • Si cambias guerra por COVID, ambas ocurrieron en 2020, así que no está tan desencaminado. Para ver si es cierto de verdad todavía hay que esperar hasta 2035

  • Nunca voy a olvidar el momento en que vi la charla de JavaScript de Gary Bernhardt.[0] Ahí fue cuando conocí por primera vez asm.js, y también caí por la madriguera de compilar código para que corriera en el navegador
    Ahora, 12 años después, me sorprende cuánto de su ficción terminó volviéndose realidad
    [0] https://www.destroyallsoftware.com/talks/the-birth-and-death...

    • La parte de las “thick apps” siempre se me quedó grabada. El nombre me daba risa, pero además se parecía bastante a mi situación
      Cuando vi esa charla por primera vez, era practicante, y la empresa hacía su propio compilador, IDE y depurador para unas pequeñas cajas de IO industrial. El compilador estaba escrito en C, lo convertimos a JS con Emscripten y luego lo “compilábamos” junto con el IDE y el depurador en un archivo HTML gigantesco, o sea, en realidad solo lo concatenábamos. La subida de código y la depuración iban por Ethernet, y todo se empujaba con Ajax
      Suena como una arquitectura maldita, pero a los clientes les encantaba. Como no era un EXE, no lo bloqueaban los filtros exagerados de TI corporativa de sus empresas. Por eso nunca migramos a Electron. En cierto sentido, sí tenía elementos primitivos de una thick app
    • Si no fuera por el auge de la IA, WASM podría haberse convertido en el objetivo de compilación a nivel máquina para todos los lenguajes. Gary predijo muchas cosas, pero no vio venir la IA

  • Hace mucho escribí un pequeño capítulo sobre asm.js en un libro de WebGL
    https://webglinsights.github.io/
    Fue divertido ver el ascenso de asm.js, que fue el precursor de WebAssembly. Entre las primeras demos había cosas realmente impresionantes, como Unreal Engine corriendo en el navegador. Da algo de nostalgia ver aquí su ocaso, pero dio paso a cosas mucho mejores

  • Tal vez haga falta un transpilador de asm.js a WASM
    Compilar código legado con versiones legadas de Emscripten es bastante frustrante. A veces es tan doloroso como actualizar el código JS para ajustarlo a los cambios acumulados del ABI de Emscripten

    • Binaryen antes tenía la herramienta asm2wasm, pero según entiendo ya fue retirada. No he podido encontrar otra equivalente
      Al menos el código asm.js va a seguir funcionando aunque se desactiven las optimizaciones de asm.js, pero estaría bien tener un convertidor
    • https://porffor.dev/

  • ¡asm.js ha muerto! ¡Larga vida a WebAssembly!

    • Siendo justos, yo creía que asm.js ya había quedado en desuso hace algunos años cuando apareció wasm

  • Personalmente creo que esta decisión es un error. Aunque no sé qué tan grande será el impacto real. Que yo sepa, ya no mucha gente usa asm.js
    Pero wasm está demasiado aislado de JavaScript. Después de usarlo de forma limitada, llegué a pensar que quizá preferiría compilar a asm.js
    Ni siquiera estaba seguro de que Emscripten siguiera dándole soporte completo
    En wasm no se puede llamar a la mayoría de las APIs web
    Y en lo que yo quería hacer, era todavía más importante que no se pudiera pasar un buffer de cero copias de JS a wasm
    Todo tiene compensaciones. El aislamiento es una ventaja, pero también una desventaja

    • asm.js seguramente sería incluso más limitado que wasm en lo que respecta a interactuar con JS. Básicamente estás restringido a valores numéricos simples y buffers de arreglo
      En cambio, hoy wasm ya tiene tipos GC y también puedes retener valores de JS con externref
      Probablemente tampoco podrías hacer buffers de cero copias en asm.js. Del lado de wasm hay una propuesta para eso: https://github.com/WebAssembly/memory-control/blob/main/prop...
    • Si no recuerdo mal, Emscripten eliminó el soporte para asm.js alrededor de 2020, y probablemente era la cadena de herramientas más importante que lo soportaba. La otra podría haber sido Rust, aunque no sé si todavía lo hace
      Incluso en asm.js estricto no puedes llamar directamente a la mayoría de las APIs web. Solo soporta números, no strings ni objetos de JS, y administra el heap de C dentro de un objeto ArrayBuffer, igual que WASM
      Los buffers de cero copias tienen el mismo problema. Tienes que salir de asm.js hacia JavaScript “real” para hacer la llamada, y tampoco puedes mapear otro ArrayBuffer directamente dentro del heap de asm.js, así que necesitas copiar. El “JavaScript FFI” en la práctica no es tan distinto entre asm.js y WASM
    • Si no estoy entendiendo mal, ¿asm.js no tiene la misma restricción? O sea, ¿que no puedes llamar directamente a las APIs web desde código asm.js y que igual hace falta un manejo aparte para funciones “externas”?

  • Recuerdo cuando Mozilla presentó OdinMonkey, extremadamente especializado para código asm.js. En cambio, el equipo de Chrome/V8 se enfocó en optimizaciones JIT más generales que aceleraran JavaScript en general y también ayudaran a asm.js
    La diferencia de velocidad favorecía a Firefox por un factor de 2 a 4, y le dieron bastante publicidad :D
    Hoy en día, la mayoría de las VMs de JavaScript de los navegadores han convergido hacia diseños y optimizaciones muy parecidos, así que incluso sin Odin el código asm.js probablemente se ejecutaría bastante rápido de todos modos

  • Mi plan de generar código JS en tiempo de ejecución para acelerar algoritmos se fue al traste. Hacer esto con wasm parece mucho más difícil

    • Generar código wasm en tiempo de ejecución es bastante fácil. Incluso podría ser más fácil que generar código asm.js válido
      Hay una pequeña librería que se encarga de buena parte de ese trabajo para pruebas: https://searchfox.org/firefox-main/source/js/src/jit-test/li...
    • Con una librería no es más difícil. En Rust puedes usar esto: https://crates.io/crates/wasm-encoder
      En JS, probablemente terminarías usando https://www.npmjs.com/package/binaryen
    • Todavía existe AssemblyScript. Si no lo estoy entendiendo mal o no me estoy confundiendo sobre lo que hace, quizá te sirva para lo que necesitas
      https://www.assemblyscript.org/
    • Simplemente usa el subconjunto de asm.js y mira qué tal rinde. Recuerdo que, incluso sin el soporte especial de asm.js en el navegador, el rendimiento de la salida de Emscripten era sorprendentemente bueno
    • Igual seguirá funcionando. asm.js al final de cuentas no deja de ser código JavaScript normal
      Solo que ya no se parseará ni ejecutará tan rápido como con una canalización dedicada a asm.js. A menos que sea una aplicación gigantesca, no creo que vayas a notar mucho la diferencia