मैं Dalvik और एंड्रॉइड टूलचेन से कौन से अनुकूलन की उम्मीद कर सकता हूं?

Question

मैं एक उच्च प्रदर्शन वाले एंड्रॉइड एप्लिकेशन (एक गेम) पर काम कर रहा हूं, और हालांकि मैं पहले पठनीयता के लिए कोड करने का प्रयास करता हूं, लेकिन मैं अपने दिमाग के पीछे हुड के नीचे क्या हो रहा है की एक तस्वीर रखना चाहता हूं। सी ++ के साथ, मैंने संकलक के बारे में काफी अच्छा अंतर्ज्ञान विकसित किया है और मेरे लिए क्या नहीं करेगा। मैं जावा/एंड्रॉइड के लिए ऐसा करने की कोशिश कर रहा हूं।

इसलिए यह प्रश्न। मैं वेब पर इस विषय के बारे में बहुत कम पा सकता हूं। क्या जावा कंपाइलर, डाल्विक कनवर्टर (डीएक्स) और/या जिटर (एंड्रॉइड 2.2+ पर) निम्न जैसे अनुकूलन निष्पादित करेंगे?

• विधि इनलाइनिंग। किस परिस्थितियों में? private विधियों को हमेशा सुरक्षित रूप से रेखांकित किया जा सकता है; क्या यह किया जाएगा? public final विधियों के बारे में कैसे? अन्य वर्गों की वस्तुओं पर तरीके? static विधियां? क्या होगा यदि ऑब्जेक्ट का रनटाइम प्रकार आसानी से संकलक द्वारा घटाया जा सकता है? क्या मुझे संभवतः final या static के रूप में विधियों को घोषित करना चाहिए?

• आम उप-संपीड़न उन्मूलन। उदाहरण के लिए, यदि मैं दो बार someObject.someField एक्सेस करता हूं, तो लुकअप केवल एक बार किया जाएगा? क्या होगा यदि यह गेटर के लिए एक कॉल है? अगर मैं कुछ अंकगणितीय अभिव्यक्ति का दो बार उपयोग करता हूं तो क्या होगा; क्या इसका मूल्यांकन केवल एक बार किया जाएगा? क्या होगा यदि मैं कुछ अभिव्यक्ति के परिणाम का उपयोग करता हूं, जिसका मूल्य मुझे बदलना नहीं है, for लूप की ऊपरी सीमा के रूप में?

• सरणी लुकअप पर बाउंड की जांच। क्या टूलचैन कुछ शर्तों में इसे खत्म कर देगा, जैसे archetypical for लूप?

• मूल्य इनलाइनिंग। कुछ public static final int तक पहुंच जाएगा हमेशा रेखांकित किया जाएगा? भले ही वे एक और कक्षा में हों? भले ही वे किसी अन्य पैकेज में हों?

• शाखा भविष्यवाणी। यह भी कितना बड़ा मुद्दा है? एक ठेठ एंड्रॉइड डिवाइस पर एक बड़े प्रदर्शन हिट की शाखा है?

• सरल अंकगणितीय। someInt * 2someInt << 1 द्वारा प्रतिस्थापित किया जाएगा?

वगैरह ...

Answer 1

यह बेन, जेआईटी @ Google पर काम कर रहे इंजीनियरों में से एक है। जब इस परियोजना पर बिल और मैंने शुरू किया, तो लक्ष्य संसाधन विवाद (जैसे मेमोरी पदचिह्न, सीपीयू को संकलित थ्रेड द्वारा अपहृत) के साथ जितनी जल्दी हो सके एक काम कर रहे जेआईटी को वितरित करना था ताकि यह कम अंत उपकरणों पर चल सके कुंआ। इसलिए हमने एक बहुत ही प्राचीन ट्रेस आधारित मॉडल का उपयोग किया। यही है, जेआईटी कंपाइलर को पास की गई संकलन इकाई एक मूलभूत ब्लॉक है, कभी-कभी एक ही निर्देश के रूप में संक्षिप्त होती है। इस तरह के निशान रनटाइम पर चेनिंग नामक तकनीक के माध्यम से एक साथ सिलाई जाएंगे ताकि दुभाषिया और कोड कैश लुकअप अक्सर नहीं बुलाया जाएगा। कुछ डिग्री के लिए स्पीडअप का प्रमुख स्रोत अक्सर निष्पादित कोड पथों पर बार-बार दुभाषिया पार्सिंग ओवरहेड को समाप्त करने से आता है।

कहा कि, हम Froyo JIT के साथ लागू काफी कुछ स्थानीय अनुकूलन की क्या ज़रूरत है:

