रास्पबियन 64-बिट मोड में चलती है


52

में इस पेज आधिकारिक RPi3 घोषणा में कहा गया है:

आपको हमारे डाउनलोड पृष्ठ से हाल ही के NOOBS या रास्पियन छवि की आवश्यकता होगी। लॉन्च के समय, हम उसी 32-बिट रास्पबियन उपयोगकर्ता का उपयोग कर रहे हैं जो हम अन्य रास्पबेरी पाई उपकरणों पर उपयोग करते हैं; अगले कुछ महीनों में हम जांच करेंगे कि 64-बिट मोड में जाने में मूल्य है या नहीं।

मेरा सवाल है, यह देखते हुए कि प्रोसेसर 64 बिट्स है, क्या यह स्पष्ट नहीं है कि 64 बिट्स में ओएस चलाना हर तरह से बेहतर होगा? मैं क्या खो रहा हूँ?


9
मैंने एक बार एक ऐसी कंपनी के लिए काम किया, जिसने DEC / Alpha (बहुत समय पहले) पर 32bit से 64bit OSF तक के सॉफ्टवेयर को पोर्ट किया। बस एक सीधा recompile, क्योंकि कोडबेस पहले से ही 64bit का अनुपालन था। पूर्णांक और बिंदुओं में अतिरिक्त मेमोरी खपत से 10% प्रदर्शन प्रभावित हुआ। यह उन दिनों में वापस आ गया था जब प्रदर्शन को तीन अंकों के mhz और दोहरे (शायद कम ट्रिपल) अंकों की यादों में मापा गया था। बिना जहाज पर 4 + जीबी के रैम, जरूरी नहीं कि एक अच्छा विचार हो।
क्रिस के

6
64-बिट पहले पीआई की तुलना में अधिक मेमोरी के साथ भुगतान करता है।
थोरबजोरन रावन एंडरसन

2
X86 आधारित प्रणालियों पर यह तय करने में कठिनाई एक हाइब्रिड एबी को भी जाने देती है: en.wikipedia.org/wiki/X32_ABI जो 32 बिट पॉइंटर्स और 64 बिट सीपीयू रजिस्टरों का उपयोग करता है।
21 दिसंबर को प्लाज़्मा एचएच

1
@ क्रिसहाइम्सकी लेकिन एआरएम और x86 अलग हैं। जब वे 32 से 64 बिट तक जाते हैं तो वे रजिस्टरों की संख्या को दोगुना कर देते हैं और निर्देश सेट के कुछ पहलुओं को फिर से डिज़ाइन करते हैं जो अधिकांश मामलों में कोड को तेजी से चलाते हैं। आप इंटरनेट पर बहुत सारे बेंचमार्क देख सकते हैं
phuclv

@rsaxvc तो मेरी टिप्पणी से क्या जुड़ता है? मैंने कहा "एआरएम और x86" यह कहने के लिए कि 64 बिट्स वाले आर्किटेक्चर में अन्य आर्किटेक्चर जैसे DEC / Alpha या Sparc, MIPS के विपरीत एप्लिकेशन के प्रदर्शन में सुधार होता है ...
phuclv

जवाबों:


62

यह देखते हुए कि प्रोसेसर 64 बिट्स है, क्या यह स्पष्ट नहीं है कि 64 बिट्स में ओएस चलाना हर तरह से बेहतर होगा?

नहीं, वास्तव में, यह नहीं है। कुछ तरीकों से, 64 बिट ऑपरेटिंग सिस्टम चलाने से रास्पबेरी पाई का प्रदर्शन बिगड़ सकता है

64 बिट के लाभ :

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

रास्पबेरी पाई में 4 जीबी से अधिक रैम नहीं है। 1 जीबी रैम में, आपने दो प्राथमिक लाभों में से पहला खो दिया है। दूसरे लाभ के रूप में, कितने प्रतिशत लोग वास्तव में पर्याप्त विशाल संख्या का उपयोग कर रहे हैं कि यह नींव के लिए पूरे दूसरे ऑपरेटिंग सिस्टम का समर्थन करने के लिए समझ में आता है? जैसा कि, आरपीआई सॉफ्टवेयर विधियों के माध्यम से बड़ी संख्या में उपयोग कर सकता है, लेकिन ऐसा लगता है जैसे आप उस दायरे में लगातार रहने वाले हैं, वैसे भी आपको बेहतर हार्डवेयर का उपयोग करने की आवश्यकता है।

64 बिट के साथ समस्या :

