GNOME 46 terminallerindeki hız artışı ne kadar?

 (bxt.rs)
3 puan yazan GN⁺ 2024-04-09 | 1 yorum | WhatsApp'ta paylaş
  • GNOME 46 döngüsünde VTE tabanlı terminallerin giriş gecikmesi büyük ölçüde azaldı; Fedora 40 testlerinde hızlı bir referans çizgisi olarak kullanılan Alacritty’ye neredeyse yaklaştı
  • Ölçüm, tuş basımından ekrandaki piksel değişimine kadar olan uçtan uca giriş gecikmesini donanım sensörüyle ölçtüğü için çekirdek, compositör, uygulama ve monitör yanıt süresi birlikte yansıtılıyor
  • Basit cat > /dev/null girdisi ile karmaşık neovim kaydırma senaryosunda Console, VTE Test App ve GNOME Terminal, GNOME 45’e kıyasla belirgin biçimde iyileşti
  • Temel değişikliğin, VTE’nin eski 40Hz repaint timer yerine monitörle senkronize şekilde her karede yeniden çizim yapmaya geçmesi olma ihtimali yüksek
  • VTE 0.76 kullanan GNOME 46 terminalleri, hissedilen gecikmeyi azaltıyor; bu yüzden VTE tabanlı terminalleri yavaş diye kaçınan kullanıcılar yeniden denemeye değer bulabilir

VTE tabanlı terminallerde neler değişti?

  • VTE, birçok GNOME terminal emülatörünün temelini oluşturan Virtual TErminal library'dir
  • GNOME 46 döngüsü boyunca VTE’ye birçok performans iyileştirmesi geldi ve kullanıcıların gerçekten hissettiği giriş gecikmesi başlıca doğrulama konusu oldu

Giriş gecikmesi nasıl ölçüldü?

  • Giriş gecikmesi, klavyede bir tuşa basıldığı andan monitörde bir pikselin renginin değiştiği ana kadar geçen süredir
    • Gecikme ne kadar düşükse uygulama o kadar anında tepki veriyormuş gibi hissedilir
    • Düşük ve yüksek gecikme art arda karşılaştırıldığında fark daha belirgin olur
  • Ölçüm için yazılımsal ekran yakalama yerine donanım tabanlı giriş gecikmesi test cihazı kullanıldı
    • Bir ışık sensörü Teensy karta bağlandı ve kart USB üzerinden bilgisayara bağlandı
    • Sensör, tuş girdisiyle parlaklığı değişen küçük bir ekran alanına, örneğin terminalde belirli bir karakter hücresine bakıyor
    • Kart, Space gibi bir tuş girdisi gönderip ışık değişimini algılıyor; ardından Backspace gibi ikinci bir tuşla durumu eski haline getiriyor
    • Ölçümün monitör yenileme hızına kilitlenmesini önlemek için tekrarlar arasına rastgele bekleme süresi ekleniyor
  • Bu yöntem, çekirdek, compositör, uygulama ve monitör yanıt süresini içeren uçtan uca gecikmeyi ölçüyor
    • Klavye firmware gecikmesi hariç tutuluyor
    • Mevcut kart ve firmware ile saniyede yaklaşık 35.500 ışık sensörü değeri kaydediliyor
  • Her test 120 kez tekrarlandı
    • Noktaların dağılımının, monitörün tek bir yenileme periyodu kadar düzgün yayılması beklenen bir durumdur
    • 144Hz monitörde bir yenileme periyodu yaklaşık 6,94 ms’dir ve örnek grafikteki noktalar 7–8 ms aralığına yayılır
    • Daha yüksek aykırı değerler veya daha geniş dağılım, test edilen uygulamada gecikme ya da yavaş işlemeye işaret edebilir

