तेज़ मशीनें, धीमी मशीनें

• Windows NT 3.51 चलाने वाले पुराने कंप्यूटर और Windows 11 चलाने वाले नए कंप्यूटर की गति की तुलना करने वाला एक वीडियो Twitter पर साझा किया गया, और वह काफ़ी वायरल हुआ
  • दोनों एक ही काम करते हैं: Command Prompt, Explorer, Notepad, और Paint ऐप खोलना और बंद करना
  • पुराने कंप्यूटर पर यह तुरंत चलता है, लेकिन नए कंप्यूटर पर धीमा है
• आधुनिक कंप्यूटरों में user interface latency बहुत खराब है और बदतर होती जा रही है
• यह भी कहा गया कि तुलना में इस्तेमाल किया गया hardware desktop और laptop (Surface Go) होने की वजह से निष्पक्ष नहीं था
• K7-600 मशीन पर Windows 2000 इंस्टॉल करके, और Mac Pro 2013 (6-core Xeon + 32GB) पर Windows 11 इंस्टॉल करके फिर से तुलना की गई, लेकिन नतीजे मिलते-जुलते रहे

कंप्यूटरों की प्रगति

• 2000 के दशक के बाद कई दिशाओं में प्रगति हुई: शानदार graphics, high-resolution monitors, ultra-fast networks, real-time video editing आदि
• I/O के क्षेत्र में भी बहुत प्रगति हुई, क्योंकि पुराने सिस्टम में disk I/O हमेशा सबसे कमज़ोर हिस्सा होता था
  • floppy अविश्वसनीय और धीमी थी, CD/DVD कुछ अधिक भरोसेमंद थे लेकिन फिर भी धीमे थे, और HDD कई चीज़ों में bottleneck था
  • random I/O भौतिक सीमाओं तक पहुँचने लगा था
• SSD के आने और desktop में इस्तेमाल होने से इस random I/O समस्या का समाधान शुरू हुआ
  • अचानक सब कुछ तेज़ हो गया: booting, game loading, बहुत सारी files वाले folder खोलना, आदि
• नया hardware इंस्टॉल करना भी आसान हुआ, wireless connectivity आम हो गई, और text/apps का internationalization बढ़ा (यह मानते हुए कि Unicode न आसान था न सस्ता)
• कई मायनों में स्थिति बेहतर हुई और हमारे पास पहले से ज़्यादा क्षमता आई। नहीं तो 2000 के दशक में कल्पना से बाहर रही चीज़ें, जैसे छोटे मोबाइल फ़ोन पर ML से photo processing, संभव नहीं होतीं

भयानक latency

• लेकिन इन प्रगतियों में से कोई भी यह नहीं समझाता कि आज UI latency इतनी बेहद धीमी क्यों है
• hardware की प्रगति को इस स्थिति को बेहतर करना चाहिए था

उदाहरण

• Notepad हाल तक native app था और तेज़ी से खुलता था, लेकिन UWP ऐप के रूप में दोबारा लिखे जाने पर धीमा हो गया। बहुत धीमा होने के बावजूद उसमें अब भी features की कमी है। यह उपयोगकर्ता के लिए बिना किसी लाभ के speed कम होना है
• Windows Terminal पहले से बहुत बेहतर है, लेकिन साफ़ तौर पर भारी है। PowerShell जोड़ने पर, top-end hardware न होने की स्थिति में नई terminal window खुलने में कई सेकंड लग सकते हैं
• macOS Windows से बेहतर है, लेकिन उसमें भी समस्या है। Settings window खोलने की रफ़्तार पुराने मशीनों पर कहीं अधिक तेज़ है
• Linux शायद इन समस्याओं से सबसे कम प्रभावित है। 11 साल पुराने PC पर भी April 2023 में रिलीज़ हुई Fedora Linux 38 अच्छी तरह चलती है। लेकिन यह भी एक भ्रम है; जब ऐसे modern apps चलाए जाते हैं जो खास Linux के लिए विकसित नहीं किए गए, तो app startup time धीमा हो जाता है और सामान्य performance गिरती है
• मुझे सबसे बड़ा झटका तब लगा जब 2009 में मैं Google में शामिल हुआ
  • उस समय Google Search और Gmail बेहतरीन performance के लिए मशहूर थे और मिसाल माने जाते थे
  • लेकिन अंदर इस्तेमाल होने वाले in-house command-line tools कितने धीमे थे, यह देखकर मुझे बड़ा झटका लगा
  • मेरा मानना है कि उन्होंने किसी भी क़ीमत पर web apps को लगातार आगे बढ़ाया, और उसी ने आज की यह स्थिति बनाई

कारण

