Seberapa Besar Peningkatan Kecepatan Terminal GNOME 46

 (bxt.rs)
3 poin oleh GN⁺ 2024-04-09 | 1 komentar | Bagikan ke WhatsApp
  • Pada siklus GNOME 46, latensi input terminal berbasis VTE berkurang drastis, hingga dalam pengujian Fedora 40 hampir menyamai Alacritty yang digunakan sebagai baseline cepat
  • Pengukuran dilakukan dengan sensor hardware untuk latensi input end-to-end, dari penekanan tombol hingga perubahan piksel di layar, sehingga waktu respons kernel, compositor, aplikasi, dan monitor ikut tercermin
  • Baik pada input sederhana cat > /dev/null maupun scrolling neovim yang kompleks, Console, VTE Test App, dan GNOME Terminal menunjukkan peningkatan jelas dibanding GNOME 45
  • Perubahan kunci kemungkinan besar adalah VTE beralih dari 40Hz repaint timer lama ke cara menggambar ulang pada setiap frame yang tersinkron dengan monitor
  • Terminal GNOME 46 yang memakai VTE 0.76 memiliki latensi yang terasa lebih rendah, sehingga pengguna yang dulu menghindari terminal berbasis VTE karena dianggap lambat layak mencobanya kembali

Perubahan yang Terjadi pada Terminal Berbasis VTE

  • VTE adalah library Virtual TErminal yang menjadi fondasi berbagai emulator terminal GNOME
  • Selama siklus GNOME 46, banyak peningkatan performa masuk ke VTE, dan latensi input yang benar-benar dirasakan pengguna menjadi fokus utama untuk diperiksa

Cara Mengukur Latensi Input

  • Latensi input adalah waktu dari saat tombol keyboard ditekan hingga warna piksel monitor berubah
    • Semakin rendah latensinya, aplikasi terasa semakin responsif
    • Perbedaannya lebih mudah terlihat jika membandingkan latensi rendah dan tinggi secara bergantian
  • Pengukuran menggunakan alat penguji latensi input berbasis hardware, bukan tangkapan layar software
    • Sensor cahaya dihubungkan ke board Teensy, dan board terhubung ke komputer melalui USB
    • Sensor mengarah ke area kecil di layar yang kecerahannya berubah akibat input tombol, seperti sel karakter tertentu di terminal
    • Board mengirim input tombol seperti Space, mendeteksi perubahan intensitas cahaya, lalu mengembalikan kondisi awal dengan tombol kedua seperti Backspace
    • Waktu tunggu acak dimasukkan di antara pengulangan untuk menghindari pengukuran terkunci pada refresh rate monitor
  • Metode ini mengukur latensi end-to-end yang mencakup waktu respons kernel, compositor, aplikasi, dan monitor
    • Latensi firmware keyboard dikecualikan
    • Dengan board dan firmware saat ini, sekitar 35.500 nilai sensor cahaya dicatat per detik
  • Setiap pengujian diulang 120 kali
    • Distribusi titik yang menyebar merata sekitar satu periode refresh monitor adalah bentuk yang diharapkan
    • Periode refresh monitor 144Hz sekitar 6,94ms, dan titik pada grafik contoh tersebar dalam rentang 7–8ms
    • Outlier tinggi atau distribusi yang lebih lebar dapat menunjukkan latensi atau pemrosesan lambat pada aplikasi yang diuji

Lingkungan Pengujian dan Pembanding

  • Sistem pengujian adalah laptop Lenovo Legion 7 Gen 7 AMD
    • CPU-nya Ryzen 7 6800H
    • GPU-nya Radeon RX 6700M dGPU, dan hanya dGPU yang digunakan melalui MUX switch
    • Monitornya Acer Nitro XV320QU, 2560×1440, 144Hz, skala 100%
    • Host menggunakan Fedora 40 Silverblue Beta, Mesa 24.0.4
    • Compositor-nya adalah raw Mutter 46.0
  • Raw Mutter adalah lingkungan pengujian sederhana yang hanya menjalankan Mutter tanpa GNOME Shell
    • Dapat dijalankan dengan perintah seperti mutter --display-server -- alacritty
    • Ini mendekati kondisi ideal dengan overhead GNOME Shell yang nyaris tidak ada
  • Ada empat terminal yang dibandingkan
    • Alacritty: bukan berbasis VTE, dan dalam pengujian sebelumnya konsisten menjadi terminal cepat sehingga berperan sebagai baseline
    • Console: terminal default GNOME berbasis GTK 4
    • VTE Test App: terminal uji GTK 4 di repositori VTE
    • GNOME Terminal: pada GNOME 46 merupakan aplikasi GTK 3, dan disediakan sebagai default di banyak distribusi
  • Perbandingan GNOME 45 dan GNOME 46 menggunakan kontainer Fedora 39 dan Fedora 40 toolbox
    • Setiap terminal dipasang apa adanya dari paket Fedora dan dijalankan tanpa penyesuaian tambahan
    • Jendela ditempatkan di kiri atas monitor, dan kursor mouse diletakkan di luar jendela agar logika deteksi tautan tidak mendistorsi hasil

