लॉजिकल एसएसई इंट्रिनिक्स के बीच क्या अंतर है?

Question

क्या विभिन्न प्रकार के लिए तार्किक एसएसई इंट्रिनिक्स के बीच कोई अंतर है? उदाहरण के लिए यदि हम लेते हैं या ऑपरेशन करते हैं, तो तीन इंट्रिनिक्स हैं: _mm_or_ps, _mm_or_pd और _mm_or_si128 जिनमें से सभी एक ही काम करते हैं: बिटवाई या उनके संचालन की गणना करें। मेरे सवालों का:

1. एक या एक और आंतरिक (उचित प्रकार कास्टिंग के साथ) का उपयोग कर के बीच कोई अंतर है। क्या किसी विशिष्ट स्थिति में लंबे समय तक निष्पादन की तरह कोई छुपी लागत नहीं होगी?

2. ये अंतर्निहित तीन अलग-अलग x86 निर्देशों (por, orps, orpd) के मानचित्र हैं। क्या किसी के पास कोई विचार है कि क्यों इंटेल कई निर्देशों के लिए बहुमूल्य ऑपोड स्पेस बर्बाद कर रहा है जो एक ही काम करता है?

Answer 1

मुझे लगता है कि सभी तीन प्रभावी रूप से समान हैं, यानी 128 बिट बिटवाई ऑपरेशंस। विभिन्न रूपों का कारण शायद ऐतिहासिक है, लेकिन मैं निश्चित नहीं हूं। मुझे लगता है कि यह संभव है कि फ़्लोटिंग पॉइंट संस्करणों में कुछ अतिरिक्त व्यवहार हो सकता है, उदा। जब NaNs होते हैं, लेकिन यह शुद्ध अनुमान है। सामान्य इनपुट के लिए निर्देश विनिमेय लगते हैं, उदा।

#include <stdio.h> 
#include <emmintrin.h> 
#include <pmmintrin.h> 
#include <xmmintrin.h> 

int main(void) 
{ 
    __m128i a = _mm_set1_epi32(1); 
    __m128i b = _mm_set1_epi32(2); 
    __m128i c = _mm_or_si128(a, b); 

    __m128 x = _mm_set1_ps(1.25f); 
    __m128 y = _mm_set1_ps(1.5f); 
    __m128 z = _mm_or_ps(x, y); 

    printf("a = %vld, b = %vld, c = %vld\n", a, b, c); 
    printf("x = %vf, y = %vf, z = %vf\n", x, y, z); 

    c = (__m128i)_mm_or_ps((__m128)a, (__m128)b); 
    z = (__m128)_mm_or_si128((__m128i)x, (__m128i)y); 

    printf("a = %vld, b = %vld, c = %vld\n", a, b, c); 
    printf("x = %vf, y = %vf, z = %vf\n", x, y, z); 

    return 0; 
} 

$ gcc -Wall -msse3 por.c -o por 

$ ./por 

a = 1 1 1 1, b = 2 2 2 2, c = 3 3 3 3 
x = 1.250000 1.250000 1.250000 1.250000, y = 1.500000 1.500000 1.500000 1.500000, z = 1.750000 1.750000 1.750000 1.750000 
a = 1 1 1 1, b = 2 2 2 2, c = 3 3 3 3 
x = 1.250000 1.250000 1.250000 1.250000, y = 1.500000 1.500000 1.500000 1.500000, z = 1.750000 1.750000 1.750000 1.750000 

Answer 2

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

Answer 3

1. एक या एक और आंतरिक (उचित प्रकार कास्टिंग के साथ) का उपयोग कर के बीच कोई अंतर है। क्या किसी विशिष्ट स्थिति में लंबे समय तक निष्पादन की तरह कोई छुपी लागत नहीं होगी?

हाँ, वहाँ प्रदर्शन के कारणों के एक अन्य बनाम चयन करने के लिए हो सकता है।

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

this answer, या Agner Fog's microarchitecture doc बाईपास-देरी के लिए देखें। Agner के डॉक्टर में "नेहलेम पर डेटा बाईपास देरी" के लिए खोजें; इसमें कुछ अच्छे व्यावहारिक उदाहरण और चर्चा हैं। उनके पास विश्लेषण किए गए प्रत्येक सूक्ष्मजीव के लिए उनके पास एक अनुभाग है।

हालांकि, अलग डोमेन या रजिस्टर के विभिन्न प्रकार के बीच डेटा पारित करने के लिए देरी सैंडी ब्रिज और Nehalem पर से आइवी ब्रिज, और अक्सर शून्य पर छोटे होते हैं। - Agner कोहरा के माइक्रो मेहराब डॉक

कि विलंबता याद रखें कोई फर्क नहीं पड़ता अगर यह आपके कोड के महत्वपूर्ण मार्ग पर नहीं है।movaps + shufps के बजाय pshufd का उपयोग करना एक जीत हो सकता है यदि आपके महत्वपूर्ण पथ की विलंबता के बजाय यूओपी थ्रूपुट आपकी बाधा है।

