Haciendo JavaScript en WebAssembly Rápido

Hola, soy Lynn Clark, y hago caricaturas de code. También trabajo en Fastly, que está haciendo un montón de cosas geniales con WebAssembly para hacer posible una mejor computación en el borde. Y soy cofundadora de la Alianza Bytecode. Estamos trabajando en herramientas para un ecosistema de WebAssembly que se extiende más allá del navegador. Y es una de esas herramientas de las que quería hablarles hoy. JavaScript fue creado inicialmente para ejecutarse en el navegador, para que las personas pudieran agregar un poco de interactividad a sus páginas web. Nadie habría adivinado que 20 años después, las personas estarían usando JavaScript para construir todo tipo de aplicaciones grandes y complejas para ejecutar en un navegador. Lo que hizo esto posible es que JavaScript en el navegador se ejecuta mucho más rápido de lo que lo hacía hace dos décadas. Y eso sucedió porque los proveedores de navegadores pasaron ese tiempo trabajando en algunas optimizaciones de performance bastante intensivas. Esto comenzó con la introducción de los compiladores justo a tiempo alrededor de 2008. Y los navegadores han construido sobre eso, continuando estos esfuerzos de optimization. Ahora estamos comenzando a trabajar en la optimización del rendimiento de JavaScript para un conjunto completamente diferente de entornos donde se aplican reglas diferentes. Y esto es posible gracias a WebAssembly. Así que, hoy quiero explicar qué es lo que permite WebAssembly. Pero primero, quiero darles un aviso. Esta charla está estructurada un poco diferente a como los expertos en oratoria me dirían que debería estar estructurando esta presentación. Voy a empezar contándoles cómo estamos haciendo que esto funcione en absoluto. Y una vez que hayan escuchado eso, es posible que no estén de acuerdo. Podrían pensar que esta es una idea bastante ridícula. Así que, por eso voy a explicar por qué. Voy a explicar por qué querrían hacer esto en realidad. Y luego, una vez que estén convencidos, y sé que estarán convencidos, entonces volveré y explicaré exactamente cómo es que estamos haciendo que esto sea rápido.

Entonces, comencemos con cómo estamos ejecutando JavaScript dentro de un motor de WebAssembly. Siempre que estás ejecutando JavaScript, el code JS necesita ser ejecutado como code de máquina de una forma u otra. Ahora, esto lo hace el motor JS utilizando una variedad de técnicas diferentes. Desde intérpretes y compiladores JIT. Y expliqué esto con más detalle en mi primer conjunto de artículos sobre WebAssembly en 2017. Así que, si quieres entender más sobre cómo funciona esto, puedes volver y leer esos artículos. Ejecutar este code de JavaScript es realmente bastante fácil en entornos como la Web donde sabes que vas a tener un motor de JavaScript disponible. ¿Pero qué pasa si tu plataforma objetivo no tiene un motor de JavaScript? Entonces necesitas desplegar tu motor de JavaScript con tu code.

Entonces, eso es lo que necesitamos hacer para llevar JavaScript a estos diferentes entornos. Entonces, ¿cómo lo hacemos? Bueno, desplegamos el motor de JavaScript como un módulo de WebAssembly, y eso lo hace portátil en un montón de diferentes arquitecturas de máquinas. Con WASI, podemos hacerlo portátil en un montón de diferentes sistemas operativos también. Esto significa que todo el entorno de JavaScript se agrupa en el módulo de WebAssembly. Y una vez que lo despliegas, todo lo que necesitas hacer es alimentar el código de JavaScript, y ese motor de JavaScript ejecutará ese código. Ahora, en lugar de trabajar directamente en la memoria de la máquina como lo haría para un navegador, el motor de JavaScript pone todo, desde el código de bytes hasta los objetos recolectados por el recolector de basura que el código de bytes trabaja, en la memoria lineal de la memoria de WebAssembly. Para nuestro motor JS, optamos por SpiderMonkey, y ese es el motor JS que utiliza Firefox. Es una de las máquinas virtuales de JavaScript de fuerza industrial, porque ha sido probada en la batalla en el navegador. Y este tipo de pruebas de batalla e inversión en seguridad es realmente importante cuando estás ejecutando código no confiable o ejecutando código que procesa entrada no confiable. SpiderMonkey también utiliza una técnica llamada escaneo de pila preciso, que es importante para algunas de las optimizaciones que describiré un poco más adelante en la charla.