एक बड़ी संख्या को संग्रहीत करने की क्षमता जादू द्वारा प्रदान नहीं की जाती है। बल्कि, स्मृति वस्तुओं के आकार को बढ़ाने की आवश्यकता है। सी (और सी ++) में यह एक बदलने से intकरने के लिए int64_t। यह स्वचालित रूप से नहीं किया जाता है, इसलिए नींव के बारे में टिप्पणी दो शाखाओं को बनाए रखना नहीं चाहती है।

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

यदि एप्लिकेशन / ऑपरेटिंग सिस्टम को 64 बिट आर्किटेक्चर का लाभ उठाने के लिए लिखा गया है, तो आपका एप्लिकेशन अधिक मेमोरी का उपयोग करने जा रहा है, बस इसलिए कि चर और पॉइंटर्स अधिक स्थान ले रहे हैं। आमतौर पर यह मशीनों के लिए एक अपेक्षाकृत छोटा व्यापार है जो भत्तों से लाभान्वित होगा। हमारे मामले में, हमारे पास बहुत कम भत्ते हैं, और बहुत कम रैम है।

नोट का भी :

सिर्फ इसलिए कि आप 64 बिट मशीन पर चल रहे हैं, इसका मतलब यह नहीं है कि एप्लिकेशन 32 बिट के रूप में नहीं चल रहा है। विंडोज दो अलग-अलग इंस्टॉल पथ, C:\Program Filesऔर C:\Program Files (x86)

तो, क्या आधार संभावना 64 बिट समर्थन प्रदान करेगा? :

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


7
मान लें कि आप C और दोस्तों के बारे में बात करते हैं, किसी भी प्रकार का आकार <= int समान है। Linux के एड्रेस मॉडल के तहत लंबे समय के अनुसार size_t और पॉइंटर्स आकार में बढ़ सकते हैं। आप वर्चुअल एड्रेस स्पेस के बिंदुओं से भी पूरी तरह से चूक जाते हैं, जो तब होता है जब आप मेमोरी मैप्ड I / O करते हैं।

3
यह भौतिक मेमोरी मात्रा और वर्चुअल मेमोरी के बीच अंतर करने के लिए उन्नत नहीं है। यह गलत सूचनाओं का प्रचार नहीं करने के लिए भी उन्नत नहीं है। sizeof(char)हमेशा एक है। लिनक्स के तहत, sizeof(short), sizeof(int), sizeof(float), sizeof(double)bitness के साथ अलग अलग नहीं है। यह आपके दावों में एक बड़ा अंतर है।

11
मुझे x64इस उत्तर के उपयोग में समस्या है । x64का संक्षिप्त नाम है x86-64। यह "64 बिट" का पर्याय नहीं है । 64 बिट एआरएम सीपीयू हैं AArch64
ओली

6
आपके द्वारा सूचीबद्ध से अधिक 64-बिट पेशेवरों हैं। क्या ARM64 में प्रदर्शन लाभ है , en.wikipedia.org/wiki/64-bit_computing#Pros_and_cons
phuclv

3
आपने 64 बिट OS में जाने का सबसे बड़ा कारण याद किया। 19 जनवरी, 2038. 32 बिट लिनक्स इस समय तारीखों को संभाल नहीं सकता है। काफी समय से यह फिक्स 64 बिट लिनक्स (और 32 बिट यूनिक्स समय पर आधारित किसी भी सॉफ्टवेयर को अपग्रेड) कर रहा है। 2038 अब 20 साल दूर है, लेकिन रास्पबेरी पाई, एक छोटी एम्बेडेड मशीन होने के कारण भविष्य में इसका उपयोग करने की कुछ क्षमता है। वास्तव में किसी ने भी Y2K समस्या को 1980 में गंभीरता से नहीं लिया।
स्टीव साइडर

19

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

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

(एक तरफ के रूप में, इस कारण से, इंटेल / एएमडी लिनक्स के लिए "x32" अबी बनाने में कुछ काम हुआ है , सीपीयू संवर्द्धन को ध्यान में रखते हुए लेकिन 32-बिट पॉइंटर्स का उपयोग करके।)


5
भले ही AArch32 में पहले से ही x86 से अधिक रजिस्टर हैं, फिर भी AArch64 बेहतर करता है क्योंकि अब अलग SP और PC है। इससे पहले कि आप अधिक से अधिक 14 सामान्य प्रयोजन रजिस्टर है। आपके पास एक बेहतर डिज़ाइन किया गया निर्देश सेट है, क्या ARM64 , 64-बिट ARM (Aarch64) इंस्ट्रक्शन बूस्ट परफॉर्मेंस में 15 से 30% तक का बूस्ट परफॉर्मेंस है, 32- बिट एआरएम (Aarch32) इंस्ट्रक्शंस की तुलना में
phuclv


