GNOME 46ターミナルの高速化はどれほど大きいのか
(bxt.rs)- GNOME 46サイクルで VTEベースのターミナル の入力遅延が大幅に減少し、Fedora 40で高速なベースラインとして使われたAlacrittyにほぼ迫った
- 測定はキー入力から画面ピクセルの変化までの エンドツーエンドの入力遅延 をハードウェアセンサーで測る方式で、カーネル・コンポジタ・アプリ・モニターの応答時間がまとめて反映される
- 単純な
cat > /dev/null入力と複雑な neovimスクロール の両方で、Console、VTE Test App、GNOME TerminalはGNOME 45より明確に改善した - 中核となる変化は、VTEが従来の 40Hz repaint timer の代わりに、モニターと同期した各フレームごとに再描画する方式へ変わった点である可能性が高い
- VTE 0.76を使うGNOME 46ターミナルは体感遅延が減っており、VTEベースのターミナルを遅いという理由で避けていたユーザーも再び試してみる価値がある
VTEベースのターミナルで起きた変化
- VTE は、複数のGNOMEターミナルエミュレーターの基盤となる Virtual TErminal library
- GTKウィジェットとしてターミナルビューを提供する
- GNOME Terminal, Console, Black Box, Tilix, Terminator, Ptyxis などで使われている
- Builder と Workbench の内蔵ターミナルもVTEを使用している
- GNOME 46サイクル中にVTEへ多くの 性能改善 が入り、ユーザーが実際に感じる入力遅延が主要な確認対象となった
入力遅延の測定方法
- 入力遅延とは、キーボードのキーを押した瞬間からモニターのピクセル色が変わる瞬間までの時間
- 遅延が低いほど、アプリがより即座に反応しているように感じられる
- 低遅延と高遅延を交互に比較すると差がよりはっきり分かる
- 測定にはソフトウェアの画面キャプチャではなく、ハードウェア入力遅延テスター を使う
- 光センサーをTeensyボードに接続し、ボードはUSBでコンピューターにつながる
- センサーは、ターミナルの特定の文字セルのようにキー入力で明るさが変わる小さな画面領域を見ている
- ボードがSpaceのようなキー入力を送り、光量変化を検知した後、Backspaceのような2つ目のキーで元の状態に戻す
- 繰り返しの間にランダムな待機時間を入れ、測定がモニターのリフレッシュレートに固定される現象を避ける
- この方式は、カーネル、コンポジタ、アプリケーション、モニター応答時間を含む エンドツーエンドの遅延 を測定する
- キーボードファームウェアの遅延は含まれない
- 現在のボードとファームウェアでは、1秒あたり約35,500個の光センサー値を記録する
- 各テストは120回繰り返される
- 点の分布は、モニター1回分の更新周期程度に均一に広がるのが期待される形である
- 144Hzモニターの更新周期は約6.94msで、例のグラフの点は7〜8msの範囲に広がる
- 高い外れ値やより広い分布は、対象アプリの遅延または遅い処理を示している可能性がある
テスト環境と比較対象
- テストシステムはLenovo Legion 7 Gen 7 AMDノートPC
- CPUはRyzen 7 6800H
- GPUはRadeon RX 6700M dGPUで、MUXスイッチによりdGPUのみを使用
- モニターはAcer Nitro XV320QU、2560×1440、144Hz、100%スケール
- ホストはFedora 40 Silverblue Beta、Mesa 24.0.4
- コンポジタは raw Mutter 46.0
- raw MutterはGNOME ShellなしでMutterだけを実行するシンプルなテスト環境
mutter --display-server -- alacrittyのようなコマンドで実行できる- GNOME Shellオーバーヘッドがほとんどない理想条件に近い
- 比較対象のターミナルは4種類
- Alacritty: VTEベースではなく、過去のテストでも一貫して高速なターミナルで、ベースラインの役割を果たす
- Console: GTK 4ベースのGNOME標準ターミナル
- VTE Test App: VTEリポジトリにあるGTK 4テストターミナル
- GNOME Terminal: GNOME 46ではGTK 3アプリで、多くのディストリビューションで標準提供される
- GNOME 45とGNOME 46の比較にはFedora 39とFedora 40の
toolboxコンテナを使用- 各ターミナルはFedoraパッケージをそのままインストールし、追加調整なしで実行した
- ウィンドウはモニター左上に配置し、マウスカーソルはリンク検出ロジックが結果を歪めないようウィンドウ外に置いた
単純入力とneovimスクロールの結果
- 最初のテストでは
cat > /dev/nullを実行した後、Space入力でブロックカーソルが右に1マス移動するまでの時間を測定した- readlineのような追加処理がない 最小オーバーヘッド の状況
- AlacrittyはFedora 39からFedora 40に変わっても予想どおり変化がない
- VTEベースのターミナルはGNOME 45に比べてGNOME 46で大きく改善し、Alacrittyとほぼ同水準に達した
- GTK 3ベースのGNOME Terminalも非常に近い結果を示した
- 大きな改善の主因は、Christian Hergertによる VTEの変更 である可能性が高い
- 従来の40Hz VTE repaint timerから脱却した
- GTKウィジェットらしく、モニターと同期して毎フレーム描画する方式に変わった
- Consoleにはいくつか外れ値があり、プロセストレースが原因の可能性がある
- この外れ値は新しく発生した現象ではない
- GNOME 47で調べる項目として残る
- 2つ目のテストでは、より現実的な neovim構成 を使う
- neovim設定スナップショットでPtyxis READMEを開き、光センサーが検知できるよう一部テキストをUnicode full-block文字に変更した
- Ctrl+DとCtrl+Uを繰り返してテキストバッファを上下にスクロールする
- ターミナルは下線、undercurl、ガターアイコン、ステータスラインなどの画面要素を描画しなければならない
- neovimテストでもGNOME 46ターミナルの改善は明確
- GNOME 46のVTEベースターミナルは依然としてAlacrittyとほぼ同等の水準
- Fedora 40の結果だけを見ると、neovimテストは単純な
catテストより遅延を増やすが、増加幅はすべてのターミナルでほぼ同じ
vtebenchが示した残りの差
- vtebench は入力遅延ではなく、PTY読み取りとパース性能 を測る自動ベンチマーク
- フレームレートや遅延のような重要要素を扱わないため、ターミナル性能全体を理解するには十分ではない
- ターミナルがPTYから読み取る速度に強い負荷をかける
- repaint時間はvtebench結果にも影響しうる
- VTEのようにPTY読み取り・パースとrepaintロジックを同じスレッドで実行するターミナルでは、特に影響が大きくなる可能性がある
- GNOME 46のVTEはvtebenchでも改善している
- 改善幅は入力遅延テストよりばらつきが大きい
- 読み取りとパースをレンダリングとは別スレッドで処理するAlacrittyの水準にはまだ達していない
- この改善はGNOME 46サイクル中にVTEへ入った複数の最適化によるものとみられる
dense_cellsとunicodeベンチマークは基本結果グラフから除外されている- この2項目はvtebenchの主要なストレステスト
- VTEが依然として大きく揺れる結果を示し、グラフの可読性を下げるため
- テストケース基準では、残る差はほぼ無視できる水準に近い
- 一部の差は、VTEがアクセシビリティ、スクロールバー計算、そのほかの機能のために追加作業をしている点で説明できる可能性がある
- アクセシビリティはGNOME Terminalでは有効で、GTK 4ターミナルでは現時点で無効になっている
- VTE 0.76を使えば、GNOME 46の改善を含む性能が得られる
1件のコメント
Hacker News のコメント
この変更のおかげで、テストした構成の入力遅延の中央値がついに Apple //e を下回った。Console は約 12ms、1983年の Apple //e は 30ms で、41年かかったことになる
https://www.extremetech.com/computing/261148-modern-computer...
https://danluu.com/input-lag/
ただし、このベンチマークは GNOME Shell ではなく、コンポジタである raw Mutter 46.0 を使っており、raw Mutter はテスト用に近いごく基本的な環境だ。またキーボード遅延を含んでいないため、エンドツーエンドの測定でもない。このテストではボードが USB 経由でキー入力を送っているが、キーボード内部の遅延だけでも 60ms に達することがある
https://danluu.com/keyboard-latency/
本当に重要なデフォルト構成での実際のエンドツーエンドの数値が知りたいので、記事でそれを測ってくれていたらよかったと思う。GNOME チームとベンチマーク作者の仕事は素晴らしいが、重要な疑問は残っている。Apple //e はハードウェアアクセラレーションを使っていたし Unicode も処理していなかったので違いは多いが、それでも41年以上前のマシンの人間にとっての応答性に戻れるといい
そうした構成要素の遅延がテスト中に大きく揺れると、この記事の核心である VTE の遅延改善を分析しにくくなる。仮に完全に一定だったとしても、絶対値に定数のように加わるだけなので結論は変わらない。だから遅延差をパーセンテージで表すべきではない。標本集合には正規化できる定数があるが、ユーザー全体には正規化できない定数が多数あるからだ。Mutter の部分は興味深い。GNOME は Mutter の上で動くので、絶対的な遅延改善は同じように現れる可能性がありそうだ。ただし GNOME もキーボード遅延のような望まない変動を生む可能性があるので、実際に確認してみたい
この記事で本当に気になったのは、最新のテスト版以前の Gnome では 再描画速度が固定 40Hz だったことだ。いったい誰がそんな決定をしたのか
良い。VTE 開発者たちが 性能に集中した点も良いし、記事のハードウェアベースの測定過程も印象的だ
遅延測定に光センサーを使う方法は、Ben Heck の露骨な名前の「Xbox One Controller Monitor」[1] という製品を思い出させる。ゲームコンソールのコントローラーボタンの状態を直接読み取り、光センサーと組み合わせて、ゲーム開発者が遅延を低く保てるようにする製品だ。格好よさそうだが、価格は900ドルだ
[1]: https://www.benheck.com/xbox1monitor/
この記事もリンク先の記事も、光センサーをモニターのほぼ中央に置いている。測定値の比較には問題ないが、一般的なモニターのかなり多くでは、60Hz 基準でセンサーを画面上部に置くと約 8ms 速く、下部に置くと約 8ms 遅く測定される。ピクセルやラインが上から下へ駆動されるためで、基本的には CRT と似ている
だから細部に踏み込むなら、光センサー信号でピクセルが点灯したと判断するしきい値をどこに置くかと同じように、この点にも触れるべきだ。記事の数値を見ると 8ms はかなり大きな差だ。同様に、「モニター X はモニター Y より 30ms 遅い」とだけ言うのも誇張になり得る。自分の構成と設定 X、Y、Z ではこう測定された、と見るべきだ。モニターが遅延だけを追加して体感上の効果はない奇妙な強化機能を適用していないか、モニターを変えるときにグラフィックカードやドライバーが親切そうな顔をして、補正・スケーリング・強化プロファイルへこっそり切り替えていないかも確認する必要がある。こうしたデバイスはたいてい何の警告もしないが、実際に見た事例がいくつかある
コンシューマー向けハードウェアでは不可能に見えた超現実的な 3D シーンやゲームをレンダリングする世界に生きている一方で、同時にターミナルにテキストを表示することをまだ完璧にしようと努力している世界だというのは面白い
速度とは関係ありませんが、Linux に Mac OSX Terminal のように、終了してから再度開くと、すべてのタブ、各タブのコマンド履歴とスクロールバックを復元してくれるターミナルがあるのか気になります。Mac 側は、タブごとに別々の bash 履歴ファイルを設定する形で処理しています
この用途には GUI ターミナルを好みます
-CC引数で実行すると、tmux セッションが iterm2 の GUI ウィンドウとタブにマッピングされ、ssh でリモートマシンの tmux を使っても可能ですtmux の制御ショートカットとコマンドをいつも忘れてしまうので、この機能にはかなり期待しています
[1] https://iterm2.com/documentation-tmux-integration.html
https://github.com/tmux/tmux/wiki
もちろん tmux は、好きな GUI ターミナルエミュレータと一緒に使えます
warp を除くと、この問題に対する本当の解決策がほとんどないのが残念です。私の小さな UX の夢は、こうしたワークスペース保存機能が OS 全体とその中のアプリに統合されることです。そうなれば素晴らしいでしょう
何年も Gnome を使ってから2年前に sway と alacritty に乗り換えましたが、正直なところ違いがまったく分かりません。高級オーディオ機器のように、私の耳と目はその違いを識別できるようには調整されていないようです
ついに、巨大なファイルを
catするだけではないターミナルベンチマークが出ました。もっと多様なターミナル、特に Linux の標準コンソールまで同じテストで見てみたいですhttps://sw.kovidgoyal.net/kitty/performance/#throughput
または
https://github.com/alacritty/vtebench/tree/master
話題から外れますが、Gnome Terminal でいちばん嫌いなのは、デフォルトで小さなウィンドウを開くことです。私の画面の1/4くらいの大きさで、サイズを変えても再起動後に記憶しません。結局、設定に入って列数と行数を直接指定する必要があります
個人的には、デフォルトサイズはそのままにして、より広い領域が必要な特定のウィンドウだけリサイズする方法を好みます。それでも、リサイズを記憶するオプションは少なくともあるべきです
ハンバーガーメニュー > Preferences > プロファイル名に進めばよいです。私のプロファイルは単に “Unnamed” です。“initial terminal size” を変えれば望みどおりになります。私は 132x43 に設定しています
なので、そういう試みはしないでほしいです。ソフトウェアが私の望みを確信できるときに賢く振る舞うのはよいですが、そうでなければまた一つの「自動で台無しにしておきました。ありがたいでしょう？」という事例になります
公開されたら、Mitchell Hashimoto の Ghostty ターミナルもベンチマークに含まれるとよいですね。まだ開発と仕上げの段階で、非公開ベータです
https://mitchellh.com/ghostty
debian で xterm と i3wn を使っていますが、これより速いものを経験したことがありません。ターミナルに GPU を浪費するという発想すらしたことがないので、alacritty は個人的にはやりすぎだと思います