हम Android LLVM टूलचेन टीम हैं. हमारी सबसे बड़ी प्राथमिकताओं में से एक है, LLVM इकोसिस्टम में ऑप्टिमाइज़ेशन की तकनीकों की मदद से Android की परफ़ॉर्मेंस को बेहतर बनाना. हम Android को ज़्यादा तेज़, बेहतर, और असरदार बनाने के लिए लगातार काम कर रहे हैं. हालांकि, ऑप्टिमाइज़ेशन से जुड़ा हमारा ज़्यादातर काम यूज़रस्पेस में होता है, लेकिन कर्नेल, सिस्टम का अहम हिस्सा बना रहता है. आज हमें यह बताते हुए खुशी हो रही है कि हम Android कर्नेल में, Automatic Feedback-Directed Optimization (AutoFDO) को कैसे शामिल कर रहे हैं, ताकि उपयोगकर्ताओं को बेहतर परफ़ॉर्मेंस मिल सके.

AutoFDO क्या है?

सॉफ़्टवेयर के स्टैंडर्ड बिल्ड के दौरान, कंपाइलर हज़ारों छोटे-छोटे फ़ैसले लेता है. जैसे, किसी फ़ंक्शन को इनलाइन करना है या नहीं और किसी शर्त की कौनसी ब्रांच इस्तेमाल की जाएगी. ये फ़ैसले, स्टैटिक कोड हिंट के आधार पर लिए जाते हैं.हालांकि, ये ह्यूरिस्टिक काम के होते हैं, लेकिन ये फ़ोन के असल इस्तेमाल के दौरान कोड के एक्ज़ीक्यूशन का सटीक अनुमान नहीं लगाते.

AutoFDO, असल इस्तेमाल के पैटर्न का इस्तेमाल करके कंपाइलर को गाइड करता है. इससे, इस समस्या को हल किया जा सकता है. इन पैटर्न में, निर्देश के एक्ज़ीक्यूशन के उन पाथ को दिखाया जाता है जिनका इस्तेमाल कोड, असल इस्तेमाल के दौरान सबसे ज़्यादा करता है. इन्हें, सीपीयू की ब्रांचिंग हिस्ट्री रिकॉर्ड करके कैप्चर किया जाता है. हालांकि, यह डेटा फ़्लीट डिवाइसों से इकट्ठा किया जा सकता है, लेकिन कर्नेल के लिए हम इसे लैब एनवायरमेंट में सिंथेसाइज़ करते हैं. इसके लिए, प्रतिनिधि वर्कलोड का इस्तेमाल किया जाता है. जैसे, सबसे लोकप्रिय 100 ऐप्लिकेशन चलाना. हम इस डेटा को कैप्चर करने के लिए, सैंपलिंग प्रोफ़ाइलर का इस्तेमाल करते हैं. इससे यह पता चलता है कि कोड के कौनसा हिस्से का इस्तेमाल ज़्यादा किया जाता है और कौनसा हिस्सा कम इस्तेमाल होता है.जब हम इन प्रोफ़ाइलों की मदद से कर्नेल को फिर से बनाते हैं, तो कंपाइलर, Android के असल वर्कलोड के हिसाब से ऑप्टिमाइज़ेशन के बेहतर फ़ैसले ले सकता है.

इस ऑप्टिमाइज़ेशन के असर को समझने के लिए, इन अहम तथ्यों पर ध्यान दें:

• Android पर, कर्नेल, सीपीयू के समय का करीब 40% हिस्सा लेता है.
• हम पहले से ही AutoFDO का इस्तेमाल करके, यूज़रस्पेस में नेटिव एक्ज़ीक्यूटेबल और लाइब्रेरी को ऑप्टिमाइज़ कर रहे हैं. इससे, ऐप्लिकेशन लॉन्च होने में लगने वाले समय में करीब 4% की कमी आई है. साथ ही, बूट होने में लगने वाले समय में 1% की कमी आई है.

असल इस्तेमाल के दौरान परफ़ॉर्मेंस में बढ़ोतरी

