तेज़ पूर्णांक प्रकार अन्य पूर्णांक प्रकारों की तुलना में तेज़ क्यों होते हैं?

Question

ISO / IEC 9899: 2018 (C18) में, इसे 7.20.1.3 के तहत बताया गया है:

7.20.1.3 सबसे तेज न्यूनतम-चौड़ाई पूर्णांक प्रकार

1 निम्नलिखित प्रकारों में से प्रत्येक पूर्णांक प्रकारों के साथ काम करने के लिए पूर्णांक प्रकार को निर्दिष्ट करता है जो आमतौर पर सबसे तेज़ ²⁶⁸⁾ होता है जिसमें कम से कम निर्दिष्ट चौड़ाई होती है।

2 टाइपसेफ नाम int_fastN_tकम से कम एन की चौड़ाई के साथ सबसे तेज हस्ताक्षरित पूर्णांक प्रकार को नामित करता है। टाइप किए गए नाम कम से कम एन की uint_fastN_tचौड़ाई के साथ सबसे तेज अहस्ताक्षरित पूर्णांक प्रकार को नामित करता है।

3 निम्नलिखित प्रकार आवश्यक हैं:

int_fast8_t, int_fast16_t, int_fast32_t, int_fast64_t, uint_fast8_t, uint_fast16_t, uint_fast32_t,uint_fast64_t

इस फॉर्म के अन्य सभी प्रकार वैकल्पिक हैं।

---

²⁶⁸⁾ निर्दिष्ट प्रकार सभी उद्देश्यों के लिए सबसे तेज़ होने की गारंटी नहीं है; यदि कार्यान्वयन में दूसरे पर एक प्रकार चुनने के लिए कोई स्पष्ट आधार नहीं है, तो यह केवल हस्ताक्षर और चौड़ाई की आवश्यकताओं को पूरा करने वाले कुछ पूर्णांक प्रकार को ले जाएगा।

---

लेकिन यह नहीं बताया गया है कि ये "तेज़" पूर्णांक प्रकार अधिक तेज़ क्यों हैं।

• ये तेज पूर्णांक प्रकार अन्य पूर्णांक प्रकारों की तुलना में अधिक तेज़ क्यों हैं?

  ---

_{मैंने C ++ के साथ प्रश्न को टैग किया है, क्योंकि फास्ट पूर्णांक प्रकार C ++ 17 में हेडर फ़ाइल में भी उपलब्ध हैं cstdint। दुर्भाग्य से, आईएसओ / आईईसी 14882: 2017 (सी ++ 17) में उनके स्पष्टीकरण के बारे में ऐसा कोई खंड नहीं है; मैंने उस अनुभाग को अन्यथा प्रश्न निकाय में लागू किया था।}

---

जानकारी: C में, उन्हें हेडर फ़ाइल में घोषित किया गया है stdint.h।

Comments

यहां मुख्य बात यह है कि ये पूर्णांक प्रकार अलग नहीं हैं, जादुई रूप से तेज प्रकार हैं। वे बस उपनाम हैं जो कुछ भी मौजूदा मौजूदा प्रकार के लिए उस ऑपरेशन के लिए मशीन पर सबसे तेज़ है।

— मत्तसुर

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

— पीटर -

@ RobertS-ReinstateMonica सटीक होने के लिए, ये "उपनाम" सिर्फ typedefबयान हैं। इसलिए आमतौर पर , यह मानक पुस्तकालय स्तर पर किया जाता है। बेशक, सी मानक डालता कोई वास्तविक वे क्या करने पर प्रतिबंध typedefतो उदाहरण के लिए एक विशिष्ट कार्यान्वयन सुनिश्चित करने के लिए है - करने के लिए int_fast32_tएक typedefके intएक 32-बिट सिस्टम पर है, लेकिन एक काल्पनिक संकलक सकता है उदाहरण के लिए एक को लागू __int_fastआंतरिक प्रकार और कुछ फैंसी करने के लिए वादा उस प्रकार के चर के लिए केस-बाय-केस के आधार पर सबसे तेज़ मशीन प्रकार लेने के लिए अनुकूलन, और फिर पुस्तकालय बस उसी के typedefलिए हो सकता है।

— 21

@ रॉबर्ट्स-रीनटेटमोनिका हाँ, सच है। आपको आर्किटेक्चर विशिष्ट संकलन झंडे के साथ अधिकतम प्रदर्शन कार्यक्रम मिलते हैं जो बाइनरी को कम पोर्टेबल बनाता है।

— पीटर - मोनिका

@ रॉबर्ट्स-ReinstateMonica यह मंच यह संकलित किया गया था पर सबसे कुशल हो जाएगा के लिए , जरूरी नहीं पर ।

