Entrando a la era Quantum — Cómo Firefox volvió a ser rápido de nuevo y como se hará aún más

15 abril, 2019 21:49 por

Esta es una traducción del artículo original publicado en el blog de Mozilla Hacks.

Durante un período de 7 meses, hemos estado remplazando partes importantes del motor, como la introducción de Rust y partes de Servo a Firefox. Ademas, hemos atacado al rendimiento del navegador mejorando problemas de rendimiento, tanto obvios como no obvias.

Hemos llamado este proceso como Proyecto Quantum, y ya lo hemos liberado en el Firefox estable.

Pero esto no significa que nuestro trabajo está hecho. Tampoco significa que el Firefox actual es tan rápido y eficiente como lo será.

Así que observemos como Firefox se volvió rápido y como será aún mas rápido.

Sentando las bases del paralelismo granular

Para volverse rápido, tuvimos que tomar ventaja de como el hardware ha cambiado en los últimos 10 años.

No somos los primeros en hacer esto. Chrome era mas rápido y brindaba mejores tiempo de respuesta que Firefox cuando se introdujo. Una de las razones era que los ingenieros vieron el cambio que se venía en el hardware y empezaron a hacer mejor uso del nuevo hardware.

Un nuevo estilo de CPU se estaba volviendo popular. Estos CPUs tenían múltiples núcleos que permitían hacer tareas independientes entre cada uno de ellos, pero al mismo tiempo – en paralelo.

Esto puede ser un poco difícil. Con paralelismo, puedes introducir bugs sutiles que son difíciles de ver y depurar. Por ejemplo, si dos núcleos necesitan agregar un 1 al mismo número en memoria, probablemente uno de ellos sobrescriba al otro si no tomas cuidado especial.

Una manera sencilla de evitar este tipo de bugs es asegurándose que las 2 cosas que están trabajando no compartan memoria. Dividir tu programa en tareas grande no coopera mucho. Esto es lo que se le conoce como paralelismo granular.

En el navegador es fácil encontrar estos granos. Tener cada pestaña en su propio pedazo de trabajo. Ademas hay cosas alrededor de esta página, el navegador Chrome puede manejar esas cosas de forma separada.

De esta manera,  las páginas pueden trabajar a su propia velocidad, simultáneamente, sin bloquear uno al otro. Si tienes un script corriendo por mucho tiempo en una pestaña de fondo, no bloqueará el trabajo en la pestaña principal.

Esta es la oportunidad que los ingenieros de Chrome vieron. Nosotros lo vimos pero teníamos un camino difícil para llegar allí. Pues al tener código existente, necesitábamos un plan para dividir ese código y tomar ventaja de los múltiples núcleos.

Tomó un tiempo llegar ahí. Con el proyecto Electrolysis, finalmente hicimos llegar el multi-proceso por defecto a todos los usuarios. Y Quantum ha estado utilizando el paralelismo granular a través de otros proyectos.

Electrolysis

Electrolysis sentó las bases para el Proyecto Quantum. Introdujo un tipo de arquitectura multi-proceso similar a la que Chrome introdujo.Debido a que era un gran cambio, tuvimos que introducirlo poco a poco, probando con un pequeño grupo de usuarios al inicio de 2016 hasta desplegarlo a todos los usuarios de Firefox a medidados del 2017.

Quantum Compositor

El Compositor de Quantum se movió a su propio proceso. El gran ganador es que hizo a Firefox mas estable. Teniendo un proceso separado significa que si el controlador de vídeo se cuelga, no colgará todo Firefox. Pero al tenerlo como un proceso separado hará Firefox mas responsivo.

Quantum DOM

Inclusive si separas el contenido de las ventanas entre los núcleos y tienen un hilo principal para cada uno, existirán muchas tareas que el hilo principal necesita realizar. Y muchas de ellas son mas importantes queotras. Por ejemplo, responder a una presión de una tecla es mas importante que ejecutar el recolector de basura. Quantum DOM nos da una forma de priorizar estas tareas. Esto hace a Firefox mas responsivo. La mayoría de este trabajo a llegado, pero planeamos llevar esto mas allá con algo llamado programación preemptiva.

Haciendo mejor uso del hardware con paralelismo granulado

Cuando miramos al futuro, necesitábamos ir mas allá del paralelismo granulado.

El paralelismo granulado hace uso del hardware.. pero no hace su mejor uso posible. Cuando divides estas páginas a través de diferentes núcleos, alguno de ellos no tienen trabajo por realizar. Así que los núcleos estarán sin hacer nada. Al mismo tiempo, una nueva página puede estar siendo lanzada para que un nuevo núcleo lo tome como si fuese un CPU de un único núcleo.

Sería grandioso poder usar todos esos núcleos para procesar la nueva página mientras se está cargando. De esa manera hacer el trabajo mas rápido.

