2012-01-20 15 views
19

मूल 64 bit पूर्णांक अंकगणितीय निर्देश 32 bit काउंटर भागों (x86_64 मशीन 64 bit ओएस के साथ) से धीमे हैं?प्रदर्शन 32 बिट बनाम 64 बिट अंकगणित

संपादित करें: वर्तमान सीपीयू पर इस तरह के इंटेल Core2 जोड़ी, i5/i7 आदि

+1

नहीं, वे नहीं हैं। –

+7

@ कोडी: ओह सच में? आप दावा करते हैं कि 64-बिट पूर्णांक विभाजन 32-बिट पूर्णांक विभाजन के रूप में तेज़ है? –

+2

आप दोनों सही हैं। डेविड श्वार्टज़ के स्पष्टीकरण को नीचे पढ़ें।सीपीयू के एएलयू में एक निर्देश निष्पादित करना एक बात है। सीपीयू में ऑपरेंड प्राप्त करना, और परिणाम सीपीयू से वापस लेना, एक और बात है। – paulsm4

उत्तर

34

यह सही सीपीयू और आपरेशन पर निर्भर करता है। 64-बिट पेंटियम IVs पर, उदाहरण के लिए, 64-बिट रजिस्टरों का गुणा काफी धीमा था। कोर 2 और बाद के सीपीयू को ग्राउंड अप से 64-बिट ऑपरेशन के लिए डिज़ाइन किया गया है।

आम तौर पर, 64-बिट प्लेटफॉर्म के लिए लिखे गए कोड 32-बिट चर का उपयोग करते हैं जहां मूल्य उनके अनुरूप होंगे। यह मुख्य रूप से इसलिए नहीं है क्योंकि अंकगणितीय तेज है (आधुनिक CPUs पर, यह आमतौर पर नहीं है) लेकिन क्योंकि यह कम स्मृति और मेमोरी बैंडविड्थ का उपयोग करता है।

एक दर्जन पूर्णांक वाले एक संरचना का आधा आकार होगा यदि वे पूर्णांक 32-बिट हैं, तो वे 64-बिट हैं। इसका मतलब है कि इसे स्टोर करने के लिए आधा बाइट्स लेना होगा, कैश में आधे से ज्यादा जगह, और इसी तरह।

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

तो असली जवाब यह है कि इससे कोई फर्क नहीं पड़ता। यहां तक ​​कि यदि आप x86_64 मोड का उपयोग करते हैं, तो आप अभी भी 32-बिट अंकगणित का उपयोग कर सकते हैं, जहां यह करेगा, और आपको बड़े पॉइंटर्स और अधिक सामान्य प्रयोजन रजिस्ट्रारों के लाभ मिलेंगे। जब आप 64-बिट देशी संचालन का उपयोग करते हैं, तो ऐसा इसलिए होता है क्योंकि आपको 64-बिट ऑपरेशंस की आवश्यकता होती है, और आप जानते हैं कि वे इसे 32-बिट ऑपरेशंस के साथ फिक्र करने से तेज़ होंगे - आपकी एकमात्र अन्य पसंद। तो 64-बिट रजिस्ट्रार बनाम 32-बिट के सापेक्ष प्रदर्शन किसी भी कार्यान्वयन निर्णय में कभी निर्णायक कारक नहीं होना चाहिए।

+0

धन्यवाद, लेकिन मैं केवल सीपीयू चक्रों के बारे में चिंतित था। कैश-मिस मुद्दे और समान बिल्कुल ठीक हैं, लेकिन यह एक और कहानी है। – Cartesius00

+0

फिर मेरा पहला वाक्य आपके प्रश्न का उत्तर देता है। लेकिन मेरा बड़ा मुद्दा यह है कि इससे कोई फर्क नहीं पड़ता। 64-बिट अंकगणित का उपयोग नहीं किया जाता है जहां 32-बिट अंकगणित किया जाएगा। तो सापेक्ष प्रदर्शन किसी भी निर्णय में कभी भी निर्धारित कारक नहीं होना चाहिए। –

+0

क्या आपके पास कोई ठोस उदाहरण हैं? चलो कोर 2 डुओ पर कहें। या लिंक? – Cartesius00

1

मुख्य रूप से 32-बिट अनुप्रयोग (जिसका मतलब केवल 32-बिट अंकगणित होता है, और 32-बिट पॉइंटर्स पर्याप्त हैं), x86-64 आर्किटेक्चर के वास्तविक लाभ आर्किटेक्चर में किए गए अन्य "अपडेट" एएमडी हैं :

  • 16 सामान्य प्रयोजन रजिस्टर, 8 से 86 में
  • आरआईपी-रिश्तेदार को संबोधित मोड
  • दूसरों ...

इस नए x32 ABI implemente से स्पष्ट है लिनक्स में डी।

5

मैंने अभी इस सवाल पर ठोकर खाई है, लेकिन मुझे लगता है कि एक बहुत ही महत्वपूर्ण पहलू यहां गायब है: यदि आप वास्तव में इंडेक्स के लिए 'int' प्रकार का उपयोग करके असेंबली कोड में देखते हैं तो आपके कंपाइलर उत्पन्न कोड को धीमा कर देगा। ऐसा इसलिए है क्योंकि कई 64 बिट कंपाइलर्स और प्लेटफॉर्म (विजुअल स्टूडियो, जीसीसी) पर 32 बिट प्रकार के लिए 'int' डिफ़ॉल्ट होता है और पॉइंटर्स के साथ पता गणना (जो कि 64 बिट ओएस पर 64 बिट आवश्यक है) और 'int' संकलक को उत्सर्जित करने का कारण बनता है 32 और 64 बिट रजिस्टरों के बीच अनावश्यक रूपांतरण। मैंने अभी अपने कोड के एक बहुत ही महत्वपूर्ण महत्वपूर्ण आंतरिक लूप में इसका अनुभव किया है। 'Int' से 'long long' तक स्विचिंग के रूप में लूप इंडेक्स ने मेरे एल्गोरिदम रन टाइम को लगभग 10% तक सुधार दिया, जो कि व्यापक एसएसई/एवीएक्स 2 वेक्टरिज़ेशन पर विचार कर रहा था, जो कि पहले से ही उस बिंदु पर उपयोग कर रहा था।

+0

क्या आप उस विशिष्ट उदाहरण तक पहुंच प्रदान कर सकते हैं? मैं वर्तमान में एक ही दुविधा में हूं (भारी AVX2 वेक्टरिज़ेशन, आदि) और मुझे यकीन है कि यह इसके लायक है, इसके अलावा, लूप इंडेक्स के प्रकार पर ध्यान दें। –

संबंधित मुद्दे