Hoy presentamos una nueva suite de pruebas de benchmark JavaScript de WebKit, JetStream. JetStream codifica lo que ha sido nuestro proceso de facto: combinar puntos de referencia de latencia y rendimiento con una ponderación aproximadamente igual, y capturar tanto métricas de estilos de programación JavaScript tradicionales como nuevas tecnologías basadas en JavaScript que han capturado nuestra imaginación. Las puntuaciones en JetStream son un buen indicador del rendimiento que los usuarios verían en aplicaciones web avanzadas como juegos.
Optimizar el rendimiento de nuestro motor JavaScript es una alta prioridad para el proyecto WebKit. Algunos ejemplos de algunas de las mejoras que introdujimos en el último año incluyen compilación concurrente, GC generacional y el JIT FTL. La ingeniería de estas mejoras requiere enfoque: tratamos de priorizar los proyectos de alto impacto sobre la construcción y el mantenimiento de optimizaciones complejas que tienen beneficios más pequeños. Por lo tanto, motivamos el trabajo de rendimiento con puntos de referencia que ilustran los tipos de cargas de trabajo que los usuarios de WebKit probablemente encontrarán. Esta filosofía de desarrollo basado en puntos de referencia ha sido parte de WebKit durante mucho tiempo.
El estado anterior de la evaluación comparativa de JavaScript
Al realizar mejoras en el motor JavaScript de WebKit, descubrimos que ninguna suite de evaluación comparativa era completamente representativa de los escenarios que queríamos mejorar. Nos gusta que JSBench mida el rendimiento del código JavaScript en sitios web populares, pero WebKit ya lo hace muy bien en este punto de referencia. Nos gusta SunSpider por su cobertura de construcciones de lenguaje de uso común y por el hecho de que su tiempo de ejecución es representativo del tiempo de ejecución del código en la web, pero se queda corto para medir el rendimiento máximo. Nos gusta el octanaje, pero se inclina demasiado en la otra dirección: es útil para determinar el rendimiento máximo de nuestro motor, pero no es lo suficientemente sensible al rendimiento que es más probable que vea en las cargas de trabajo web típicas. También minimiza tecnologías de JavaScript novedosas como asm.js; solo uno de los 15 puntos de referencia de Octane era un asm.prueba js, y esta prueba ignora el rendimiento de punto flotante.
Encontrar buenos asm.los puntos de referencia de js son difíciles. A pesar de que Emscript está ganando mindshare, sus pruebas son de larga duración y, hasta hace poco, carecían de un arnés web. Así que construimos nuestro propio asm.puntos de referencia de js mediante el uso de pruebas de la suite de pruebas LLVM. Estas pruebas de C y C++ son utilizadas por los desarrolladores de LLVM para realizar un seguimiento de las mejoras de rendimiento de la pila de compiladores clang/LLVM. Emscripten utiliza LLVM para generar el código JavaScript. Esto hace que el conjunto de pruebas LLVM sea particularmente apropiado para probar qué tan bien maneja un motor JavaScript el código nativo. Otra ventaja de nuestras nuevas pruebas es que son mucho más rápidas de ejecutar que la suite de pruebas Emscripten.
Tener buenos parámetros de JavaScript nos permite buscar con confianza ambiciosas mejoras en WebKit. Por ejemplo, SunSpider guió nuestro trabajo de compilación simultáneo, mientras que el asm.las pruebas js y las pruebas de rendimiento de Octane motivaron nuestro trabajo en el FTL JIT. Pero permitir que nuestras pruebas se basen en una mezcolanza de estas diferentes suites de referencia se ha vuelto poco práctico. Es difícil decir a los contribuyentes lo que deberían probar si no hay un conjunto de pruebas unificado que pueda decirles si su cambio tuvo el efecto deseado en el rendimiento. Queremos un conjunto de pruebas que pueda reportar una puntuación al final, y queremos que esta puntuación sea representativa de la dirección futura de WebKit.
Diseñar el nuevo JetStream Benchmark Suite
Los diferentes componentes de WebKit requieren diferentes enfoques para medir el rendimiento. Por ejemplo, para el rendimiento del DOM, acabamos de introducir el indicador de referencia del velocímetro. En algunos casos, el enfoque obvio funciona bastante bien: por ejemplo, muchas optimizaciones de diseño y renderizado se pueden controlar midiendo el tiempo de carga de páginas en páginas web representativas. Pero medir el rendimiento de una implementación de lenguaje de programación requiere más sutileza. Queremos aumentar la sensibilidad de los puntos de referencia a las mejoras principales del motor, pero no tanto como para perder la perspectiva de cómo se desarrollan esas mejoras del motor en sitios web reales. Queremos minimizar las oportunidades de que el ruido del sistema desvíe nuestras mediciones, pero siempre que una carga de trabajo sea inherentemente propensa al ruido, queremos un punto de referencia que lo muestre. Queremos que nuestros puntos de referencia representen una aproximación de alta fidelidad de las cargas de trabajo que es probable que les interesen a los usuarios de WebKit.
JetStream combina una variedad de puntos de referencia de JavaScript, que cubren una variedad de cargas de trabajo avanzadas y técnicas de programación, e informa de una sola puntuación que las equilibra utilizando una media geométrica. Cada prueba se realiza tres veces y las puntuaciones se informan con intervalos de confianza del 95%. Cada punto de referencia mide una carga de trabajo distinta, y ninguna técnica de optimización única es suficiente para acelerar todos los puntos de referencia. Algunos puntos de referencia demuestran compensaciones, y la optimización agresiva o especializada para un punto de referencia puede hacer que otro punto de referencia sea más lento. Demostrar las compensaciones recíprocas es crucial para nuestro trabajo. Como comenté en mi artículo anterior sobre nuestro nuevo compilador JIT, WebKit intenta adaptarse dinámicamente a la carga de trabajo utilizando diferentes niveles de ejecución. Pero esto nunca es perfecto. Por ejemplo, mientras que nuestro nuevo compilador JIT FTL nos da fantásticas aceleraciones en las pruebas de rendimiento máximo, causa ligeras regresiones en algunas pruebas de aceleración. Las nuevas optimizaciones para tiempos de ejecución de lenguaje avanzados a menudo se enfrentan a tales compensaciones, y nuestro objetivo con JetStream es tener un punto de referencia que nos informe sobre las compensaciones que estamos haciendo.
JetStream incluye puntos de referencia de las suites de puntos de referencia JavaScript de SunSpider 1.0.2 y Octane 2. También incluye puntos de referencia del proyecto de código abierto del compilador LLVM, compilado en JavaScript utilizando Emscripten 1.13. También incluye un punto de referencia basado en el HashMap del proyecto de código abierto Apache Harmony, traducido a mano a JavaScript. Más información sobre los puntos de referencia incluidos en JetStream está disponible en la página de JetStream en profundidad.
Estamos muy contentos de presentar este nuevo punto de referencia. Para ejecutarlo, simplemente visite browserbench.org/JetStream. Puede presentar errores contra el punto de referencia utilizando el sistema de gestión de errores de WebKit en el componente Herramientas/Pruebas.
