GNOME 46 टर्मिनल की गति में कितना सुधार हुआ

 (bxt.rs)
3 पॉइंट द्वारा GN⁺ 2024-04-09 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • GNOME 46 cycle में VTE-आधारित terminals की input latency काफी घट गई है, और Fedora 40 tests में वे तेज़ baseline के रूप में इस्तेमाल किए गए Alacritty के लगभग बराबर पहुँच गए
  • मापन keyboard input से screen pixel change तक की end-to-end input latency को hardware sensor से मापने की विधि है, इसलिए kernel, compositor, app और monitor response time सभी इसमें शामिल होते हैं
  • सरल cat > /dev/null input और जटिल neovim scrolling दोनों में Console, VTE Test App और GNOME Terminal ने GNOME 45 की तुलना में स्पष्ट सुधार दिखाया
  • मुख्य बदलाव संभवतः यह है कि VTE पुराने 40Hz repaint timer के बजाय monitor से synchronized हर frame पर redraw करने की पद्धति पर चला गया
  • VTE 0.76 इस्तेमाल करने वाले GNOME 46 terminals में महसूस होने वाली latency कम हुई है, इसलिए जो users VTE-आधारित terminals को धीमा मानकर बचते थे, वे इन्हें फिर से आज़मा सकते हैं

VTE-आधारित terminals में क्या बदला

  • VTE कई GNOME terminal emulators का आधार बनने वाली Virtual TErminal library है
    • यह GTK widget के रूप में terminal view उपलब्ध कराती है
    • इसका उपयोग GNOME Terminal, Console, Black Box, Tilix, Terminator, Ptyxis आदि में होता है
    • Builder और Workbench के built-in terminals भी VTE इस्तेमाल करते हैं
  • GNOME 46 cycle के दौरान VTE में कई performance improvements आए, और users द्वारा वास्तव में महसूस की जाने वाली input latency मुख्य जांच विषय बनी

input latency मापने की विधि

  • input latency वह समय है जो keyboard key दबाने के क्षण से monitor pixel का रंग बदलने तक लगता है
    • latency जितनी कम हो, app उतना ही तुरंत respond करता हुआ महसूस होता है
    • कम और अधिक latency की बारी-बारी से तुलना करने पर फर्क ज्यादा साफ दिखता है
  • मापन के लिए software screen capture नहीं, बल्कि hardware input latency tester का उपयोग किया गया
    • एक optical sensor को Teensy board से जोड़ा गया, और board USB के जरिए computer से जुड़ा
    • sensor terminal के किसी खास character cell जैसे छोटे screen area को देखता है, जिसकी brightness key input से बदलती है
    • board Space जैसी key input भेजता है, light intensity change detect करता है, फिर Backspace जैसी दूसरी key से original state में वापस लौटाता है
    • repeats के बीच random wait time डाला जाता है ताकि measurement monitor refresh rate पर lock न हो जाए
  • यह तरीका kernel, compositor, application और monitor response time सहित end-to-end latency मापता है
    • keyboard firmware latency इसमें शामिल नहीं है
    • मौजूदा board और firmware में प्रति सेकंड लगभग 35,500 optical sensor values record होती हैं
  • हर test 120 बार दोहराया गया
    • points का distribution monitor के एक refresh cycle के आसपास समान रूप से फैला होना अपेक्षित pattern है
    • 144Hz monitor का refresh cycle लगभग 6.94ms है, और example graph के points 7–8ms range में फैले हैं
    • ज्यादा ऊँचे outliers या अधिक चौड़ा distribution test किए जा रहे app की latency या slow processing दर्शा सकता है