Pero con paralelismo, no puedes dividir el trabajo de un núcleo a otro. No hay límites entre los trabajos.

Además con paralelismo granular, tu puedes dividir tareas grandes en unidades mas pequeñas que pueden ser enviadas a diferentes núcleos. Por ejemplo, si tienes algo como el sitio web de  Pinterest, puedes dividir cada uno de los elementos y sean procesados por diferentes núcleos.

Esto no solo ayuda con el paralelismo, sino también a mejorar la velocidad. La página carga mas rápido porque el trabajo es dividido a través de todos los núcleos. Mientras agregas mas núcleos, tu página cargará mas rápido. Vimos que éste es el futuro, pero no estaba claro como lelgar allí. Porque hacer rápido estos granos paralelos, necesitas compartir memoria entre los núcleos. Pero esto ocasiona esas carreras de datos que se mencionaron anteriormente.

Sabíamos que el navegador tenía que hacer un cambio, por eso invertimos en investigación. Creamos un lenguaje que fuese libre de estas carreras de datos – Rust. Entonces creamos un nuevo motor de navegador llamado Servo, que permitió usar este grado de paralelismo. Así pudimos probar que podría funcionar y tener menos bugs  mientras íbamos rápido.

Velocidad de Firefox

Quantum CSS (también llamado Stylo)

Quantum CSS

Con Stylo, el trabajo computacional de los estilos CSS es paralelizado en todos los núcleos del CPU. Stylo utiliza una técnica llamada robo de trabajo para dividir eficientemente  el trabajo entre los núcleos para que todos estén ocupados. Con esto, obtienes mayor velocidad lineal, puedes dividir el tiempo que toma hacer un cómputo de CSS entre todos los núcleos que posees.

Quantum Render (también llamado WebRender)

Otra parte del hardware que también es paralelizado es el GPU. Tiene cientos o miles de núcleos. Debes hacer mucha planificación para asegurarte que estos núcleos este lo mas ocupados posibles. Es lo que WebRender hace.

WebRender llegó en 2018, y toma ventaja de los GPUs modernos. Sin embargo, también hemos atacado este problema desde otro ángulo. El proyecto de Capas Avanzadas modifica las capas existentes de Firefox para soportar renderizado por lotes. Nos da una ganancia al optimizar el consumo actual de patrones de la GPU de Firefox.

???

Pensamos en otras partes del proceso de renderizado pueden beneficiarse de este paralelismo. En los próximos meses veremos como podemos usar estas técnicas.

Asegurándonos que seguiremos siendo rápidos y mas nunca lentos

Detrás de estos cambios de arquitectura que sabíamos que debíamos hacer, un número de problemas de rendimiento se encontraron en el código a pesar de no estar búscandolos.

Así que hicimos otra parte de Quantum para arreglarlo… básicamente fue un batallón de rendimiento del navegador que encontraba estos problemas y mobilizar equipos para repararlos.

Quantum Flow

El equipo de Quantum Flow fue este batallón. En vez de enfocarnos en todo el rendimiento general de un subsistema particular, se enfocaron en casos específicos — como leer la cronología de tus redes sociales— y trabajar entre varios equipos para ver porque Firefox era mas lento que otros navegadores.

Quantum Flow nos brindó grandes ganancias en el área de rendimiento. A lo largo del camino, hemos desarrollado herramientas y procesos para facilitar encontrar este tipo de problemas.

Así que, ¿qué pasará ahora con Quantum Flow?

Estamos tomando este proceso con emoción – identificando y enfocándonos en un caso a la vez — y transformándolo en parte de nuestro flujo. Para hacerlo, estamos mejorando nuestras herramientas para no necesitar un batallón de expertos para buscar problemas, sino mas bien potenciar los ingenieros de la organización a encontrarlos.

Pero existe un problema con esta metodología. Cuando optimizamos un caso, podríamos des-optimizar otro. Para prevenirlo, estamos añadiendo nuevos monitoreos, incluyendo mejoras a la automatización de  CI para ejecutar pruebas de rendimiento, telemetría para chequear la experiencia de usuario y manejo de regresiones. Con esto, esperamos que  Firefox Quantum siga mejorando.

¡Apenas solo es el comienzo!

Hemos trabajado fuertemente el año pasado para hacer Firefox rápido. Pero solo es el inicio.

Estaremos brindando nuevas mejoras de rendimiento a través del próximo año. Buscaremos compartirlas contigo!

Intenta Firefox Quantum Developer Edition para asegurarte de tener las últimas mejoras.

The following two tabs change content below.
Colaborador de Mozilla Venezuela e Hispano en las áreas de desarrollo y medios sociales, entre otros. También soy desarrollador Web, Skateboarder, Profesor universitario, jugador de Playstation y PC, usuario Linux, Blogger, Geek, entre otros.

Compartir artículo:

Empezar la discusión en foro.mozilla-hispano.org

cc-by-sa