क्या 64 बिट प्रोग्राम 32 बिट संस्करणों की तुलना में बड़े और तेज हैं?

Question

मुझे लगता है कि मैं x86 पर ध्यान केंद्रित कर रहा हूं, लेकिन मैं आम तौर पर 32 से 64 बिट की चाल में रुचि रखता हूं।

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

मैंने यह भी सुना है कि x86 पर 32 बिट मोड को अपने कैश को फ्लश करना पड़ता है जब संभव अतिव्यापी 4 जी एड्रेस स्पेस के कारण संदर्भ स्विच हो जाता है।

तो, 64 बिट के वास्तविक लाभ क्या हैं?

और पूरक प्रश्न के रूप में, क्या 128 बिट और भी बेहतर होगा?

संपादित करें:

मैंने सिर्फ अपना पहला 32/64 बिट प्रोग्राम लिखा है। यह 16 बाइट (32 बी संस्करण) या 32 बाइट (64 बी संस्करण) ऑब्जेक्ट्स से जुड़ी हुई सूचियाँ / पेड़ बनाता है और बहुत कुछ करने के लिए मुद्रण करता है - वास्तव में उपयोगी कार्यक्रम नहीं है, और कुछ विशिष्ट नहीं है, लेकिन यह मेरा पहला है।

आकार: 81128 (32 बी) वी 83672 (64 बी) - इतना अंतर नहीं

गति: 17 एस (32 बी) वी 24 एस (64 बी) - 32 बिट ओएस (ओएस-एक्स 10.5.8) पर चल रहा है

अपडेट करें:

मैं ध्यान देता हूं कि एक नया हाइब्रिड x32 ABI (एप्लिकेशन बाइनरी इंटरफ़ेस) विकसित किया जा रहा है जो कि 64b है लेकिन 32b पॉइंटर्स का उपयोग करता है। कुछ परीक्षणों के लिए इसका परिणाम छोटे कोड और 32 बी या 64 बी की तुलना में तेजी से निष्पादन है।

https://sites.google.com/site/x32abi/

Comments

का डुप्लिकेट की तरह लगता है stackoverflow.com/questions/324015/...

— सुमा

और मेरा कुछ दिन पहले से ही: stackoverflow.com/questions/2334148/…

— श्री बॉय

कुछ ओवरलैप मैं सहमत हूं, लेकिन सीपीयू कैश और 128 बिट भागों पर अभी तक कोई लेने वाला नहीं है। लिंक के लिए धन्यवाद सुमा और जॉन।

— दार्शनिकोर्न

पर एक नजर डालें stackoverflow.com/questions/607322/...

— शॉन

"मैंने यह भी सुना है कि x86 पर 32 बिट मोड को अपने कैश को फ्लश करना पड़ता है जब 4 जी एड्रेस स्पेस को ओवरलैप करने के कारण संदर्भ स्विच हो जाता है।" क्या आप कृपया मुझे उस संदर्भ की ओर संकेत कर सकते हैं जो इस बारे में बात करता है?

— gkb0986

Answer 1

जब तक आपको अधिक मेमोरी एक्सेस करने की आवश्यकता नहीं होती है, जो कि 32 बी एड्रेसिंग आपको अनुमति देगा, लाभ छोटे होंगे, यदि कोई हो।

64 बी सीपीयू पर चलने पर, आपको 32 जीबी या 64 बी कोड (आप एक ही कैश और एक ही बस का उपयोग कर रहे हैं) पर समान मेमोरी इंटरफ़ेस मिलता है।

जबकि x64 वास्तुकला में कुछ और रजिस्टर हैं जो आसान अनुकूलन की अनुमति देता है, यह अक्सर इस तथ्य से मुकाबला होता है कि संकेत अब बड़े हैं और किसी भी संरचना का उपयोग करके उच्चतर मेमोरी ट्रैफ़िक में परिणाम लाते हैं। मैं एक 32b की तुलना में 64-30 एप्लिकेशन के लिए समग्र मेमोरी उपयोग में वृद्धि का अनुमान लगाता हूं कि यह लगभग 15-30% है।

Comments

प्रस्तावित x32 ABI पर आपका क्या विचार है?

— दार्शनिकों

मुझे लगता है कि मेम्स्की और स्ट्रैची 32 बिट सीपीयू से अधिक तेज़ होंगे क्योंकि यह हर बार एक शब्द पढ़ेगा क्योंकि एक शब्द 64 बिट सीपीयू पर 8 बाइट्स है

— मार्क मा

Answer 2

मैं आमतौर पर x86 की तुलना में x86-64 पर कंप्यूट-गहन कोड के लिए 30% की गति में सुधार देखता हूं। यह इस तथ्य के कारण सबसे अधिक संभावना है कि हमारे पास 8 x 32 बिट सामान्य प्रयोजन रजिस्टर और 8 x एसएसई रजिस्टरों के बजाय 16 x 64 बिट सामान्य प्रयोजन रजिस्टर और 16 x एसएसई रजिस्टर हैं। यह x86-64 लिनक्स पर Intel ICC कंपाइलर (11.1) के साथ है - अन्य संकलक (जैसे gcc), या अन्य ऑपरेटिंग सिस्टम (जैसे Windows) के साथ परिणाम, निश्चित रूप से भिन्न हो सकते हैं।