हमने कंट्रोल किए गए लैब एनवायरमेंट से मिली प्रोफ़ाइलों का इस्तेमाल करके, Android की अहम मेट्रिक में शानदार सुधार देखे हैं. इन प्रोफ़ाइलों को, ऐप्लिकेशन क्रॉल करने और लॉन्च करने के दौरान इकट्ठा किया गया था. साथ ही, इन्हें Pixel डिवाइसों पर 6.1, 6.6, और 6.12 कर्नेल पर मेज़र किया गया था.

सबसे अहम सुधार यहां दिए गए हैं. कर्नेल के इन वर्शन के लिए, AutoFDO प्रोफ़ाइलों के बारे में ज़्यादा जानकारी, android16-6.12 और android15-6.6 कर्नेल के लिए, Android कर्नेल के संबंधित रिपॉज़िटरी में देखी जा सकती है.

ये सिर्फ़ थ्योरेटिकल आंकड़े नहीं हैं. इनसे, इंटरफ़ेस ज़्यादा तेज़ होता है, ऐप्लिकेशन को तेज़ी से स्विच किया जा सकता है, बैटरी लाइफ़ बढ़ जाती है, और असली उपयोगकर्ता के लिए डिवाइस ज़्यादा रिस्पॉन्सिव हो जाता है.

यह कैसे काम करता है: पाइपलाइन

हमारी डिप्लॉयमेंट रणनीति में एक सोफ़िस्टिकेटेड पाइपलाइन शामिल है. इससे यह पक्का किया जाता है कि प्रोफ़ाइलें काम की बनी रहें और परफ़ॉर्मेंस स्थिर रहे.

पहला चरण: प्रोफ़ाइल कलेक्शन

यूज़रस्पेस बाइनरी की प्रोफ़ाइल बनाने के लिए, हम अपने इंटरनल टेस्ट फ़्लीट पर निर्भर रहते हैं. हालांकि, हमने जेनेरिक कर्नेल इमेज (जीकेआई) के लिए, कंट्रोल किए गए लैब एनवायरमेंट का इस्तेमाल किया है. डिवाइस रिलीज़ साइकल से प्रोफ़ाइलिंग को अलग करने से, डिप्लॉय किए गए कर्नेल वर्शन से अलग, तुरंत अपडेट किए जा सकते हैं. अहम बात यह है कि टेस्ट से पुष्टि होती है कि लैब में इकट्ठा किए गए डेटा से, असल फ़्लीट से मिले डेटा के मुकाबले बेहतर परफ़ॉर्मेंस मिलती है.

• टूल और एनवायरमेंट: हम टेस्ट डिवाइसों को कर्नेल की नई इमेज के साथ फ़्लैश करते हैं. साथ ही, निर्देश के एक्ज़ीक्यूशन स्ट्रीम को कैप्चर करने के लिए, simpleperf का इस्तेमाल करते हैं. इस प्रोसेस में, ब्रांचिंग हिस्ट्री रिकॉर्ड करने के लिए हार्डवेयर की क्षमताओं का इस्तेमाल किया जाता है. खास तौर पर, Pixel डिवाइसों पर  ARM Embedded Trace Extension (ETE) और ARM Trace Buffer Extension (TRBE) का इस्तेमाल किया जाता है.
• वर्कलोड: हम Android App Compatibility Test Suite (C-Suite) से सबसे लोकप्रिय 100 ऐप्लिकेशन का इस्तेमाल करके, प्रतिनिधि वर्कलोड तैयार करते हैं. सबसे सटीक डेटा कैप्चर करने के लिए, हम इन पर फ़ोकस करते हैं:
  • ऐप्लिकेशन लॉन्च करना: उपयोगकर्ता को होने वाली सबसे ज़्यादा देरी के लिए ऑप्टिमाइज़ करना
  • एआई-ड्रिवन ऐप्लिकेशन क्रॉलिंग: लगातार, उपयोगकर्ता के इंटरैक्शन को सिम्युलेट करना
  • सिस्टम-वाइड मॉनिटरिंग: सिर्फ़ फ़ोरग्राउंड ऐप्लिकेशन की गतिविधियों को ही नहीं, बल्कि अहम बैकग्राउंड वर्कलोड और इंटर-प्रोसेस कम्यूनिकेशन को भी कैप्चर करना