यह Pi3 (विशेष रूप से वास्तविक दुनिया के कार्यों के साथ) पर बेंचमार्क देखना दिलचस्प होगा।
Mattdm

6

मुझे यकीन है कि पहले से ही Pi 3 पर डेबियन Aarch64 (ARMv8) चलाने वाले लोग हैं; यह निश्चित रूप से बहुत से लोगों के लिए कठिन नहीं होगा ( यहां कुछ सुराग के बारे में देखें जो काम कर सकते हैं) 1 हालांकि अधिकांश उपयोगकर्ताओं के लिए यह शायद थोड़ा खिंचाव है।

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


अब Pi 3 के लिए Fedora अराजकता रिलीज़ है


1. 32-बिट /opt/vcसामान के साथ कुछ जटिलताएं होंगी , मुझे यकीन नहीं है कि यह कितना महत्वपूर्ण है; वहाँ x86-64 के लिए 32-बिट कम्प्रेशन फ़ेबर्स हुआ करते थे लेकिन Aarch64 ... शायद नहीं।


1
raspbian.org/RaspbianFAQ##hat_is_Raspbian.3F स्टेट्स (रास्पियन के बारे में बात करते हुए): पोर्ट आवश्यक है क्योंकि आधिकारिक डेबियन व्हीज़ेह रिलीज़ केवल रास्पबेरी पाई (ARMv7-A CPUs) पर उपयोग किए गए एआरएम आर्किटेक्चर के संस्करणों के साथ संगत है। और उच्चतर, रास्पबेरी पाई के ARMv6 CPU बनाम)। क्या यह अभी भी RPi3 के साथ सही है?
११:१६ बजे १

@ कैंडी मुझे लगता है कि 1) अपेक्षाकृत प्राचीन है; 2) कन्फ्यूज्ड और / या तब से बिना सोचे समझे, चूंकि डेबियन आर्महफ को हार्ड फ्लोट के साथ संकलित किया जाता है, यही hf के लिए है, बनाम ARMv4 / 5 के लिए एक और डेबियन है, जो मुझे लगता है कि पहले एक पर इस्तेमाल किया गया था और आईएसए नहीं किया था हार्ड फ्लोट्स हैं (मुझे लगता है कि न तो 6 एक निश्चित बिंदु तक किया गया था, लेकिन यह ज्यादातर समय उर्फ ​​ARM1176JZ (F) -S) के लिए रहा है। इसलिए हार्डवेयर फ्लोटिंग पॉइंट सपोर्ट के साथ Raspbian, period, ARMv6 का केवल एक ही संस्करण है, A / B / + / 0 मॉडल और 2 के बीच का एकमात्र अंतर है, जिसका उपयोग कर्नेल के रूप में किया जाता है, संभवतः इसलिए 3.
गोल्डिलॉक्स

2
... "आर्मल" नॉन-एचएफ डेबियन है जिसका उपयोग रास्पियन से पहले किया गया था।
गोल्डीलॉक्स

@sandy कि भावना pi1 के दिनों में लिखी गई थी, इसलिए जब यह pi कहता है तो इसका मतलब है कि जिसे अब हम pi1 कहेंगे। वहाँ pi2 (और presumablly pi3) के लिए डेबियन armhf छवियों को जारी करने वाले तीसरे पक्ष हैं, लेकिन आरपीएफ ने अभी के लिए सभी बोर्डों के लिए एक छवि के साथ छड़ी करने का फैसला किया है।
पीटर ग्रीन

5

लॉन्च पब्लिसिटी के एक हिस्से के रूप में मैंने यह उल्लेख किया कि एक चिंता दो अलग कोड बेस (32 और 64 बिट) को बनाए रखने के लिए आवश्यक प्रयास है। Adafruit PI3 लॉन्च वीडियो ने यह भी उल्लेख किया है कि 64 बिट प्रोसेसर का उपयोग घड़ी की गति को बढ़ाने के बारे में अधिक था ताकि 64 बिट मोड का उपयोग करने की तुलना में नई चिप प्रदान की जा सके।


मैंने सोचा कि कोड समान होगा, लेकिन आर्किटेक्चर का लाभ उठाने के लिए कंपाइलर अंतिम कोड का अनुकूलन करने के लिए प्रभारी होगा। क्या नया निर्माण करना अपेक्षाकृत आसान है? कहो, डेबियन को 64 बिट्स में चलाने के लिए?
ज़ूंडी

