हम 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 एम्बेड किए गए ट्रेस एक्सटेंशन (ईटीई) और ARM ट्रेस बफ़र एक्सटेंशन (टीआरबीई) का इस्तेमाल किया जाता है.
• वर्कलोड: हम Android App Compatibility Test Suite (C-Suite) से, सबसे ज़्यादा लोकप्रिय 100 ऐप्लिकेशन का इस्तेमाल करके एक वर्कलोड बनाते हैं. सबसे सटीक डेटा कैप्चर करने के लिए, हम इन बातों पर फ़ोकस करते हैं:
  • ऐप्लिकेशन लॉन्च करना: उपयोगकर्ताओं को ऐप्लिकेशन लॉन्च होने में लगने वाले समय को कम करना
  • एआई की मदद से ऐप्लिकेशन क्रॉल करना: लगातार और बेहतर होते उपयोगकर्ता इंटरैक्शन का सिम्युलेशन
  • सिस्टम-वाइड मॉनिटरिंग: इसमें सिर्फ़ फ़ोरग्राउंड ऐप्लिकेशन की गतिविधियों को कैप्चर नहीं किया जाता है, बल्कि बैकग्राउंड में चल रहे ज़रूरी वर्कलोड और इंटर-प्रोसेस कम्यूनिकेशन को भी कैप्चर किया जाता है
• पुष्टि: इस सिंथेसाइज़ किए गए वर्कलोड में, हमारी इंटरनल फ्लीट से इकट्ठा किए गए एक्ज़ीक्यूशन पैटर्न से 85% समानता दिखती है.
• टारगेट किया गया डेटा: इन टेस्ट को बार-बार करके, हम हाई-फ़िडेलिटी एक्ज़ीक्यूशन पैटर्न कैप्चर करते हैं. ये पैटर्न, सबसे लोकप्रिय ऐप्लिकेशन के साथ रीयल-वर्ल्ड (असल) में उपयोगकर्ता के इंटरैक्शन को सटीक तरीके से दिखाते हैं. इसके अलावा, इस एक्सटेंसिबल फ़्रेमवर्क की मदद से, हम अपने कवरेज को बढ़ाने के लिए अतिरिक्त वर्कलोड और बेंचमार्क को आसानी से इंटिग्रेट कर सकते हैं.

दूसरा चरण: प्रोफ़ाइल प्रोसेस करना

हम रॉ ट्रेस डेटा को प्रोसेस करने के बाद, यह पक्का करते हैं कि वह सटीक हो, असरदार हो, और कंपाइलर के लिए तैयार हो.

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

तीसरा चरण: प्रोफ़ाइल की जांच करना

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

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

लगातार अपडेट

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

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

स्थिरता बनाए रखना

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

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

आगे की योजना

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

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

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