• यह सब क्यों हुआ? इसे "Bloat" कहना आसान है, लेकिन परिभाषित करना कठिन
  • Bloat को उचित भी ठहराया जा सकता है: हर व्यक्ति की Bloat को लेकर अलग राय होती है
• चीज़ों को धीमा बनाने वाली असली वजह "priorities" हैं
  • games/video transcoding जैसे महत्वपूर्ण मामलों को छोड़कर अब लगभग कोई performance को प्राथमिकता नहीं देता
  • लोग और कंपनियाँ जिस चीज़ को प्राथमिकता देती हैं, वह है "developer time": Rust और Electron
• हर platform के लिए अलग native app बनाना दोहराव वाला काम माना जाता है, इसलिए Electron का उपयोग किया जाता है
  • इसका इस्तेमाल आसान है, लेकिन इसका desktop latency पर बड़ा असर पड़ता है
  • 1Password और Spotify जैसे मामलों में एकीकृत अनुभव देने और लागत कम करने के लिए Electron में दोबारा लिखा गया
  • लेकिन लागत में कटौती कंपनी के लिए है, उपयोगकर्ता के लिए नहीं
  • यह लागत-कटौती उन लोगों पर रोज़ का tax है जो इन apps का रोज़ इस्तेमाल करते हैं
• latency बढ़ाने वाला एक और फ़ैसला managed और interpreted भाषाओं को बड़े पैमाने पर अपनाना है
  • JDK/CLR लंबे समय तक चलने वाली processes को optimize करने में अच्छे हैं, लेकिन fast startup time उनका मजबूत पक्ष नहीं है

एक-बार वाले सुधार खत्म हो गए (One-off improvements eaten away)

• आखिर में, hardware की प्रगति पर लौटते हुए एक निराशावादी बात के साथ समाप्त करें
• SSD जो खास सुधार लेकर आया था, वह एक-बार का बदलाव था
  • HDD लगातार तेज़ हुए, लेकिन desktop के लिए ज़रूरी तेज़ random I/O नहीं दे पाए
  • SSD की ओर बदलाव ने बिल्कुल अलग स्तर का सुधार दिया, लेकिन इसका लाभ हम केवल एक बार ही ले सकते थे
  • ऐसा कोई दूसरा technology shift नहीं है जो उतना ही क्रांतिकारी अनुभव दे
  • इसलिए जब इस नई technology का लाभ लापरवाह software की वजह से खत्म हो जाएगा, तो हम फिर वहीं लौट आएँगे जहाँ से शुरू किया था
  • बेशक SSD लगातार तेज़ हो रहे हैं, लेकिन HDD से SSD में बदलाव जैसी विशाल छलांग अब नहीं मिलती
• SSD के बिना Windows/macOS के नए versions इस्तेमाल करके इसे सीधे महसूस किया जा सकता है
• यही वजह है कि Apple Silicon को लेकर चिंता होती है
  • M1 लॉन्च के समय की शानदार performance, बहुत लंबी battery life, और बिना fan noise का अनुभव याद है?
  • अगर हम इसी लापरवाह दिशा में चलते रहे, तो ये फ़ायदे भी गायब हो जाएँगे, और तब तक बहुत देर हो चुकी होगी
• मौजूदा applications में performance सुधार जोड़ना तकनीकी रूप से बहुत कठिन है, और संगठनों के भीतर इसे priority देना लगभग असंभव है
• तो क्या computer architects किसी और क्रांतिकारी technology shift से हमें बचा सकते हैं? मैं उस पर निर्भर नहीं रहना चाहता। इसलिए नहीं कि ऐसा बदलाव संभव नहीं हो सकता, बल्कि इसलिए कि उसकी ज़रूरत ही नहीं होनी चाहिए

GN⁺ द्वारा संक्षिप्त संस्करण (रिकॉर्ड के लिए रखा गया)

