X32 ABI मिथकों का विमोचन

शायद आप में से कुछ ने एक फ्रीबी के बारे में सुना है जिसे एक्स 32 एबी कहा जाता है।

संक्षेप में x32 ABI के बारे में

संक्षेप में, यह 32-बिट पॉइंटर्स को बनाए रखते हुए 64-बिट आर्किटेक्चर का पूरा लाभ उठाने का अवसर है। संभावित रूप से, एप्लिकेशन कम मेमोरी का उपभोग करेगा, हालांकि यह 4 जीबी से अधिक मेमोरी को संबोधित करने में सक्षम नहीं होगा।

एक उदाहरण है। अपने कोड में, आप पूर्णांक की एक सरणी को परिभाषित करते हैं और इसे मूल्यों से भरते हैं। आप कितनी मेमोरी खर्च करते हैं? यदि चित्रण करना बहुत कठिन है, तो यह कुछ इस तरह दिखाई देगा:
32 बिट्स: पॉइंटर + एलीमेंट काउंटर + एन पूर्णांक = एन + 2 32-बिट संख्या
64 बिट्स: पॉइंटर + एलीमेंट काउंटर + एन पूर्णांक = एन + 2 64-बिट संख्या = 2 एन + 4 32-बिट संख्या
तो इंजीनियरों ने सोचा: क्या होगा यदि आप 64-बिट आर्किटेक्चर पर 32-बिट पॉइंटर्स का उपयोग करने का प्रयास करें? X86-64 आर्किटेक्चर में CISC कमांड सिस्टम है और यह अनुमति देता है। इस स्थिति में, ऊपर दिया गया हमारा सरणी 2N + 4 के बजाय 2N + 3 मेमोरी का उपभोग करेगा। बचत निश्चित रूप से महत्वहीन है, लेकिन तथ्य यह है कि आधुनिक कोड में संरचनाओं में सभी प्रकार के पॉइंटर्स की संख्या अक्सर दस तक पहुंच जाती है, और शॉर्ट पॉइंटर्स का उपयोग करने से संभवतः 50% तक मेमोरी (आदर्श मामले में) की बचत होगी।

उन लोगों के लिए जिन्हें अधिक सटीक गणना की आवश्यकता है:
* PHP में सरणियाँ (और मान) कितने बड़े हैं? (संकेत: बहुत बड़ा)
* PHP में ऑब्जेक्ट कितनी मेमोरी का उपभोग करते हैं और क्या यह 64-बिट संस्करण का उपयोग करने के लायक है?

लेकिन जैसा कि यह निकला कि कोई मुफ्त नहीं होगा।

---

डिबंकिंग x32 मिथक लेख अनुवाद

मेरे पिछले x32 एबीआई लेख पर कई टिप्पणियां थीं। उनमें से कुछ दिलचस्प हैं, जबकि अन्य बस समझ नहीं पाते हैं कि वे क्या लिख ​​रहे हैं। मुझे इस बात का आभास हो गया था कि इस विषय के इर्दगिर्द माल की खेती जैसी कोई चीज थी। लोग सोचते हैं: "किसी कारण से वे ऐसा कर रहे हैं, ताकि मैं भी इसका उपयोग कर सकूं," जबकि तकनीकी साक्षरता बहुत लाभ का मूल्यांकन करने के लिए उपलब्ध नहीं है।

तो इसी भावना से कि मैं लगभग चार साल पहले ccache से गुजरता था (वाह, मेरा ब्लॉग इतने साल पुराना है, अच्छा, क्या मैंने ऐसा नहीं किया है?), मैं इस x32I के बारे में मिथकों और भ्रांतियों को दूर करने की कोशिश करूंगा। ।

x32 ABI कोड तेजी से

बिलकुल ठीक नहीं। अब हमारे पास केवल कुछ परीक्षा परिणाम हैं जिन्होंने इस ABI को बनाया है। बेशक, आप उन लोगों से अपेक्षा करते हैं जिन्होंने इसे दिलचस्प और तेज़ खोजने के लिए सिस्टम स्थापित करने के लिए समय लिया, लेकिन ईमानदार होने के लिए, मुझे परिणामों के बारे में संदेह है, उन कारणों के लिए जो अगले कुछ वाक्यों को पढ़ने के बाद स्पष्ट होंगे।

यह नोट करना भी दिलचस्प है कि इस तथ्य के बावजूद कि सामान्य माप तेज थे, अंतर मौलिक नहीं है। और यहां तक ​​कि इंटेल की प्रस्तुति केवल मूल x86 की तुलना में बहुत अंतर दिखाती है, जो पहले से ही समझ में आता है, जो x86-64 से भी बदतर है।

