Hacer que JavaScript funcione rápidamente es clave para una aplicación web receptiva. Incluso con las optimizaciones avanzadas de V8, analizar y compilar JavaScript crítico durante el inicio aún puede generar cuellos de botella en el rendimiento. Saber qué funciones de JavaScript compilar durante la compilación inicial del script puede acelerar la carga de las páginas web.
El compilador optimizador de última etapa de V8, Turbofan, es conocido por ser uno de los pocos compiladores de producción a gran escala que utiliza Sea of Nodes (SoN). Sin embargo, desde hace casi 3 años, hemos comenzado a deshacernos del Mar de Nodos y a recurrir a una Representación Intermedia (IR) más tradicional basada en Graphos de Flujo de Control (CFG), que hemos denominado Turboshaft. Hasta ahora, todo el backend de JavaScript de Turbofan usa Turboshaft en su lugar, y WebAssembly usa Turboshaft en toda su tubería. Dos partes de Turbofan aún usan algo del Mar de Nodos: la tubería integrada, que estamos reemplazando lentamente por Turboshaft, y el frontend de la tubería de JavaScript, que estamos reemplazando por Maglev, otra IR basada en CFG. Esta publicación en el blog explica las razones que nos llevaron a alejarnos del Mar de Nodos.
En V8, siempre estamos buscando mejorar el rendimiento de JavaScript. Como parte de este esfuerzo, recientemente volvimos a analizar el conjunto de pruebas de JetStream2 para eliminar caídas de rendimiento. Esta publicación detalla una optimización específica que realizamos y que generó una mejora significativa de 2.5x en la prueba de referencia async-fs, contribuyendo a un aumento notable en la puntuación general. La optimización se inspiró en el benchmark, pero este tipo de patrones también aparecen en código del mundo real.
¿Alguna vez te has preguntado de dónde provienen undefined, true y otros objetos centrales de JavaScript? Estos objetos son los átomos de cualquier objeto definido por el usuario y necesitan estar ahí primero. V8 los llama raíces inmutables inamovibles y viven en su propio montón: el montón de solo lectura. Dado que se utilizan constantemente, el acceso rápido es crucial. ¿Y qué podría ser más rápido que adivinar correctamente su dirección de memoria en tiempo de compilación?
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.
En Chrome M117 presentamos un nuevo compilador de optimización: Maglev. Maglev se sitúa entre nuestros compiladores existentes Sparkplug y TurboFan, y cumple el rol de un compilador de optimización rápida que genera un código suficientemente bueno, lo suficientemente rápido.
Hasta 2021, V8 tenía dos niveles principales de ejecución: Ignition, el intérprete; y TurboFan, el compilador de optimización de V8 enfocado en el rendimiento máximo. Todo el código JavaScript se compila primero en bytecode de Ignition y se ejecuta interpretándolo. Durante la ejecución, V8 rastrea cómo se comporta el programa, incluyendo el seguimiento de formas y tipos de objetos. Tanto los metadatos de ejecución en tiempo de ejecución como el bytecode se ingresan en el compilador de optimización para generar código máquina de alto rendimiento, a menudo especulativo, que se ejecuta significativamente más rápido que el intérprete.
En V8 v9.1 hemos deshabilitado temporalmente los builtins incrustados en el escritorio. Si bien incrustar builtins mejora significativamente el uso de memoria, nos hemos dado cuenta de que las llamadas a funciones entre builtins incrustados y código compilado por JIT pueden conllevar un considerable costo de rendimiento. Este costo depende de la microarquitectura de la CPU. En esta publicación explicaremos por qué sucede esto, cómo se ve el rendimiento y qué planeamos hacer para resolverlo a largo plazo.
La palabra clave super puede ser utilizada para acceder a propiedades y funciones en el objeto padre.
Anteriormente, acceder a una propiedad super (como super.x) se implementaba a través de una llamada en tiempo de ejecución. A partir de V8 v9.0, reutilizamos el sistema de caché en línea (IC) en código no optimizado y generamos el código optimizado adecuado para el acceso a propiedades super, sin necesidad de saltar al tiempo de ejecución.
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.