32 बिट से 64 बिट तक एक एप्लिकेशन को स्थानांतरित करते समय, स्मृति उपयोग में वृद्धि कब होगी?64 बिट पर जाने पर स्मृति उपयोग कितना बढ़ने की संभावना है?
मैं समझता हूं कि पॉइंटर्स आकार में दोगुना हो जाएंगे, मुझे संदेह है कि एक स्ट्रिंग में वर्ण स्मृति का अधिक कुशलतापूर्वक उपयोग करने के लिए 'बंच' होते हैं (इसलिए अधिक स्मृति का उपयोग नहीं करेंगे)।
स्मृति उपयोग में और वृद्धि होगी? क्या कहीं भी यह घट जाएगा, या जहां गैर-अंकगणितीय परिचालनों को गति लाभ दिखाई देगा?
आप यहां और वहां कुछ अतिरिक्त बाइट्स खर्च करने के लिए अतिरिक्त संरेखण देख सकते हैं। ऑपरेटरों में 64 बिट स्थिरांक के कारण कोड शायद बड़ा होगा।
गति के लिए, आप स्मृति उपयोग में वृद्धि के कारण मंदी का अनुभव कर सकते हैं। सीपीयू कैश अधिक तेज़ी से भर जाएगा।
मैंने x86 से x64 पर जाने वाले महत्वपूर्ण गति लाभ देखे हैं, क्योंकि x86 में x64 आर्किटेक्चर की तुलना में बहुत कम रजिस्ट्रार हैं। आपके कोड को बेहतर अनुकूलित करने के लिए कंपाइलर्स अतिरिक्त रजिस्टरों का उपयोग करते हैं। मैंने समान हार्डवेयर पर 15% स्पीडअप देखा।
दिलचस्प, मैंने कैश नहीं माना था।तो एक x86 कंपाइलर 64 बिट संगत CPU पर सभी उपलब्ध रजिस्टरों का उपयोग नहीं करेगा? क्या इसे मजबूर करने का कोई तरीका है? –
@Peter 32-बिट निष्पादनयोग्य 64-बिट रजिस्टर उपयोग नहीं कर सकते, के रूप में तक मुझे पता है। कंपाइलर को यह बताने का सबसे अच्छा तरीका है कि यह 64-बिट रजिस्टरों का "उपयोग कर सकता है" यह 64-बिट निष्पादन योग्य आउटपुट को बताना है। – luiscubal
@ पीटर: नहीं, x86 निर्देशों के साथ x64 रजिस्टर का संदर्भ देने का कोई तरीका नहीं है। यदि आप विभिन्न 64-बिट एक्सटेंशन का उपयोग करना चाहते हैं तो 64-बिट के लिए संकलित करें। – jalf
जैसा कि आपने ध्यान दिया है पॉइंटर्स बड़े होंगे। प्रोसेसर आर्किटेक्चर के आधार पर ints और/या longs भी हो सकता है। स्ट्रिंग्स को एक ही आकार में रहना चाहिए लेकिन दक्षता के लिए स्मृति में अलग-अलग गठबंधन किया जाना चाहिए। आम तौर पर, 64-बिट सीमाओं पर डेटा संरचनाओं की मेमोरी संरेखण से ज्यादातर मामलों में विखंडन बढ़ जाएगा।
इसके अलावा आपकी प्रक्रिया पता स्थान उच्च स्मृति (और नीचे बढ़ने) में दिखाई देने वाले स्टैक फ्रेम पॉइंटर्स के साथ बहुत बड़ा होने के लिए (कई आर्किटेक्चर में) दिखाई दे सकता है, लेकिन ये हमेशा वर्चुअल मेमोरी पॉइंटर्स आपके एप्लिकेशन द्वारा उपयोग में वास्तविक भौतिक स्मृति को इंगित करते हैं आमतौर पर काफी छोटा होता है।
असंभव है कि इंटेल बड़े पैमाने पर होगा। दो सबसे आम 64 बिट मॉडल एलपी 64 (पॉसिक्स) और एलएलपी 64 (विंडोज) हैं और उनमें से दोनों में, int अभी भी 32 बिट हैं। –
कुछ ऐसे मामले हैं जहां आप स्मृति को सहेज सकते हैं। वास्तविक कोड स्थानों में थोड़ा छोटा हो सकता है, क्योंकि रजिस्टरों की बढ़ती संख्या के कारण कम लोड/स्टोर आवश्यक हैं। डिफ़ॉल्ट कॉलिंग सम्मेलन उदाहरण के लिए रजिस्टरों में पैरामीटर पास करता है।
कुल मिलाकर, 64-बिट ऐप शायद थोड़ा 32-बिट एक से अधिक स्मृति का उपयोग करेगा। लेकिन यह एक सौदा-ब्रेकर होने वाला नहीं है।
"कुल मिलाकर, एक 64-बिट ऐप शायद 32-बिट की तुलना में थोड़ा अधिक स्मृति का उपयोग करेगा।" लेकिन संरेखण के मुद्दों के कारण 8 बाइट 8 बिट नहीं लेगा? ;) – tstenner
आर्किटेक्चर के आधार पर कोड भी बढ़ सकता है। वैश्विक चर और निरंतर अक्सर पूर्ण पते (जिसे प्रोग्राम लोडर द्वारा स्थानांतरित किया जाता है) के माध्यम से संदर्भित किया जाता है, ये संदर्भ 64 बिट मोड में 64 बिट हैं। X64 पर 64 बिट स्थिरांक के लिए एक स्पष्ट mov निर्देश है, इसलिए प्रोग्राम केवल स्थिरता के आकार का विकास करेगा। जंप और कॉल निर्देश भी बड़ा हो सकते हैं, लेकिन यह कंपाइलर और लिंकर के कई पैरामीटर पर निर्भर करता है। अन्य वास्तुकलाओं पर यह भी बदतर हो सकता है। उदाहरण के लिए एसपीएआरसी पर, 32 से 64 बिट तक जाने पर कोड महत्वपूर्ण रूप से बढ़ सकता है। चूंकि स्पार्क में कोई निर्देश नहीं है जो 22 बिट से अधिक लोड कर सकता है, जब वैश्विक चर या स्थिर के 32 बिट पते को लोड करते समय, इसे 64 बिट स्थिर लोड करने के लिए 2 निर्देशों की आवश्यकता होती है, इसे 3 रजिस्टरों के साथ 5 निर्देशों की भी आवश्यकता होती है। रजिस्टर दबाव को बढ़ाकर कंपाइलर अक्सर ऑप्टिमाइज़ेशन अवसरों को याद करता है, जिससे कोड आवश्यक से बहुत बड़ा होता है।
न केवल सूचक आकार बढ़ता है बल्कि लंबे और हस्ताक्षरित लंबे आकार तक भी। – pmr
+1 अपराह्न; और खूबसूरती से यहां समझाया गया है: http://developers.sun.com/solaris/articles/ILP32toLP64Issues.html – bits
यह पीडीएफ एक बार भी देखें: http://scc.ustc.edu.cn/zlsc/czxt/200910/W020100308601263456982.pdf – bits