इसके अलावा, इन परिणामों को सिंथेटिक परीक्षणों का उपयोग करके प्राप्त किया गया था, और सिस्टम के वास्तविक उपयोग से नहीं, और आप जानते हैं, निश्चित रूप से, यदि आप जानते हैं कि ऐसे परिणाम तीन बक्से से झूठ हो सकते हैं।

x32 ABI कोड अधिक कॉम्पैक्ट है

नया एबीआई कम कोड उत्पन्न करता है, जिसका अर्थ है कि अधिक निर्देश प्रोसेसर कैश में जाएंगे, और हमारे पास कम फाइलें भी होंगी। यह बिल्कुल असत्य है। उत्पन्न कोड, सामान्य रूप से, x86-64 के लिए समान है, क्योंकि निर्देशों का सेट नहीं बदलता है, तथाकथित डेटा मॉडल बस बदलता है, जिसका अर्थ है कि आप लंबे समय तक (और संबंधित प्रकार) और पॉइंटर्स के आकार (लेकिन परिवर्तन) के लिए आकार बदलते हैं और उपलब्ध पता स्थान का आकार)।

यह सैद्धांतिक रूप से सच है कि यदि आप छोटी डेटा संरचनाओं का उपयोग करने का इरादा रखते हैं, तो वे डेटा कैश में अधिक फिट होंगे (लेकिन निर्देश कैश में नहीं, सुनिश्चित करें। लगभग। CISC आंतरिक रूप से सभी छोटे निर्देशों को लंबे समय में परिवर्तित करता है), लेकिन ऐसा करता है। सही दृष्टिकोण? मेरे अनुभव में, उस कोड को लिखने में ध्यान केंद्रित करना बेहतर है जो आपके कैश में सबसे अच्छा कैश में रखा गया है। आप Arnaldo (acme) से देव- उपयोग / बौने उपयोगिताओं का उपयोग कर सकते हैं। उदाहरण के लिए, pahole आपको बताएगा कि आपकी डेटा संरचनाएं मेमोरी में कैसे साझा की जाएंगी।

यह भी याद रखें कि संगतता के लिए, सिस्टम कॉल को x86-64 के समान छोड़ दिया जाएगा, जिसका अर्थ है कि आपके द्वारा उपयोग किए जाने वाले सभी कर्नेल कोड और सिस्टम डेटा संरचनाएं x86-64 के समान होंगी। जिसका अर्थ है कि बड़ी संख्या में संरचनाएं नए एबीआई (लगभग। अनुवाद: बाइनरी इंटरफ़ेस) में अपना आकार नहीं बदलेंगी।

अंत में, यदि आप फिर से प्रस्तुति की ओर मुड़ते हैं, तो आप स्लाइड 24 पर देख सकते हैं कि x32 ABI कोड मूल x86 कोड से अधिक लंबा हो सकता है। यह अच्छा होगा यदि वे x86-64 कोड के लिए एक उदाहरण भी शामिल करते हैं (क्योंकि मेरे पास VCISC (लगभग प्रति नहीं है। मेरा मतलब है कि CISC से 64-बिट निर्देशों का एक समूह है)), लेकिन मुझे लगता है कि यह एक है एक ही कोड।

मजे के लिए libc.so.6 फ़ाइल के आकार की तुलना करें। यहाँ रूबी एल्फ सुइट से rbelf-size यूटिलिटी का आउटपुट दिया गया है:

exec data rodata relro bss overhead allocated filename 1239436 7456 341974 13056 17784 94924 1714630 /lib/libc.so.6 1259721 4560 316187 6896 12884 87782 1688030 x32/libc.so.6 

निष्पादन योग्य कोड x32 संस्करण में और भी बड़ा है। डेटा संरचना (डेटा, रॉडाटा, रिले और बीएसएस) में बड़ा बदलाव निश्चित रूप से है, क्योंकि संकेत अब संक्षिप्त हैं। मैं ईमानदारी से चिंतित हूं: "एक सी लाइब्रेरी के लिए अपनी संरचनाओं में इतने सारे पॉइंटर्स कैसे हो सकते हैं?" लेकिन यह सवाल बंद विषय है। भले ही संकेत छोटे हों, अंतर उतना बड़ा नहीं है। सामान्य तौर पर, आपके पास 30 KiB जैसी किसी चीज़ की बचत होगी, जो मेमोरी मैपिंग के पैटर्न को बदलने की संभावना नहीं है।

डेटा में कमी उपयोगी है

खैर, हां, यह मुख्य सवाल है। बेशक, डेटा संरचनाएं x32 के साथ छोटी हैं, क्योंकि इसके लिए यह अंत में किया गया था। लेकिन मुख्य सवाल शायद यह होगा: "क्या यह महत्वपूर्ण है?" मुझे ऐसा नहीं लगता। यहां तक ​​कि सी लाइब्रेरी के साथ ऊपर के उदाहरण में, जहां अंतर ध्यान देने योग्य है, यह केवल कब्जे वाले स्थान का लगभग 20% है। और यह सी लाइब्रेरी है! एक पुस्तकालय जो मानता है कि आप बहुत छोटे इंटरफेस लिखेंगे।