Hasil Input Sederhana dan Scrolling neovim

  • Pengujian pertama menjalankan cat > /dev/null, lalu mengukur waktu yang dibutuhkan kursor blok untuk bergeser satu sel ke kanan akibat input Space
    • Ini adalah situasi dengan overhead minimum tanpa pemrosesan tambahan seperti readline
    • Sesuai perkiraan, Alacritty tidak berubah saat berpindah dari Fedora 39 ke Fedora 40
    • Terminal berbasis VTE meningkat besar pada GNOME 46 dibanding GNOME 45 hingga hampir mencapai level yang sama dengan Alacritty
    • GNOME Terminal berbasis GTK 3 juga menunjukkan hasil yang sangat mendekati
  • Penyebab utama peningkatan besar ini kemungkinan adalah perubahan VTE oleh Christian Hergert
    • Keluar dari VTE repaint timer 40Hz lama
    • Berubah menjadi cara menggambar setiap frame secara tersinkron dengan monitor, sebagaimana layaknya widget GTK
  • Console memiliki beberapa outlier, kemungkinan karena pelacakan proses
    • Outlier ini bukan fenomena baru
    • Ini tetap menjadi hal yang dapat ditinjau di GNOME 47
  • Pengujian kedua menggunakan konfigurasi neovim yang lebih realistis
    • Membuka README Ptyxis dari snapshot konfigurasi neovim, lalu mengubah sebagian teks menjadi karakter Unicode full-block agar bisa dideteksi sensor cahaya
    • Mengulang Ctrl+D dan Ctrl+U untuk menggulir buffer teks ke bawah dan ke atas
    • Terminal harus menggambar elemen layar seperti underline, undercurl, ikon gutter, dan status line
  • Dalam pengujian neovim, peningkatan terminal GNOME 46 juga tampak jelas
    • Terminal berbasis VTE di GNOME 46 masih hampir setara dengan Alacritty
    • Jika hanya melihat hasil Fedora 40, pengujian neovim menambah latensi dibanding pengujian cat sederhana, tetapi besar kenaikannya mirip di semua terminal

Perbedaan Lain yang Ditunjukkan vtebench

  • vtebench adalah benchmark otomatis yang mengukur performa pembacaan dan parsing PTY, bukan latensi input
    • Karena tidak menangani faktor penting seperti framerate atau latensi, benchmark ini belum cukup untuk memahami performa terminal secara menyeluruh
    • Benchmark ini sangat menekan kecepatan terminal membaca dari PTY
  • Waktu repaint juga dapat memengaruhi hasil vtebench
    • Dampaknya dapat sangat besar terutama pada terminal yang menjalankan pembacaan/parsing PTY dan logika repaint di thread yang sama, seperti VTE
  • VTE di GNOME 46 juga meningkat dalam vtebench
    • Besar peningkatannya lebih bervariasi dibanding pengujian latensi input
    • Belum mencapai level Alacritty, yang melakukan pembacaan dan parsing di thread terpisah dari rendering
    • Peningkatan ini tampaknya berasal dari berbagai optimasi yang masuk ke VTE selama siklus GNOME 46
  • Benchmark dense_cells dan unicode dikecualikan dari grafik hasil utama
    • Keduanya merupakan stress test utama vtebench
    • VTE masih menunjukkan hasil yang sangat bergejolak sehingga mengurangi keterbacaan grafik
  • Berdasarkan kasus pengujian, perbedaan yang tersisa hampir bisa diabaikan
    • Sebagian perbedaan dapat dijelaskan oleh pekerjaan tambahan yang dilakukan VTE untuk aksesibilitas, perhitungan scrollbar, dan fitur lainnya
    • Aksesibilitas aktif di GNOME Terminal, sementara saat ini nonaktif di terminal GTK 4
    • Dengan VTE 0.76, pengguna mendapatkan performa yang mencakup peningkatan GNOME 46

Bacaan terkait