— HABO

Answer 1

एक सीपीयू की कल्पना करें जो केवल 64 बिट अंकगणितीय ऑपरेशन करता है। अब कल्पना करें कि आप इस तरह के सीपीयू पर एक अहस्ताक्षरित 8 बिट को कैसे लागू करेंगे। यह सही परिणाम प्राप्त करने के लिए जरूरी एक से अधिक ऑपरेशन को शामिल करेगा। ऐसे सीपीयू पर, 64 बिट ऑपरेशन अन्य पूर्णांक चौड़ाई पर संचालन से तेज होते हैं। इस स्थिति में, Xint_fastY_tसंभवतः सभी 64 बिट प्रकार का एक उपनाम हो सकते हैं।

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

जिज्ञासा से बाहर, मैंने कुछ आर्किटेक्चर पर एक विशेष कार्यान्वयन (जीएनयू, लिनक्स) पर आकारों की जांच की। ये समान वास्तुकला पर सभी कार्यान्वयनों में समान नहीं हैं:

┌────╥───────────────────────────────────────────────────────────┐
│ Y  ║   sizeof(Xint_fastY_t) * CHAR_BIT                         │
│    ╟────────┬─────┬───────┬─────┬────────┬──────┬────────┬─────┤
│    ║ x86-64 │ x86 │ ARM64 │ ARM │ MIPS64 │ MIPS │ MSP430 │ AVR │
╞════╬════════╪═════╪═══════╪═════╪════════╪══════╪════════╪═════╡
│ 8  ║ 8      │ 8   │ 8     │ 32  │ 8      │ 8    │ 16     │ 8   │
│ 16 ║ 64     │ 32  │ 64    │ 32  │ 64     │ 32   │ 16     │ 16  │
│ 32 ║ 64     │ 32  │ 64    │ 32  │ 64     │ 32   │ 32     │ 32  │
│ 64 ║ 64     │ 64  │ 64    │ 64  │ 64     │ 64   │ 64     │ 64  │
└────╨────────┴─────┴───────┴─────┴────────┴──────┴────────┴─────┘

---

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

---

Android उपयोगकर्ताओं के लिए तालिका का स्क्रीनशॉट:

^{(एंड्रॉइड के मोनो-फ़ॉन्ट में बॉक्स-ड्राइंग वर्ण नहीं हैं - रेफरी )}

Comments

टिप्पणियाँ विस्तारित चर्चा के लिए नहीं हैं; इस वार्तालाप को बातचीत में स्थानांतरित कर दिया गया है ।

— शमूएल ल्यू

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

— एरोरिका

@RobertSsupportsMonicaCellio मेरी राय में, ये टिप्पणियां उत्तर के लिए प्रासंगिक हैं, और यहां उपयुक्त हैं। अगर वे ऐसा करने की आवश्यकता महसूस करते हैं, तो मैं एक मॉडरेटर को उन्हें स्थानांतरित करने देता हूं।

— एरोरिका

Answer 2

वे कम से कम मज़बूती से नहीं कर रहे हैं।

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

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

हालांकि, कैश प्रेशर की प्रतिस्पर्धी चिंता भी है, भले ही यह एक छोटे मूल्य को लोड / स्टोर / प्रोसेस करने के लिए अधिक निर्देश लेता हो। यदि कैश की कमी की संख्या कम हो जाती है, तो छोटा मूल्य अभी भी बेहतर प्रदर्शन कर सकता है।

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

इसके अलावा, C के प्रकार प्लेटफॉर्म के ABI का हिस्सा बन जाते हैं। इसलिए, भले ही एक प्लेटफ़ॉर्म विक्रेता को पता चलता है कि उन्होंने गूंगा विकल्प बनाया है, बाद में उन गूंगे विकल्पों को बदलना मुश्किल है।

"तेज़" प्रकारों को अनदेखा करें। यदि आप पूर्णांक प्रदर्शन के बारे में वास्तव में चिंतित हैं, तो सभी उपलब्ध आकारों के साथ अपने कोड को बेंचमार्क करें।

Answer 3

अन्य सभी पूर्णांक प्रकारों की तुलना में तेज़ प्रकार तेज़ नहीं होते हैं - वे वास्तव में कुछ "सामान्य" पूर्णांक प्रकार के समान होते हैं (वे उस प्रकार के लिए केवल एक उपनाम हैं) - जो भी प्रकार होता है वह किसी मान का मान रखने के लिए सबसे तेज़ होता है कम से कम कि कई बिट्स।

यह सिर्फ प्लेटफ़ॉर्म-डिपेंडेंट है जो प्रत्येक प्रकार के पूर्णांक प्रकार के लिए एक उपनाम है।