• एक Twitter thread, जिसमें पुराने और नए कंप्यूटरों की responsiveness की तुलना की गई थी, को 8.8K likes मिले।
• वीडियो में पुराने कंप्यूटर पर apps तुरंत खुलते हैं, जबकि नए कंप्यूटर पर उनमें काफ़ी देरी होती है।
• लेखक ने सवाल उठाया कि hardware में प्रगति के बावजूद आधुनिक कंप्यूटरों की user interface latency क्यों बदतर हो गई है।
• तुलना की खामियाँ ठीक करने के बाद भी वही परिणाम मिला।
• graphics, high-resolution monitors, और fast networks जैसी तकनीकी प्रगति पर चर्चा की गई।
• यह दावा किया गया कि आधुनिक कंप्यूटरों की user interface latency बहुत खराब है और और बिगड़ रही है।
• Windows, macOS, और Linux में धीमे apps के उदाहरण दिए गए।
• भारी software, frameworks, और managed languages को latency समस्या के कारण के रूप में सुझाया गया।
• लापरवाह software के कारण SSD के लाभ बेअसर हो रहे हैं, जिससे Apple Silicon के भविष्य को लेकर चिंता जताई गई।
• मौजूदा applications में performance सुधार करना तकनीकी और संगठनात्मक दोनों रूप से कठिन है।
• computer architects के अनुसार, हो सकता है कि क्रांतिकारी तकनीकी बदलाव हमें बचा न पाएँ।
• latency समस्या के लिए remote work कोई समाधान नहीं है।
• 1990 और 2000 के दशक का open source development पहले ही पूरी तरह distributed और asynchronous work को संभव बना चुका था।
• कंप्यूटर latency कम-से-कम 1977 से एक समस्या रही है।
• Dan Luu के अनुसार latency के लिहाज़ से सबसे बेहतरीन कंप्यूटर 1983 का था, लेकिन वह आधुनिक workloads को संभाल नहीं सकता।

[nuthatch]

शायद हम यहीं तक इस सोच के साथ पहुँचे हैं कि परफ़ॉर्मेंस की जगह maintainability चुनी जाए, और उसकी कीमत hardware की प्रगति से पूरी कर ली जाए।
जब 2010 MacBook Air बहुत धीमा हो गया था, तब किसी तरह मैंने उस पर Snow Leopard इंस्टॉल किया, और वह अविश्वसनीय रूप से तेज़ था। बेशक, मैं उसे वास्तव में इस्तेमाल नहीं करता हूँ, लेकिन..

[googol]

अब यह बात सच में महसूस होती है कि कंपनियां अब performance को प्राथमिकता नहीं देतीं।

[anyjava]

लेकिन लागत में कटौती कंपनी के लिए होती है, उपयोगकर्ताओं के लिए नहीं

यह हिस्सा बहुत सोचने पर मजबूर करता है।

[edunga1]

धन्यवाद। इसे पढ़ते हुए गहरा जुड़ाव महसूस हुआ।
Windows डेस्कटॉप पर context menu खोलें तो 20 साल पहले हो या आज, hourglass देखते हुए यह धीमा ही लगता है (पहली बार के बाद थोड़ा बेहतर होता है, लेकिन फिर भी बहुत खटकता है)।
हार्डवेयर तो निश्चित ही तेज़ हो रहा है, लेकिन लगता है software वैसा नहीं हो पा रहा।

[ruinnel]

कुछ मिलती-जुलती बात करते हुए, मुझे लगता है मैंने सिर्फ हल्के applications (शायद Linux वाली तरफ) इकट्ठा करके रखी हुई एक साइट देखी थी... लेकिन जब सच में खोजा तो मिली ही नहीं, हाहा

[nicewook]

आभार, मैंने इसे रुचि के साथ पढ़ा।

[iolothebard]

क्या महत्वपूर्ण है?

[devjeonghwan]

जब सिर्फ WinAPI से implementation होता था, तब का UI साफ-सुथरा और फुर्तीला होता था.
आजकल तरह-तरह के बेतरतीब UI frameworks हैं, ऊपर से ये web-based apps भी... web engine या framework engine चलाने के लिए काफ़ी resources लगते हैं.

[xguru]

यह GN⁺ पर आया हुआ लेख है, लेकिन AI के summary से इसे समझना मुश्किल लग रहा था, इसलिए मैंने इसे फिर से व्यवस्थित किया है।

[botplaysdice]

देखा, मैं सही कह रहा था ना, हाहा...

यह कुछ वैसा ही एहसास है जैसे Lee Sedol की जीत हुई थी... हमारी job security.... अभी के लिए तो ठीक रहेगी, है ना? आह

[GN⁺]

Hacker News राय

• युवा उपयोगकर्ताओं ने software stack में असली performance का अनुभव नहीं किया है
• software engineers अक्षम हैं और parallel computing को नज़रअंदाज़ करते हैं
• non-technical लोग धीमी computing की परवाह नहीं करते
• security उपाय desktop apps की latency को प्रभावित कर सकते हैं
• macOS में Quartz Extreme और Metal के साथ graphics performance बेहतर होती है
• speed के लिए software optimization महत्वपूर्ण है
• Rust का learning curve बहुत कठिन नहीं है
• छोटे computing achievements का जश्न मनाना महत्वपूर्ण है
• हमें अपने hardware से और अधिक उम्मीद करनी चाहिए
• dynamic UI performance गिरावट में योगदान देता है
• Linux low-spec hardware पर तेज़ चलता है, लेकिन cross-platform apps की performance खराब होती है
• modern application frameworks app startup time धीमा होने का कारण बन सकते हैं