Cuánto mejoró la velocidad de las terminales de GNOME 46

 (bxt.rs)
3 puntos por GN⁺ 2024-04-09 | 1 comentarios | Compartir por WhatsApp
  • Durante el ciclo de GNOME 46, la latencia de entrada de las terminales basadas en VTE se redujo notablemente, hasta quedar muy cerca de Alacritty, que se usó como línea base rápida en pruebas con Fedora 40
  • La medición se hizo con un sensor de hardware para registrar la latencia de entrada de extremo a extremo desde la pulsación de una tecla hasta el cambio de píxel en pantalla, por lo que incluye tiempos de respuesta del kernel, compositor, app y monitor
  • Tanto en la entrada simple con cat > /dev/null como en el scroll en neovim más complejo, Console, VTE Test App y GNOME Terminal muestran una mejora clara frente a GNOME 45
  • El cambio clave probablemente sea que VTE dejó atrás el temporizador de repintado a 40 Hz y pasó a redibujar en cada cuadro sincronizado con el monitor
  • Las terminales de GNOME 46 que usan VTE 0.76 reducen la latencia perceptible, así que incluso quienes evitaban las terminales basadas en VTE por sentirse lentas podrían volver a probarlas

Cambios en las terminales basadas en VTE

  • VTE es la biblioteca Virtual TErminal que sirve de base para varios emuladores de terminal de GNOME
  • Durante el ciclo de GNOME 46, VTE recibió muchas mejoras de rendimiento, y uno de los principales puntos a verificar fue la latencia de entrada real que percibe el usuario

Cómo se midió la latencia de entrada

  • La latencia de entrada es el tiempo desde que se presiona una tecla en el teclado hasta que cambia el color de un píxel en el monitor
    • Cuanto menor es la latencia, más inmediata se siente la respuesta de la app
    • La diferencia se nota mejor al comparar alternadamente entre latencia baja y alta
  • Para medirla no se usó captura de pantalla por software, sino un tester de latencia de entrada por hardware
    • Se conectó un sensor de luz a una placa Teensy, y la placa se conectó a la computadora por USB
    • El sensor observa una pequeña zona de la pantalla, como una celda de caracteres específica en la terminal, cuyo brillo cambia con una pulsación de tecla
    • La placa envía una tecla como Space, detecta el cambio de luz y luego vuelve al estado original con una segunda tecla, como Backspace
    • Entre repeticiones se agrega una espera aleatoria para evitar que las mediciones queden fijadas a la tasa de refresco del monitor
  • Este método mide la latencia de extremo a extremo, incluyendo los tiempos del kernel, compositor, aplicación y respuesta del monitor
    • No incluye la latencia del firmware del teclado
    • Con la placa y el firmware actuales se registran unas 35,500 lecturas del sensor de luz por segundo
  • Cada prueba se repitió 120 veces
    • Se espera una distribución de puntos aproximadamente uniforme a lo largo de un ciclo de refresco del monitor
    • En un monitor de 144 Hz, un ciclo de refresco dura unos 6.94 ms, y en los gráficos de ejemplo los puntos se distribuyen en un rango de 7–8 ms
    • Valores atípicos altos o una distribución más amplia pueden indicar latencia o procesamiento lento en la app evaluada

Entorno de prueba y comparación

  • El sistema de prueba fue una laptop Lenovo Legion 7 Gen 7 AMD
    • CPU Ryzen 7 6800H
    • GPU Radeon RX 6700M dGPU, usando solo la dGPU mediante un switch MUX
    • Monitor Acer Nitro XV320QU, 2560×1440, 144 Hz, escala al 100 %
    • Host con Fedora 40 Silverblue Beta, Mesa 24.0.4
    • El compositor fue raw Mutter 46.0
  • raw Mutter es un entorno de prueba simple que ejecuta solo Mutter, sin GNOME Shell
    • Puede iniciarse con comandos como mutter --display-server -- alacritty
    • Se acerca a una condición ideal con casi nada de sobrecarga de GNOME Shell
  • Se compararon cuatro terminales
    • Alacritty: no está basada en VTE y en pruebas anteriores fue consistentemente una terminal rápida, así que sirve como línea base
    • Console: terminal predeterminada de GNOME basada en GTK 4
    • VTE Test App: terminal de prueba GTK 4 incluida en el repositorio de VTE
    • GNOME Terminal: en GNOME 46 sigue siendo una app GTK 3 y viene por defecto en varias distribuciones
  • Para comparar GNOME 45 y GNOME 46 se usaron contenedores toolbox de Fedora 39 y Fedora 40
    • Cada terminal se instaló tal cual desde los paquetes de Fedora y se ejecutó sin ajustes adicionales
    • La ventana se colocó en la esquina superior izquierda del monitor, y el cursor del mouse se dejó fuera de la ventana para que la lógica de detección de enlaces no alterara los resultados

