ब्लॉग पोस्ट का कुछ हद तक अनुवादित अनुवाद जो मुझे इस बात में दिलचस्पी रखता है कि वास्तव में विपणन भूसी के बिना iPhone पर 64-बिट प्रोसेसर देता है। यदि पाठ आपको बहुत स्पष्ट लगता है, तो "बुनियादी लाभ और नुकसान" खंड को छोड़ दें।

जैसे ही iPhone 5S की घोषणा की गई, तकनीकी मीडिया अमानवीय लेखों से भर गया। दुर्भाग्य से, अच्छे लेख लिखने में समय लगता है, और तकनीकी पत्रकारिता मूल्यों की दुनिया में विश्वसनीयता से अधिक गति होती है। आज, अपने कई पाठकों के अनुरोध पर, मैं प्रदर्शन, विशेषताओं और विकास के संदर्भ में iPhone 5S में 64-बिट एआरएम को संक्षेप में बताऊंगा।

64 बिट्स

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

यह नोट करना भी महत्वपूर्ण है कि 64-बिट का मतलब नहीं है, क्योंकि और बहुत सी गलतफहमी है। तो, 64-बिट निर्धारित नहीं करता है:

1. पता योग्य स्मृति का आकार। पॉइंटर में वास्तव में उपयोग किए जाने वाले बिट्स की संख्या प्रोसेसर बिट से संबंधित नहीं है। एआरएम प्रोसेसर 26 से 40 बिट्स का उपयोग करते हैं, और यह संख्या प्रोसेसर बिट से अलगाव में भिन्न हो सकती है।
   
2. डेटा बस की चौड़ाई। रैम या कैश से अनुरोधित डेटा भी बिट दर से संबंधित नहीं है। अलग प्रोसेसर निर्देश डेटा की मनमानी मात्रा का अनुरोध कर सकते हैं, लेकिन वास्तव में अनुरोधित डेटा की मात्रा अलग-अलग हो सकती है, या तो अनुरोधों को भागों में तोड़ सकती है, या आवश्यकता से अधिक अनुरोध कर सकती है। पहले से ही iPhone 5 में, अनुरोधित डेटा ब्लॉक का आकार 64 बिट्स है, जबकि पीसी 192 बिट्स तक पहुंचता है।
   
3. फ्लोटिंग पॉइंट गणना से संबंधित सब कुछ। FPU रजिस्टर वास्तुकला से संबंधित नहीं हैं और ARM प्रोसेसर ARM64 से बहुत पहले 64-बिट रजिस्टरों का उपयोग करते थे।
   

बुनियादी फायदे और नुकसान

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

इस तथ्य के बावजूद कि 64-बिट सीधे पता योग्य मेमोरी की मात्रा से संबंधित नहीं है, यह एक ही कार्यक्रम में बड़ी मात्रा में रैम के उपयोग की सुविधा प्रदान करता है। 32-बिट प्रोसेसर पर चलने वाला एक प्रोग्राम 4GB से अधिक एड्रेस स्पेस को संबोधित नहीं कर सकता है। मेमोरी का हिस्सा ऑपरेटिंग सिस्टम और मानक पुस्तकालयों के लिए आवंटित किया जाता है, जो कार्यक्रम के लिए 1-3GB छोड़ देता है। यदि 32-बिट सिस्टम में 4GB से अधिक रैम है, तो प्रोग्राम के लिए इस सभी एड्रेस स्पेस का उपयोग अधिक जटिल है। आपको वर्चुअल एड्रेस स्पेस के एक हिस्से में रैम के विभिन्न हिस्सों को क्रमिक रूप से मैप करने या एक प्रोग्राम को कई प्रक्रियाओं में तोड़ने जैसे धोखाधड़ी से निपटना होगा।

इस तरह के गुर बेहद समय लेने वाले होते हैं और सिस्टम को धीमा कर सकते हैं, इसलिए कुछ प्रोग्रामर वास्तव में इनका उपयोग करते हैं। व्यवहार में, 32-बिट प्रोसेसर पर प्रत्येक प्रोग्राम 1-3GB रैम का उपयोग करता है, और अधिक भौतिक रैम होने में सभी मूल्य एक ही समय में अधिक प्रोग्राम चलाने की क्षमता और डिस्क से अधिक डेटा कैश करने की क्षमता है।