@ कैंडी आसान आपके कौशल स्तर और अनुभव पर निर्भर करेगा। उपयोग मामला क्या है जो अब इसकी आवश्यकता है?
स्टीव रोबिलार्ड

विशेष रूप से कोई भी, केवल आरपीआई 3 प्रदर्शन को अधिकतम करने के लिए सक्षम है।
१२:३५ बजे ११:१६ पर zundi

@sandy फाउंडेशन ने कहा है कि Pi3 के लिए प्रतिस्थापन जल्दी नहीं आएगा क्योंकि Pi3 ने Pi2 (लगभग 1 वर्ष) का अनुसरण किया है। वे नए हार्डवेयर की आवश्यकता के बिना एक प्रदर्शन टक्कर के लिए 64 बिट पर स्विच का उपयोग कर सकते हैं - ध्यान दें कि यह मेरी ओर से सभी अटकलें हैं।
स्टीव रोबिलार्ड

4

यदि आपके पास 1GB से अधिक मेमोरी नहीं है तो भी 64-बिट एड्रेसिंग उपयोगी हो सकती है।

यह आपको बड़ी फ़ाइलों को मेमोरी-मैप करने की अनुमति देता है, इसलिए आपके पास एक संकेतक है और ओएस को I / O पारदर्शी रूप से करने देता है। I / O करने का दूसरा तरीका। बड़ी फ़ाइलों पर ऐसा करने के लिए आपको 64-बिट एड्रेसिंग की आवश्यकता होती है।

एक अन्य उदाहरण जहां मैं देखता हूं कि यह उपयोगी हो सकता है, स्वैप स्थान का उपयोग करके प्रक्रियाओं को 2GB से अधिक पता स्थान की अनुमति है। मेरे पास हाल ही में 32-बिट एनएएस पर बहुत सारे भंडारण के साथ एक मुद्दा था, और एक क्षतिग्रस्त फाइल सिस्टम। कैशिंग विकल्प चालू होने के साथ ही fsck प्रक्रिया मेमोरी से बाहर हो गई। स्वैप स्पेस को जोड़ने से समस्या हल नहीं हो सकती है, 32-बिट एड्रेस स्पेस वहां की कठिन सीमा थी। इसलिए 32-बिट बाइनरी के साथ इस बड़े क्षतिग्रस्त फाइल सिस्टम पर fsck चलाने का कोई तरीका नहीं था। 64-बिट बाइनरी और कुछ स्वैप स्पेस के साथ, यह चला होगा।


3

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

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

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

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

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

वर्तमान में OS इसका लाभ उठाता है या नहीं, यह फर्क करने वाला है क्योंकि मुख्यधारा 32 बिट से दूर जाती है।

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

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

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


शायद हमें एआरएम के लिए एक एक्स 32 एबीआई की आवश्यकता है। फिर हमारे पास छोटे पॉइंटर्स और सभी रजिस्टर हो सकते हैं।
rsaxvc

2

मौजूदा उत्तर 64-बिट आर्क की समस्याओं को बहुत अच्छी तरह से कवर करते हैं, लेकिन मैं उन्नयन के कई घोषित फायदे नहीं देख रहा हूं। इसलिए, यहाँ दो मैंने हाल ही में खोजे हैं:

  • जब PHP यूनिक्स टाइमस्टैम्प को संभालता है, तो 32-बिट आर्च में पूर्णांक आकार तिथियों पर एक ऊपरी सीमा निर्धारित करता है, जैसे कि वे 2038 में किसी विशेष दिन से आगे नहीं जा सकते । मुझे उम्मीद है कि यह सभी भाषाओं के लिए एक मुद्दा है जो टाइमस्टैम्प को संभालता है। (शुक्र है, ज्यादातर डेट हैंडलिंग सबसिस्टम जो यूनिक्स टाइमस्टैम्प का उपयोग नहीं करते हैं, जैसे कि PHP की डेटटाइम, विशेष रूप से पुराने सीपीयू पर भी इस समस्या से सीमित नहीं होने के लिए डिज़ाइन किए गए हैं)।
  • मानगो इस आर्च पर 2G के तहत डेटाबेस तक सीमित है, और 32-बिट बिल्ड जल्द ही अपदस्थ होने वाले हैं। से मैनुअल :

    MongoDB 3.2 में शुरू, 32-बिट बायनेरिज़ को हटा दिया जाता है और भविष्य के रिलीज में अनुपलब्ध होगा।

    यद्यपि 32-बिट बिल्ड लिनक्स और विंडोज के लिए मौजूद हैं, लेकिन वे उत्पादन परिनियोजन के लिए अनुपयुक्त हैं। 32-बिट बिल्ड भी वायर्डटेगर स्टोरेज इंजन का समर्थन नहीं करते हैं।