Resultados con entrada simple y scroll en neovim

  • La primera prueba ejecutó cat > /dev/null y luego midió cuánto tarda en moverse una celda a la derecha el cursor de bloque al presionar Space
    • Es una situación de sobrecarga mínima, sin procesamiento adicional como readline
    • Como era de esperarse, Alacritty no muestra cambios entre Fedora 39 y Fedora 40
    • Las terminales basadas en VTE mejoran mucho en GNOME 46 frente a GNOME 45 y llegan a un nivel muy cercano al de Alacritty
    • GNOME Terminal, a pesar de estar basada en GTK 3, también muestra resultados muy cercanos
  • La principal causa de esta gran mejora probablemente sea un cambio en VTE realizado por Christian Hergert
    • Abandona el antiguo temporizador de repintado de VTE a 40 Hz
    • Pasa a dibujar en cada cuadro sincronizado con el monitor, como corresponde a un widget de GTK
  • En Console aparecieron algunos valores atípicos, posiblemente por el rastreo de procesos
    • No es un fenómeno nuevo
    • Queda como un punto a revisar en GNOME 47
  • La segunda prueba usó una configuración de neovim más realista
    • Se abrió el README de Ptyxis desde un snapshot de configuración de neovim, y parte del texto se reemplazó por caracteres Unicode de bloque sólido para que el sensor de luz pudiera detectarlo
    • Se repitieron Ctrl+D y Ctrl+U para desplazar el búfer de texto hacia abajo y hacia arriba
    • La terminal debe dibujar elementos de pantalla como subrayado, undercurl, íconos del gutter y barra de estado
  • En la prueba con neovim también se ve claramente la mejora de las terminales de GNOME 46
    • Las terminales basadas en VTE de GNOME 46 siguen quedando muy cerca de Alacritty
    • Si se miran solo los resultados de Fedora 40, la prueba con neovim aumenta la latencia frente a la prueba simple con cat, pero el incremento es parecido en todas las terminales