Test ortamı ve karşılaştırılan uygulamalar

  • Test sistemi Lenovo Legion 7 Gen 7 AMD dizüstü bilgisayardı
    • CPU: Ryzen 7 6800H
    • GPU: Radeon RX 6700M dGPU ve MUX anahtarıyla yalnızca dGPU kullanılıyor
    • Monitör: Acer Nitro XV320QU, 2560×1440, 144Hz, %100 ölçek
    • Host: Fedora 40 Silverblue Beta, Mesa 24.0.4
    • Compositör: raw Mutter 46.0
  • raw Mutter, GNOME Shell olmadan yalnızca Mutter’ın çalıştırıldığı basit bir test ortamıdır
    • mutter --display-server -- alacritty gibi komutlarla çalıştırılabilir
    • GNOME Shell yükünün neredeyse hiç olmadığı, ideale yakın bir koşuldur
  • Karşılaştırılan terminal sayısı dört
    • Alacritty: VTE tabanlı değildir; önceki testlerde sürekli hızlı çıkan bir terminal olduğu için referans çizgisi görevi görür
    • Console: GTK 4 tabanlı GNOME varsayılan terminali
    • VTE Test App: VTE deposundaki GTK 4 test terminali
    • GNOME Terminal: GNOME 46’da GTK 3 uygulamasıdır ve birçok dağıtımda varsayılan olarak sunulur
  • GNOME 45 ile GNOME 46 karşılaştırması için Fedora 39 ve Fedora 40 toolbox konteynerleri kullanıldı
    • Her terminal Fedora paketleriyle olduğu gibi kuruldu ve ek ayar yapılmadan çalıştırıldı
    • Pencere monitörün sol üstüne yerleştirildi, fare imleci ise bağlantı algılama mantığının sonucu bozmasını önlemek için pencerenin dışında tutuldu

Basit giriş ve neovim kaydırma sonuçları

  • İlk testte cat > /dev/null çalıştırıldı ve Space girdisiyle blok imlecin sağa bir hücre kayması için geçen süre ölçüldü
    • Bu, readline gibi ek işleme olmayan asgari ek yük senaryosudur
    • Alacritty, Fedora 39’dan Fedora 40’a geçildiğinde beklendiği gibi değişmedi
    • VTE tabanlı terminaller, GNOME 45’e kıyasla GNOME 46’da büyük ölçüde iyileşti ve Alacritty ile neredeyse aynı seviyeye ulaştı
    • GTK 3 tabanlı GNOME Terminal de buna çok yakın sonuç verdi
  • Büyük iyileştirmenin başlıca nedeni muhtemelen Christian Hergert’in yaptığı VTE değişikliği
    • Eski 40Hz VTE repaint timer kullanımından çıkıldı
    • Bir GTK widget'ı gibi monitörle senkronize şekilde her karede çizim yapmaya geçildi
  • Console’da birkaç aykırı değer vardı; bunun süreç izleme nedeniyle olması mümkün
    • Bu aykırı değerler yeni ortaya çıkmış bir durum değil
    • GNOME 47’de incelenebilecek bir konu olarak duruyor
  • İkinci test, daha gerçekçi bir neovim yapılandırması kullandı
    • neovim ayarları anlık görüntüsünde Ptyxis README açıldı ve ışık sensörünün algılayabilmesi için bazı metinler Unicode full-block karakterleriyle değiştirildi
    • Ctrl+D ve Ctrl+U tekrarlanarak metin tamponu aşağı ve yukarı kaydırıldı
    • Terminalin alt çizgi, undercurl, gutter simgeleri, durum çubuğu gibi ekran öğelerini çizmesi gerekiyor
  • neovim testinde de GNOME 46 terminallerindeki iyileşme belirgin
    • GNOME 46’daki VTE tabanlı terminaller hâlâ Alacritty’ye çok yakın seviyede
    • Yalnızca Fedora 40 sonuçlarına bakıldığında neovim testi, basit cat testine göre gecikmeyi artırıyor; ancak artış miktarı tüm terminallerde benzer