पता स्थान में वृद्धि रैम की एक छोटी मात्रा के साथ सिस्टम के लिए भी उपयोगी है - मेमोरी-मैप्ड फाइलें, जिनमें से आकार उपलब्ध रैम से बड़ा हो सकता है, क्योंकि ऑपरेटिंग सिस्टम वास्तव में फ़ाइल के केवल उन हिस्सों को डाउनलोड करता है जो एक्सेस किए गए थे और, इसके अलावा, यह रैम पर फ़्रीज किए गए डेटा को फ़ाइल में वापस "निचोड़" सकता है। 32-बिट सिस्टम पर, 1-3GB से बड़ी फ़ाइलों को प्रदर्शित नहीं किया जा सकता है। 64-बिट सिस्टम पर, पता स्थान बहुत बड़ा है, इसलिए ऐसी कोई समस्या नहीं है।

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

संक्षेप में: 64-बिट कोड के कुछ हिस्सों के प्रदर्शन को बढ़ा सकता है और कुछ तकनीकों को सरल कर सकता है, जैसे कि मेमोरी-मैपेड फाइलें। हालाँकि, मेमोरी के उपयोग में वृद्धि के कारण प्रदर्शन को नुकसान हो सकता है।

ARM64

IPhone 5S में 64-बिट प्रोसेसर केवल एआरएम नहीं है एक बढ़े हुए रजिस्टर आकार के साथ, महत्वपूर्ण बदलाव हैं।

सबसे पहले, मैं नाम का उल्लेख करूँगा: ARM का आधिकारिक नाम "AArch64" है, लेकिन यह एक मूर्खतापूर्ण नाम है जो मुझे टाइपिंग से परेशान करता है। Apple ARM64 आर्किटेक्चर को कॉल करता है और मैं भी नाम दूंगा।

ARM64 ने पूर्णांक रजिस्टरों की संख्या को दोगुना कर दिया। 32-बिट एआरएम 16 पूर्णांक रजिस्टर प्रदान करता है, जिनमें से एक प्रोग्राम काउंटर है, दो और स्टैक और लिंक रजिस्टर के लिए एक पॉइंटर के लिए उपयोग किया जाता है और 13 सामान्य प्रयोजन रजिस्टर। ARM64 में 32 पूर्णांक रजिस्टर हैं, जिसमें एक समर्पित शून्य रजिस्टर, संचार रजिस्टर और फ़्रेम पॉइंटर रजिस्टर है। एक अन्य रजिस्टर 28 सामान्य प्रयोजन रजिस्टरों को छोड़कर, मंच द्वारा आरक्षित है।

ARM64 फ्लोटिंग पॉइंट नंबरों के लिए रजिस्टरों की संख्या भी बढ़ाता है। 32-बिट एआरएम में रजिस्टर कुछ अजीब हैं, इसलिए तुलना करना मुश्किल है। एक 32-बिट एआरएम में 32 32-बिट फ्लोटिंग पॉइंट रजिस्टर हैं, जिन्हें 16 ओवरलैपिंग 64-बिट रजिस्टरों के रूप में दर्शाया जा सकता है। इसके अलावा, 16 और स्वतंत्र 64-बिट रजिस्टर हैं। ARM64 इसे 32 गैर-अतिव्यापी 128-बिट रजिस्टरों के लिए सरल करता है जो छोटे डेटा के लिए उपयोग किया जा सकता है।

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

ARM64 ने रजिस्टरों की संख्या बढ़ाने के अलावा महत्वपूर्ण बदलाव भी पेश किए।

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

ARM64 में, NEON SIMD (एक-निर्देश-कई-डेटा) सेट NEON पूरी तरह से डबल -सटीक फ़्लोटिंग-पॉइंट संख्याओं के लिए IEEE754 मानक का समर्थन करता है, जबकि NEON का 32-बिट संस्करण केवल एकल परिशुद्धता का समर्थन करता है और कुछ बिट्स के लिए मानक का बिल्कुल पालन नहीं करता है।

ARM64 ने एईएस एन्क्रिप्शन और SHA-1 और SHA-256 हैश के लिए विशेष निर्देश जोड़े। सामान्य रूप से बहुत उपयोगी नहीं है, लेकिन यदि आप इन मुद्दों से निपटते हैं तो एक महत्वपूर्ण बोनस।