test environment और तुलना के target

  • test system Lenovo Legion 7 Gen 7 AMD laptop है
    • CPU Ryzen 7 6800H है
    • GPU Radeon RX 6700M dGPU है, और MUX switch से केवल dGPU इस्तेमाल किया गया
    • monitor Acer Nitro XV320QU, 2560×1440, 144Hz, 100% scale है
    • host Fedora 40 Silverblue Beta, Mesa 24.0.4 है
    • compositor raw Mutter 46.0 है
  • raw Mutter, GNOME Shell के बिना केवल Mutter चलाने वाला सरल test environment है
    • इसे mutter --display-server -- alacritty जैसे command से चलाया जा सकता है
    • यह GNOME Shell overhead लगभग न होने वाली ideal condition के करीब है
  • comparison के लिए चार terminals लिए गए
    • Alacritty: VTE-आधारित नहीं है, और पिछले tests में लगातार तेज़ terminal रहा है, इसलिए baseline की भूमिका निभाता है
    • Console: GTK 4 आधारित GNOME default terminal
    • VTE Test App: VTE repository में मौजूद GTK 4 test terminal
    • GNOME Terminal: GNOME 46 में GTK 3 app है, और कई distributions में default मिलता है
  • GNOME 45 और GNOME 46 की तुलना के लिए Fedora 39 और Fedora 40 toolbox containers इस्तेमाल किए गए
    • हर terminal को Fedora package के रूप में जस का तस install किया गया और बिना extra tuning के चलाया गया
    • window को monitor के top-left में रखा गया, और mouse cursor को window के बाहर रखा गया ताकि link detection logic results को distort न करे

सरल input और neovim scrolling results

  • पहला test cat > /dev/null चलाने के बाद Space input से block cursor के एक cell right move करने का time मापता है
    • यह readline जैसे extra processing के बिना minimum overhead scenario है
    • Alacritty में Fedora 39 से Fedora 40 जाने पर उम्मीद के मुताबिक कोई change नहीं है
    • VTE-आधारित terminals ने GNOME 45 की तुलना में GNOME 46 पर बड़ा सुधार दिखाया और Alacritty के लगभग समान level पर पहुँच गए
    • GTK 3 आधारित GNOME Terminal ने भी बहुत करीबी results दिखाए
  • बड़े सुधार का मुख्य कारण संभवतः Christian Hergert का VTE change है
    • यह पुराने 40Hz VTE repaint timer से हटता है
    • GTK widget की तरह monitor से sync होकर हर frame draw करने के तरीके पर बदल गया
  • Console में कुछ outliers थे, जिनकी वजह process tracing हो सकती है
    • ये outliers कोई नया phenomenon नहीं हैं
    • यह GNOME 47 में देखने लायक item के रूप में बचता है
  • दूसरा test अधिक realistic neovim configuration का उपयोग करता है
    • neovim settings snapshot में Ptyxis README खोला गया, और optical sensor detect कर सके इसके लिए कुछ text को Unicode full-block characters में बदला गया
    • Ctrl+D और Ctrl+U को repeat करके text buffer को ऊपर-नीचे scroll किया गया
    • terminal को underline, undercurl, gutter icons, status line जैसे screen elements draw करने पड़ते हैं
  • neovim test में भी GNOME 46 terminals का improvement साफ है
    • GNOME 46 के VTE-आधारित terminals अब भी लगभग Alacritty जैसे level पर हैं
    • सिर्फ Fedora 40 results देखें तो neovim test, simple cat test की तुलना में latency बढ़ाता है, लेकिन increase सभी terminals में लगभग समान है

