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

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

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