Wie stark GNOME-46-Terminals schneller geworden sind

 (bxt.rs)
3 Punkte von GN⁺ 2024-04-09 | 1 Kommentare | Auf WhatsApp teilen
  • Im GNOME-46-Zyklus wurde die Eingabelatenz von VTE-basierten Terminals deutlich reduziert; in Fedora-40-Tests kommen sie Alacritty, das als schnelle Referenz diente, fast gleich
  • Gemessen wurde die End-to-End-Eingabelatenz vom Tastendruck bis zur Pixeländerung auf dem Bildschirm mit Hardware-Sensoren, sodass Kernel-, Compositor-, App- und Monitor-Reaktionszeiten gemeinsam einfließen
  • Sowohl bei einfacher Eingabe mit cat > /dev/null als auch beim komplexeren Scrollen in neovim verbesserten sich Console, VTE Test App und GNOME Terminal gegenüber GNOME 45 deutlich
  • Die wichtigste Änderung dürfte sein, dass VTE statt des bisherigen 40-Hz-Repaint-Timers nun bei jedem mit dem Monitor synchronisierten Frame neu zeichnet
  • Terminals mit VTE 0.76 unter GNOME 46 fühlen sich weniger verzögert an; Nutzer, die VTE-basierte Terminals wegen ihrer Trägheit gemieden haben, können ihnen wieder eine Chance geben

Was sich bei VTE-basierten Terminals geändert hat

  • VTE ist die Virtual TErminal Library, auf der mehrere GNOME-Terminal-Emulatoren basieren
  • Während des GNOME-46-Zyklus flossen viele Performance-Verbesserungen in VTE ein; ein wichtiger Prüfpunkt war die von Nutzern tatsächlich wahrgenommene Eingabelatenz

Messmethode für Eingabelatenz

  • Eingabelatenz ist die Zeit vom Drücken einer Taste auf der Tastatur bis zu dem Moment, in dem sich die Farbe eines Monitorpixels ändert
    • Je niedriger die Latenz, desto unmittelbarer fühlt sich die App an
    • Der Unterschied fällt deutlicher auf, wenn man niedrige und hohe Latenz im Wechsel vergleicht
  • Für die Messung wurde kein Software-Screen-Capture, sondern ein Hardware-Tester für Eingabelatenz verwendet
    • Ein Lichtsensor ist mit einem Teensy-Board verbunden, das wiederum per USB am Computer hängt
    • Der Sensor blickt auf einen kleinen Bildschirmbereich, dessen Helligkeit sich durch eine Tasteneingabe ändert, etwa eine bestimmte Zeichenzelle im Terminal
    • Das Board sendet einen Tastendruck wie Space, erkennt die Änderung der Lichtmenge und setzt den Zustand anschließend mit einer zweiten Taste wie Backspace zurück
    • Zwischen Wiederholungen wird eine zufällige Wartezeit eingefügt, um zu vermeiden, dass sich die Messung auf die Bildwiederholrate des Monitors einrastet
  • Dieses Verfahren misst die End-to-End-Latenz einschließlich Kernel, Compositor, Anwendung und Monitor-Reaktionszeit
    • Die Latenz der Tastatur-Firmware ist ausgenommen
    • Mit dem aktuellen Board und der Firmware werden rund 35.500 Lichtsensorwerte pro Sekunde aufgezeichnet
  • Jeder Test wird 120-mal wiederholt
    • Erwartet wird, dass sich die Punkte ungefähr gleichmäßig über eine Monitor-Aktualisierung verteilen
    • Die Aktualisierungsdauer eines 144-Hz-Monitors beträgt etwa 6,94 ms; in den Beispielgrafiken verteilen sich die Punkte über einen Bereich von 7–8 ms
    • Hohe Ausreißer oder eine breitere Verteilung können auf Latenz oder langsame Verarbeitung in der getesteten App hinweisen