vtebench’in gösterdiği kalan farklar

  • vtebench, giriş gecikmesini değil PTY okuma ve ayrıştırma performansını ölçen otomatik bir benchmark’tır
    • Kare hızı veya gecikme gibi önemli unsurları ele almadığı için terminal performansının tamamını anlamak adına yeterli değildir
    • Esas olarak terminalin PTY’den ne kadar hızlı okuduğunu zorlar
  • repaint süresi vtebench sonuçlarını da etkileyebilir
    • Özellikle VTE gibi PTY okuma-ayrıştırma ile repaint mantığını aynı thread üzerinde çalıştıran terminallerde bu etki daha büyük olabilir
  • GNOME 46’daki VTE, vtebench’te de iyileşti
    • İyileşme miktarı giriş gecikmesi testlerine göre daha değişken
    • Okuma ve ayrıştırmayı render’dan ayrı thread’de yapan Alacritty seviyesine ulaşamıyor
    • Bu gelişme, GNOME 46 döngüsü boyunca VTE’ye eklenen çeşitli optimizasyonlardan kaynaklanıyor gibi görünüyor
  • dense_cells ve unicode benchmark’ları varsayılan sonuç grafiklerine dahil edilmedi
    • Bu iki test vtebench’in başlıca stres testleri
    • VTE hâlâ bu testlerde ciddi dalgalanma gösterdiği için grafiklerin okunabilirliğini düşürüyor
  • Test senaryolarına göre kalan fark neredeyse ihmal edilebilir düzeye yakın
    • Bazı farklar, VTE’nin erişilebilirlik, kaydırma çubuğu hesaplaması ve diğer özellikler için ek iş yapmasıyla açıklanabilir
    • Erişilebilirlik GNOME Terminal’de etkin, GTK 4 terminallerde ise şu anda devre dışı
    • VTE 0.76 kullanıldığında GNOME 46’daki iyileştirmeleri içeren performans elde edilebilir

İlgili okumalar