अब यदि आप इसमें सभी संभावित पुस्तकालयों को जोड़ते हैं, तो शायद आप कुछ मेगाबाइट डेटा सहेज सकते हैं, निश्चित रूप से, लेकिन आपको उन सभी पोर्टिंग समस्याओं पर भी विचार करना चाहिए जिन पर मैं जल्द ही चर्चा करने जा रहा हूं। हां, यह सच है कि सी ++ और एक आभासी मशीन वाली अधिकांश भाषाओं में कम कठिनाई होगी, खासकर वस्तुओं की नकल करते समय, कम किए गए बिंदुओं के लिए धन्यवाद, लेकिन अभी तक हम इसे बड़े खिंचाव के साथ मुखर कर सकते हैं। खासकर जब से नए निर्देशों का उपयोग करने के लिए आपके अधिकांश डेटा बफ़र्स को कम से कम 8 बाइट्स (64 बिट्स) से जोड़ा जाना चाहिए। और आप पहले से ही कुछ SIMD अनुदेश सेट का उपयोग करने के लिए उन्हें 16 बाइट्स (128 बिट्स) में संरेखित करते हैं।

और उन लोगों के लिए जो सोचते हैं कि x32 डिस्क स्थान को बचाएगा। याद रखें कि आपके पास "क्लीन" x32 सिस्टम नहीं हो सकता है, जो आपको मिलता है वह तीन दृष्टिकोणों का मिश्रण है: x86, x86-64 और x32।

यह 4 जीबी से अधिक मेमोरी का उपयोग करने वाले अनुप्रयोगों के लिए लागू नहीं है।

हां, निश्चित रूप से, यह शायद सच है। लेकिन गंभीरता से, क्या आप वास्तव में संकेत के आकार के बारे में चिंतित हैं? यदि आप वास्तव में यह सुनिश्चित करना चाहते हैं कि एप्लिकेशन एक निश्चित मात्रा से अधिक मेमोरी का उपयोग नहीं करता है, तो सिस्टम सीमा का उपयोग करें! वे निश्चित रूप से एक पूरे के रूप में एक नया एबीआई बनाने की तुलना में "भारी" कम हैं।

दिलचस्प है, 4 जीबी से कम मेमोरी वाले पूर्ण 64-बिट एड्रेस स्पेस में अनुप्रयोगों के लिए 2 अलग, विपरीत दृष्टिकोण हैं:

• एएसएलआर (एड्रेस स्पेस लेआउट रैंडमाइजेशन), जो वास्तव में विभिन्न एप्लिकेशन ऑब्जेक्ट्स को विस्तृत श्रेणी के पते (लगभग। ट्रांसलेशन ।: यानी, जैसे कि मेमोरी से बिखरने के लिए लोड कर सकता है)।
• और प्रीलिंक , जो यह सुनिश्चित करता है कि सिस्टम की प्रत्येक अनोखी वस्तु हमेशा एक ही पते पर लोड की जाती है, और यह वास्तव में ASLR के विपरीत है

एप्लिकेशन लंबे समय तक उपयोग करते हैं , लेकिन उन्हें 64-बिट एड्रेस स्पेस की आवश्यकता नहीं होती है

(नोट लेन: लेखक का अर्थ है 64-बिट लंबा)
और, निश्चित रूप से, इसका समाधान कुछ लोगों के अनुसार, इसके लिए एक नया एबीआई बनाना है।

मैं यह नहीं कहने जा रहा हूं कि अनुप्रयोगों के लिए कई लोग अभी भी लंबे समय का उपयोग करते हैं , बिना यह सोचने के बिना कि वे ऐसा क्यों करते हैं। शायद उनके पास संख्याओं की छोटी श्रृंखला है जिसका वे उपयोग करना चाहते हैं, और फिर भी वे बड़े प्रकारों का उपयोग करते हैं, जैसे कि लंबे समय से , क्योंकि उन्होंने संभवतः उन प्रणालियों पर प्रोग्रामिंग का अध्ययन किया है जो लंबे समय तक int के पर्याय के रूप में उपयोग करते हैं, या उन प्रणालियों पर भी जहां लंबे समय तक 32-बिट है और int 16bit (हैलो MS-DOS!) है।