1 komentar

 
GN⁺ 2024-04-09
Komentar Hacker News

  • Berkat perubahan ini, median latensi input pada konfigurasi yang diuji akhirnya lebih rendah daripada Apple //e. Console sekitar 12ms, sedangkan Apple //e tahun 1983 adalah 30ms, jadi butuh 41 tahun untuk mencapainya
    https://www.extremetech.com/computing/261148-modern-computer...
    https://danluu.com/input-lag/
    Namun benchmark ini memakai raw Mutter 46.0 sebagai compositor, bukan GNOME Shell, dan raw mutter adalah lingkungan yang sangat dasar yang lebih dekat ke keperluan pengujian. Selain itu, ini juga bukan pengukuran end-to-end karena tidak memasukkan latensi keyboard. Dalam pengujian ini, board mengirim input tombol lewat USB, padahal latensi internal keyboard saja bisa mencapai 60ms
    https://danluu.com/keyboard-latency/
    Yang benar-benar ingin diketahui adalah angka end-to-end nyata pada konfigurasi default yang penting, dan akan lebih baik kalau artikel itu mengukurnya. Pekerjaan tim GNOME dan pembuat benchmark ini luar biasa, tetapi pertanyaan pentingnya masih tersisa. Apple //e memakai akselerasi hardware dan tidak menangani Unicode, jadi ada banyak perbedaan, tetapi tetap saja akan menyenangkan jika kita bisa kembali ke responsivitas yang terasa manusiawi dari mesin berusia lebih dari 41 tahun itu

    • Justru menurut saya keputusan penulis untuk mengecualikan latensi keyboard itu tepat. Setiap orang memakai keyboard, antarmuka USB, komputer, dan versi sistem operasi yang berbeda, belum lagi hub atau KVM yang bisa ikut masuk di tengah
      Jika latensi dari komponen-komponen itu banyak berfluktuasi selama pengujian, akan sulit menganalisis peningkatan latensi VTE yang menjadi inti tulisan ini. Kalaupun benar-benar konstan, nilainya hanya akan menambah konstanta pada nilai absolut sehingga kesimpulannya tidak berubah. Karena itu perbedaan latensi tidak boleh dinyatakan sebagai persentase. Ada konstanta yang bisa dinormalisasi dalam himpunan sampel, tetapi pada keseluruhan populasi pengguna ada banyak konstanta yang tidak bisa dinormalisasi. Bagian tentang Mutter menarik, karena GNOME berjalan di atas Mutter, jadi peningkatan latensi absolutnya kemungkinan akan terlihat mirip. Namun GNOME juga bisa menimbulkan variasi yang tidak diinginkan seperti latensi keyboard, jadi saya tetap ingin melihat konfirmasi nyata
    • Kalau begitu pakai saja Apple 2e dan tinggalkan fitur-fitur kenyamanan sistem operasi modern. Sulit menerima komentar panjang yang terkesan meremehkan para pengembang open source yang berusaha menyediakan ini secara gratis
    • Dalam metodologi pada tulisan latensi keyboard yang ditautkan, saya selalu agak terganggu karena mereka sampai memasukkan waktu perpindahan fisik tombol
    • Pemrosesan Unicode tidak sesulit yang dipercaya banyak orang. Memang ada kasus batas yang aneh, tetapi tidak banyak dan juga mudah diatasi
      Hal yang benar-benar mengganggu dari tulisan ini adalah bahwa pada Gnome sebelum versi uji terbaru, kecepatan redraw dikunci di 40Hz. Siapa sebenarnya yang memutuskan itu
    • Klaim 60ms pada tulisan latensi keyboard itu terdengar meragukan. Jika latensi dari penekanan tombol ke USB memang umum mencapai 60ms pada keyboard, maka game ritme benar-benar tidak akan bisa dimainkan. Namun saya belum pernah mengalami masalah seperti itu pada keyboard mana pun yang pernah saya pakai

  • Bagus. Senang melihat para pengembang VTE fokus pada kinerja, dan proses pengukuran berbasis hardware di artikel itu juga mengesankan
    Cara mereka mengukur latensi dengan sensor cahaya mengingatkan saya pada produk Ben Heck yang namanya terang-terangan, “Xbox One Controller Monitor” [1]. Produk ini membaca langsung status tombol pada kontroler konsol game dan menggabungkannya dengan sensor cahaya untuk membantu pengembang game menjaga latensi tetap rendah. Terlihat keren, tetapi harganya 900 dolar
    [1]: https://www.benheck.com/xbox1monitor/

    • Fokus pada performa itu baru hal yang relatif belakangan. VTE dulunya memang cukup lambat
    • Fakta menarik: jika vertical sync aktif, latensi akan berbeda tergantung di mana sensornya ditempatkan

  • Baik artikel ini maupun tulisan yang ditautkan sama-sama menaruh sensor cahaya kira-kira di tengah monitor. Untuk membandingkan hasil ukur itu tidak masalah, tetapi pada cukup banyak monitor umum, pada 60Hz jika sensor diletakkan di bagian atas layar, hasilnya akan terukur sekitar 8ms lebih cepat, dan jika diletakkan di bawah akan sekitar 8ms lebih lambat. Ini karena piksel atau garis digerakkan dari atas ke bawah, pada dasarnya mirip CRT
    Jadi kalau mau masuk ke detail, hal ini juga perlu disebutkan, sama seperti menentukan ambang pada sinyal sensor cahaya untuk memutuskan kapan piksel dianggap menyala. Melihat angka-angka di artikel itu, 8ms adalah selisih yang cukup besar. Dengan cara yang sama, mengatakan “monitor X 30ms lebih lambat daripada monitor Y” juga bisa berlebihan. Lebih tepatnya, pada konfigurasi dan pengaturan saya X, Y, Z hasilnya terukur seperti itu. Perlu juga dicek apakah monitor menambahkan latensi sambil menerapkan fitur peningkatan aneh yang tidak memberi efek nyata, atau apakah saat mengganti monitor kartu grafis atau driver diam-diam mengubah koreksi, scaling, atau profil peningkatan seolah-olah membantu. Perangkat-perangkat seperti ini biasanya tidak memberi peringatan apa pun, dan saya benar-benar pernah melihat beberapa kasus seperti itu

    • Jika saya sedang melihat layar yang sedang discroll secara real-time, saya jauh lebih mungkin melihat sepertiga bawah layar

  • Lucu bahwa kita hidup di dunia yang bisa merender adegan 3D surealis dan game yang dulu tampak mustahil di hardware konsumen, tetapi pada saat yang sama masih berusaha menyempurnakan hal sesederhana menampilkan teks di terminal

    • Mungkin sebagian ini akibat optimalisasi yang lebih condong ke grafis. Ada trade-off di antara keduanya, dan makin bagus grafisnya, bisa jadi teks justru cenderung memburuk. Terminal memang memakai akselerasi GPU sehingga sedikit mengimbanginya, tetapi tetap saja harus membayar biaya pipeline grafis itu
    • Mungkin juga ada hal-hal yang dulu tidak terlalu penting. Dulu cukup sekadar “berfungsi”, dan sampai belum lama ini pada banyak kasus penggunaan terminal, latensi jaringan adalah masalah yang jauh lebih besar untuk diatasi

  • Tidak terkait dengan kecepatan, tetapi saya penasaran apakah ada terminal di Linux yang, seperti Mac OSX Terminal, saat ditutup lalu dibuka lagi bisa memulihkan semua tab, riwayat perintah tiap tab, dan scrollback-nya. Di Mac, ini ditangani dengan cara seperti menetapkan file riwayat bash yang berbeda untuk setiap tab
    Untuk keperluan ini saya lebih suka terminal GUI

    • Ceritanya agak berbeda, tetapi baru sekitar 1 jam yang lalu saya mengetahui bahwa iterm2 di Mac bisa terintegrasi dengan tmux. Jika tmux dijalankan dengan argumen -CC, sesi tmux dipetakan ke jendela dan tab GUI iterm2, dan ini juga bisa dilakukan saat memakai tmux di mesin jarak jauh lewat ssh
      Saya selalu lupa pintasan dan perintah kontrol tmux, jadi fitur ini cukup saya nantikan
      [1] https://iterm2.com/documentation-tmux-integration.html
    • Saya penasaran apa yang terjadi jika semua tab ditutup lalu tab baru dibuka. Apakah riwayat per tab saat ditutup akan digabung kembali ke file riwayat umum, sehingga perintah-perintah itu juga bisa dipakai di tab baru?
    • Saya memakai Tmux. Ini adalah multiplexer yang tidak terikat pada terminal tertentu, sehingga persistensi dan kemampuan otomatisasinya menjadi sangat kuat
      https://github.com/tmux/tmux/wiki
    • Jika Anda lebih suka terminal GUI mungkin ini tidak menarik, tetapi bisa berguna bagi sebagian orang: https://github.com/tmux-plugins/tmux-resurrect
      Tentu saja tmux bisa dipakai bersama emulator terminal GUI apa pun yang Anda inginkan
    • Saya juga sedang mencari hal yang persis seperti itu. Sekarang saya memakai tmux dan tmux-ressurect untuk mempertahankan status antar-reboot; lumayan berfungsi, tetapi tetap hanya hack yang terasa seperti hack
      Sayang sekali selain warp hampir tidak ada solusi sungguhan untuk masalah ini. Mimpi UX kecil saya adalah fitur penyimpanan ruang kerja seperti ini terintegrasi ke seluruh sistem operasi dan aplikasi di dalamnya. Itu akan keren

  • Setelah memakai Gnome selama beberapa tahun, 2 tahun lalu saya beralih ke sway dan alacritty, tetapi sejujurnya saya sama sekali tidak merasakan perbedaannya. Mungkin telinga dan mata saya tidak cukup terlatih untuk membedakannya, seperti perlengkapan audio kelas atas

    • Apakah Anda pernah mencoba kembali? Sering kali penurunan latensi lebih terasa saat latensi itu bertambah lagi
    • Saya sudah memakai Gnome selama beberapa tahun dan sekarang di Gnome 46, tetapi dibanding Gnome 45 saya tidak merasakan perbedaan latensi terminal. Sepertinya saya juga bukan tipe yang peka terhadap hal seperti ini
    • Mungkin ini bukan perbandingan yang adil, tetapi sekitar 20 tahun lalu, saat mengompilasi kernel, gnome-terminal memakai setengah CPU, jadi sejak itu saya memutuskan untuk tidak memakainya lagi. Xterm memakai sekitar 2%
    • Soal latensi atau responsivitas, satu-satunya hal yang saya pedulikan adalah apakah terminal membuat saya ingin muntah saat scroll di vim
    • Bisa jadi layar atau keyboard Anda sendiri sudah menambahkan latensi yang cukup besar, sehingga perangkat lunak apa pun tidak akan memberi hasil bagus. Perbedaan antara latensi buruk dan sangat buruk jadi tidak terlalu jelas. Saya penasaran apakah Anda sudah mencoba perangkat keras gaming

  • Akhirnya ada benchmark terminal yang bukan cuma cat file besar. Saya ingin melihat lebih banyak terminal lain, terutama konsol bawaan Linux, diuji dengan pengujian yang sama

  • Agak di luar topik, tetapi hal yang paling saya benci dari Gnome Terminal adalah ia membuka jendela kecil secara default. Ukurannya sekitar 1/4 layar saya, dan meski saya ubah ukurannya, setelah dijalankan ulang ukurannya tidak diingat. Akhirnya saya harus masuk ke pengaturan dan menetapkan jumlah kolom dan baris secara manual

    • Perilaku seperti itu cukup umum di banyak terminal. Yang langsung terlintas, macOS Terminal bawaan dan Windows Terminal sama-sama mengharuskan Anda mengubah ukuran default di pengaturan
      Secara pribadi, saya lebih suka membiarkan ukuran default apa adanya dan hanya me-resize jendela tertentu yang membutuhkan ruang lebih besar. Tetap saja, setidaknya harus ada opsi untuk mengingat hasil resize
    • Bisa diubah di pengaturan
      hamburger menu > Preferences > nama profil. Profil saya hanya bernama “Unnamed”. Ubah “initial terminal size” dan hasilnya akan sesuai keinginan. Saya menyetelnya ke 132x43
    • Saya sering membuka beberapa terminal dengan ukuran yang berbeda-beda. Tidak jelas ukuran mana yang seharusnya diingat
      Jadi saya harap mereka tidak mencoba melakukan itu. Tidak masalah jika perangkat lunak bersikap pintar saat benar-benar yakin dengan yang saya inginkan, tetapi kalau tidak, itu hanya jadi satu lagi contoh “Saya sudah mengacaukannya secara otomatis untuk Anda. Sama-sama.”
    • Console, terminal gnome yang lebih baru, mengingat ukuran jendela
    • Kalau tidak salah, ini adalah fitur yang berasal dari CMD.EXE

  • Saat sudah dirilis, akan bagus jika terminal Ghostty milik Mitchell Hashimoto juga dimasukkan ke benchmark. Saat ini masih dalam tahap pengembangan dan pemolesan, serta masih beta tertutup
    https://mitchellh.com/ghostty

  • Di debian saya memakai xterm dan i3wn, dan saya belum pernah merasakan sesuatu yang lebih cepat dari ini. Saya bahkan tidak pernah berpikir untuk memboroskan GPU pada terminal, jadi menurut saya alacritty itu berlebihan

    • Saya juga kurang lebih merasakan hal yang sama. Saat memakai xterm, saya tidak pernah memikirkan latensi. Saya bahkan memakai fitur berat seperti rendering dan sixel setiap hari, dan tetap tidak masalah. Sepertinya orang-orang meremehkannya karena gaya widget Athena, padahal sebenarnya ini luar biasa