1 yorum

 
GN⁺ 2024-04-09
Hacker News yorumları

  • Bu değişiklik sayesinde, test edilen yapılandırmada giriş gecikmesinin medyanı nihayet Apple //e'den daha düşük oldu. Console yaklaşık 12 ms, 1983 tarihli Apple //e ise 30 ms idi; yani bu 41 yıl sürdü
    https://www.extremetech.com/computing/261148-modern-computer...
    https://danluu.com/input-lag/
    Ancak bu benchmark GNOME Shell'i değil, bir compositor olan raw Mutter 46.0'ı kullandı; raw mutter test amaçlı sayılabilecek oldukça temel bir ortam. Ayrıca klavye gecikmesini içermediği için uçtan uca bir ölçüm de değil. Bu testte kart, tuş girişlerini USB üzerinden gönderiyor; oysa yalnızca klavyenin iç gecikmesi bile 60 ms'ye kadar çıkabiliyor
    https://danluu.com/keyboard-latency/
    Asıl önemli olan varsayılan yapılandırmadaki gerçek uçtan uca değerleri merak ediyorum; keşke makalede bunlar ölçülseydi. GNOME ekibinin ve benchmark yazarının çalışması harika, ama önemli soru hâlâ duruyor. Apple //e donanım hızlandırma kullanıyordu ve Unicode da işlemiyordu, dolayısıyla arada çok fark var; yine de 41 yılı aşkın bir makinenin insani tepki hızına geri dönebilsek güzel olurdu

    • Bence yazarın klavye gecikmesini hariç tutması aksine doğru olmuş. Herkes farklı klavye, USB arayüzü, bilgisayar, işletim sistemi sürümü kullanıyor; araya hub veya KVM bile girebiliyor
      Bu tür bileşenlerin gecikmesi test sırasında ciddi biçimde oynarsa, bu yazının odağı olan VTE gecikme iyileştirmesini analiz etmek zorlaşır. Tamamen sabit olsa bile mutlak değere yalnızca bir sabit gibi eklenir, sonuç değişmez. Bu yüzden gecikme farklarını yüzde olarak ifade etmemek gerekir. Örneklem kümesinde normalize edilebilecek bir sabit vardır, ama tüm kullanıcı kitlesinde normalize edilemeyen çok sayıda sabit bulunur. Mutter kısmı ilginç; GNOME Mutter'ın üzerinde çalıştığı için mutlak gecikme iyileştirmesinin benzer görünme ihtimali var. Yine de GNOME da klavye gecikmesi gibi istenmeyen oynaklıklar yaratabileceğinden bunu gerçekten doğrulamak isterim
    • O zaman Apple 2e kullanıp modern işletim sistemlerinin kolaylıklarından vazgeçebilirsiniz. Ücretsiz sunmaya çalışan açık kaynak geliştiricilerini uzun uzun küçümseyen bir üslup gibi geldiği için kabul etmesi zor
    • Bağlantı verilen klavye gecikmesi yazısının metodolojisinde tuşun fiziksel olarak hareket ettiği süreyi de dahil etmeleri beni hep biraz rahatsız etmiştir
    • Unicode işleme, insanların sandığı kadar zor bir problem değil. Garipleşen sınır durumları var, ama çok değil ve çözmeleri de kolay
      Bu yazıda asıl beni rahatsız eden şey, en yeni test sürümünden önce Gnome'da yeniden çizim hızının sabit 40 Hz olmasıydı. Buna kim karar vermiş acaba
    • Klavye gecikmesi yazısındaki 60 ms iddiası şüpheli. Tuşa basıştan USB'ye kadar olan gecikme klavyelerde yaygın olarak 60 ms olsaydı, ritim oyunları kelimenin tam anlamıyla oynanamaz olurdu. Oysa şimdiye kadar kullandığım hiçbir klavyede böyle bir sorun yaşamadım

  • Güzel. VTE geliştiricilerinin performansa odaklanması da iyi; yazıdaki donanım tabanlı ölçüm süreci de etkileyici
    Gecikme ölçümünde ışık sensörü kullanmaları, Ben Heck'in oldukça açık isimli “Xbox One Controller Monitor” [1] ürününü hatırlattı. Oyun konsolu kontrolcüsünün düğme durumunu doğrudan okuyup ışık sensörüyle birleştirerek oyun geliştiricilerinin gecikmeyi düşük tutmasına yardımcı olan bir ürün. Havalı görünüyor ama fiyatı 900 dolar
    [1]: https://www.benheck.com/xbox1monitor/

    • Performansa odaklanmaya başlamaları yakın zamanlı bir şey. VTE eskiden epey yavaştı
    • İlginç bilgi: dikey senkronizasyon açıksa gecikme, sensörü nereye koyduğunuza göre değişir

  • Hem bu yazıda hem de bağlantılı yazıda ışık sensörünü monitörün yaklaşık ortasına koymuşlar. Ölçüm değerlerini karşılaştırmak için sorun yok, ama tipik monitörlerin önemli bir kısmında 60 Hz'de sensörü ekranın üst tarafına koyarsanız yaklaşık 8 ms daha hızlı, alt tarafına koyarsanız yaklaşık 8 ms daha yavaş ölçersiniz. Çünkü pikseller ya da satırlar yukarıdan aşağıya sürülür; temelde CRT'ye benzer
    Dolayısıyla ayrıntıya girilecekse, ışık sensörü sinyalinde pikselin yandığına karar vermek için eşiğin nereye konacağı gibi bu noktanın da belirtilmesi gerekir. Yazıdaki değerlere bakınca 8 ms oldukça büyük bir fark. Benzer şekilde “X monitörü Y monitöründen 30 ms daha yavaş” demek de abartı olabilir. Bunu, benim yapılandırmamda ve X, Y, Z ayarlarında böyle ölçüldü diye görmek gerekir. Monitörün yalnızca gecikme ekleyen ve hissedilir bir etkisi olmayan tuhaf iyileştirme özellikleri uygulayıp uygulamadığını; monitörü değiştirirken ekran kartının veya sürücünün yardımseverlik taslayıp düzeltme, ölçekleme ya da iyileştirme profillerini gizlice değiştirip değiştirmediğini de kontrol etmek gerekir. Bu cihazlar genelde hiçbir uyarı vermez; gerçekten gördüğüm birkaç örnek var

    • Ekranın gerçek zamanlı kaydığını izliyorsam, büyük olasılıkla ekranın alt 1/3 kısmına bakarım

  • Tüketici donanımında imkânsız gibi görünen aşırı gerçekçi 3D sahneleri ve oyunları render ettiğimiz bir dünyada yaşarken, aynı zamanda terminale metin yazdırma işini hâlâ kusursuz hâle getirmeye çalışıyor olmamız komik

    • Bunun bir kısmı grafiklere daha fazla optimizasyon yapılmasının sonucu olabilir. İkisi arasında bir ödünleşim var; grafikler iyileştikçe metin kötüleşme eğiliminde olabilir. Terminalin GPU hızlandırma kullanması bunu kısmen telafi ediyor, ama yine de o grafik pipeline maliyetini ödüyorsunuz
    • Belki eskiden çok da önemli görülmüyordu. “Çalışıyor işte” düzeyindeydi; yakın zamana kadar birçok terminal kullanım senaryosunda çözülmesi gereken ağ gecikmesi büyüktü

  • Hızla ilgili değil ama Linux’ta, Mac OSX Terminal gibi kapatıp yeniden açınca tüm sekmeleri, her sekmenin komut geçmişini ve scrollback’ini geri getiren bir terminal olup olmadığını merak ediyorum. Mac tarafı bunu her sekme için farklı bir bash geçmiş dosyası ayarlayarak hallediyor
    Bu kullanım için GUI terminal tercih ediyorum

    • Biraz farklı bir konu ama az önce, 1 saat önce Mac’te iterm2’nin tmux ile entegre olabildiğini öğrendim. tmux’u -CC argümanıyla çalıştırınca tmux oturumu iterm2’nin GUI pencerelerine ve sekmelerine eşleniyor; ssh ile uzak makinedeki tmux’u kullanırken de mümkün
      tmux kontrol kısayollarını ve komutlarını hep unutuyordum; bu özellik beni epey heyecanlandırdı
      [1] https://iterm2.com/documentation-tmux-integration.html
    • Tüm sekmeleri kapattıktan sonra yeni bir sekme açınca ne olduğunu merak ediyorum. Sekme bazlı geçmiş, kapatırken normal geçmiş dosyasına geri birleştirilip yeni sekmede de o komutları kullanmayı mı sağlıyor?
    • Ben Tmux kullanıyorum. Terminalden bağımsız bir çoklayıcı olduğu için kalıcılık ve otomasyon yetenekleri güçlü hale geliyor
      https://github.com/tmux/tmux/wiki
    • GUI terminal tercih ediyorsanız hoşunuza gitmeyebilir ama birileri için faydalı olabilir: https://github.com/tmux-plugins/tmux-resurrect
      Elbette tmux, istediğiniz herhangi bir GUI terminal emülatörüyle birlikte kullanılabilir
    • Tam da aynı şeyi arıyordum. Şu anda yeniden başlatmalar arasında durumu korumak için tmux ve tmux-ressurect kullanıyorum; fena çalışmıyor ama iyi bir hack’ten ibaret ve hâlâ hack gibi hissettiriyor
      warp dışında bu sorun için gerçek bir çözümün neredeyse olmaması üzücü. Benim küçük UX hayalim, böyle bir çalışma alanı kaydetme özelliğinin işletim sisteminin tamamına ve içindeki uygulamalara entegre edilmesi. Harika olurdu

  • Birkaç yıl Gnome kullandıktan sonra 2 yıl önce sway ve alacritty’ye geçtim; açıkçası hiçbir farkı anlayamıyorum. Üst seviye ses ekipmanlarında olduğu gibi, kulaklarım ve gözlerim o farkı ayırt edecek şekilde ayarlı değil sanırım

    • Hiç geri dönmeyi denedin mi? Gecikme azalırken değil de artarken çoğu zaman daha iyi hissedilir
    • Birkaç yıldır Gnome kullanıyorum ve şu anda Gnome 46’dayım; Gnome 45’e kıyasla terminal gecikmesinde bir fark hissetmedim. Ben de bu tür şeyleri pek fark etmeyenlerdenim galiba
    • Adil bir karşılaştırma olmayabilir ama yaklaşık 20 yıl önce çekirdek derlerken gnome-terminal CPU’nun yarısını kullanıyordu; o günden sonra kullanmamaya karar verdim. Xterm yaklaşık %2 kullanıyordu
    • Gecikme veya tepki hızı konusunda benim için önemli olan tek şey, vim’de kaydırırken terminal yüzünden midemin bulanıp bulanmadığı
    • Ekran ya da klavye zaten yeterince gecikme ekliyor olabilir; bu yüzden hangi yazılımı kullanırsanız kullanın iyi sonuç alamayabilirsiniz. Kötü gecikme ile çok kötü gecikme arasındaki fark o kadar belirgin değil. Oyun donanımı denediniz mi merak ediyorum

  • Sonunda yalnızca devasa dosyaları cat etmekten ibaret olmayan bir terminal benchmark’ı çıktı. Aynı testte daha fazla terminali, özellikle de Linux’un varsayılan konsolunu görmek isterdim

  • Konu dışı ama Gnome Terminal’de en sevmediğim şey varsayılan olarak küçük bir pencere açması. Ekranımın yaklaşık 1/4’ü boyutunda ve yeniden boyutlandırsam da yeniden başlatınca hatırlamıyor. Sonunda ayarlara girip sütun ve satır sayısını elle belirtmek gerekiyor

    • Bu davranış birçok terminalde oldukça yaygın. Aklıma hemen gelenlerden varsayılan macOS Terminal ve Windows Terminal de varsayılan boyutu ayarlardan değiştirmenizi gerektiriyor
      Kişisel olarak varsayılan boyutu bırakıp, daha büyük alana ihtiyaç duyan belirli pencereleri yeniden boyutlandırmayı tercih ediyorum. Yine de yeniden boyutlandırmayı hatırlama seçeneği en azından olmalı
    • Ayarlardan değiştirilebilir
      Hamburger menüsü > Preferences > profil adına girmeniz yeterli. Benim profilim sadece “Unnamed”. “initial terminal size”ı değiştirince istediğiniz gibi oluyor. Ben 132x43 olarak ayarladım
    • Çoğu zaman farklı boyutlarda birden fazla terminal açık tutuyorum. Hangi boyutun hatırlanmasının doğru olduğu net değil
      Bu yüzden böyle bir şey denenmesin isterim. Yazılım ne istediğimden emin olabiliyorsa akıllı davranması sorun değil; değilse bu da bir başka “Sizin için otomatik olarak mahvettim, teşekkür edersiniz değil mi?” vakası oluyor
    • Daha yeni gnome terminali olan Console pencere boyutunu hatırlıyor
    • Hatırladığım kadarıyla bu, CMD.EXE’den gelen bir özellikti

  • Herkese açıldığında Mitchell Hashimoto’nun Ghostty terminalinin de benchmark’a dahil edilmesi güzel olurdu. Şimdilik geliştirme ve cilalama aşamasında, kapalı beta
    https://mitchellh.com/ghostty

  • Debian’da xterm ve i3wn kullanıyorum; bundan daha hızlısını deneyimlemedim. Terminal için GPU harcamayı hiç düşünmedim bile, bu yüzden alacritty bana şahsen fazla geliyor

    • Ben de benzer hissediyorum. xterm kullanırken gecikmeyi hiç düşünmedim. Çeviri özelliği veya sixel gibi ağır özellikleri her gün kullanmama rağmen böyle. İnsanlar Athena widget stili yüzünden görmezden geliyor gibi ama aslında harika