vtebench ने दिखाए बाकी अंतर

  • vtebench input latency नहीं बल्कि PTY reading और parsing performance मापने वाला automated benchmark है
    • यह framerate या latency जैसे अहम factors को cover नहीं करता, इसलिए terminal performance को पूरी तरह समझने के लिए पर्याप्त नहीं है
    • यह terminal की PTY से read करने की speed पर ही ज्यादा दबाव डालता है
  • repaint time vtebench results को भी प्रभावित कर सकता है
    • खासकर VTE जैसे terminals में, जहाँ PTY reading/parsing और repaint logic एक ही thread में चलते हैं, इसका असर बड़ा हो सकता है
  • GNOME 46 का VTE vtebench में भी बेहतर हुआ है
    • improvement की मात्रा input latency tests की तुलना में ज्यादा varied है
    • यह Alacritty के level तक नहीं पहुँचता, जो reading और parsing को rendering से अलग thread में करता है
    • यह सुधार GNOME 46 cycle के दौरान VTE में आए कई optimizations से आया लगता है
  • dense_cells और unicode benchmarks को default result graph से हटाया गया
    • ये दोनों vtebench के मुख्य stress tests हैं
    • VTE अब भी इनमें काफी unstable results दिखाता है, जिससे graph की readability घटती है
  • test cases के आधार पर बचा हुआ difference लगभग negligible level के करीब है
    • कुछ अंतर इस बात से समझाए जा सकते हैं कि VTE accessibility, scrollbar calculation और अन्य features के लिए extra work करता है
    • accessibility GNOME Terminal में enabled है, और GTK 4 terminals में currently disabled है
    • VTE 0.76 इस्तेमाल करने पर GNOME 46 के improvements सहित performance मिलती है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-04-09
