हम 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 कर्नेल के संबंधित रिपॉज़िटरी में देखी जा सकती है.

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

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

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

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

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

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

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