सामान्य तौर पर, सबसे महत्वपूर्ण अंतर NEON में दोहरे-सटीक संख्याओं पर IEEE754- संगत अंकगणित के लिए सामान्य-उद्देश्य रजिस्टर की संख्या में वृद्धि और पूर्ण समर्थन है। यह बड़ी संख्या में उत्पादकता में वृद्धि को मूर्त रूप दे सकता है।

32 बिट अनुप्रयोग संगतता

यह ध्यान रखना महत्वपूर्ण है कि ए 7 में 32-बिट संगतता मोड शामिल है, जो आपको बिना किसी बदलाव के 32-बिट एप्लिकेशन चलाने की अनुमति देता है। इसका मतलब है कि iPhone 5S प्रदर्शन पर कोई प्रभाव डाले बिना किसी भी पुराने एप्लिकेशन को चला सकता है।

निष्पादन अवधि प्रणाली में परिवर्तन

Apple अपने पुस्तकालयों में नई वास्तुकला का लाभ उठाता है। चूंकि उन्हें इस तरह के परिवर्तनों के साथ द्विआधारी पिछड़े संगतता के बारे में चिंता करने की आवश्यकता नहीं है, इसलिए यह उन परिवर्तनों को बनाने के लिए एक अच्छा समय है जो अन्यथा "मौजूदा अनुप्रयोगों को तोड़ देंगे"।

मैक्स OS X 10.7 में, Apple ने टैग किए गए पॉइंटर्स पेश किए। लेबल पॉइंटर्स आपको पॉइंटर में सीधे मात्रा में डेटा की थोड़ी मात्रा के साथ कुछ कक्षाएं संग्रहीत करने की अनुमति देते हैं। यह कुछ मामलों में स्मृति आवंटन से बचता है, जैसे कि NSNumber, और एक महत्वपूर्ण प्रदर्शन को बढ़ावा दे सकता है। टैग किए गए संकेत केवल 64-बिट प्लेटफ़ॉर्म पर समर्थित हैं, आंशिक रूप से प्रदर्शन के मुद्दे के कारण, और आंशिक रूप से इस तथ्य के कारण कि 32-बिट पॉइंटर में "टैग" के लिए बहुत जगह नहीं बची है। इस तरह स्पष्ट रूप से, iOS के पास लेबल पॉइंटर्स के लिए समर्थन नहीं था। इस प्रकार, एआरएम 64 में ऑब्जेक्टिव-सी रनटाइम सपोर्ट में लेबल पॉइंटर्स के लिए शामिल है, जो मैक के समान ही लाभ देता है।

इस तथ्य के बावजूद कि सूचक का आकार 64 बिट्स है, इन सभी बिट्स का वास्तव में उपयोग नहीं किया जाता है। X86-64 पर Mac OS X केवल 47 बिट्स का उपयोग करता है। ARM64 पर IOS कम उपयोग करता है - केवल 33 बिट्स। यदि आप उपयोग करने से पहले हर बार इन बिट्स को मास्क करते हैं, तो आप अतिरिक्त डेटा स्टोर करने के लिए शेष बिट्स का उपयोग कर सकते हैं। इसने अपने इतिहास में ऑब्जेक्टिव-सी रनटाइम के सबसे महत्वपूर्ण परिवर्तनों में से एक की अनुमति दी।

आइसा पॉइंटर को रीथिंक करना

इस खंड की अधिकांश जानकारी ग्रेग पार्कर के एक लेख से है। सबसे पहले, मेमोरी को रीफ्रेश करने के लिए: ऑब्जेक्टिव-सी में ऑब्जेक्ट्स आवंटित मेमोरी ब्लॉक का प्रतिनिधित्व करते हैं। पहला भाग, एक पॉइंटर का आकार, आइसा है। सामान्य रूप से, isa किसी ऑब्जेक्ट क्लास का एक पॉइंटर होता है। ऑब्जेक्ट को मेमोरी में कैसे संग्रहीत किया जाता है, इसके बारे में अधिक जानने के लिए, मेरे अन्य लेख को पढ़ें ।