Hacker News की रायें

  • इस बदलाव की वजह से टेस्ट किए गए configuration में input latency का median आखिरकार Apple //e से कम हो गया। Console करीब 12ms था, जबकि 1983 का Apple //e 30ms था—यानी इसमें 41 साल लग गए
    https://www.extremetech.com/computing/261148-modern-computer...
    https://danluu.com/input-lag/
    हालांकि इस benchmark में GNOME Shell नहीं, बल्कि compositor raw Mutter 46.0 इस्तेमाल हुआ था, और raw mutter टेस्टिंग के लिए बने बहुत बुनियादी environment जैसा है। इसमें keyboard latency भी शामिल नहीं है, इसलिए यह end-to-end measurement भी नहीं है। इस टेस्ट में board USB के जरिए key input भेजता है, लेकिन keyboard की अपनी internal latency ही 60ms तक जा सकती है
    https://danluu.com/keyboard-latency/
    असल में अहम default configuration के वास्तविक end-to-end आंकड़े जानने की उत्सुकता है; अच्छा होता अगर article ने वही मापा होता। GNOME team और benchmark लेखक का काम शानदार है, लेकिन अहम सवाल बाकी है। Apple //e hardware acceleration इस्तेमाल करता था और Unicode भी handle नहीं करता था, इसलिए अंतर बहुत हैं, फिर भी अच्छा होगा अगर हम 41 साल से ज्यादा पुराने machine जैसी मानवीय responsiveness पर लौट सकें

    • मुझे तो लगता है कि लेखक ने keyboard latency को बाहर रखकर सही किया। अलग-अलग लोग अलग keyboard, USB interface, computer, operating system version इस्तेमाल करते हैं, और बीच में hub या KVM भी आ सकते हैं
      अगर ऐसे components की latency test के दौरान बहुत बदलती रहे, तो इस लेख के मुख्य विषय यानी VTE latency improvement का analysis मुश्किल हो जाएगा। भले ही वह पूरी तरह constant हो, तब भी वह absolute value में बस एक constant की तरह जुड़ती है, इसलिए निष्कर्ष नहीं बदलेगा। इसी वजह से latency difference को percentage में express नहीं करना चाहिए। sample set में normalize किया जा सकने वाला constant होता है, लेकिन पूरी user population में normalize न किए जा सकने वाले बहुत से constants होते हैं। Mutter वाला हिस्सा रोचक है; चूंकि GNOME Mutter के ऊपर चलता है, इसलिए absolute latency improvement लगभग वैसा ही दिखने की संभावना लगती है। हालांकि GNOME भी keyboard latency की तरह अनचाहा variation पैदा कर सकता है, इसलिए मैं इसे असल में verify होते देखना चाहूंगा
    • फिर Apple 2e इस्तेमाल कर लीजिए और modern operating system की convenience features छोड़ दीजिए। मुफ्त में देने की कोशिश कर रहे open-source developers को इतने लंबे तरीके से नीचा दिखाने जैसा यह तरीका मुझे स्वीकार करना मुश्किल लगता है
    • linked keyboard latency लेख की methodology में key के physical movement में लगने वाला समय भी शामिल किया गया है, यह बात मुझे हमेशा थोड़ी खटकती रही है
    • Unicode handling उतनी कठिन समस्या नहीं है जितनी लोग मानते हैं। कुछ अजीब edge cases हैं, लेकिन वे ज्यादा नहीं हैं और उन्हें हल करना भी आसान है
      इस लेख में सच में खटकने वाली बात यह थी कि latest test version से पहले Gnome में redraw speed fixed 40Hz थी। आखिर यह फैसला किसने किया था
    • keyboard latency लेख का 60ms वाला दावा संदिग्ध है। अगर key input से USB तक की latency keyboard में आम तौर पर 60ms होती, तो rhythm games literally खेलने लायक नहीं होते। लेकिन अब तक मैंने जितने भी keyboards इस्तेमाल किए हैं, उनमें ऐसा issue कभी नहीं आया

  • अच्छा है। VTE developers ने performance पर focus किया, यह भी अच्छा है, और लेख में hardware-based measurement process भी प्रभावशाली है
    latency measurement में optical sensor इस्तेमाल करने का तरीका Ben Heck के खुले-खुले नाम वाले “Xbox One Controller Monitor” [1] product की याद दिलाता है। यह product game console controller button state को सीधे पढ़ता है और optical sensor के साथ जोड़कर game developers को latency कम बनाए रखने में मदद करता है। दिखने में बढ़िया है, लेकिन कीमत 900 डॉलर है
    [1]: https://www.benheck.com/xbox1monitor/

    • performance पर focus करना हाल की बात है। VTE पहले काफी slow था
    • मजेदार तथ्य: अगर vertical sync on है, तो latency इस पर निर्भर करती है कि sensor कहां रखा गया है

  • इस लेख और linked लेख दोनों में optical sensor monitor के लगभग middle में रखा गया है। measured values की comparison में समस्या नहीं है, लेकिन कई आम monitors में 60Hz के हिसाब से sensor को screen के ऊपर रखने पर measurement लगभग 8ms तेज, और नीचे रखने पर लगभग 8ms धीमा आता है। ऐसा इसलिए होता है क्योंकि pixels या lines ऊपर से नीचे की ओर drive होती हैं, और मूल रूप से यह CRT जैसा ही है
    इसलिए अगर detail में जाएं, तो optical sensor signal में pixel on हुआ मानने के लिए threshold कहां रखना है, जैसी बातों के साथ इसका भी उल्लेख होना चाहिए। लेख के आंकड़ों को देखते हुए 8ms काफी बड़ा अंतर है। उसी तरह “monitor X, monitor Y से 30ms धीमा है” कहना भी अतिशयोक्ति हो सकता है। इसे ऐसे देखना चाहिए कि मेरे configuration और settings X, Y, Z में ऐसा measure हुआ। यह भी check करना चाहिए कि monitor कोई अजीब enhancement feature तो लागू नहीं कर रहा जो सिर्फ latency जोड़ता है और perceived effect नहीं देता, या monitor बदलते समय graphics card या driver मददगार बनने का दिखावा करते हुए correction, scaling, enhancement profile में चुपके से switch तो नहीं कर गया। ऐसे devices आम तौर पर कोई warning नहीं देते, और मैंने असल में ऐसे कुछ cases देखे हैं

    • अगर screen को real time में scroll होते देखना हो, तो मैं शायद screen के निचले 1/3 हिस्से को ज्यादा देखूंगा

  • यह मजेदार है कि हम ऐसी दुनिया में रहते हैं जहां consumer hardware पर असंभव लगने वाले hyper-realistic 3D scenes और games render होते हैं, और उसी समय terminal में text print करने जैसी चीज को अभी भी perfect बनाने की कोशिश चल रही है

    • मुझे लगता है इसका कुछ हिस्सा graphics के लिए ज्यादा optimization करने से आया होगा। दोनों के बीच trade-off है, और जैसे-जैसे graphics बेहतर होते हैं, text के खराब होने की प्रवृत्ति हो सकती है। terminal GPU acceleration इस्तेमाल करके कुछ हद तक इसकी भरपाई करता है, लेकिन फिर भी उस graphics pipeline की cost चुकानी पड़ती है
    • शायद पहले यह इतना महत्वपूर्ण भी नहीं था। “चल तो रहा है” वाली स्थिति थी, और हाल तक कई terminal use cases में हल करने लायक network latency काफी बड़ी थी

  • गति से संबंधित नहीं है, लेकिन जानना चाहता हूँ कि क्या Linux में Mac OSX Terminal जैसा कोई टर्मिनल है, जो बंद करके फिर खोलने पर सभी टैब, हर टैब की command history और scrollback वापस ला देता हो। Mac में यह हर टैब के लिए अलग bash history file सेट करने जैसे तरीके से किया जाता है
    इस काम के लिए मैं GUI टर्मिनल पसंद करता हूँ

    • थोड़ा अलग विषय है, लेकिन अभी 1 घंटे पहले पता चला कि Mac का iterm2 tmux के साथ integrate हो सकता है। tmux को -CC argument के साथ चलाने पर tmux session iterm2 की GUI windows और tabs में map हो जाता है, और ssh के जरिए remote machine के tmux का इस्तेमाल करने पर भी यह संभव है
      मैं tmux control shortcuts और commands हमेशा भूल जाता था, इसलिए यह feature काफी उम्मीद जगाता है
      [1] https://iterm2.com/documentation-tmux-integration.html
    • सोच रहा हूँ कि सभी tabs बंद करने के बाद नया tab खोलें तो क्या होता होगा। क्या tab-specific history बंद करते समय वापस सामान्य history file में merge हो जाती है, ताकि नए tab में भी वे commands इस्तेमाल की जा सकें
    • मैं Tmux इस्तेमाल करता हूँ। यह terminal-agnostic multiplexer है, इसलिए persistence और automation की क्षमता बहुत मजबूत हो जाती है
      https://github.com/tmux/tmux/wiki
    • अगर GUI टर्मिनल पसंद है तो शायद पसंद न आए, लेकिन किसी के लिए उपयोगी हो सकता है: https://github.com/tmux-plugins/tmux-resurrect
      बेशक tmux को किसी भी मनचाहे GUI terminal emulator के साथ इस्तेमाल किया जा सकता है
    • मैं बिल्कुल यही ढूँढ रहा था। अभी reboot के बीच state बनाए रखने के लिए tmux और tmux-ressurect इस्तेमाल करता हूँ; काम तो ठीक-ठाक करता है, लेकिन यह बस एक अच्छा hack है और अब भी hack जैसा ही लगता है
      warp को छोड़ दें तो इस समस्या के लिए असली समाधान बहुत कम हैं, यह अफसोस की बात है। मेरा छोटा-सा UX सपना है कि ऐसी workspace saving capability पूरे operating system और उसके अंदर की apps में integrate हो। ऐसा हो तो शानदार होगा

  • कई साल Gnome इस्तेमाल करने के बाद 2 साल पहले sway और alacritty पर शिफ्ट किया, लेकिन सच कहूँ तो फर्क बिल्कुल समझ नहीं आता। high-end audio equipment की तरह शायद मेरे कान और आँखें उस फर्क को पहचानने के लिए tuned नहीं हैं

    • कभी वापस जाकर देखा है? latency कम होने की तुलना में बढ़ने पर अक्सर ज्यादा अच्छी तरह महसूस होती है
    • मैं कई सालों से Gnome इस्तेमाल कर रहा हूँ और अभी Gnome 46 पर हूँ, लेकिन Gnome 45 की तुलना में terminal latency में फर्क महसूस नहीं हुआ। शायद मैं भी ऐसी चीजें अच्छे से महसूस नहीं कर पाता
    • शायद fair comparison न हो, लेकिन करीब 20 साल पहले kernel compile करते समय gnome-terminal CPU का आधा हिस्सा इस्तेमाल कर रहा था, इसलिए उसके बाद मैंने उसे इस्तेमाल न करने का फैसला किया। Xterm करीब 2% इस्तेमाल कर रहा था
    • latency या responsiveness में मेरे लिए मायने रखने वाली बात बस यह है कि vim में scroll करते समय terminal की वजह से उल्टी जैसा महसूस होता है या नहीं
    • screen या keyboard पहले से ही पर्याप्त latency जोड़ रहे हों, तो कोई भी software इस्तेमाल करने पर अच्छा result नहीं मिल सकता। खराब latency और बहुत खराब latency का फर्क इतना साफ नहीं होता। सोच रहा हूँ कि क्या आपने gaming hardware इस्तेमाल करके देखा है

  • आखिरकार ऐसा terminal benchmark आया जो सिर्फ विशाल file को cat करने तक सीमित नहीं है। मैं इसी test में और तरह-तरह के terminals, खासकर Linux default console, भी देखना चाहूँगा

  • विषय से थोड़ा हटकर, Gnome Terminal में मुझे सबसे खराब बात यह लगती है कि यह default में छोटी window खोलता है। यह मेरी screen के करीब 1/4 आकार की होती है, और size बदलने पर भी restart के बाद याद नहीं रखता। आखिरकार settings में जाकर columns और rows की संख्या खुद specify करनी पड़ती है

    • ऐसा behavior कई terminals में काफी आम है। तुरंत याद आने वाले उदाहरणों में default macOS Terminal और Windows Terminal दोनों में default size बदलने के लिए settings में जाना पड़ता है
      व्यक्तिगत रूप से मुझे default size छोड़कर, जिन खास windows को ज्यादा space चाहिए सिर्फ उन्हें resize करने का तरीका पसंद है। फिर भी resize याद रखने का option कम से कम होना चाहिए
    • settings में बदला जा सकता है
      hamburger menu > Preferences > profile name में जाएँ। मेरा profile बस “Unnamed” है। “initial terminal size” बदलें तो मनचाहा हो जाता है। मैंने 132x43 पर सेट कर रखा है
    • अक्सर अलग-अलग size के कई terminals खोलकर रखता हूँ। कौन-सा size याद रखना सही है, यह स्पष्ट नहीं है
      इसलिए मैं चाहता हूँ कि ऐसी कोशिश न की जाए। software जब पक्का जानता हो कि मुझे क्या चाहिए, तब smart behavior ठीक है; वरना यह एक और “मैंने आपके लिए अपने-आप गड़बड़ कर दी। धन्यवाद देंगे?” वाला मामला बन जाता है
    • नया gnome terminal Console window size याद रखता है
    • जहाँ तक याद है, यह feature CMD.EXE से आया था

  • जब public हो जाए, तो अच्छा होगा कि Mitchell Hashimoto का Ghostty terminal भी benchmark में शामिल हो। अभी यह development और polishing phase में है और private beta में है
    https://mitchellh.com/ghostty

  • debian पर xterm और i3wn इस्तेमाल करता हूँ और इससे तेज कुछ अनुभव नहीं किया। terminal पर GPU बर्बाद करने का विचार कभी आया भी नहीं, इसलिए alacritty मुझे व्यक्तिगत रूप से overkill लगता है

    • मुझे भी कुछ वैसा ही लगता है। xterm इस्तेमाल करते समय latency के बारे में कभी सोचा ही नहीं। translation feature या sixel जैसे heavy features रोज इस्तेमाल करने के बावजूद ऐसा है। लगता है लोग Athena widget style की वजह से इसे नजरअंदाज करते हैं, लेकिन असल में यह बेहतरीन है