Hasta ahora, no hay nada revolucionario en el enfoque que he descrito. La gente ya ha estado ejecutando JavaScript dentro de WebAssembly de esta manera durante varios años. El problema es que es lento. WebAssembly no te permite generar dinámicamente nuevo código de máquina y ejecutarlo desde dentro del código puro de WebAssembly. Entonces, esto significa que no puedes usar el JIT. Solo puedes usar el intérprete. Ahora, dada esta restricción, podrías estar preguntando por qué. Dado que los JIT son cómo los navegadores hicieron que el código JS se ejecute rápido, y dado que no puedes compilar JIT dentro de un módulo de WebAssembly, esto simplemente no tiene sentido. Pero, ¿qué pasaría si, incluso con estas restricciones, pudiéramos hacer que este JavaScript se ejecute rápido? Veamos un par de casos de uso donde una versión rápida de este enfoque podría ser realmente útil. Hay algunos lugares donde no puedes usar un compilador justo a tiempo debido a preocupaciones de seguridad. Entonces, por ejemplo, dispositivos iOS o algunos televisores inteligentes y consolas de juegos. En estas plataformas, tienes que usar un intérprete. Pero los tipos de aplicaciones que ejecutas en estas plataformas son de larga duración y requieren mucho código y esas son exactamente las condiciones en las que históricamente no querrías usar un intérprete debido a cuánto ralentiza tu ejecución. Si podemos hacer que nuestro enfoque sea rápido, entonces estos desarrolladores podrían usar JavaScript en plataformas sin JIT sin tomar un gran golpe en el rendimiento. Ahora, hay otros lugares donde usar un JIT no es un problema, pero donde los tiempos de inicio son prohibitivos. Entonces, un ejemplo de esto es en las funciones serverless y esto juega en ese problema de latencia de inicio en frío del que podrías haber oído hablar a la gente. Incluso si estás usando el entorno de JavaScript más reducido, que es un aislante que solo inicia un motor de JavaScript desnudo, estás buscando alrededor de cinco milisegundos de latencia de inicio. Ahora, hay algunas formas de ocultar esta latencia de inicio para una solicitud entrante. Pero es cada vez más difícil de ocultar a medida que los tiempos de conexión se optimizan en la capa de red con propuestas como QUIC. Y es más difícil de ocultar cuando estás encadenando funciones serverless

Con esto, podemos proporcionar una nueva instancia para cada solicitud, lo que significa que no hay estado residual entre solicitudes. Y como las instancias son tan ligeras, los desarrolladores podrían sentirse libres de dividir su code en piezas de grano fino. Y esto reduciría su radio de explosión a un mínimo para cualquier pieza de code. Así que, para estos casos de uso, hay un gran beneficio en hacer que JavaScript en WASM sea rápido. Pero, ¿cómo podemos hacer eso? Para responder a esa pregunta, necesitamos entender dónde pasa su tiempo el motor de JavaScript. Podemos desglosar el trabajo que tiene que hacer un motor de JavaScript en dos partes diferentes. Inicialización y tiempo de ejecución. Pienso en el motor JS como un contratista. Este contratista es contratado para completar un trabajo, y ese trabajo es ejecutar el code de JavaScript y llegar a un resultado final. Antes de que este contratista pueda realmente empezar a ejecutar el proyecto, sin embargo, necesita hacer un poco de trabajo preliminar. Esta fase de inicialización incluye todo lo que sólo necesita suceder una vez al principio del proyecto. Así que, una parte de esto es la inicialización de la aplicación. Para cualquier proyecto, el contratista necesita echar un vistazo al trabajo que el cliente quiere que haga y luego configurar los recursos que necesita para completar ese trabajo. Así que, por ejemplo, el contratista lee el briefing del proyecto y otros documentos de apoyo y los convierte en algo con lo que pueda trabajar. Así que, esto podría ser algo como configurar el sistema de gestión del proyecto con todos los documentos almacenados y organizados y desglosar las cosas en tareas que van al sistema de gestión de tareas. En el caso del motor JS, esto funciona más como leer a través del nivel superior del código fuente code y parsear funciones en el byte code, o asignar memoria para las variables que son declaradas y establecer valores donde ya están definidos. Así que, eso es la inicialización de la aplicación. Pero en algunos casos, también hay inicialización del motor. Y ves esto en contextos como serverless. El motor JS en sí mismo necesita ser iniciado en primer lugar. Y las funciones incorporadas necesitan ser añadidas al entorno. Pienso en esto como configurar la oficina en sí misma.

Hacer cosas como montar las sillas y mesas de Ikea y todo lo demás en el entorno antes de comenzar el trabajo. Ahora, esto puede llevar bastante tiempo. Y eso es parte de lo que puede hacer que el inicio en frío sea un problema para los casos de uso de serverless. Una vez que la fase de inicialización ha terminado, el motor JS puede comenzar su trabajo. Este trabajo de ejecutar el code. Y la velocidad de esta parte del trabajo se llama rendimiento. Y este rendimiento está afectado por muchas variables diferentes. Así, por ejemplo, qué características del lenguaje se están utilizando. Si el code se comporta de manera predecible desde el punto de vista del motor JS. Qué tipos de estructuras de data se utilizan y si el code se ejecuta lo suficiente como para beneficiarse del compilador de optimización del motor JS.