अजीब तरह से, यह आपके प्लेटफॉर्म पर निर्भर करता है। यह आमतौर पर पूर्णांक आकार नहीं है, लेकिन 'C' लाइब्रेरी में time_t का आकार है। 32-बिट प्लेटफार्मों पर भी, कुछ सीपीयू टाइम ओवरहेड के साथ 64-बिट time_t का उपयोग करना संभव है, लेकिन कई 32-बिट प्लेटफॉर्म अभी तक ऐसा नहीं करते हैं, क्योंकि ऐसा करने में द्विआधारी संगतता समस्या है।
rsaxvc

@rsaxvc, दिलचस्प, धन्यवाद। तो क्या मैं PHP recompiling करके 64-बिट टाइम-हैंडलिंग प्राप्त कर सकता हूं, या क्या इसे अंतर्निहित सी लाइब्रेरीज़ के संशोधन की भी आवश्यकता होगी? पूर्व मेरी क्षमता के भीतर होगा, लेकिन बाद के बारे में निश्चित नहीं था - मैं पूरे रास [खुद भी] को पुन: स्थापित कर रहा था, लेकिन ऐसा करने के लिए कोई सरल निर्देश नहीं लगता (अभी तक, वैसे भी)।
रोकें

लिनक्स के लिए, आपको कर्नेल, libc और अपने एप्लिकेशन को पैच करना होगा। यह शायद इसके लायक नहीं है। कुछ पढ़ने के बाद, OpenBSD (आरपीआई पर नहीं) time_t 5.5 के बाद से 64-बिट है। विज़ुअल स्टूडियो 2005 या नए time_t का उपयोग करके 32-बिट विंडोज पर 64-बिट है।
rsaxvc

@rsaxvc: ठीक है, धन्यवाद। मुझे आश्चर्य है कि अगर यह मेरे लिए 64-बिट ओएस के लिए प्रतीक्षा करने के लिए समझ में आता है - यह कुछ महीनों पहले कुछ समाचार लेखों पर आसन्न लग रहा था ....:-)
15:12 पर

-4

इस पर मेरे विचार: यद्यपि मुझे ठीक से पता नहीं है कि एआरएम प्रोसेसर मेमोरी को कैसे संबोधित करता है, मैं आपको पिछले मल्टीपल सीपीयू आर्किटेक्चर जो मैंने प्रोग्राम किया था (SPARC / Alpha / i386 / AMD64 / X86_64) से यह बता सकता हूं: साझा मेमोरी और एड्रेसिंग का उपयोग करते समय इसके "वास्तविक" वर्चुअल एड्रेस पॉइंटर के द्वारा, 64 बिट पर जाना तुच्छ नहीं है। यद्यपि मेमसीपी वह करता है जो उसे करना चाहिए था, आपको यह ध्यान में रखना होगा कि 64 बिट्स में डेटा इस तरह संग्रहीत किया जाता है (बिटवर्ड:

HGFEDCBA
HGFEDCBA
HGFEDCBA

अभी तक 32 बिट्स में ऐसा दिखता है:

ABCD
ABCD
ABCD

इसलिए, 32 बिट्स में जब आप रैम में एक jpeg कहते हैं, तो आप इसके हेडर बाइट्स पढ़ सकते हैं, या एज डिटेक्शन कर सकते हैं, बिना किसी समस्या के लीनियर फैशन में कहेंगे * बाइट फॉरवर्ड करके। लेकिन एक 64 बिट वास्तुकला में यह परिवर्तन:

32 बिट:

for (i=0; i< img_length/4; i++) 
{ 
    address=shm_start+i; 
    for (c=0; c< 4; c++) 
    { 
        byte=((*address >> c) & 15) 
    } 
}

64 बिट:

for (i=-; i< img_length/8; i++) 
{ 
    address=shm_start+i; 
    for (c=7; c>=0; c--) 
    { 
        byte=((*address >> c) & 15) 
    } 
}

5
एंडियननेस शब्द के आकार से कोई लेना-देना नहीं है। हेक, कई आर्किटेक्चर प्रोग्रामर को एआरएम सहित एंडियननेस का चयन करने की अनुमति देते हैं! इसके अलावा, "64-बिट" के प्रश्न में वास्तुकला के आधार पर पूरी तरह से अलग परिणाम हो सकते हैं, और आर्किटेक्चर के बीच तुलना करना या उनके बीच समानताएं खींचने की कोशिश करना मुश्किल है।
बॉब

1
मुझे नहीं लगता कि मैं = - वैध है।
rsaxvc
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.