एक पॉइंटर के पूरे आकार का इज़ा पॉइंटर का उपयोग करना कुछ हद तक बेकार है, खासकर 64-बिट प्लेटफॉर्म पर जो सभी 64-बिट्स का उपयोग नहीं करता है। IOS पर ARM64 वास्तव में 33 बिट्स का उपयोग करता है, अन्य चीजों के लिए 31 बिट्स को छोड़कर। मेमोरी में कक्षाएं 8 बाइट्स की सीमा पर गठबंधन की जाती हैं, इसलिए अंतिम 3 बिट्स को खारिज किया जा सकता है, जो अतिरिक्त जानकारी संग्रहीत करने के लिए isa से 34 बिट्स उपलब्ध कराता है। और Apple64 का ARM64 रनटाइम प्रदर्शन को बढ़ावा देने के लिए इसका उपयोग करता है।

शायद सबसे महत्वपूर्ण अनुकूलन इनलाइन लिंक काउंटर था। ऑब्जेक्टिव-सी की लगभग सभी वस्तुओं में एक संदर्भ काउंटर होता है (अपरिवर्तनीय वस्तुओं के अपवाद के साथ, जैसे एनएसएसट्रिंग शाब्दिक) और इस काउंटर को बदलने वाले संचालन / रिलीज संचालन को बहुत बार होता है। यह ARC के लिए विशेष रूप से महत्वपूर्ण है, जो प्रोग्रामर की तुलना में अधिक बार कॉल / रिटेन करता है। इस प्रकार, बनाए रखने / जारी करने के तरीकों का उच्च प्रदर्शन महत्वपूर्ण है।

सामान्यतया, संदर्भ गणना ऑब्जेक्ट में ही संग्रहीत नहीं होती है। ऑब्जेक्ट में ही संदर्भ काउंटर को स्टोर करना संभव होगा, लेकिन यह बहुत अधिक स्थान लेगा। यह अब इतना महत्वपूर्ण नहीं है, लेकिन फिर, बहुत पहले, यह बहुत महत्वपूर्ण था। इस वजह से, संदर्भ गणना एक बाहरी हैश तालिका में संग्रहीत की जाती है। हर बार जब आप कॉल रिटेन करते हैं, तो निम्न क्रियाएं की जाती हैं:

1. पॉइंटर काउंटर की एक वैश्विक हैश तालिका प्राप्त करें
   
2. हैश टेबल को लॉक करें ताकि ऑपरेशन थ्रेड सुरक्षित हो
   
3. किसी दिए गए ऑब्जेक्ट के लिए हैश तालिका में एक काउंटर खोजें
   
4. एक-एक करके काउंटर बढ़ाएँ और इसे वापस टेबल पर सहेजें
   
5. हैश टेबल लॉक जारी करें
   

काफी धीरे! काउंटरों के हैश टेबल के कार्यान्वयन को हैश तालिका के लिए बहुत कुशल बनाया गया है, लेकिन यह अभी भी मेमोरी की सीधी पहुंच की तुलना में बहुत धीमा है। ARM64 में, आइसा पॉइंटर के 19 बिट्स का उपयोग रेफरेंस काउंट को स्टोर करने के लिए किया जाता है। इसका मतलब यह है कि रिटेन कॉल सरल है:

1. इसा क्षेत्र के एक हिस्से में परमाणु वृद्धि का उत्पादन करने के लिए
   

और वह सब है! यह बहुत, बहुत तेजी से होना चाहिए।

वास्तव में, अलग-अलग किनारे के मामलों के कारण सब कुछ कुछ अधिक जटिल है जिसे भी संभालने की आवश्यकता है। क्रियाओं का सही क्रम लगभग निम्नलिखित है:

1. Isa में अंतिम बिट कहता है कि क्या isa में अतिरिक्त बिट्स का उपयोग संदर्भ गणना को संग्रहीत करने के लिए किया जाता है। यदि नहीं, तो पुराने हैश टेबल एल्गोरिथ्म का उपयोग किया जाता है।
   
2. यदि ऑब्जेक्ट पहले से ही हटा दिया गया है, तो कुछ भी नहीं किया जाता है
   
3. यदि काउंटर ओवरफ्लो होता है (जो शायद ही कभी होता है, लेकिन यह 19 बिट्स के साथ काफी संभव है), पुराने हैश टेबल एल्गोरिथ्म का उपयोग किया जाता है
   
4. नए मूल्य पर isa का परमाणु परिवर्तन करें
   

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

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