Comments

'कम्प्यूट इंटेंसिव' से क्या आपका मतलब ग्राफिक्स, मैट्रिक्स, डीएफटी से है?

— दार्शनिकोर्न

@ एफिल: हाँ, मुख्य रूप से इमेज प्रोसेसिंग, ज्यादातर पूर्णांक (निश्चित बिंदु), बहुत सारे सिम कोड, आदि

— पॉल आर

मैंने देखा है कि 64-बिट कंपाइलर SSE रजिस्टरों का उपयोग करते हैं जबकि 32-बिट कंपाइलर मानक ALU का उपयोग करते हैं। यह संकीर्ण एफपी चौड़ाई (64 बनाम 80) प्लस अतिरिक्त निर्देशों के कारण 64-बिट कोड को तेज बनाता है।

— आईएएमआईसी

Answer 3

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

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

संपादित करें :
समानांतर जोड़ के बारे में मेरे कथन की अवहेलना करें। यह एक साधारण ऐड स्टेटमेंट द्वारा नहीं किया गया है ... मैं भ्रमित कर रहा था कि कुछ सदिश / SSE निर्देशों के साथ। बड़े पते वाले स्थान से अलग एक और सटीक लाभ यह है कि अधिक सामान्य उद्देश्य रजिस्टर हैं, जिसका अर्थ है कि सीपीयू रजिस्टर फ़ाइल में अधिक स्थानीय चर बनाए रखा जा सकता है, जो कि एक्सेस करने के लिए बहुत तेज़ है, जैसे कि आप चर में डालते हैं प्रोग्राम स्टैक (जिसका अर्थ है आमतौर पर L1 कैश के लिए बाहर जाना)।

Comments

> "उदाहरण के लिए, दो रजिस्टरों में 32-बिट संख्या के दो जोड़े रखना और एकल ऐड ऑपरेशन में दो जोड़ता है" क्या कोई कंपाइलर ऐसा कर रहा है? इसके अलावा, लगता है कि एसएसई निर्देशों का उपयोग करके x86 पर भी ऐसा ही किया जा सकता है।

— सुमा

इस तरह के "दो को एक में जोड़ता है" के बारे में अधिक सोचना, यह एक बकवास है और कोई संकलक इसे अनुकूलन के रूप में नहीं कर सकता है, क्योंकि कम 32 बी के अलावा उच्चतर 32 बी में अतिप्रवाह हो सकता है। इसके लिए आपको SIMD के निर्देशों की आवश्यकता है।

— सुमा

मुझे लगता है कि अगर आप उत्सुक थे तो आप 64 बिट रजिस्टरों में कई 16 बिट अंकगणित कर सकते थे। गड़बड़ लगता होगा, लेकिन मुझे यकीन है कि यह किया गया है।

— दार्शनिकोर्न

'लगातार कारक' - ध्वनि की तरह कुछ ब्रायन हार्वे कहेंगे।

— दार्शनिकोर्न

Answer 4

अधिक रजिस्टर होने के अलावा, डिफ़ॉल्ट रूप से 64-बिट में SSE2 है। इसका मतलब है कि आप वास्तव में समानांतर में कुछ गणना कर सकते हैं। SSE एक्सटेंशन में अन्य उपहार भी थे। लेकिन मुझे लगता है कि मुख्य लाभ एक्सटेंशन की उपस्थिति की जांच करने के लिए नहीं है। यदि यह x64 है, तो इसमें SSE2 उपलब्ध है। ... अगर मेरी स्मृति मुझे सही ढंग से सेवा देती है।

Answer 5

मैं एक शतरंज इंजन को बेवकूफ बना रहा हूं जिसका नाम कोडिंग है । न्यूनतम 9 पर आधारित वृक्ष की खोज (एक निश्चित स्थिति से) का उपयोग करते हुए सबसे अच्छी चाल निष्कर्षण:

Win32विन्यास पर : ~ 17.0s;

x64कॉन्फ़िगरेशन पर स्विच करने के बाद : ~ 10.3s;

यह त्वरण का 41% है!

Answer 6