2:...ps संस्करण दूसरे दो की तुलना में कोड के 1 कम बाइट लेता है। यह निम्नलिखित निर्देशों को अलग-अलग संरेखित करेगा, जो डिकोडर्स और/या यूओपी कैश लाइनों के लिए महत्वपूर्ण हो सकता है।

3: हालिया इंटेल CPU केवल पोर्ट 5 पर एफपी संस्करण चला सकते हैं।

• मेरॉम (Core2) और Penryn: orps p0/p1/पी 5 पर चला सकते हैं, लेकिन केवल पूर्णांक-डोमेन। संभवतः सभी 3 संस्करण सटीक उसी यूओपी में डीकोड किए गए हैं। तो क्रॉस-डोमेन अग्रेषण देरी होती है। (एएमडी सीपीयू ऐसा भी कर: एफपी बिटवाइज़ निर्देश ivec डोमेन चलाते हैं।)

• Nehalem/Sandybridge/IVB/Haswell/Broadwell: por p0/p1/पी 5 पर चला सकते हैं, लेकिन orps केवल port5 पर चला सकते हैं। पी 5 को शफल द्वारा भी जरूरी है, लेकिन एफएमए, एफपी एड, और एफपी मूल इकाइयां बंदरगाहों पर हैं 0/1।

• स्किलेक: por और orpsboth have 3-per-cycle throughput। देरी अग्रेषण के बारे में जानकारी अभी तक उपलब्ध नहीं है।

ध्यान दें कि SNB/IVB (AVX नहीं बल्कि AVX2) पर, केवल पी 5, 256b तार्किक ऑप्स को संभालने के लिए के रूप में vpor ymm, ymm AVX2 की आवश्यकता की जरूरत है। यह शायद बदलाव का कारण नहीं था, क्योंकि नेहलेम ने ऐसा किया था।

बुद्धिमानी कैसे चुनें: port5 पर तार्किक सेशन throughput एक टोंटी हो सकता है

है, तो, पूर्णांक संस्करणों का उपयोग भी एफपी डेटा पर। यह विशेष रूप से सच है यदि आप पूर्णांक शफल या अन्य डेटा-आंदोलन निर्देशों का उपयोग करना चाहते हैं।

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

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

...pd संस्करणों का उपयोग करने के लिए व्यावहारिक/मानव-कारक कारण हैं, हालांकि, अक्सर कोड के 1 बाइट से अधिक बचत होगी। अन्य मनुष्यों द्वारा अपने कोड की पठनीयता एक कारक है: वे आश्चर्य करेंगे क्यों तुम जब यह वास्तव में दोगुना हो जाता है है एकल के रूप में अपने डेटा का इलाज कर रहे हैं। Esp। सी/सी ++ इंट्रिनिक्स के साथ, __mm256 और __mm256d के बीच आपके कोड को कूड़े हुए के लायक नहीं है। insn संरेखण मामलों के स्तर पर ट्यूनिंग, तो सीधे एएसएम में लिखते हैं, intrinsics नहीं! पूर्णांक डेटा के लिए (अनुदेश एक बाइट अब होने UOP कैश लाइन घनत्व और/या डिकोडर के लिए चीजों को बेहतर संरेखित सकता है।)

, पूर्णांक संस्करणों का उपयोग करें। सहेजा जा रहा है एक अनुदेश बाइट बाईपास-देरी के लायक नहीं है, और पूर्णांक कोड अक्सर पूरी तरह से शफ़ल के साथ व्यस्त port5 रहता है। Haswell के लिए, कई फेरबदल/सम्मिलित/निकालने/पैक/खोल दिए गए निर्देशों का P5 केवल, SNB/IVB के लिए p1/पी 5 के बजाय बन गया।

तीन अलग-अलग 86 निर्देश ( por, orps, orpd) को
1. ये intrinsics नक्शे। क्या किसी के पास कोई विचार है कि क्यों इंटेल कई निर्देशों के लिए बहुमूल्य ओपोड स्थान बर्बाद कर रहा है जो एक ही काम करता है?

आप इन निर्देश सेट के इतिहास को देखें, तो आप एक तरह से देख सकते हैं कि हम यहाँ मिल गया।

por (MMX):  0F EB /r 
orps (SSE):  0F 56 /r 
orpd (SSE2): 66 0F 56 /r 
por (SSE2): 66 0F EB /r 

MMX SSE से पहले से ही अस्तित्व में है, इसलिए इसे SSE के लिए opcodes की तरह (...ps) निर्देश एक ही 0F xx स्थान से बाहर चुने गए हैं लग रहा है। फिर एसएसई 2 के लिए, ...pd संस्करण ने 66...ps ऑपोड पर ऑपरेंड-आकार उपसर्ग जोड़ा, और पूर्णांक संस्करण ने 66 एमएमएक्स संस्करण में उपसर्ग जोड़ा।

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