- Macintosh को 68000 microprocessor की वजह से तेज़ computer माना जाता था, लेकिन असल इस्तेमाल में floppy disk ही speed की bottleneck बन गई
- Steve Jobs को खास तौर पर जिस बात से समस्या थी, वह power on करने के बाद memory test, operating system initialization और Finder loading तक चलने वाला boot time था
- Jobs ने Larry Kenyon पर दबाव डालते हुए कहा कि अगर boot को 10 सेकंड कम किया जाए, तो 50 लाख users हर दिन 5 करोड़ सेकंड बचाएँगे, और एक साल में यह दर्जनों लोगों की पूरी ज़िंदगी के बराबर होगा
- टीम पहले से ही software performance सुधारने के लिए motivated थी, इसलिए यह साफ नहीं है कि इस गणना का वास्तव में कितना असर पड़ा
- नतीजतन, Macintosh team ने कुछ महीनों बाद boot time को 10 सेकंड से ज़्यादा कम कर दिया, और Jobs-स्टाइल persuasion एक मज़ेदार किस्से के रूप में रह गया
Macintosh की bottleneck floppy disk थी
- Macintosh team ने माना कि 68000 microprocessor Apple II से व्यवहार में 10 गुना तेज़ है, इसलिए वे इसे तेज़ computer समझते थे
- लेकिन RAM सीमित थी, इसलिए floppy से data अक्सर पढ़ना पड़ता था, और इस मामले में यह Apple II से तेज़ नहीं था
- जब वास्तविक applications चलने लगीं, तो floppy disk मुख्य bottleneck के रूप में सामने आई
Steve Jobs ने boot time पर ज़िद्दी नज़र रखी
- Jobs को सबसे ज़्यादा खटकने वाली बातों में से एक Mac को पहली बार चालू करने पर लगने वाला boot time था
- memory test
- operating system initialization
- Finder loading
- इस प्रक्रिया में कई मिनट, या उससे भी ज़्यादा लग सकते थे
- Jobs ने disk driver और file system संभालने वाले Larry Kenyon से कहा कि Macintosh का boot बहुत धीमा है और इसे तेज़ बनाना होगा
“10 सेकंड घटाने से ज़िंदगियाँ बचती हैं” वाली गणना
- Larry Kenyon ने यह समझाने की कोशिश की कि कहाँ सुधार किया जा सकता है, लेकिन Jobs को उस स्पष्टीकरण में रुचि नहीं थी
- Jobs ने मान लिया कि कुछ साल बाद 50 लाख लोग हर दिन कम-से-कम एक बार Macintosh boot करेंगे
- उन्होंने हिसाब लगाया कि boot time 10 सेकंड घटाने से हर दिन 5 करोड़ सेकंड बचेंगे, और एक साल में यह दर्जनों लोगों की पूरी ज़िंदगी के बराबर होगा
- इसलिए उन्होंने कहा कि boot को 10 सेकंड तेज़ बनाना “दर्जनों लोगों की ज़िंदगियाँ बचाने” जितना मूल्यवान है
वास्तविक नतीजा
- टीम वैसे भी software को जितना संभव हो उतना तेज़ बनाना चाहती थी, इसलिए यह पक्का नहीं है कि Jobs के persuasion का कितना बड़ा असर पड़ा
- हालांकि, उनके persuasion का तरीका टीम के भीतर काफी मज़ेदार माना गया
- इसके बाद अगले कुछ महीनों में Macintosh का boot time सचमुच 10 सेकंड से ज़्यादा कम हो गया
1 टिप्पणियां
Hacker News की रायें
Apple के एक पुराने इंजीनियर से सुनी कहानी के मुताबिक, MacOS 8.x के दौर में user research में सबसे बड़ी शिकायत boot time थी
उस समय औसतन करीब 45 सेकंड लगते थे, और system पहले से sleep support करता था, इसलिए उन्होंने पूछा कि लोग boot time की इतनी परवाह क्यों कर रहे हैं
पता चला कि लोग सिर्फ दिन में एक बार या हफ्ते में एक बार reboot नहीं कर रहे थे, बल्कि unstability की वजह से बार-बार reboot कर रहे थे; नए release में booting भी सुधारी गई, लेकिन ज़्यादा ध्यान operating system को stable बनाने पर दिया गया
नतीजतन boot time की शिकायत गायब हो गई—इसलिए नहीं कि वह बहुत तेज़ हो गया था, बल्कि इसलिए कि reboot करना ही कम पड़ गया था; सीख यह थी कि ग्राहक क्या मांग रहे हैं, इतना ही नहीं, वे क्यों मांग रहे हैं, यह भी समझना चाहिए
patching के नियम भी साफ नहीं थे; उदाहरण के लिए, किसी system call patch के अंदर ऐसा code path हो सकता था जो memory allocate करे, जबकि memory manager reentrant नहीं था, इसलिए यह नहीं किया जाना चाहिए था
ऊपर से उस समय के C compiler से built code चलता था, और out-of-bounds memory writes रोकने वाले tools भी बहुत सीमित थे
MacOS 8 ने भी बहुत limited memory protection introduce किया था, लेकिन असल हालात में उससे खास मदद नहीं मिली; context में यह कहानी किसी organization की समस्या को rationalize करने की क्षमता और इच्छा के बारे में है
यह समस्या business के लिहाज़ से Apple को लगभग खत्म करने वाली थी
एक दोस्त ने अपनी पत्नी को पहली बार Mac OS X दिखाया और shutdown करने लगा, तो पत्नी ने मुंह बनाते हुए कहा, “Mac में मुझे यही बात अच्छी लगती थी कि वह तुरंत shutdown हो जाता था,” और दोस्त ने जवाब दिया, “तो फिर तुम्हें Mac OS में पसंद करने के लिए कोई और चीज़ ढूंढनी पड़ेगी”
अगर अभी यह तेज़ है, तो बस कुछ साल इंतज़ार करिए। developers इतनी performance regressions आने देंगे कि यह फिर उसी स्तर तक पहुंच जाएगा
शायद मैंने यह कहानी सुनी थी और फिर भूल गया था। जब मैं Blizzard में install, download और patch team संभालता था, तो team से कहा करता था: “1 करोड़ लोग यह patch download और install कर रहे हैं; अगर हम उनसे 1 मिनट और खर्च करवाते हैं, तो हम मानव जीवन का एक और हिस्सा खर्च करा रहे हैं”
यह बढ़ा-चढ़ाकर और थोड़ा cheesy था, लेकिन improvements push करने में मदद मिली
जिस metric को मैंने और ज़्यादा अहमियत देकर push किया, वह speed of light था। DVD से install करने वाले दिनों में disk की rotation speed ही उस environment की speed of light थी, इसलिए install को जितना हो सके उस speed के करीब होना चाहिए था
physical limits से टकराने तक काम की speed लगातार improve करनी चाहिए; समय कीमती है और इसे और हासिल नहीं किया जा सकता
बड़े infra performance improvements deploy करते समय असली बात सिर्फ speed या cost saving नहीं होती, बल्कि यह होती है कि atmosphere में CO2 कम होता है और लाखों लोगों में फैला मानव समय computer response का इंतज़ार करने के बजाय कहीं और इस्तेमाल होता है
हम किसी व्यक्ति की जान बचाने वाले doctor नहीं हैं, लेकिन लोगों को उनकी ज़िंदगी का एक हिस्सा वापस दे सकते हैं। कुछ software करोड़ों, अरबों लोग इस्तेमाल करते हैं, इसलिए छोटी-सी change भी कई “ज़िंदगियों” के बराबर समय बचा सकती है
अगर याद सही है, तो WoW वगैरह के torrent-based patch distribution सचमुच बहुत अच्छे से बनाए गए थे, और दबाव वाले industry में यह खास तौर पर impressive था
मैंने कई ऐसे engineers देखे हैं जिन्हें मेहनती कहा जा सकता है, लेकिन वे जिस hardware को चला रहे हैं और उस पर क्या संभव है, यह समझने में बहुत कम समय लगाते हैं
performance discussions में “slow है” या “ठीक है” जैसी बातें बहुत सुनीं, लेकिन अक्सर underlying machine और possible limits को पूरी तरह ignore किया गया
मेरा पसंदीदा feature progressive loading support है। WoW एक विशाल game है, लेकिन कुछ assets के साथ भी खेलना शुरू किया जा सकता है, और placeholder तथा low-quality assets दिखाकर downgrade कर देता है या कुछ areas को पूरी तरह skip भी कर देता है
बिलकुल fresh install के बाद भी कुछ ही मिनटों में खेल सकते हैं। players आम तौर पर इसे given मान लेते हैं, लेकिन चलती train के पहिए बदलते हुए विशाल data को बिना बड़ी problems के high performance में deliver करने में जो मेहनत लगी होगी, उसके लिए मैं सचमुच आभारी महसूस करता हूं
मुझे शक है कि क्या यह download का इंतज़ार करने से इतना बेहतर समय-उपयोग है
Steve Jobs लोगों को motivate करने और push करने के लिए हमेशा कुछ-न-कुछ गढ़ लेते थे—एक तरह से तथाकथित reality distortion field जैसा तरीका था
Mike Slade के मुताबिक, करीब 1990 में जब वे Microsoft में काम कर रहे थे, Jobs उन्हें NeXT में लाना चाहते थे। उस समय Microsoft Windows 95 जैसी बड़ी हिट के करीब था, जबकि NeXT कंप्यूटर बेचने में जूझ रहा था
Jobs ने Slade से कहा कि Seattle में रहने पर उनकी प्रतिभा बर्बाद हो जाएगी, और Silicon Valley उत्साह और गतिविधि का केंद्र है—वही जगह जहां वे खिल सकते हैं
फिर उन्होंने Palo Alto को इतालवी Renaissance काल के Florence जैसा “खास स्थान” बताया, और तुरंत जोशीला भाषण देने लगे कि वहां सड़कों पर चलते हुए एक पल में किसी विद्वान से और अगले ही पल किसी astronaut से मुलाकात हो सकती है, इतनी प्रतिभा वहां भरी पड़ी है
Slade उस वर्णन से इतने प्रभावित हुए कि उन्होंने Palo Alto शिफ्ट होने का फैसला कर लिया। एक साल बाद, अपनी पत्नी के साथ Palo Alto की University Avenue पर इटालियन chain restaurant Il Fornaio में खाना खाते समय उन्होंने मेनू के पीछे देखा तो वहां “Palo Alto Renaissance युग के Florence जैसा है…” जैसी वही बात लिखी हुई थी
आखिरकार, Jobs ने अपने पसंदीदा chain restaurant के मेनू की लाइन—वह भी कोई खास अच्छी ad copy नहीं—से ही किसी को मना लिया था; Slade ने उन्हें “वाकई बेशर्म डींगमार” के तौर पर याद किया
https://www.cultofmac.com/573753/how-jobs-poached-a-microsof...
कुछ साल पहले जब मैं वहां काम करता था, Palo Alto की सड़कों से मेरी सबसे यादगार चीज़ Caltrain Station के नीचे वाले underpass से आती जबरदस्त पेशाब की बदबू ही थी
यह मानना मुश्किल है कि उस समय दुनिया की सबसे बड़ी और प्रतिष्ठित कंपनियों में से एक में काम कर रहा कोई तेज-तर्रार professional engineer, संभावित employer की बस “मुझ पर भरोसा करो, यह कमाल है” वाली बात सुनकर नौकरी छोड़ दे और अपनी पूरी जिंदगी समेटकर दूसरे राज्य में चला जाए
ऐसा फैसला लेने के लिए कम-से-कम वह flight लेकर गया होगा, apartments देखे होंगे, office visit किया होगा। कहानी अच्छी है, लेकिन जाहिर है इसमें और context रहा होगा
वह ऐसा restaurant था जहां तब जाते थे जब बाकी सभी विकल्प booked हों या कहीं और दूर drive करने के लिए बहुत देर हो चुकी हो
वह computing दुनिया का केंद्र था, और Fry’s, restaurants या bars जैसी जगहों पर अद्भुत लोगों से यूं ही टकरा जाना सच में होता था
लगता है आज के युवा अच्छी तरह नहीं समझते कि आज technology के आसपास जो बहुत कुछ है, उसकी जड़ें 90s के South Bay और Peninsula में हैं
Programmers और engineers को यह सोच व्यापक रूप से लागू करनी चाहिए। धीमे software का इंतजार करने में कुल मिलाकर बहुत समय बर्बाद होता है, और ज्यादा development teams को performance को ऊंची priority देनी चाहिए
धीमे software और services की वजह से इंतजार में जाने वाला समय हम consciously जोड़ते नहीं हैं, लेकिन उस पल में unconsciously system ऐसा लगता है जैसे मेरे खिलाफ हो, जिससे असहजता और चिढ़ होती है
अगर जरा भी consciously सोचने लगें, तो उन engineers और project leaders के प्रति तिरस्कार होने लगता है जिन्होंने माना कि उनकी बनाई चीज़ release करने लायक पर्याप्त है
आधुनिक computers की processing power को देखते हुए, मामूली request पर सैकड़ों milliseconds इंतजार कराना या थोड़ी complex request पर उससे भी काफी ज्यादा इंतजार कराना programmer की गंभीर लापरवाही का सबूत है
गुरुवार रात मेरी girlfriend ने एक पुराने MacBook को साफ करने में मदद मांगी। बस कुछ steps थे: hardware से जुड़े account को disconnect करना, शायद पहले मैंने ही set की हुई firmware key हटाने का तरीका ढूंढना, fresh install, updates वगैरह
लेकिन कुछ steps या restarts single-digit seconds से ज्यादा लंबे लगे, और काम बार-बार मेरा ध्यान खींचता रहा, इसलिए इसमें 6 महीने लग गए
कई बार बीच में छोड़ने के बाद उसे keyboard के पास desk पर रख दिया, तो 6 घंटे में कुल 30 मिनट लगाकर खत्म कर दिया—यह जीत थी
अगर किसी ने मेरा हाथ laptop से बांध दिया होता तो शायद जल्दी हो जाता, लेकिन खाली screen, progress bars और spinning indicator को जबरन देखते रहने की पीड़ा कल्पना से बाहर होती
लंबे समय तक चलने वाले batch jobs जैसे मामलों में अपवाद है
साधारण computers भी 5400rpm spinning hard disk से 30 seconds के अंदर cold boot कर सकते थे, तो modern NVMe SSD पर 1 second के अंदर boot क्यों नहीं कर पाते, यह सवाल है
Windows 95, ज्यादातर features समेत, install size में करीब 50MB था, और Windows 2000 एक installation CD में समा जाता था
आज का Windows 10 installer single-layer DVD में भी नहीं आता, और FAT32 USB memory से install करने का विचार भी छोड़ना पड़ता है। कुछ पुराने UEFI अब भी exFAT handle नहीं कर पाते
मेरी याद में सबसे तेज महसूस हुआ computer dual Pentium 3 866, Rambus, और 15k U320 SCSI disks पर XP boot करने वाली machine थी; वह लगभग telepathy जैसा था
लगता है यह वही पुरानी समस्या है कि Windows जितना ज्यादा कबाड़ जमा करता जाता है, boot उतना लंबा होता जाता है
System fonts भी पहले करीब 200 characters के होते थे, अब उनमें tens of thousands characters होते हैं
इसे बाकी हर चीज़ पर extrapolate करें, तो काफी साफ है कि load करने के लिए बहुत ज्यादा चीजें हो गई हैं
इतना तेज है कि परेशान नहीं करता
अगर आपको कंप्यूटर का इंतज़ार करना पड़ रहा है, तो वह पर्याप्त तेज़ नहीं है
यहां Steve का तर्क इंडस्ट्री में व्यापक रूप से इस्तेमाल होता है, और यह लगभग भावनात्मक ब्लैकमेल जैसा है—अगर आप असफल हुए तो आप हत्यारे हैं—लेकिन फिर भी यह क्लासिक है
धीमे सॉफ़्टवेयर की ज़िम्मेदारी यूज़र पर डाल देना, या इसे उन PMs या संगठनों पर थोप देना बहुत आसान है जो प्रोडक्ट की गति से ज़्यादा फीचर्स और डेवलपमेंट स्पीड को आगे बढ़ाते हैं
यहां Steve का नारा यह कहता है कि सॉफ़्टवेयर परफॉर्मेंस का रोज़मर्रा की ज़िंदगी पर वास्तविक असर पड़ता है, और इस बात को रेखांकित करना भावनात्मक ब्लैकमेल नहीं है
कहा जाता है कि iPad लॉन्च के बाद Jobs iPad लेकर Mac टीम की मीटिंग में आए, iPad को wake किया, और वह तुरंत चालू हो गया
फिर उन्होंने Mac को wake किया, तो sleep से जागने में समय लगा, और Jobs ने कुछ ऐसा पूछा, “यह वैसा क्यों नहीं कर सकता?”
अगर iPad यह दिखाने के लिए न होता कि यह संभव है, तो memory speed और disk speed जैसी बहसें चलती रहतीं, और तेज़ Mac sleep/wake ने Windows पर भी बेहतर करने का दबाव बनाया
अगर यह तर्क सही है, तो आज UI में जगह-जगह मौजूद ढेरों animations के बारे में क्या कहा जाए
शुरुआती कुछ दर्जन बार देखने में अच्छा बनाने के अलावा, कई मामलों में वे सिर्फ़ समय बर्बाद करते हैं
मेरे फोन का app switcher animations ऑन होने पर 0.5–1 सेकंड लेता है, लेकिन animations बंद करने पर असल में तुरंत switch हो जाता है
अगर स्क्रीन तुरंत पूरी तरह अलग layout में बदल जाए, तो उसे visually process करने में समय लगता है, लेकिन अगर elements नई position तक interpolate होकर move करें, तो वह processing time animation की लंबाई जितना रह जाता है
आम तौर पर यह 0.5 सेकंड या 1 सेकंड नहीं, बल्कि करीब 0.25 सेकंड होता है
speed freaks या advanced users के लिए यह बाधा हो सकता है, इसलिए वे इसे बंद कर सकते हैं, लेकिन target users औसत यूज़र हैं, वे लोग नहीं जिन्होंने UI के हर कोने को muscle memory से याद कर लिया है
कुछ animations समय लेने वाले कामों के साथ overlap होकर यूज़र को response का एहसास दिलाते हुए इंतज़ार करवा सकते हैं। iOS जब disk पर swap हुई app पर switch करता है, तो यह ऐसा ही लगता है; loading time होता है, इसलिए animation delay के एक हिस्से की भरपाई कर देता है
animation न हो तो यूज़र सोच सकता है कि उसने action ठीक से नहीं किया, और repeated input करने की कोशिश कर सकता है, जिससे frustration होता है
कुछ animations UI flow में यूज़र की दिशा-बोध बनाए रखने के लिए ज़रूरी होते हैं। उदाहरण के लिए minimize animation window को उस icon तक ले जाता है जिसे restore करने के लिए दबाना होता है, और close और minimize में फर्क समझाता है
कुछ animations responsiveness बनाए रखते हुए सही feedback देने के लिए ज़रूरी होते हैं। touch screen पर list scroll करते समय आखिर में आने वाला spring animation न हो, तो यूज़र के पास यह जानने का तरीका नहीं होता कि list खत्म हो गई है या touch screen रुक गई है
video game console system UI और कुछ game menus इस मामले में खास तौर पर खराब लगते हैं
25fps पर 200ms की छोटी animation में सिर्फ़ 5 frames होंगे, इसलिए वह झटकेदार और घटिया लगेगी
1000ms करने पर वह smooth और अच्छी दिखेगी, लेकिन इस्तेमाल के लिए निराशाजनक होगी
यह शायद unpopular solution हो, लेकिन iPhone इस्तेमाल करें। app switcher उंगली की movement जितनी तेज़ी से काम करता है, और consistent 60fps देने में कोई समस्या नहीं होती
वे unusably slow नहीं थीं, लेकिन महसूस होने लायक धीमी थीं; बाद में पता चला कि animation speed default पर बहुत कम थी
उसे दोगुना करने पर सब कुछ 1,000 गुना बेहतर जैसा लगा
Windows 11 को HDD से boot होने में करीब 12 मिनट लगते हैं। कल्पना करें कि आप FDD से boot करने की कोशिश कर रहे हैं
Windows 11 install करने के बाद HDD पर सभी updates install होने का इंतज़ार करें तो करीब 8 दिन लगते हैं
https://www.youtube.com/watch?v=MpNagBwWlNk
कुछ समय पहले dual boot system बनाने की कोशिश में मैंने Fusion drive वाले 2017 iMac की partitions बिगाड़ दीं, और उसके बाद Mac धीमा हो गया
startup से लेकर कुछ हद तक usable होने तक शायद 5 मिनट लगते थे, और जो भी हो, यह काफी लंबा था
पिछले weekend धीमेपन से तंग आकर खोजा, तो partitions को default पर लौटाने वाला
diskutil resetFusion0 command मिलायह command चलाकर OS फिर से install किया, तो iMac फिर से काफी तेज़ हो गया। शानदार नहीं, लेकिन पहले से बहुत बेहतर
सीखा यह कि Fusion drive पर dual boot एक खराब idea है
आम तौर पर Windows 10 machine को हर कुछ महीनों में एक बार reboot करता हूं, और हमारा IT department Windows PC को करीब एक घंटे में तैयार कर देता है
लगता है कुछ बहुत गलत है, लेकिन मैं IT expert नहीं हूं
मुझे याद है कि पहले InterBase (अब FireBase) पर एक लेख और चर्चा देखी थी। उसमें कहा गया था कि storage और self-healing recovery model कुछ खास scenarios में अहम होते हैं, और उस समय यह quote था
“AFATDS में Ada code की 935,000 lines शामिल हैं, जो HP RISC workstations और Army की Light Weight Computer Units पर चलती हैं,” prime contractor Magnavox Electronic Systems Company के John Williams ने कहा था
“हमें एक single database चाहिए था जो Unix और PC platforms पर scale और operate कर सके। product को जल्दी install होना था, और system resources पर कब्ज़ा किए बिना high availability देनी थी”
“इस तरह के decision support के लिए ऐसा modular और flexible architecture चाहिए था जो distributed processing और distributed databases दोनों को support करे। इसलिए हमने InterBase चुना। इसकी performance competitors से बेहतर थी और इसने हमें भरोसा दिलाया कि life-and-death situations में भी इस पर भरोसा किया जा सकता है”
चर्चा का सटीक संदर्भ यह था कि कुछ tanks में main gun fire करते समय अंदरूनी EMP event हो सकता था, जिससे system reboot हो सकता था, और दोबारा fire करने के लिए बहुत तेज़ reboot और recovery time की ज़रूरत होती थी
सोचता हूँ, अगर Steve को पता होता कि एक छोटे-से glass slab पर endlessly scroll करते हुए कितने लाखों लोगों की ज़िंदगियाँ खत्म हो जाएँगी, तो कैसा होता