L’ampleur des gains de vitesse des terminaux de GNOME 46

 (bxt.rs)
3 points par GN⁺ 2024-04-09 | 1 commentaires | Partager sur WhatsApp
  • Pendant le cycle GNOME 46, la latence de saisie des terminaux basés sur VTE a fortement diminué, au point de presque rejoindre Alacritty, utilisé comme référence rapide dans les tests Fedora 40
  • La mesure repose sur une latence de bout en bout entre la frappe d’une touche et le changement de pixels à l’écran, relevée avec des capteurs matériels, ce qui inclut le noyau, le compositeur, l’application et le temps de réponse du moniteur
  • Sur une simple saisie cat > /dev/null comme sur un défilement neovim plus complexe, Console, VTE Test App et GNOME Terminal montrent tous une nette amélioration par rapport à GNOME 45
  • Le changement principal vient probablement du fait que VTE ne repose plus sur un timer de rafraîchissement à 40 Hz, mais redessine désormais à chaque frame synchronisée avec le moniteur
  • Avec VTE 0.76, les terminaux GNOME 46 offrent une latence perceptible plus faible, au point que les utilisateurs qui évitaient les terminaux basés sur VTE parce qu’ils les trouvaient lents peuvent raisonnablement les réessayer

Ce qui a changé dans les terminaux basés sur VTE

  • VTE est la bibliothèque Virtual TErminal qui sert de base à plusieurs émulateurs de terminal GNOME
  • Pendant le cycle GNOME 46, VTE a reçu de nombreuses améliorations de performance, et la latence de saisie réellement perçue par l’utilisateur est devenue un point de vérification majeur

Méthode de mesure de la latence de saisie

  • La latence de saisie est le temps écoulé entre l’instant où l’on appuie sur une touche du clavier et celui où la couleur d’un pixel change sur le moniteur
    • Plus la latence est faible, plus l’application donne l’impression de réagir immédiatement
    • La différence apparaît encore plus clairement quand on compare en alternance une faible latence et une latence élevée
  • La mesure n’utilise pas une capture d’écran logicielle, mais un testeur matériel de latence d’entrée
    • Un capteur optique est relié à une carte Teensy, elle-même connectée en USB à l’ordinateur
    • Le capteur observe une petite zone de l’écran, comme une cellule de caractère du terminal, dont la luminosité change après une frappe
    • La carte envoie une touche comme Space, détecte le changement de lumière, puis restaure l’état initial avec une seconde touche comme Backspace
    • Un temps d’attente aléatoire est ajouté entre les répétitions pour éviter que la mesure ne se verrouille sur la fréquence de rafraîchissement du moniteur
  • Cette méthode mesure une latence de bout en bout qui inclut le noyau, le compositeur, l’application et le temps de réponse du moniteur
    • La latence du firmware du clavier est exclue
    • Avec la carte et le firmware actuels, environ 35 500 valeurs du capteur optique sont enregistrées par seconde
  • Chaque test est répété 120 fois
    • On s’attend à voir une distribution des points à peu près uniforme sur une durée correspondant à un cycle de rafraîchissement du moniteur
    • Sur un écran 144 Hz, un cycle de rafraîchissement dure environ 6,94 ms, et dans les graphes d’exemple les points s’étalent sur une plage de 7 à 8 ms
    • Des valeurs aberrantes plus élevées ou une distribution plus large peuvent indiquer de la latence ou un traitement plus lent dans l’application testée

Environnement de test et éléments comparés

  • Le système de test est un portable Lenovo Legion 7 Gen 7 AMD
    • Le CPU est un Ryzen 7 6800H
    • Le GPU est un Radeon RX 6700M dédié, utilisé seul via un commutateur MUX
    • Le moniteur est un Acer Nitro XV320QU, 2560×1440, 144 Hz, avec une mise à l’échelle de 100 %
    • L’hôte est Fedora 40 Silverblue Beta, avec Mesa 24.0.4
    • Le compositeur est raw Mutter 46.0
  • raw Mutter désigne un environnement de test simplifié où seul Mutter est lancé, sans GNOME Shell
    • Il peut être lancé avec une commande comme mutter --display-server -- alacritty
    • Cela se rapproche de conditions idéales avec très peu de surcharge liée à GNOME Shell
  • Quatre terminaux sont comparés
    • Alacritty : non basé sur VTE, utilisé comme référence car il figure régulièrement parmi les terminaux les plus rapides dans les tests précédents
    • Console : terminal GNOME par défaut basé sur GTK 4
    • VTE Test App : terminal de test GTK 4 présent dans le dépôt VTE
    • GNOME Terminal : application GTK 3 dans GNOME 46, fournie par défaut dans plusieurs distributions
  • La comparaison entre GNOME 45 et GNOME 46 utilise des conteneurs toolbox Fedora 39 et Fedora 40
    • Chaque terminal est installé à partir des paquets Fedora tels quels, puis exécuté sans réglage supplémentaire
    • Les fenêtres sont placées en haut à gauche de l’écran, et le curseur de la souris reste hors de la fenêtre pour éviter que la logique de détection des liens ne perturbe les résultats