• पुष्टि करना: सिंथेसाइज़ किए गए इस वर्कलोड में, हमारे इंटरनल फ़्लीट से इकट्ठा किए गए एक्ज़ीक्यूशन पैटर्न से 85% समानता दिखती है.
• टारगेट किया गया डेटा: इन टेस्ट को बार-बार करके, हम हाई-फ़िडेलिटी एक्ज़ीक्यूशन पैटर्न कैप्चर करते हैं. इनसे, सबसे लोकप्रिय ऐप्लिकेशन के साथ असल उपयोगकर्ता के इंटरैक्शन का सटीक अनुमान लगाया जा सकता है. इसके अलावा, इस एक्सटेंसिबल फ़्रेमवर्क की मदद से, हम अपने कवरेज को बढ़ाने के लिए, अतिरिक्त वर्कलोड और बेंचमार्क को आसानी से इंटिग्रेट कर सकते हैं.

दूसरा चरण: प्रोफ़ाइल प्रोसेसिंग

हम रॉ ट्रेस डेटा को पोस्ट-प्रोसेस करते हैं, ताकि यह साफ़, असरदार, और कंपाइलर के लिए तैयार हो.

• एग्रीगेशन: हम कई टेस्ट रन और डिवाइसों से मिले डेटा को, एक ही सिस्टम व्यू में कंसोलिडेट करते हैं.
• कन्वर्ज़न: हम रॉ ट्रेस को AutoFDO प्रोफ़ाइल फ़ॉर्मैट में बदलते हैं. साथ ही, ज़रूरत के हिसाब से अनचाहे सिंबल को फ़िल्टर करते हैं.
• प्रोफ़ाइल ट्रिम करना: हम प्रोफ़ाइलों को ट्रिम करके, "कोल्ड" फ़ंक्शन के लिए डेटा हटाते हैं. इससे, वे स्टैंडर्ड ऑप्टिमाइज़ेशन का इस्तेमाल कर पाते हैं. इससे, कभी-कभी इस्तेमाल होने वाले कोड में रिग्रेशन नहीं होता. साथ ही, बाइनरी साइज़ में गैर-ज़रूरी बढ़ोतरी नहीं होती.

तीसरा चरण: प्रोफ़ाइल टेस्टिंग

डिप्लॉयमेंट से पहले, प्रोफ़ाइलों की कड़ी जांच की जाती है, ताकि यह पक्का किया जा सके कि वे स्थिरता से जुड़े जोखिमों के बिना, लगातार बेहतर परफ़ॉर्मेंस दें.

• प्रोफ़ाइल और बाइनरी का विश्लेषण: हम नई प्रोफ़ाइल के कॉन्टेंट (इसमें हॉट फ़ंक्शन, सैंपल की संख्या, और प्रोफ़ाइल का साइज़ शामिल है) की तुलना, पहले के वर्शन से करते हैं. हम नई कर्नेल इमेज बनाने के लिए, प्रोफ़ाइल का इस्तेमाल भी करते हैं. साथ ही, बाइनरी का विश्लेषण करके यह पक्का करते हैं कि टेक्स्ट सेक्शन में किए गए बदलाव, उम्मीद के मुताबिक हों.
• परफ़ॉर्मेंस की पुष्टि करना: हम कर्नेल की नई इमेज पर, टारगेट किए गए बेंचमार्क चलाते हैं. इससे पुष्टि होती है कि यह, पहले के बेसलाइन से मिले परफ़ॉर्मेंस में सुधार को बनाए रखता है.

लगातार अपडेट

समय के साथ, कोड में बदलाव होते रहते हैं. इसलिए, स्टैटिक प्रोफ़ाइल की असरदारता धीरे-धीरे कम हो जाती है. बेहतर परफ़ॉर्मेंस बनाए रखने के लिए, हम नियमित अपडेट देने के लिए पाइपलाइन को लगातार चलाते हैं:

• नियमित तौर पर रीफ़्रेश करना: हम GKI के हर रिलीज़ से पहले, Android कर्नेल की एलटीएस ब्रांच में प्रोफ़ाइलों को रीफ़्रेश करते हैं. इससे यह पक्का होता है कि हर बिल्ड में, प्रोफ़ाइल का नया डेटा शामिल हो.
• आने वाले समय में विस्तार: फ़िलहाल, हम ये अपडेट android16-6.12 और android15-6.6 ब्रांच को दे रहे हैं. साथ ही, हम GKI के नए वर्शन के लिए भी सहायता बढ़ाएंगे. जैसे, आने वाला android17-6.18.