Así que estas son las dos fases en las que el motor JS pasa su tiempo. Inicialización y tiempo de ejecución. Ahora, ¿cómo podemos hacer que el trabajo en estas dos fases sea más rápido? Empecemos con la inicialización. ¿Podemos hacer que sea rápida? Y alerta de spoiler, sí, podemos. Utilizamos una herramienta llamada Wiser para esto. Y explicaré cómo funciona en un minuto. Pero primero quiero mostrarles algunos de los resultados que vimos. Probamos con una pequeña aplicación de markdown. Y usando Wiser, pudimos hacer que el tiempo de inicio fuera seis veces más rápido. Si miramos más a fondo en este caso, alrededor del 80% de esto se gastó en la inicialización del motor. Y el 20% restante se gastó en la inicialización de la aplicación. Y parte de eso es porque este renderizador de markdown es una aplicación muy pequeña y sencilla. A medida que las aplicaciones se vuelven más grandes y complejas, el tiempo de inicialización de la aplicación simplemente lleva más tiempo. Así que veríamos aceleraciones comparativas aún mayores para aplicaciones del mundo real. Ahora, obtenemos este inicio rápido utilizando una técnica llamada instantáneas. Antes de que el code se despliegue, como parte del paso de construcción, ejecutamos el code de JavaScript usando el motor de JavaScript hasta el final de la fase de inicialización. Y en este punto, el motor JS ha analizado todo el byte code o JS y lo ha convertido en byte code, que el módulo del motor JS almacena en la memoria lineal. Y el motor también hace mucho de asignación e inicialización de memoria en esta fase. Debido a que esta memoria lineal es tan autónoma, una vez que todos los valores han sido llenados, podemos simplemente tomar esa memoria y adjuntar como una sección de data a un módulo Wasm. Cuando el módulo del motor JS se instancia, tiene acceso

Actualmente, adjuntamos la sección data al mismo módulo que el motor JS, pero en el futuro, una vez que el enlace de módulos de WebAssembly esté en su lugar, podremos enviar la sección data como un módulo separado. Esto proporciona una separación realmente limpia y permite que el módulo del motor JS se reutilice en un montón de diferentes aplicaciones JS. El módulo del motor JS sólo contiene el code para el motor. Eso significa que una vez que está compilado, ese code puede ser efectivamente almacenado en caché y reutilizado entre muchas instancias diferentes.

Ahora, por otro lado, el módulo específico de la aplicación no contiene ningún code de WebAssembly. Sólo contiene la memoria lineal, que a su vez, contiene el bytecode de JavaScript, junto con todo el resto del estado del motor JS que fue inicializado. Esto hace que sea realmente fácil mover esta memoria y enviarla donde sea necesario. Es como si el contratista del motor JS no necesitara configurar su propia oficina en absoluto. Simplemente recibe este maletín de viaje, y ese maletín tiene toda la oficina, con todo en ella ya configurado y listo para ir, para que el motor JS simplemente se ponga a trabajar. Y lo más genial de esto es que no depende de nada que sea dependiente de JS. Sólo está utilizando una propiedad existente de WebAssembly en sí. Por lo tanto, podrías usar la misma técnica con lenguajes como Python o Ruby o Lua y otros

Tradicionalmente, este tipo de stub de IC en el JIT codificaría dos valores. El puntero a la forma y el desplazamiento de la propiedad. Eso requiere información que no tenemos con anticipación. Pero lo que podemos hacer es parametrizar el stub de IC, por lo que podemos tratar la forma y el desplazamiento de la propiedad como variables que se pasan al stub. Y de esta manera podemos crear un único stub que carga valores de la memoria y luego usar ese mismo code de stub en todas partes. Podemos simplemente hornear todos los stubs para estos patterns comunes en el módulo compilado AOT independientemente de lo que el JavaScript esté haciendo en realidad. Y descubrimos que con solo un par de kilobytes de stubs de IC, podemos cubrir la gran mayoría de todo el code de JS. Por ejemplo, con dos kilobytes de stubs de IC,

Si te emociona esto como a nosotros y quieres contribuir a los esfuerzos de optimización, o si quieres intentar hacer que esto funcione para otro lenguaje, como Python, Ruby o Lua, nos encantaría escuchar de ti. Puedes encontrarnos en la plataforma de mensajería, Zulip, y no dudes en publicar allí si quieres pedir más información. También puedes encontrar enlaces a los proyectos que mencioné en mi reciente post en el blog de Bytecode Alliance. Quiero agradecer a los organizadores por invitarme a hablar