Résultats sur la saisie simple et le défilement dans neovim

  • Le premier test lance cat > /dev/null, puis mesure le temps nécessaire pour qu’un appui sur Space déplace le curseur bloc d’une case vers la droite
    • Il s’agit d’un cas à surcharge minimale, sans traitement supplémentaire comme readline
    • Alacritty ne montre, comme prévu, aucun changement notable entre Fedora 39 et Fedora 40
    • Les terminaux basés sur VTE progressent fortement dans GNOME 46 par rapport à GNOME 45 et atteignent presque le niveau d’Alacritty
    • Même GNOME Terminal, pourtant basé sur GTK 3, obtient un résultat très proche
  • La cause principale de cette forte amélioration est probablement la modification de VTE par Christian Hergert
    • Elle abandonne l’ancien timer de rafraîchissement VTE à 40 Hz
    • Et adopte, comme un widget GTK normal, un rendu à chaque frame synchronisé avec le moniteur
  • Console présente quelques valeurs aberrantes, probablement dues au traçage des processus
    • Ce phénomène n’est pas nouveau
    • Il reste à examiner dans GNOME 47
  • Le second test utilise une configuration neovim plus réaliste
    • Il ouvre le README de Ptyxis depuis un instantané de configuration neovim, en remplaçant une partie du texte par des caractères Unicode full-block pour que le capteur optique puisse les détecter
    • Ctrl+D et Ctrl+U sont répétés pour faire défiler le buffer de texte vers le bas puis vers le haut
    • Le terminal doit alors dessiner des éléments d’interface comme le soulignement, l’undercurl, les icônes de gutter et la barre d’état
  • Les améliorations des terminaux GNOME 46 restent très nettes aussi dans le test neovim
    • Les terminaux basés sur VTE de GNOME 46 restent globalement très proches d’Alacritty
    • Si l’on ne regarde que les résultats Fedora 40, le test neovim augmente la latence par rapport au simple test cat, mais la hausse est comparable sur tous les terminaux

Les écarts restants montrés par vtebench

  • vtebench est un benchmark automatisé qui mesure non pas la latence de saisie, mais les performances de lecture et de parsing PTY
    • Il ne couvre pas des éléments importants comme le framerate ou la latence, et ne suffit donc pas à lui seul pour comprendre l’ensemble des performances d’un terminal
    • Il pousse surtout très fort la vitesse à laquelle un terminal lit depuis le PTY
  • Le temps de repaint peut aussi influencer les résultats de vtebench
    • Cet effet peut être particulièrement marqué pour les terminaux qui, comme VTE, exécutent la lecture PTY, le parsing et la logique de repaint sur le même thread
  • VTE dans GNOME 46 progresse aussi dans vtebench
    • L’ampleur des gains est plus variable que dans les tests de latence de saisie
    • Il n’atteint toujours pas le niveau d’Alacritty, qui effectue la lecture et le parsing sur un thread distinct du rendu
    • Cette amélioration semble venir de plusieurs optimisations intégrées à VTE pendant le cycle GNOME 46
  • Les benchmarks dense_cells et unicode sont exclus du graphe de résultats principal
    • Ces deux cas font partie des tests de charge majeurs de vtebench
    • VTE y montre encore des variations importantes, ce qui nuit à la lisibilité du graphe
  • Dans les scénarios testés, les écarts restants sont presque négligeables
    • Une partie de ces différences peut s’expliquer par le travail supplémentaire effectué par VTE pour l’accessibilité, le calcul des barres de défilement et d’autres fonctionnalités
    • L’accessibilité est activée dans GNOME Terminal, mais actuellement désactivée dans les terminaux GTK 4
    • Utiliser VTE 0.76 permet de bénéficier des améliorations de performance de GNOME 46