इस समस्या का समाधान सरल है - stdint.h द्वारा प्रदान किए गए मानक प्रकारों का उपयोग करें, जैसे कि uint32_t और int16_t । इसलिए आप हमेशा उस डेटा साइज का उपयोग करेंगे जिसकी आपको उम्मीद है। यह आपकी अपेक्षा से अधिक सिस्टम पर भी काम करता है, और एफएफआई और अन्य तकनीकों के साथ काम करता है।

कई कोडांतरक आवेषण नहीं हैं

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

रूबी जैसी चीजों में कोडांतरक आवेषण के साथ एक समस्या भी है, जहां रूबी 1.9 x32 पर संकलन नहीं करता है। रूबी 1.8 के साथ , स्थिति अधिक दिलचस्प है क्योंकि यह संकलित करता है, लेकिन स्टार्टअप पर रनगेट पर सेगफॉल्ट्स फेंकता है। क्या आपको कुछ याद नहीं है?

इसके अलावा, सी लाइब्रेरी में बहुत सारे असेंबलर आवेषण होते हैं। और केवल यही कारण है कि आपको इतना पोर्ट करने की आवश्यकता नहीं है - एचजे लू, जो उनमें से अधिकांश की परवाह करता है, नए एबीआई के लेखकों में से एक है, जिसका अर्थ है कि कोड पहले से ही पोर्ट है।

x32 एबीआई x86 के साथ संगत होगा, यदि अभी नहीं, तो भविष्य में

ठीक है, मैंने पहले भी इसका उल्लेख नहीं किया था, लेकिन यह उन गलत धारणाओं में से एक है, जिन्हें मैंने पत्थर मारने से पहले देखा था। सौभाग्य से, प्रस्तुति इससे मदद करेगी। स्लाइड 22 यह स्पष्ट करती है कि नया ABI संगत नहीं है। अन्य बातों के अलावा, आप देख सकते हैं कि ABI कम से कम x86 में कुछ वास्तविक त्रुटियों को ठीक करता है, जिसमें off_t और अन्य के लिए 32-बिट डेटा प्रकारों का उपयोग शामिल है। फिर से, मैंने दो साल पहले इस विषय को छुआ था ।

यह 64-बिट प्रोसेसर का भविष्य है

नहीं, फिर से हम स्लाइड पर जाते हैं, विशेष रूप से स्लाइड करने के लिए 10. यह स्पष्ट रूप से मालिकाना प्रणालियों के लिए किया जाता है, सामान्य रूप से x86-64 को बदलने के लिए! अच्छा, अब आप कैसा महसूस कर रहे हैं?

पोर्टिंग तुच्छ होगा, आपको बस कोडांतरक आवेषण की कुछ पंक्तियों को बदलने और पॉइंटर्स के आकार को बदलने की आवश्यकता है

यह मामला नहीं है। पोर्टिंग के लिए कई अन्य मुद्दों को हल करने की आवश्यकता होती है, और कोडांतरक आवेषण सिर्फ हिमशैल के टिप हैं। इस अवधारणा को तोड़ना कि x86-64 में 64-बिट पॉइंटर्स अपने आप में एक बड़ा काम है, लेकिन एफएफआई स्टाइल सी बाइंडिंग के कार्यान्वयन की तुलना में, पहली नज़र में (और विंडोज के लिए भी) जितना बड़ा कोई नहीं सोच सकता है। याद रखें, मैंने कहा कि यह एक आसान जवाब नहीं है ?

प्रोसेसर 64-बिट से बेहतर 32-बिट निर्देश करता है

दिलचस्प बात यह है कि इंटेल एक प्रस्तुति में 32-बिट निर्देशों पर बेहतर प्रदर्शन करने का दावा करने वाला एकमात्र प्रोसेसर एटम है। मैं बोली: "64-बिट IMUL ऑपरेशन पर विलंब एटम पर 32-बिट वाले लोगों की तुलना में दोगुना है।"

तो वास्तव में IMUL क्या है? यह एक साइन गुणा ऑपरेशन है। क्या आप पॉइंटर्स को गुणा करते हैं? यह व्यर्थ है। इसके अलावा, संकेत महत्वपूर्ण नहीं हैं। और आप मुझे बताएं कि आप उस प्लेटफॉर्म (एटम) के बारे में अधिक चिंतित हैं, जिसमें बड़ी देरी होती है जब लोग 32-बिट के बजाय 64-बिट डेटा का उपयोग करते हैं? और आपकी इस समस्या का समाधान एक नया ABI बनाना है, जहाँ 64-बिट प्रकारों का उपयोग करना कठिन है। और यह सब, कार्यक्रम में सिर्फ तय करने के बजाय इन समस्याओं का कारण क्या है?

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

---

युपीडी। मैंने सिर्फ Gentoo x32 ABI RC के साथ अपने वर्चुअल मशीन पर PHP बनाने की कोशिश की। रूबी की तरह, यह संकलन नहीं करता है।