Sí, de nuevo, aquí estás hablando más de que las personas lo están usando como consumidor pero no como desarrollador. Sí. Sí, no me sorprende en absoluto. Quiero decir, aunque ha estado alrededor durante mucho tiempo. Realmente salto de cliente a cliente cada año y nunca escucho en ningún lugar donde se use todavía aquí en los Países Bajos. Entonces, por supuesto, habrá empresas pero no en mi experiencia. Entonces, no me sorprende. Entonces, pasemos a las preguntas y respuestas. Tenemos algunas preguntas de nuestra audiencia, y si todavía tienes alguna pregunta para Lynn, puedes ir al canal de Preguntas y Respuestas de la Pista de la Community en Discord. Quiero hacer una pequeña nota, por supuesto, haces tus caricaturas, y bueno, creo que todos aquí deben haberse enamorado de tus diapositivas, y verás un gran aumento en tu tráfico en el sitio web de CodeCartoons. Realmente gran estilo de tus diapositivas. Entonces, quería dar algunos cumplidos por eso. Gracias. Y el sitio web de CodeCartoons no ha sido actualizado en un tiempo. Necesito cuidar eso. Entonces, un gran lugar para encontrarlos es el blog de la alianza de bytecode o el sitio web de hacks de Mozilla. Y en tu Twitter, creo.

Sí, y en mi Twitter. Para lo último y lo mejor de Lin, revisa su Twitter.

Veamos, la primera pregunta es de Alexius. ¿Crees que WebAssembly se convertirá en una parte importante del desarrollo web, trayendo otros lenguajes a la web, o se quedará en el área de aplicaciones computacionalmente pesadas? Entonces, creo que este no era el plan, pero creo que en realidad vamos a ver más del desarrollo interesante sucediendo fuera de la web y luego volviendo a la web a través de WebAssembly porque creo que en la web, para la mayoría de las cosas, mantener tu trabajo en JavaScript tiene sentido. Mantenerlo en JavaScript que se ejecuta de forma nativa en el navegador tiene sentido, excepto para esas piezas computacionalmente pesadas. Pero cuando hablas de fuera de la web, obtienes muchos beneficios de WebAssembly. Obtienes el aislamiento, obtienes la pequeña huella, obtienes la portabilidad que no tienes con muchas otras tecnologías. Creo que vamos a ver una gran adopción y trabajo interesante sucediendo fuera de la web. A medida que las personas quieran comenzar a usar esas aplicaciones en sus propios sitios web, lo traerán de vuelta a la web y comenzarán a integrarlo allí. Esa es mi predicción. Eso suena bien. La siguiente pregunta es de Happy to Collaborate. Creo que esta es alguien que quiere ayudar. ¿Crees que existen muchos módulos estándar, muy utilizados que actualmente existen en JavaScript serían imitados o duplicados o reemplazados por equivalentes módulos basados en Wasm? ¿Esto ofrecería una mejor seguridad al consumidor? Me interesaría. ¿Dijiste módulos gestionados? Bueno, módulos muy utilizados, módulos estándar. Entonces, estoy pensando que significa algo como subrayado. Bueno, ese subrayado es como un módulo de NPM. Podría estar hablando sobre módulos incorporados, que son los módulos estandarizados en JavaScript. Y esos son incorporados del navegador. Y luego también está el ecosistema de NPM que tiene muchos módulos comúnmente utilizados. Y sí, creo que vamos a ver implementaciones de esa misma funcionalidad en WebAssembly a veces más rendimiento. Sí, eso sería increíble. La siguiente pregunta es de nuestro asistente Keith. ¿Cuál sería una buena manera de incorporar WebAssembly en una aplicación existente para minimizar el riesgo pero comenzar a sentirse cómodo usándolo y aprovechándolo? ¿Cómo usar WebAssembly en un proyecto existente? Depende de si estás hablando de la web o fuera de la web. Si estás hablando de la web, probablemente quieras estar usando una aplicación donde si tienes algo que es computacionalmente pesado, entonces tiene sentido tomar esa pequeña parte que es computacionalmente pesada y portar ese pequeño bit a WebAssembly. Si estás trabajando fuera de la web, hay plataformas como la que tenemos en Fastly donde puedes poner fácilmente un módulo de WebAssembly como tu, ya sabes, ese es el artefacto que pones para ejecutar en una plataforma de borde computado. Entonces, en ese caso, simplemente vas a iniciar un servicio haciendo WebAssembly. Y así, si tienes una arquitectura de microservicios, entonces puedes