À lire aussi

1 commentaires

 
GN⁺ 2024-04-09
Avis sur Hacker News

  • Grâce à ce changement, la latence médiane de saisie de la configuration testée est enfin passée sous celle de l’Apple //e. Console est autour de 12 ms, l’Apple //e de 1983 était à 30 ms : il aura donc fallu 41 ans
    https://www.extremetech.com/computing/261148-modern-computer...
    https://danluu.com/input-lag/
    Cela dit, ce benchmark n’utilisait pas GNOME Shell, mais raw Mutter 46.0, le compositeur ; raw Mutter est un environnement très basique, quasiment destiné aux tests. Il n’inclut pas non plus la latence du clavier, donc ce n’est pas une mesure de bout en bout. Dans ce test, une carte envoie les frappes en USB, mais la latence interne du clavier à elle seule peut monter jusqu’à 60 ms
    https://danluu.com/keyboard-latency/
    J’aimerais vraiment connaître les chiffres réels de bout en bout de la configuration par défaut, qui sont les plus importants ; c’est dommage que l’article ne les ait pas mesurés. Le travail de l’équipe GNOME et de l’auteur du benchmark est excellent, mais la question essentielle reste ouverte. L’Apple //e utilisait l’accélération matérielle et ne gérait pas Unicode, donc les différences sont nombreuses, mais ce serait quand même agréable de retrouver la réactivité humaine d’une machine de plus de 41 ans

    • Au contraire, je trouve que l’auteur a bien fait d’exclure la latence du clavier. Tout le monde utilise des claviers, interfaces USB, ordinateurs et versions de système d’exploitation différents, sans compter les hubs ou KVM qui peuvent s’intercaler
      Si la latence de ces composants varie fortement pendant le test, il devient difficile d’analyser l’amélioration de latence de VTE, qui est le cœur de cet article. Même si elle était parfaitement constante, elle ne ferait qu’ajouter une constante à la valeur absolue, sans changer la conclusion. C’est pourquoi il ne faut pas exprimer les écarts de latence en pourcentage. Dans l’échantillon, il existe une constante que l’on peut normaliser, mais dans l’ensemble des utilisateurs, il y a beaucoup de constantes qu’on ne peut pas normaliser. La partie sur Mutter est intéressante : comme GNOME repose sur Mutter, l’amélioration absolue de la latence a de bonnes chances d’être similaire. Cela dit, GNOME peut aussi introduire des variations indésirables, comme la latence du clavier, donc j’aimerais le vérifier en pratique
    • Dans ce cas, il suffit d’utiliser un Apple 2e et de renoncer aux fonctions pratiques des systèmes d’exploitation modernes. J’ai du mal à accepter cette manière de dénigrer longuement des développeurs open source qui s’efforcent de fournir gratuitement leur travail
    • Dans la méthodologie de l’article lié sur la latence des claviers, le fait d’inclure jusqu’au temps de déplacement physique de la touche m’a toujours un peu dérangé
    • Le traitement d’Unicode n’est pas un problème aussi difficile que les gens le croient. Il y a des cas limites bizarres, mais ils ne sont pas nombreux et ils se résolvent facilement
      Ce qui m’a vraiment gêné dans cet article, c’est que, dans Gnome avant la dernière version de test, la fréquence de rafraîchissement du rendu était fixée à 40 Hz. Qui a bien pu décider ça ?
    • L’affirmation des 60 ms dans l’article sur la latence des claviers me paraît suspecte. Si une latence de 60 ms entre la pression d’une touche et l’USB était courante sur les claviers, les jeux de rythme seraient littéralement injouables. Or je n’ai jamais rencontré ce problème avec aucun des claviers que j’ai utilisés

  • Bien. J’aime que les développeurs de VTE se soient concentrés sur les performances, et le processus de mesure matériel de l’article est impressionnant
    La méthode qui utilise un capteur optique pour mesurer la latence me rappelle le produit au nom très explicite de Ben Heck, “Xbox One Controller Monitor” [1]. Il lit directement l’état des boutons d’une manette de console de jeu et le combine à un capteur optique pour aider les développeurs de jeux à maintenir une faible latence. Ça a l’air génial, mais ça coûte 900 dollars
    [1]: https://www.benheck.com/xbox1monitor/

    • Le fait de commencer à se concentrer sur les performances est récent. VTE était à l’origine plutôt lent
    • Fait amusant : quand la synchronisation verticale est activée, la latence dépend de l’endroit où l’on place le capteur

  • Dans cet article comme dans celui qui est lié, le capteur optique est placé à peu près au milieu de l’écran. Ce n’est pas un problème pour comparer les mesures, mais sur beaucoup de moniteurs courants, à 60 Hz, placer le capteur en haut de l’écran donne une mesure environ 8 ms plus rapide, et le placer en bas une mesure environ 8 ms plus lente. C’est parce que les pixels ou les lignes sont pilotés de haut en bas, à peu près comme sur un CRT
    Donc si l’on entre dans les détails, il faudrait aussi mentionner ce point, au même titre que le seuil du signal du capteur optique à partir duquel on considère que le pixel s’est allumé. Vu les chiffres de l’article, 8 ms représente une différence assez importante. De même, dire simplement « le moniteur X est 30 ms plus lent que le moniteur Y » peut être exagéré. Il faut plutôt comprendre : « voilà ce qui a été mesuré avec ma configuration et les réglages X, Y, Z ». Il faut aussi vérifier si le moniteur n’applique pas des fonctions d’amélioration étranges qui ne font qu’ajouter de la latence sans effet perceptible, ou si, au changement de moniteur, la carte graphique ou le pilote n’a pas discrètement basculé vers un profil de correction, de mise à l’échelle ou d’amélioration en prétendant rendre service. Ces appareils ne préviennent généralement pas, et j’ai déjà vu plusieurs cas réels

    • Si je regarde un écran défiler en temps réel, j’ai bien plus de chances de regarder le tiers inférieur de l’écran

  • C’est amusant de vivre dans un monde capable de rendre des scènes 3D surréalistes et des jeux qui semblaient impossibles sur du matériel grand public, tout en continuant à se battre pour rendre parfaitement l’affichage de texte dans un terminal

    • Je me demande si cela ne vient pas en partie du fait qu’on a optimisé davantage pour le graphisme. Il y a un compromis entre les deux, et plus les graphismes s’améliorent, plus le texte peut avoir tendance à se dégrader. Les terminaux compensent en partie avec l’accélération GPU, mais ils paient quand même le coût de ce pipeline graphique
    • Peut-être aussi que ce n’était pas si important avant. C’était du genre « ça marche », et jusqu’à récemment, dans beaucoup de cas d’usage des terminaux, il y avait une latence réseau importante à gérer

  • Cela n’a rien à voir avec la vitesse, mais je me demande s’il existe sous Linux un terminal qui, comme le Terminal de Mac OSX, restaure tous les onglets, l’historique des commandes de chaque onglet et le scrollback quand on le ferme puis le rouvre. Côté Mac, c’est géré en définissant un fichier d’historique bash différent pour chaque onglet
    Pour cet usage, je préfère un terminal GUI

    • C’est un peu à part, mais je viens d’apprendre il y a une heure que iterm2 sur Mac peut s’intégrer à tmux. Si on lance tmux avec l’argument -CC, la session tmux est mappée sur les fenêtres et onglets GUI d’iterm2, et ça marche aussi en utilisant tmux sur une machine distante via ssh
      J’oublie tout le temps les raccourcis de contrôle et les commandes tmux, donc cette fonctionnalité me paraît assez prometteuse
      [1] https://iterm2.com/documentation-tmux-integration.html
    • Je me demande ce qui se passe si on ferme tous les onglets puis qu’on en ouvre un nouveau. L’historique par onglet est-il refusionné dans le fichier d’historique normal à la fermeture, de sorte que ces commandes soient utilisables dans le nouvel onglet ?
    • J’utilise Tmux. Comme c’est un multiplexeur indépendant du terminal, il apporte une persistance et des capacités d’automatisation puissantes
      https://github.com/tmux/tmux/wiki
    • Si tu préfères un terminal GUI, ça peut ne pas te plaire, mais ça peut être utile à quelqu’un : https://github.com/tmux-plugins/tmux-resurrect
      Bien sûr, tmux peut s’utiliser avec n’importe quel émulateur de terminal GUI de ton choix
    • Je cherchais exactement la même chose. Pour l’instant, j’utilise tmux et tmux-ressurect pour conserver l’état entre les redémarrages ; ça marche à peu près, mais ça reste un bon bidouillage, et ça donne toujours l’impression d’en être un
      Dommage qu’en dehors de warp, il y ait si peu de vraies solutions à ce problème. Mon petit rêve d’UX, ce serait que cette fonction de sauvegarde d’espace de travail soit intégrée à tout le système d’exploitation et aux applis qu’il contient. Ce serait chouette

  • Après avoir utilisé Gnome pendant des années, je suis passé à sway et alacritty il y a deux ans, et franchement je ne vois aucune différence. Comme avec du matériel audio haut de gamme, j’ai l’impression que mes oreilles et mes yeux ne sont pas réglés pour distinguer la différence

    • Tu as déjà essayé de revenir en arrière ? On remarque souvent mieux la latence quand elle augmente que quand elle diminue
    • J’utilise Gnome depuis des années et je suis maintenant sous Gnome 46, mais je n’ai pas senti de différence de latence dans le terminal par rapport à Gnome 45. Moi aussi, je ne suis sans doute pas très sensible à ce genre de choses
    • Ce n’est peut-être pas une comparaison équitable, mais il y a environ 20 ans, pendant que je compilais le noyau, gnome-terminal utilisait la moitié du CPU, et j’ai décidé de ne plus l’utiliser depuis. Xterm utilisait environ 2 %
    • En matière de latence ou de réactivité, la seule chose qui m’importe, c’est de savoir si le terminal me donne envie de vomir quand je fais défiler dans vim
    • Il se peut que l’écran ou le clavier ajoutent déjà assez de latence pour qu’aucun logiciel ne donne un bon résultat. La différence entre une mauvaise latence et une très mauvaise latence n’est pas si nette. Je me demande si tu as essayé du matériel de jeu

  • Enfin un benchmark de terminal qui ne consiste pas seulement à faire cat sur un énorme fichier. J’aimerais voir davantage de terminaux soumis au même test, en particulier la console Linux de base

  • Hors sujet, mais ce que je déteste le plus dans Gnome Terminal, c’est qu’il ouvre par défaut une petite fenêtre. Elle fait environ 1/4 de mon écran, et même si je la redimensionne, il ne s’en souvient pas après redémarrage. Au final, il faut aller dans les paramètres et définir soi-même le nombre de colonnes et de lignes

    • Ce comportement est assez courant dans beaucoup de terminaux. Rien que ceux qui me viennent à l’esprit, le Terminal macOS par défaut et Windows Terminal exigent tous deux de modifier la taille par défaut dans les paramètres
      Personnellement, je préfère garder une taille par défaut et ne redimensionner que les fenêtres spécifiques qui ont besoin de plus d’espace. Mais il devrait au moins y avoir une option pour mémoriser le redimensionnement
    • Ça se change dans les paramètres
      Menu hamburger > Preferences > puis le nom du profil. Mon profil s’appelle simplement “Unnamed”. Change “initial terminal size” et tu obtiendras ce que tu veux. Je l’ai réglé sur 132x43
    • J’ai souvent plusieurs terminaux ouverts, de tailles différentes. Il n’est pas évident de savoir quelle taille il faudrait mémoriser
      Donc je préférerais qu’il n’essaie pas. Quand un logiciel peut être sûr de ce que je veux, c’est bien qu’il soit intelligent ; sinon, ça devient encore un cas de “j’ai automatiquement tout cassé pour vous, vous me remerciez ?”
    • Le terminal gnome plus récent, Console, mémorise la taille des fenêtres
    • De mémoire, c’était une fonctionnalité venue de CMD.EXE

  • Quand il sera public, j’aimerais que le terminal Ghostty de Mitchell Hashimoto soit aussi inclus dans les benchmarks. Il est encore en phase de développement et de finition, et en bêta privée
    https://mitchellh.com/ghostty

  • Sous debian, j’utilise xterm et i3wn, et je n’ai jamais connu plus rapide. Je n’ai jamais envisagé de gaspiller le GPU pour un terminal, donc alacritty me paraît personnellement excessif

    • J’ai un ressenti similaire. Quand j’utilise xterm, je ne pense jamais à la latence. Même en utilisant tous les jours des fonctions lourdes comme la traduction ou sixel. J’ai l’impression que les gens l’ignorent à cause du style des widgets Athena, mais en réalité il est excellent