Testumgebung und Vergleichskandidaten

  • Das Testsystem ist ein Lenovo Legion 7 Gen 7 AMD Laptop
    • CPU: Ryzen 7 6800H
    • GPU: Radeon RX 6700M dGPU, wobei per MUX-Switch ausschließlich die dGPU genutzt wird
    • Monitor: Acer Nitro XV320QU, 2560×1440, 144 Hz, 100 % Skalierung
    • Host: Fedora 40 Silverblue Beta, Mesa 24.0.4
    • Compositor: raw Mutter 46.0
  • raw Mutter ist eine einfache Testumgebung, in der nur Mutter ohne GNOME Shell läuft
    • Startbar etwa mit einem Befehl wie mutter --display-server -- alacritty
    • Das kommt idealen Bedingungen mit kaum GNOME-Shell-Overhead nahe
  • Verglichen wurden vier Terminals
    • Alacritty: nicht VTE-basiert und in früheren Tests durchgehend ein schnelles Terminal, daher als Referenzlinie genutzt
    • Console: das standardmäßige GNOME-Terminal auf GTK-4-Basis
    • VTE Test App: ein GTK-4-Testterminal im VTE-Repository
    • GNOME Terminal: unter GNOME 46 eine GTK-3-App und in vielen Distributionen standardmäßig enthalten
  • Für den Vergleich zwischen GNOME 45 und GNOME 46 wurden Fedora-39- und Fedora-40-toolbox-Container genutzt
    • Jedes Terminal wurde unverändert aus den Fedora-Paketen installiert und ohne zusätzliche Anpassungen gestartet
    • Das Fenster wurde oben links auf dem Monitor platziert, der Mauszeiger blieb außerhalb des Fensters, damit die Link-Erkennungslogik die Ergebnisse nicht verfälscht

Ergebnisse bei einfacher Eingabe und neovim-Scrolling

  • Der erste Test misst nach dem Start von cat > /dev/null, wie lange es dauert, bis sich der Blockcursor nach einer Space-Eingabe um eine Position nach rechts bewegt
    • Das ist eine Situation mit minimalem Overhead, ohne zusätzliche Verarbeitung wie readline
    • Alacritty zeigt beim Wechsel von Fedora 39 auf Fedora 40 erwartungsgemäß keine Veränderung
    • Die VTE-basierten Terminals verbessern sich unter GNOME 46 gegenüber GNOME 45 stark und erreichen nahezu das Niveau von Alacritty
    • Auch das GTK-3-basierte GNOME Terminal liefert sehr ähnliche Ergebnisse
  • Hauptursache der großen Verbesserung ist vermutlich eine VTE-Änderung von Christian Hergert
    • Sie löst VTE vom bisherigen 40-Hz-Repaint-Timer
    • Stattdessen zeichnet es nun, wie es sich für ein GTK-Widget gehört, synchron zum Monitor in jedem Frame
  • Bei Console gab es einige Ausreißer, möglicherweise wegen Prozess-Tracking
    • Diese Ausreißer sind kein neues Phänomen
    • Sie bleiben ein möglicher Punkt für GNOME 47
  • Der zweite Test nutzt eine realistischere neovim-Konfiguration
    • Aus einem Snapshot der neovim-Einstellungen wurde die Ptyxis-README geöffnet; ein Teil des Texts wurde durch Unicode-Full-Block-Zeichen ersetzt, damit der Lichtsensor ihn erkennen kann
    • Mit Ctrl+D und Ctrl+U wurde der Textpuffer wiederholt nach unten und oben gescrollt
    • Das Terminal muss dabei Bildschirmelemente wie Unterstreichungen, Undercurl, Gutter-Icons und Statuszeile zeichnen
  • Auch im neovim-Test sind die Verbesserungen der GNOME-46-Terminals deutlich
    • Die VTE-basierten Terminals unter GNOME 46 liegen weiterhin fast auf dem Niveau von Alacritty
    • Betrachtet man nur die Fedora-40-Ergebnisse, erhöht der neovim-Test die Latenz gegenüber dem einfachen cat-Test, aber der Anstieg ist bei allen Terminals ähnlich

