32-बिट इंटेल प्रोसेसर पर मेमोरी संरेखण

Question

इंटेल के 32-बिट प्रोसेसर जैसे कि पेंटियम में 64-बिट विस्तृत डेटा बस है और इसलिए प्रति एक्सेस 8 बाइट्स प्राप्त करें। इस पर आधारित, मैं मानता हूं कि पता प्रोसेसर पर इन प्रोसेसर उत्सर्जित होने वाले भौतिक पते हमेशा 0 के गुणक होते हैं।

सबसे पहले, क्या यह निष्कर्ष सही है?

दूसरा, यदि यह सही है, तो किसी को डेटा संरचना सदस्यों को 8 बाइट सीमा पर संरेखित करना चाहिए। लेकिन मैंने लोगों को इन प्रोसेसर पर 4-बाइट संरेखण का उपयोग करके देखा है।

ऐसा करने में उन्हें कैसे उचित ठहराया जा सकता है?

Answer 1

अंगूठे का सामान्य नियम (सीधे इंटेल और एएमडी के अनुकूलन मैनुअल से) यह है कि प्रत्येक डेटा प्रकार को अपने आकार से गठबंधन किया जाना चाहिए। एक int32 को 64-बिट सीमा पर 0 -पर एक 32-बिट सीमा पर गठबंधन किया जाना चाहिए, और इसी तरह। एक चार कहीं भी ठीक फिट होगा।

अंगूठे का एक और नियम है, निश्चित रूप से "संकलक को संरेखण आवश्यकताओं के बारे में बताया गया है"। आपको इसके बारे में चिंता करने की आवश्यकता नहीं है क्योंकि संकलक डेटा तक कुशल पहुंच की अनुमति देने के लिए सही पैडिंग और ऑफ़सेट जोड़ना जानता है।

एकमात्र अपवाद जब SIMD निर्देश है, जहां आप मैन्युअल रूप से सबसे compilers पर संरेखण सुनिश्चित करने के लिए है के साथ काम कर रहा है।

दूसरे, अगर यह सही है, तो एक डेटा संरचना सदस्यों एक 8 बाइट सीमा पर संरेखित करना चाहिए। लेकिन मैंने लोगों को इन प्रोसेसर के बजाय 4-बाइट संरेखण का उपयोग करके देखा है।

मुझे नहीं लगता कि इससे कोई फर्क पड़ता है। सीपीयू बस 64-बिट ब्लॉक के लिए एक पठन जारी कर सकता है जिसमें उन 4 बाइट्स शामिल हैं। इसका मतलब है कि अनुरोधित डेटा से पहले या उसके बाद 4 अतिरिक्त बाइट प्राप्त होते हैं। लेकिन दोनों मामलों में, यह केवल एक ही पढ़ता है। 32-बिट चौड़ा डेटा के 32-बिट संरेखण सुनिश्चित करता है कि यह एक 64-बिट सीमा पार नहीं करेगा।

Answer 2

शारीरिक बस 64 बिट व्यापक है ... 8 के कई -> हाँ

हालांकि, वहाँ रहे हैं दो और कारक पर विचार करने के:

1. कुछ x86 निर्देश सेट बाइट संबोधित कर रहे हैं। कुछ 32 बिट गठबंधन हैं (यही कारण है कि आपके पास 4 बाइट चीज है)। लेकिन कोई (कोर) निर्देश 64 बिट गठबंधन नहीं है। सीपीयू misaligned डेटा का उपयोग संभाल सकता है।
2. यदि आप प्रदर्शन की परवाह करते हैं, तो आपको कैश लाइन के बारे में सोचना चाहिए, मुख्य स्मृति नहीं। कैश लाइनें बहुत व्यापक हैं।

Answer 3

यादृच्छिक पहुंच के लिए और जब तक डेटा गलत तरीके से गलत नहीं किया जाता है (उदाहरण के लिए सीमा पार करना), मुझे नहीं लगता कि यह बहुत मायने रखता है; डेटा में सही पता और ऑफ़सेट हार्डवेयर के साथ सरल और निर्माण के साथ पाया जा सकता है। जब एक पढ़ने का उपयोग एक मूल्य प्राप्त करने के लिए पर्याप्त नहीं होता है तो यह धीमा हो जाता है। यही कारण है कि संकलक आमतौर पर छोटे मान (बाइट इत्यादि) को एक साथ रखते हैं क्योंकि उन्हें एक विशिष्ट ऑफसेट पर नहीं होना चाहिए; शॉर्ट्स भी पते पर होना चाहिए, 4-बाइट पते पर 32-बिट और 8-बाइट पते पर 64-बिट होना चाहिए।

ध्यान दें कि यदि आपके पास कैशिंग शामिल है और रैखिक डेटा पहुंच है, तो चीज़ें अलग-अलग होंगी।

Answer 4

वे ऐसा करने में उचित हैं क्योंकि 8-बाइट संरेखण में बदलना एबीआई परिवर्तन का गठन करेगा, और मामूली प्रदर्शन सुधार समस्या के लायक नहीं है।

जैसा कि किसी और ने पहले ही कहा है, cachelines पदार्थ। वास्तविक मेमोरी बस पर सभी पहुंच कैश लाइनों (x86 पर 64 बाइट्स, आईआईआरसी) के मामले में हैं। "हर प्रोग्रामर को स्मृति के बारे में क्या जानने की आवश्यकता है" दस्तावेज़ देखें जो पहले से ही उल्लेख किया गया था। तो वास्तविक स्मृति यातायात 64 बाइट गठबंधन है।

Answer 5

64 बिट्स बस जो आप संदर्भित करते हैं उन्हें कैश खिलाती है। एक सीपीयू के रूप में, हमेशा पूरे कैश लाइनों को पढ़ें और लिखें। कैश लाइन का आकार हमेशा 8 का एक बहु होता है, और इसका भौतिक पता वास्तव में 8 बाइट ऑफ़सेट पर गठबंधन होता है।

कैश-टू-रजिस्टर ट्रांसफर बाहरी डेटाबेस का उपयोग नहीं करते हैं, इसलिए उस बस की चौड़ाई अप्रासंगिक है।