1. यदि ऑब्जेक्ट में objc_setAssociatedObject का उपयोग करके संबंधित ऑब्जेक्ट सेट नहीं थे, तो उन्हें हटाने की आवश्यकता नहीं है।
   
2. यदि ऑब्जेक्ट में C ++ डिस्ट्रक्टर (जिसे डीललॉक के दौरान कहा जाता है) नहीं है, तो उसे भी कॉल करने की आवश्यकता नहीं है।
   
3. यदि किसी ऑब्जेक्ट को कमजोर (__weak) पॉइंटर द्वारा संदर्भित नहीं किया गया है, तो इन पॉइंटर्स को शून्य करने की आवश्यकता नहीं है।
   

पहले, इन सभी झंडों को कक्षाओं में संग्रहीत किया गया था। उदाहरण के लिए, यदि किसी वर्ग के कम से कम एक उदाहरण ने कभी संबद्ध वस्तु संग्रहीत की है, तो इस वर्ग के सभी उदाहरणों ने संबंधित वस्तु को हटाए जाने के दौरान हटा दिया है। प्रत्येक उदाहरण के लिए इन झंडों को ट्रैक करना व्यक्तिगत रूप से केवल उन तरीकों के लिए उपयुक्त तरीकों को कॉल करने की अनुमति देता है जिनके लिए यह वास्तव में आवश्यक था।

कुल मिलाकर, यह एक महत्वपूर्ण लाभ है। मेरे बेंचमार्क ने दिखाया कि एक साधारण ऑब्जेक्ट को बनाने और हटाने से 32-बिट मोड में 5S पर 380ns लगते हैं, जबकि 64-बिट में केवल 200ns। यदि कम से कम एक उदाहरण का कभी भी स्वयं के लिए कमजोर संदर्भ रहा है, तो 32-बिट मोड में सभी के लिए विलोपन समय बढ़कर 480 ns हो गया, जबकि 64-बिट मोड में सभी उदाहरणों के लिए 200 ns के क्षेत्र में समय बना रहा, जिस पर कोई कमजोर लिंक नहीं है यह किया गया था।

संक्षेप में, रनटाइम में सुधार इस तरह के हैं कि 64-बिट मोड में आवंटन समय 32-50 बिट मोड में आवंटन समय का 40-50% लेता है। यदि आपका एप्लिकेशन कई ऑब्जेक्ट बनाता है और हटाता है, तो यह महत्वपूर्ण हो सकता है।

निष्कर्ष

64-बिट ए 7 न केवल एक विपणन चाल है, लेकिन यह भी एक अद्भुत सफलता नहीं है जो अनुप्रयोगों का एक नया वर्ग बनाने की अनुमति देगा। सत्य, हमेशा की तरह, बीच में निहित है।

64 बिट पर स्विच करने का मात्र तथ्य थोड़ा सा देता है। यह कुछ मामलों में अनुप्रयोगों को गति देता है, अधिकांश कार्यक्रमों द्वारा उपयोग की जाने वाली स्मृति की मात्रा को थोड़ा बढ़ाता है। सामान्य तौर पर, बहुत अंतर नहीं है।

एआरएम वास्तुकला न केवल 64-बिट में बदल गई है। रजिस्टरों की बढ़ी हुई संख्या और संशोधित, सुव्यवस्थित निर्देश सेट 32-बिट एआरएम की तुलना में एक अच्छा प्रदर्शन को बढ़ावा देते हैं।

Apple ने रनटाइम में सुधार के लिए एक नए आर्किटेक्चर के लिए संक्रमण का उपयोग किया। मुख्य परिवर्तन इनलाइन लिंक काउंटर है, जो महंगी हैश टेबल खोजों से बचा जाता है। चूंकि ऑब्जेक्टिव-सी में रिटेन / रिलीज ऑपरेशन बहुत सामान्य हैं, यह एक महत्वपूर्ण लाभ है। झंडे के आधार पर संसाधनों को हटाने से वस्तुओं को लगभग दो बार तेजी से हटाना पड़ता है। टैग किए गए संकेत भी प्रदर्शन को जोड़ते हैं और मेमोरी खपत को कम करते हैं।

ARM64 Apple का एक अच्छा जोड़ है। हम सभी जानते थे कि यह जल्द या बाद में होगा, लेकिन कुछ लोगों को उम्मीद है कि यह जल्द ही होगा। लेकिन यह है, और यह उत्कृष्ट है।