अपने आवेदन को 64 बिट तक ले जाने का औचित्य केवल बड़े डेटाबेस जैसे अनुप्रयोगों में अधिक मेमोरी के लिए आवश्यक है या कम से कम 100 समवर्ती उपयोगकर्ताओं के साथ ईआरपी एप्लिकेशन जहां 2 जीबी की सीमा बेहतर प्रदर्शन के लिए कैश होने पर बहुत जल्दी से अधिक हो जाएगी। यह विशेष रूप से विंडोज ओएस पर मामला है जहां पूर्णांक और लंबा अभी भी 32 बिट है (उनके पास नया चर _int64 है। केवल बिंदु 64 बिट हैं। वास्तव में WOW64 विंडोज x64 पर अत्यधिक अनुकूलित है ताकि 64 बिट विंडोज पर कम दंड के साथ 32 बिट अनुप्रयोग चलें। OS। Windows x64 पर मेरा अनुभव 32 बिट अनुप्रयोग संस्करण है, जो कि पूर्व के मामले में 64 बिट की तुलना में 10-15% तेज है, कम से कम मालिकाना मेमोरी डेटाबेस के लिए आप बी-ट्री को बनाए रखने के लिए सूचक अंकगणितीय का उपयोग कर सकते हैं (डेटाबेस सिस्टम का अधिकांश प्रोसेसर गहन भाग) । संगणना गहन अनुप्रयोगों के लिए 32-64 बिट ऑपरेटिंग सिस्टम पर दोहरे द्वारा वहन नहीं किए जाने वाले उच्चतम सटीकता के लिए बड़े दशमलव की आवश्यकता होती है। ये एप्लिकेशन सॉफ़्टवेयर इम्यूलेशन के बजाय मूल रूप से _int64 का उपयोग कर सकते हैं। बेशक बड़े डिस्क आधारित डेटाबेस भी क्वेरी योजनाओं और इतने पर कैशिंग के लिए बड़ी मेमोरी का उपयोग करने की क्षमता के कारण 32 बिट में सुधार दिखाएंगे।

Comments

पहला, intनिष्पादन वातावरण के शब्द आकार की परवाह किए बिना, हर जगह 32-बिट रहता है। long64-बिट के लिए संकलन करते समय क्या कंपाइलर अभी भी 32-बिट है? क्या आप दावा कर रहे हैं कि MSVC ऐसा करता है? AFAIK, यह भी [लगभग] C ++ 11 मानक में कवर किया गया है: sizeof(long) == sizeof(void*)कृपया, किसी ने मुझे सही कर दिया है अगर मैं गलत हूं, क्योंकि मेरे पास MSVC तक आसान पहुंच नहीं है।

— मैथ्यू हॉल

@ मैथ्यू हॉल: इसकी विंडोज़ 64 बिट ऑपरेटिंग सिस्टम स्टैंडर्ड और उसके बाद MSVC इस LLP64 मॉडल (बनाम यूनिक्स वेरिएंट के लिए LP64) को फॉलो करती है। देखें ( msdn.microsoft.com/en-us/library/3b2e7499(v=vs.100).aspx )।

— गिरीशके

Answer 7

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

Comments

वास्तव में, ऐसा नहीं है: मेमोरी बस कुछ भी चौड़ाई है, जिसमें प्रोसेसर के रजिस्टरों की चौड़ाई के साथ कुछ भी करना आवश्यक नहीं है। कुछ 32 बिट सिस्टम एक समय में 128 बिट प्राप्त करते हैं, 64 बिट सिस्टम होते हैं जो एक बार में 32 लाते हैं, और यहां तक ​​कि 32 बिट सिस्टम जो एक बार में 8 बिट्स से अधिक मेमोरी नहीं लेते हैं।

— एंड्रयू मैकग्रेगर

ठीक है, मुझे इस बारे में पता नहीं था- फिर भी, क्या यह सही नहीं है कि एक एकल निर्देश एक 64 बिट सीपीयू पर 64 बिट्स और 32 बिट्स सीपीयू पर 32 बिट्स को स्थानांतरित करता है? इसलिए जब बिंदु A से बिंदु B तक की बड़ी मात्रा में मेमोरी की प्रतिलिपि बनाई जाती है, तो इसका मतलब कम से कम कम निर्देश को 64-बिट CPU (भले ही मेमोरी बस अड़चन हो) पर निकालने की आवश्यकता होगी?

— रुण आमोद

बड़ी मात्रा में मेमोरी को स्थानांतरित करते समय, आप x86 और x64 दोनों पर 128b SIMD निर्देशों का उपयोग करेंगे।

— सुमा

क्या वास्तव में कोई "64 बिट सिस्टम है जो एक बार में 32 प्राप्त करता है" है? कृपया कुछ नाम बताएं। यदि वहाँ हैं, तो क्या वे वास्तव में "64 बिट सिस्टम" हैं?

— जॉनी

Answer 8

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

सामान्य तौर पर, हालांकि, 64 बिट कोड आवश्यक रूप से कोई तेज नहीं है, और आमतौर पर बड़ा होता है, रनटाइम पर कोड और मेमोरी उपयोग दोनों के लिए।

Comments

मुझे आपके द्वारा बनाई जा रही बात काफी रास नहीं आ रही है। प्रारंभ में (पहला वाक्य) आप कहते हैं कि 64 बिट प्रोग्राम आम तौर पर तेजी से चलेंगे, लेकिन फिर आपका आखिरी वाक्य सभी को "वास्तव में नहीं" कहने के लिए पीछे हटने वाला प्रतीत होता है

— एसएन

Answer 9

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

Comments

नहीं । यह अभ्यस्त है। अगर RAM की आवश्यकता 4GB से अधिक हो जाती है, तो ही यह तेज़ होगा। आप 32 बिट आर्किटेक्चर में 4GB से कम डेटा में 1000Millions पूर्णांक सरणी आसानी से खोज सकते हैं। तो यहाँ 64 बिट मशीन का प्रयोग धीमा हो जाएगा

— चिकित्सा