• रजिस्टर आवंटन (v5te लक्ष्य के लिए 8 रजिस्टरों के बाद से JIT v7 के लिए अंगूठे कोड/16 रजिस्टरों का उत्पादन)
• शेड्यूलिंग (उदाहरण के लिए डाल्विक रजिस्टरों के लिए अनावश्यक एलडी/सेंट उन्मूलन, लोड होस्टिंग, स्टोर डूबने)
• रिडंडंट नल चेक उन्मूलन (यदि ऐसी अनावश्यकता मूलभूत ब्लॉक में पाई जा सकती है)।
• सरल गिनती लूप के लिए लूप गठन और अनुकूलन (यानी लूप बॉडी में कोई साइड-एक्जिट नहीं)। ऐसे लूपों के लिए, विस्तारित प्रेरण चर के आधार पर सरणी पहुंच अनुकूलित की जाती है ताकि शून्य और रेंज चेक केवल लूप प्रस्तावना में ही किए जा सकें।
• रनटाइम पर प्रति वर्चुअल कॉलसाइट डब्ल्यू/गतिशील पैचिंग में एक प्रविष्टि इनलाइन कैश।
• मिश/div के लिए शाब्दिक संचालन पर बिजली-कमी जैसे पाइपहोल अनुकूलन।

जिंजरब्रेड में हमने गेटर्स/सेटर्स के लिए सरल इनलाइनिंग जोड़ा। चूंकि अंतर्निहित जेआईटी फ्रंटएंड अभी भी सरल ट्रेस आधारित है, यदि कैली में शाखाएं हैं तो इसे रेखांकित नहीं किया जाएगा। लेकिन इनलाइन कैश तंत्र लागू किया गया है ताकि वर्चुअल गेटर्स/सेटर्स को बिना किसी समस्या के रेखांकित किया जा सके।

हम वर्तमान में संकलन के दायरे को एक साधारण ट्रेस से आगे बढ़ाने पर काम कर रहे हैं ताकि संकलक के पास कोड विश्लेषण और अनुकूलन के लिए एक बड़ी विंडो हो। बने रहें।

Answer 2

मुझे यकीन है कि मेरा उत्तर आपके सभी प्रश्नों का उत्तर नहीं होगा लेकिन मैं इसे एक जीत है अगर यह भी एक जवाब देता है लगता है।

आपको इस विषय पर गहरा ज्ञान होना प्रतीत होता है और पता है कि आप क्या चाहते हैं ताकि आप निम्न कार्य करना चाहें। एक उदाहरण एप्लिकेशन बनाएं जिसमें पहलुओं को आप जांचना चाहते हैं।

एपीके लें और इसे APK Tool के माध्यम से चलाएं। जो भी आप जानते हैं, वह करने के लिए अपने स्वयं के कोड को रिवर्स इंजीनियरिंग पूरी तरह से ठीक है जैसा हम जानते हैं।

एपीके उपकरण आपके संसाधनों को निकालने और डीकोड करेगा और .dex फ़ाइलों को .smali फ़ाइलों को रिवर्स इंजीनियर करेगा। .smali फ़ाइलों और इसकी सीमाओं को पढ़ने के तरीके के बारे में अधिक जानकारी प्राप्त करने के लिए आप smali प्रोजेक्ट को भी देखना चाहेंगे।

फिर मुझे पूरा यकीन है कि यह आपके सभी सवालों के जवाब देने वाला नहीं है लेकिन यह एक अच्छी शुरुआत हो सकती है।

Answer 3

सबसे पहले, मुझे यह कहकर प्रस्तावना दें कि मैं दल्विक पर एक विशेषज्ञ नहीं हूं, और मेरे कुछ जवाब गलत हो सकते हैं। लेकिन मैंने दल्विक में जेआईटी कोड में खोला है, और मैं बाल्कोकोड से काफी परिचित हूं कि दल्विक चलता है।

1. विधि रूपरेखा - जहां तक ​​मुझे पता है, यह कभी नहीं होता है। मैं लगभग सकारात्मक हूं यह बाइटकोड स्तर पर कभी नहीं होता है, और मुझे नहीं लगता कि यह वर्तमान में जेआईटी स्तर पर होता है - हालांकि यह भविष्य में हो सकता है।

2. सामान्य उप-संपीड़न उन्मूलन - मेरा मानना ​​है कि यह केवल उप-अभिव्यक्तियों के लिए किया जाएगा जो किसी भी गैर-अंतिम चर/फ़ील्ड का उपयोग नहीं करते हैं। अगर यह तब भी होता है तो मैं पूरी तरह से सकारात्मक नहीं हूं। यदि यह किया जाता है, तो मैं उम्मीद करता हूं कि यह बाइटकोड स्तर पर किया जाए, शायद जेआईटी स्तर पर नहीं।

3. सीमा सरणी लुकअप पर जाँच - कोई सुराग नहीं

4. मूल्य इनलाइनिंग - जहाँ तक मुझे पता है, हाँ - वे उन स्थितियों के सभी में inlined कर दिया जाएगा।

5. शाखा भविष्यवाणी - यकीन नहीं

6. सरल गणित - जहाँ तक मैं जानता हूँ कि नहीं

के रूप में भी, मैं तुम्हें करने के लिए दृष्टिकोण का एक और अवसर का उल्लेख करना चाहते हैं - dx और Dalvik हैं दोनों खुले स्रोत, ताकि आप उन्हें पसंद में खोद सकें। हालांकि, वे स्पष्ट रूप से छोटे कोडबेस नहीं हैं, इसलिए उस स्तर पर उन्हें खोदने के लिए काफी प्रयास किए जाएंगे