Die verbleibenden Unterschiede laut vtebench

  • vtebench ist ein automatischer Benchmark, der nicht die Eingabelatenz, sondern die PTY-Lese- und Parsing-Leistung misst
    • Da er wichtige Faktoren wie Framerate oder Latenz nicht abdeckt, reicht er nicht aus, um Terminal-Performance insgesamt zu verstehen
    • Er setzt vor allem die Geschwindigkeit unter Druck, mit der ein Terminal aus dem PTY liest
  • Repaint-Zeit kann auch die vtebench-Ergebnisse beeinflussen
    • Besonders stark kann sich das bei Terminals auswirken, die wie VTE PTY-Lesen, Parsing und Repaint-Logik im selben Thread ausführen
  • VTE in GNOME 46 verbessert sich auch in vtebench
    • Das Ausmaß der Verbesserungen variiert stärker als in den Eingabelatenztests
    • Das Niveau von Alacritty, das Lesen und Parsing in einem vom Rendering getrennten Thread ausführt, wird nicht erreicht
    • Diese Verbesserung scheint aus mehreren Optimierungen zu stammen, die während des GNOME-46-Zyklus in VTE eingeflossen sind
  • Die Benchmarks dense_cells und unicode wurden aus der Standard-Ergebnisgrafik ausgeschlossen
    • Beide sind wichtige Stresstests von vtebench
    • VTE zeigt dort weiterhin stark schwankende Ergebnisse, was die Lesbarkeit der Grafik verschlechtert
  • Bezogen auf die getesteten Szenarien sind die verbleibenden Unterschiede nahezu vernachlässigbar
    • Einige Unterschiede lassen sich dadurch erklären, dass VTE für Barrierefreiheit, Scrollbar-Berechnungen und andere Funktionen zusätzliche Arbeit leistet
    • Barrierefreiheit ist in GNOME Terminal aktiviert, in den GTK-4-Terminals derzeit jedoch deaktiviert
    • Mit VTE 0.76 erhält man die Performance einschließlich der Verbesserungen aus GNOME 46

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-04-09
Meinungen auf Hacker News

  • Dank dieser Änderung liegt der Median der Eingabeverzögerung in der getesteten Konfiguration endlich unter dem des Apple //e. Console kommt auf etwa 12 ms, der Apple //e von 1983 lag bei 30 ms – es hat also 41 Jahre gedauert.
    https://www.extremetech.com/computing/261148-modern-computer...
    https://danluu.com/input-lag/
    Allerdings nutzte dieser Benchmark nicht GNOME Shell, sondern den Compositor raw Mutter 46.0; raw mutter ist eine sehr einfache Umgebung, eher für Tests gedacht. Außerdem wurde die Tastaturverzögerung nicht einbezogen, es handelt sich also nicht um eine End-to-End-Messung. In diesem Test sendet ein Board die Tasteneingaben per USB, doch allein die interne Verzögerung der Tastatur kann bis zu 60 ms betragen.
    https://danluu.com/keyboard-latency/
    Mich würden die realen End-to-End-Werte der wirklich wichtigen Standardkonfiguration interessieren; es wäre schön gewesen, wenn der Artikel das gemessen hätte. Die Arbeit des GNOME-Teams und des Benchmark-Autors ist großartig, aber die entscheidende Frage bleibt offen. Der Apple //e nutzte Hardwarebeschleunigung und musste auch kein Unicode verarbeiten, es gibt also viele Unterschiede. Trotzdem wäre es schön, zur menschenfreundlichen Reaktionsfähigkeit einer über 41 Jahre alten Maschine zurückzukehren.

    • Ich finde eher, dass der Autor gut daran getan hat, Tastaturverzögerung auszuklammern. Menschen nutzen unterschiedliche Tastaturen, USB-Interfaces, Computer und Betriebssystemversionen, und auch Hubs oder KVMs können dazwischenhängen.
      Wenn die Verzögerung solcher Komponenten während des Tests stark schwankt, wird es schwierig, die VTE-Latenzverbesserungen zu analysieren, um die es in diesem Beitrag im Kern geht. Selbst wenn sie völlig konstant wäre, würde sie nur wie eine Konstante zum Absolutwert addiert; die Schlussfolgerung ändert sich dadurch nicht. Deshalb sollte man Latenzunterschiede nicht als Prozentsatz ausdrücken. In der Stichprobe gibt es eine Konstante, auf die man normalisieren kann, in der gesamten Nutzerschaft aber viele Konstanten, auf die man nicht normalisieren kann. Der Mutter-Teil ist interessant: Da GNOME auf Mutter aufsetzt, dürfte die absolute Latenzverbesserung vermutlich ähnlich ausfallen. Allerdings kann auch GNOME, ähnlich wie Tastaturverzögerung, unerwünschte Schwankungen erzeugen; das würde ich gern in der Praxis überprüft sehen.
    • Dann kann man eben einen Apple 2e benutzen und auf die Komfortfunktionen moderner Betriebssysteme verzichten. Diese ausführliche Herabsetzung von Open-Source-Entwicklern, die sich bemühen, etwas kostenlos bereitzustellen, ist schwer zu akzeptieren.
    • An der Methodik des verlinkten Artikels zur Tastaturverzögerung hat mich immer etwas gestört, dass sogar die Zeit, in der sich die Taste physisch bewegt, mit einbezogen wurde.
    • Unicode-Verarbeitung ist kein so schwieriges Problem, wie viele glauben. Es gibt Grenzfälle, in denen es seltsam wird, aber nicht viele, und sie sind leicht zu lösen.
      Was mich an diesem Artikel wirklich gestört hat, war, dass Gnome vor der aktuellen Testversion eine feste Neuzeichnungsrate von 40 Hz hatte. Wer hat das bitte so entschieden?
    • Die 60-ms-Behauptung aus dem Artikel zur Tastaturverzögerung erscheint mir zweifelhaft. Wenn die Verzögerung von der Tasteneingabe bis USB bei Tastaturen häufig 60 ms betragen würde, wären Rhythm Games buchstäblich unspielbar. Mit keiner der Tastaturen, die ich bisher benutzt habe, hatte ich jedoch solche Probleme.

  • Gut. Mir gefällt, dass sich die VTE-Entwickler auf Performance konzentriert haben, und der hardwarebasierte Messaufbau im Artikel ist beeindruckend.
    Die Methode, für Latenzmessungen einen Lichtsensor zu verwenden, erinnert an Ben Hecks unverblümt benanntes Produkt „Xbox One Controller Monitor“ [1]. Es liest den Tastenstatus eines Spielekonsolen-Controllers direkt aus und kombiniert ihn mit einem Lichtsensor, um Spieleentwicklern zu helfen, die Latenz niedrig zu halten. Sieht cool aus, kostet aber 900 Dollar.
    [1]: https://www.benheck.com/xbox1monitor/

    • Dass man sich auf Performance konzentriert, ist eine neuere Entwicklung. VTE war ursprünglich ziemlich langsam.
    • Interessante Tatsache: Wenn vertikale Synchronisation aktiviert ist, hängt die Latenz davon ab, wo man den Sensor platziert.

  • Sowohl dieser Artikel als auch der verlinkte Artikel platzieren den Lichtsensor ungefähr in der Mitte des Monitors. Für den Vergleich der Messwerte ist das kein Problem, aber bei vielen gängigen Monitoren misst man bei 60 Hz etwa 8 ms schneller, wenn der Sensor oben am Bildschirm sitzt, und etwa 8 ms langsamer, wenn er unten sitzt. Das liegt daran, dass Pixel bzw. Zeilen von oben nach unten angesteuert werden, im Grunde ähnlich wie bei CRTs.
    Wenn man also ins Detail geht, sollte man auch das erwähnen – ebenso wie die Frage, wo man den Schwellwert setzt, ab dem das Lichtsensorsignal als „Pixel ist an“ gilt. Bei den Zahlen im Artikel sind 8 ms ein ziemlich großer Unterschied. Genauso kann es übertrieben sein, einfach zu sagen: „Monitor X ist 30 ms langsamer als Monitor Y.“ Man sollte eher sagen: In meiner Konfiguration und mit den Einstellungen X, Y, Z wurde es so gemessen. Man muss auch prüfen, ob der Monitor irgendwelche seltsamen Verbesserungsfunktionen anwendet, die nur Latenz hinzufügen und keinen spürbaren Effekt haben, oder ob beim Monitorwechsel die Grafikkarte oder der Treiber in vermeintlicher Hilfsbereitschaft heimlich auf Korrektur-, Skalierungs- oder Verbesserungsprofile umgeschaltet hat. Solche Geräte warnen normalerweise nicht davor; ich habe tatsächlich einige Fälle davon gesehen.

    • Wenn ich sehe, wie der Bildschirm in Echtzeit scrollt, schaue ich sehr wahrscheinlich auf das untere Drittel des Bildschirms.

  • Es ist lustig, dass wir in einer Welt leben, in der surreale 3D-Szenen und Spiele gerendert werden, die auf Consumer-Hardware früher unmöglich wirkten, und gleichzeitig noch immer daran gearbeitet wird, das Ausgeben von Text im Terminal perfekt hinzubekommen.

    • Ich vermute, das liegt teilweise daran, dass stärker für Grafik optimiert wurde. Zwischen beidem gibt es einen Trade-off, und je besser die Grafik wird, desto schlechter kann Text tendenziell werden. Dass Terminals GPU-Beschleunigung nutzen, gleicht das teilweise aus, aber man zahlt trotzdem die Kosten dieser Grafik-Pipeline.
    • Vielleicht war es früher auch einfach nicht so wichtig. Es war eher ein „funktioniert schon“, und bis vor Kurzem gab es bei vielen Terminal-Anwendungsfällen eine erhebliche Netzwerklatenz, die gelöst werden musste.

  • Hat zwar nichts mit Geschwindigkeit zu tun, aber ich frage mich, ob es unter Linux ein Terminal gibt, das wie das Terminal von Mac OSX nach dem Schließen und erneuten Öffnen alle Tabs, die Befehlshistorie jedes Tabs und den Scrollback wiederherstellt. Auf dem Mac wird das gelöst, indem pro Tab eine andere bash-Historiendatei gesetzt wird.
    Für diesen Zweck bevorzuge ich ein GUI-Terminal

    • Etwas anderes Thema, aber ich habe gerade vor einer Stunde erfahren, dass iTerm2 auf dem Mac in tmux integriert werden kann. Wenn man tmux mit dem Argument -CC startet, wird die tmux-Session auf die GUI-Fenster und Tabs von iTerm2 abgebildet, und das funktioniert sogar, wenn man per ssh tmux auf einer Remote-Maschine nutzt.
      Ich vergesse ständig die tmux-Steuerkürzel und -Befehle, daher freue ich mich ziemlich auf diese Funktion.
      [1] https://iterm2.com/documentation-tmux-integration.html
    • Ich frage mich, was passiert, wenn man alle Tabs schließt und dann einen neuen Tab öffnet. Wird die Verlaufshistorie pro Tab beim Schließen wieder in die normale Historiendatei zusammengeführt, sodass man diese Befehle auch im neuen Tab verwenden kann?
    • Ich nutze Tmux. Als terminalunabhängiger Multiplexer bietet es starke Persistenz- und Automatisierungsfähigkeiten.
      https://github.com/tmux/tmux/wiki
    • Wenn man GUI-Terminals bevorzugt, gefällt einem das vielleicht nicht, aber für manche könnte es nützlich sein: https://github.com/tmux-plugins/tmux-resurrect
      Natürlich kann man tmux mit jedem beliebigen GUI-Terminalemulator verwenden.
    • Ich habe genau so etwas gesucht. Im Moment nutze ich tmux und tmux-resurrect, um den Zustand über Neustarts hinweg zu erhalten; es funktioniert halbwegs, ist aber nur ein guter Hack und fühlt sich weiterhin wie ein Hack an.
      Schade, dass es abgesehen von Warp kaum echte Lösungen für dieses Problem gibt. Mein kleiner UX-Traum ist, dass so eine Funktion zum Speichern von Arbeitsbereichen ins gesamte Betriebssystem und die darin laufenden Apps integriert wird. Das wäre großartig.

  • Ich habe jahrelang Gnome genutzt und bin vor zwei Jahren auf sway und alacritty umgestiegen, aber ehrlich gesagt merke ich überhaupt keinen Unterschied. Wie bei High-End-Audioequipment scheinen meine Ohren und Augen nicht darauf abgestimmt zu sein, den Unterschied zu erkennen.

    • Bist du schon einmal zurückgewechselt? Häufig spürt man es stärker, wenn die Latenz zunimmt, als wenn sie abnimmt.
    • Ich nutze seit Jahren Gnome und bin jetzt auf Gnome 46, aber im Vergleich zu Gnome 45 habe ich keinen Unterschied bei der Terminal-Latenz bemerkt. Ich scheine für so etwas auch nicht besonders sensibel zu sein.
    • Vielleicht kein fairer Vergleich, aber vor etwa 20 Jahren hat gnome-terminal beim Kompilieren des Kernels die Hälfte der CPU verbraucht; danach habe ich beschlossen, es nicht mehr zu verwenden. Xterm lag bei etwa 2 %.
    • Bei Latenz oder Reaktionsfähigkeit interessiert mich eigentlich nur, ob mir wegen des Terminals beim Scrollen in vim schlecht wird.
    • Vielleicht fügen Bildschirm oder Tastatur ohnehin schon genug Latenz hinzu, sodass man mit keiner Software ein gutes Ergebnis bekommt. Der Unterschied zwischen schlechter und sehr schlechter Latenz ist nicht so deutlich. Ich frage mich, ob du schon Gaming-Hardware ausprobiert hast.

  • Endlich gibt es einen Terminal-Benchmark, der nicht nur darin besteht, riesige Dateien mit cat auszugeben. Ich würde gern mehr verschiedene Terminals, insbesondere auch die Standard-Linux-Konsole, im selben Test sehen.

  • Etwas off-topic, aber was ich am Gnome Terminal am meisten hasse, ist, dass es standardmäßig ein kleines Fenster öffnet. Es ist ungefähr ein Viertel meines Bildschirms groß, und selbst wenn ich die Größe ändere, merkt es sich das nach einem Neustart nicht. Am Ende muss man in die Einstellungen gehen und die Anzahl der Spalten und Zeilen manuell festlegen.

    • Dieses Verhalten ist bei vielen Terminals ziemlich üblich. Spontan fallen mir das standardmäßige macOS Terminal und Windows Terminal ein, bei denen man ebenfalls die Standardgröße in den Einstellungen ändern muss.
      Persönlich bevorzuge ich es, die Standardgröße beizubehalten und nur bestimmte Fenster zu vergrößern, wenn ich mehr Platz brauche. Trotzdem sollte es zumindest eine Option geben, sich die geänderte Größe zu merken.
    • Das lässt sich in den Einstellungen ändern.
      Über das Hamburger-Menü > Preferences > Profilname kommt man dorthin. Mein Profil heißt einfach „Unnamed“. Wenn man „initial terminal size“ ändert, ist es wie gewünscht. Ich habe es auf 132x43 gesetzt.
    • Ich habe oft mehrere Terminals in unterschiedlichen Größen geöffnet. Es ist nicht klar, welche Größe es sich merken sollte.
      Deshalb würde ich mir wünschen, dass so etwas gar nicht erst versucht wird. Wenn Software sicher wissen kann, was ich will, darf sie gern schlau sein; andernfalls wird es nur ein weiteres Beispiel für „Ich habe das automatisch für Sie kaputtgemacht. Gern geschehen.“
    • Das neuere Gnome-Terminal Console merkt sich die Fenstergröße.
    • Soweit ich mich erinnere, war das eine Funktion, die von CMD.EXE kam.

  • Wenn Mitchell Hashimotos Terminal Ghostty veröffentlicht wird, wäre es schön, es ebenfalls in die Benchmarks aufzunehmen. Es befindet sich noch in Entwicklung und Feinschliff und ist eine private Beta.
    https://mitchellh.com/ghostty

  • Ich nutze unter Debian xterm und i3wn und habe noch nie etwas Schnelleres erlebt. Ich bin nie auf die Idee gekommen, GPU-Ressourcen an ein Terminal zu verschwenden; alacritty halte ich persönlich daher für übertrieben.

    • Geht mir ähnlich. Bei xterm habe ich noch nie über Latenz nachgedacht. Und das, obwohl ich täglich auch schwerere Funktionen wie Übersetzungsfunktionen oder sixel nutze. Ich glaube, die Leute ignorieren es wegen des Athena-Widget-Stils, aber in Wirklichkeit ist es hervorragend.