स्थिरता पक्का करना

प्रोफ़ाइल-गाइडेड ऑप्टिमाइज़ेशन से जुड़ा एक आम सवाल यह है कि क्या इससे स्थिरता से जुड़े जोखिम पैदा होते हैं. AutoFDO, सोर्स कोड की लॉजिक में बदलाव करने के बजाय, मुख्य तौर पर कंपाइलर ह्यूरिस्टिक को प्रभावित करता है. जैसे, फ़ंक्शन इनलाइनिंग और कोड लेआउट. इसलिए, यह कर्नेल की फ़ंक्शनल इंटिग्रिटी को बनाए रखता है. इस टेक्नोलॉजी को बड़े पैमाने पर पहले ही आज़माया जा चुका है. यह सालों से Android प्लैटफ़ॉर्म लाइब्रेरी, ChromeOS, और Google के अपने सर्वर इन्फ़्रास्ट्रक्चर के लिए, स्टैंडर्ड ऑप्टिमाइज़ेशन के तौर पर काम कर रही है.

लगातार बेहतर परफ़ॉर्मेंस की गारंटी देने के लिए, हम "डिफ़ॉल्ट रूप से कंज़र्वेटिव" रणनीति अपनाते हैं. हमारी हाई-फ़िडेलिटी प्रोफ़ाइलों में कैप्चर नहीं किए गए फ़ंक्शन को, कंपाइलर के स्टैंडर्ड तरीकों का इस्तेमाल करके ऑप्टिमाइज़ किया जाता है. इससे यह पक्का होता है कि कर्नेल के "कोल्ड" या कभी-कभी इस्तेमाल होने वाले हिस्से, स्टैंडर्ड बिल्ड की तरह ही काम करें. साथ ही, कॉर्नर केस में परफ़ॉर्मेंस रिग्रेशन या अनचाहे व्यवहार से बचा जा सके.

आने वाले समय में

फ़िलहाल, हम android16-6.12 और android15-6.6 ब्रांच में AutoFDO को डिप्लॉय कर रहे हैं. शुरुआती रोल आउट के अलावा, हमें टेक्नोलॉजी को और बेहतर बनाने के लिए कई बेहतरीन अवसर दिख रहे हैं:

• ज़्यादा लोगों तक पहुंच: हम GKI कर्नेल के नए वर्शन और मौजूदा aarch64 सहायता के अलावा, अन्य बिल्ड टारगेट के लिए AutoFDO प्रोफ़ाइलें डिप्लॉय करने के लिए उत्साहित हैं.
• जीकेआई मॉड्यूल ऑप्टिमाइज़ेशन: फ़िलहाल, हमारा ऑप्टिमाइज़ेशन, कर्नेल की मुख्य बाइनरी (vmlinux) पर फ़ोकस है. GKI मॉड्यूल के लिए AutoFDO को बढ़ाने से, कर्नेल सबसिस्टम के बड़े हिस्से को परफ़ॉर्मेंस के फ़ायदे मिल सकते हैं.
• वेंडर मॉड्यूल सहायता: हम ड्राइवर डेवलपमेंट किट (डीडीके) का इस्तेमाल करके बनाए गए वेंडर मॉड्यूल के लिए, AutoFDO की सहायता देने में भी दिलचस्पी रखते हैं. हमारे बिल्ड सिस्टम (Kleaf) और प्रोफ़ाइलिंग टूल (simpleperf) में पहले से ही सहायता उपलब्ध है. इससे, वेंडर अपने खास हार्डवेयर ड्राइवर पर, ऑप्टिमाइज़ेशन की इन तकनीकों को लागू कर सकते हैं.
• प्रोफ़ाइल का ज़्यादा कवरेज: क्रिटिकल यूज़र जर्नी (सीयूजे) की ज़्यादा रेंज से प्रोफ़ाइलें इकट्ठा करके, उन्हें ऑप्टिमाइज़ किया जा सकता है.

Android कर्नेल में AutoFDO को शामिल करके, हम यह पक्का कर रहे हैं कि ओएस की बुनियादी चीज़ें, आपके डिवाइस को हर दिन इस्तेमाल करने के तरीके के हिसाब से ऑप्टिमाइज़ हों.