Las otras diferencias que mostró vtebench

  • vtebench es un benchmark automático que no mide latencia de entrada, sino rendimiento de lectura y parseo de PTY
    • No cubre factores importantes como frame rate o latencia, así que no basta para entender por completo el rendimiento de una terminal
    • Presiona fuertemente solo la velocidad con la que la terminal lee desde la PTY
  • El tiempo de repintado también puede afectar los resultados de vtebench
    • Esto puede influir especialmente en terminales como VTE, donde la lectura y el parseo de PTY comparten hilo con la lógica de repintado
  • VTE en GNOME 46 también mejora en vtebench
    • El tamaño de la mejora es más variable que en las pruebas de latencia de entrada
    • Aun así, no alcanza el nivel de Alacritty, que realiza lectura y parseo en un hilo separado del renderizado
    • Esta mejora parece venir de varias optimizaciones incorporadas a VTE durante el ciclo de GNOME 46
  • Los benchmarks dense_cells y unicode se excluyeron del gráfico principal de resultados
    • Son dos de las principales pruebas de estrés de vtebench
    • VTE todavía muestra resultados muy inestables ahí, lo que dificulta la legibilidad del gráfico
  • Según estos casos de prueba, la diferencia restante ya está cerca de ser prácticamente irrelevante
    • Parte de esa diferencia podría explicarse porque VTE hace trabajo adicional para accesibilidad, cálculo de barras de desplazamiento y otras funciones
    • La accesibilidad está activada en GNOME Terminal, pero actualmente desactivada en las terminales GTK 4
    • Al usar VTE 0.76 se obtiene el rendimiento que incluye las mejoras de GNOME 46

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-04-09
Opiniones de Hacker News

  • Gracias a este cambio, la mediana de latencia de entrada en la configuración probada por fin quedó por debajo de la de la Apple //e. Console ronda los 12 ms; la Apple //e de 1983 tenía 30 ms, así que tomó 41 años.
    https://www.extremetech.com/computing/261148-modern-computer...
    https://danluu.com/input-lag/
    Eso sí, este benchmark no usó GNOME Shell, sino raw Mutter 46.0, que es el compositor; raw Mutter es un entorno muy básico, más cercano a algo para pruebas. Además, no incluye la latencia del teclado, así que tampoco es una medición de extremo a extremo. En esta prueba, la placa envía las pulsaciones por USB, pero solo la latencia interna del teclado puede llegar hasta 60 ms.
    https://danluu.com/keyboard-latency/
    Me da curiosidad conocer las cifras reales de extremo a extremo en la configuración predeterminada que de verdad importa; habría sido bueno que el artículo las midiera. El trabajo del equipo de GNOME y del autor del benchmark es excelente, pero la pregunta importante sigue abierta. La Apple //e usaba aceleración por hardware y tampoco manejaba Unicode, así que hay muchas diferencias, pero aun así estaría bien poder volver a la capacidad de respuesta humana de una máquina de hace más de 41 años.

    • Más bien creo que el autor hizo bien en excluir la latencia del teclado. Cada persona usa teclados, interfaces USB, computadoras y versiones de sistema operativo distintos, y también pueden meterse hubs o KVM.
      Si la latencia de esos componentes fluctúa mucho durante la prueba, se vuelve difícil analizar la mejora de latencia de VTE, que es el punto central del artículo. Incluso si fuera completamente constante, solo se sumaría como una constante al valor absoluto, así que la conclusión no cambiaría. Por eso no hay que expresar las diferencias de latencia como porcentajes. En el conjunto de muestras hay una constante que se puede normalizar, pero en toda la población de usuarios hay muchas constantes que no se pueden normalizar. La parte de Mutter es interesante: como GNOME corre sobre Mutter, parece probable que la mejora absoluta de latencia se manifieste de forma similar. Aun así, GNOME también puede introducir variaciones no deseadas, como la latencia del teclado, y me gustaría comprobarlo en la práctica.
    • Entonces basta con usar una Apple 2e y renunciar a las comodidades de los sistemas operativos modernos. Me cuesta aceptar una crítica tan larga a desarrolladores open source que se esfuerzan por ofrecer esto gratis.
    • Siempre me ha molestado un poco que la metodología del artículo enlazado sobre latencia de teclados incluya incluso el tiempo que tarda la tecla en moverse físicamente.
    • El procesamiento de Unicode no es un problema tan difícil como la gente cree. Hay casos límite donde se pone raro, pero no son muchos y son fáciles de resolver.
      Lo que de verdad me molestó de este artículo fue que, antes de la versión de prueba más reciente, en Gnome la velocidad de redibujado estaba fija en 40 Hz. ¿A quién se le ocurrió decidir eso?
    • La afirmación de 60 ms en el artículo sobre latencia de teclados me parece sospechosa. Si la latencia desde la pulsación hasta USB fuera comúnmente de 60 ms en los teclados, los juegos de ritmo serían literalmente injugables. Pero nunca tuve ese problema con ningún teclado que haya usado.

  • Bien. Me gusta que los desarrolladores de VTE se hayan enfocado en el rendimiento, y también me impresionó el proceso de medición basado en hardware del artículo.
    La forma de medir la latencia con un sensor óptico me recuerda al producto de Ben Heck, con nombre bastante explícito, “Xbox One Controller Monitor” [1]. Lee directamente el estado de los botones de un control de consola y lo combina con un sensor óptico para ayudar a los desarrolladores de juegos a mantener baja la latencia. Se ve genial, pero cuesta 900 dólares.
    [1]: https://www.benheck.com/xbox1monitor/

    • Que empezaran a enfocarse en el rendimiento es algo reciente. VTE antes era bastante lento.
    • Dato curioso: si la sincronización vertical está activada, la latencia depende de dónde coloques el sensor.

  • Tanto este artículo como el artículo enlazado colocan el sensor óptico más o menos a la mitad del monitor. No hay problema para comparar mediciones, pero en muchos monitores comunes, a 60 Hz, si pones el sensor en la parte superior de la pantalla medirá unos 8 ms más rápido, y si lo pones en la parte inferior, unos 8 ms más lento. Esto se debe a que los píxeles o las líneas se activan de arriba hacia abajo, básicamente como en un CRT.
    Así que, si entramos en detalle, esto también debería mencionarse, igual que dónde poner el umbral de la señal del sensor óptico para decidir que un píxel se encendió. Viendo las cifras del artículo, 8 ms es una diferencia bastante grande. Del mismo modo, decir simplemente “el monitor X es 30 ms más lento que el monitor Y” también puede ser una exageración. Hay que entenderlo como “esto fue lo que medí con mi configuración y ajustes X, Y, Z”. También habría que verificar si el monitor aplica funciones raras de mejora que solo agregan latencia sin un efecto perceptible, o si al cambiar de monitor la tarjeta gráfica o el driver, haciéndose los amables, cambian a escondidas perfiles de corrección, escalado o mejora. Estos dispositivos normalmente no avisan nada, y he visto varios casos reales.

    • Si estoy viendo la pantalla desplazarse en tiempo real, es mucho más probable que mire el tercio inferior de la pantalla.

  • Es gracioso vivir en un mundo donde renderizamos escenas 3D ultrarrealistas y juegos que parecían imposibles en hardware de consumo, y al mismo tiempo seguimos intentando perfeccionar algo tan básico como imprimir texto en una terminal.

    • Sospecho que parte de esto se debe a que se optimizó más para gráficos. Hay un compromiso entre ambas cosas, y cuanto mejores se vuelven los gráficos, puede que el texto tienda a empeorar. La terminal usa aceleración por GPU y eso compensa en parte, pero aun así se paga el costo de esa pipeline gráfica.
    • Quizás antes tampoco importaba tanto. Era más bien “funciona”, y hasta hace poco, en muchos usos de terminal había una latencia de red grande que resolver.

  • No tiene que ver con la velocidad, pero me da curiosidad si en Linux existe una terminal que, como Terminal de Mac OSX, al cerrarla y volver a abrirla restaure todas las pestañas, el historial de comandos de cada pestaña y el scrollback. En Mac lo manejan configurando un archivo de historial de bash distinto para cada pestaña.
    Para este uso prefiero una terminal con GUI

    • Es un tema algo distinto, pero justo hace 1 hora me enteré de que iTerm2 en Mac puede integrarse con tmux. Si ejecutas tmux con el argumento -CC, la sesión de tmux se mapea a las ventanas y pestañas GUI de iTerm2, y también funciona usando tmux en una máquina remota vía ssh.
      Siempre se me olvidan los atajos de control y comandos de tmux, así que esta función me entusiasma bastante.
      [1] https://iterm2.com/documentation-tmux-integration.html
    • Me pregunto qué pasa si cierras todas las pestañas y luego abres una nueva. ¿El historial por pestaña se vuelve a combinar en el archivo de historial normal al cerrar, para que esos comandos también estén disponibles en la nueva pestaña?
    • Yo uso Tmux. Como es un multiplexor independiente de la terminal, su persistencia y capacidad de automatización se vuelven muy potentes.
      https://github.com/tmux/tmux/wiki
    • Si prefieres una terminal con GUI quizá no te guste, pero a alguien le puede servir: https://github.com/tmux-plugins/tmux-resurrect
      Por supuesto, tmux se puede usar con cualquier emulador de terminal GUI que quieras.
    • Estaba buscando exactamente lo mismo. Ahora uso tmux y tmux-ressurect para mantener el estado entre reinicios; funciona más o menos, pero no deja de ser un buen hack y todavía se siente como un hack.
      Es una lástima que, salvo warp, casi no haya soluciones reales para este problema. Mi pequeño sueño de UX es que esta función de guardar espacios de trabajo se integre en todo el sistema operativo y en las apps dentro de él. Sería genial.

  • Usé Gnome durante varios años y hace 2 años cambié a sway y alacritty, y sinceramente no noto ninguna diferencia. Como con el equipo de audio de gama alta, parece que mis oídos y ojos no están afinados para distinguir esa diferencia.

    • ¿Has intentado volver? Muchas veces se nota más cuando la latencia aumenta que cuando disminuye.
    • He usado Gnome durante años y ahora estoy en Gnome 46, pero no noté diferencia de latencia en la terminal respecto a Gnome 45. Creo que yo tampoco soy muy sensible a estas cosas.
    • Quizá no sea una comparación justa, pero hace unos 20 años, mientras compilaba el kernel, gnome-terminal usaba la mitad de la CPU, así que desde entonces decidí no usarlo. Xterm usaba alrededor del 2%.
    • En cuanto a latencia o capacidad de respuesta, lo único que me importa es si la terminal me hace sentir ganas de vomitar al hacer scroll en vim.
    • Puede que la pantalla o el teclado ya estén agregando suficiente latencia como para que ningún software dé buenos resultados. La diferencia entre una latencia mala y una muy mala no es tan clara. Me pregunto si has probado hardware gamer.

  • Por fin aparece un benchmark de terminales que no consiste solo en hacer cat de un archivo enorme. Me gustaría ver más terminales con las mismas pruebas, en especial la consola básica de Linux.

  • Fuera de tema, pero lo que más odio de Gnome Terminal es que por defecto abre una ventana pequeña. Es como 1/4 de mi pantalla, y aunque cambie el tamaño no lo recuerda después de reiniciar. Al final hay que entrar a la configuración y especificar manualmente el número de columnas y filas.

    • Ese comportamiento es bastante común en muchas terminales. Solo por mencionar las que me vienen a la mente, tanto la Terminal predeterminada de macOS como Windows Terminal requieren cambiar el tamaño predeterminado desde la configuración.
      Personalmente prefiero dejar el tamaño por defecto y redimensionar solo las ventanas específicas que necesitan más espacio. Aun así, al menos debería existir una opción para recordar el tamaño redimensionado.
    • Se puede cambiar en la configuración.
      Ve al menú hamburguesa > Preferences > nombre del perfil. Mi perfil simplemente se llama “Unnamed”. Cambia “initial terminal size” y quedará como quieres. Yo lo tengo en 132x43.
    • A menudo tengo abiertas varias terminales de tamaños distintos. No está claro qué tamaño sería el correcto recordar.
      Por eso preferiría que no intentara hacerlo. Está bien que el software sea inteligente cuando puede estar seguro de lo que quiero, pero si no, se convierte en otro caso de “Lo arruiné automáticamente por usted. ¿Verdad que agradece?”
    • La terminal más nueva de gnome, Console, sí recuerda el tamaño de la ventana.
    • Según recuerdo, esta era una función que venía de CMD.EXE.

  • Cuando se haga pública, me gustaría que la terminal Ghostty de Mitchell Hashimoto también se incluya en los benchmarks. Por ahora sigue en desarrollo y pulido, y está en beta privada.
    https://mitchellh.com/ghostty

  • En debian uso xterm e i3wn y nunca he experimentado algo más rápido que eso. Ni siquiera se me había ocurrido desperdiciar GPU en una terminal, así que personalmente me parece que alacritty es excesivo.

    • A mí me pasa algo parecido. Nunca he pensado en la latencia al usar xterm. Incluso uso a diario funciones pesadas como traducción o sixel, y aun así. Creo que la gente lo ignora por el estilo de widgets Athena, pero en realidad es excelente.