बैंक संघर्ष क्या है? (डूइंग क्यूडा / ओपनसीएल प्रोग्रामिंग)


95

मैं CUDA और OpenCL के लिए प्रोग्रामिंग गाइड पढ़ रहा हूं, और मैं यह पता नहीं लगा सकता कि बैंक संघर्ष क्या है। वे सिर्फ विषय पर विस्तार से बताए बिना समस्या को हल करने में गोता लगाते हैं। क्या कोई मुझे इसे समझने में मदद कर सकता है? अगर कंप्यूटर साइंस में सामान्य तौर पर CUDA / OpenCL या सिर्फ बैंक टकराव के संदर्भ में मदद मिलती है तो मेरी कोई प्राथमिकता नहीं है।

जवाबों:


105

एनवीडिया (और उस मामले के लिए एएमडी) के लिए स्थानीय मेमोरी को मेमोरीबैंक में विभाजित किया जाता है। प्रत्येक बैंक एक समय में केवल एक डेटासेट को संबोधित कर सकता है, इसलिए यदि कोई अर्धस्वर डेटा को उसी बैंक से / से स्टोर करने / स्टोर करने का प्रयास करता है, तो एक्सेस को क्रमबद्ध किया जाना है (यह एक बैंक संघर्ष है)। Gt200 gpus के लिए 16 बैंक (fermi के लिए 32 जीबी), AMD gpus के लिए 16 या 32 बैंक (57xx या उच्चतर: 32, सब कुछ नीचे: 16)) हैं, जो 32 बिट की एक ग्रैन्युलिटी के साथ जुड़े हैं (इसलिए बाइट 0-3 में हैं) बैंक 1, 4-7 बैंक 2 में, ..., बैंक 1 में 64-69 और इतने पर)। एक बेहतर दृश्य के लिए यह मूल रूप से इस तरह दिखता है:

Bank    |      1      |      2      |      3      |...
Address |  0  1  2  3 |  4  5  6  7 |  8  9 10 11 |...
Address | 64 65 66 67 | 68 69 70 71 | 72 73 74 75 |...
...

इसलिए यदि एक अर्धवार्षिक में प्रत्येक धागा 32 बिट मूल्यों तक पहुंचता है तो बैंक संघर्ष नहीं होते हैं। इस नियम का एक अपवाद (प्रत्येक थ्रेड को अपने बैंक तक पहुंचना चाहिए) प्रसारण हैं: यदि सभी थ्रेड्स एक ही पते पर पहुंचते हैं, तो मान केवल एक बार पढ़ा जाता है और सभी थ्रेड्स पर प्रसारित किया जाता है (GT200 के लिए यह हाफपावरिंग में सभी थ्रेड्स होना चाहिए) एक ही पता, iirc fermi और AMD gpus समान मूल्य तक पहुँचने वाले किसी भी थ्रेड की संख्या के लिए ऐसा कर सकते हैं)।


3
दृश्य और स्पष्टीकरण के लिए मीठा धन्यवाद। मैं प्रसारण के बारे में नहीं जानता था और यह एक महत्वपूर्ण जानकारी की तरह लगता है :) मैं कैसे पुष्टि करूंगा कि मेरे लोड और स्टोर साझा मेमोरी में बैंक टकराव का कारण नहीं हैं? क्या मुझे किसी तरह विधानसभा कोड प्राप्त करना है या अन्य तरीके हैं?
smuggledPancakes

3
चूंकि बैंक संघर्ष की घटना somethink है जो रनटाइम पर निर्धारित की जाएगी (जिसका अर्थ है कि संकलक को इसके बारे में पता नहीं है, रनटाइम के दौरान अधिकांश पते उत्पन्न होने के बाद), संकलित संस्करण प्राप्त करने से बहुत मदद नहीं मिलेगी। मैं आम तौर पर यह पुराने तरीके से करता हूं, मैं एक पेन और पेपर लेता हूं और सोचने लगता हूं कि मेरे कोड स्टोर कहां हैं। बैंक संघर्षों की घटना को नियंत्रित करने वाले नियमों के बाद यह जटिल नहीं हैं। अन्यथा आप एनवीडिया ओपनसीएल प्रोफाइलर का उपयोग कर सकते हैं (इसे एसडीके, आई सर्किल के साथ बंडल किया जाना चाहिए)। मुझे लगता है कि यह ताना धारावाहिकों के लिए एक काउंटर है।
ग्रिजली

1
ताना धारावाहिकों को इंगित करने के लिए धन्यवाद। कंपाइलर प्रोफाइलर के साथ आने वाली रीडमी टेक्स्ट फाइल्स में से एक ने यह कहा,
स्मगलिंगपैंक्स

1
Ack, उपरोक्त टिप्पणी को माफ करें, किसी कारण से मैं इसे फिर से संपादित नहीं कर सकता। वैसे भी, मैंने इसे कंपाइलर के रीडमी में पाया, "warp_serialize: थ्रेड वॉर की संख्या जो पते पर क्रमबद्ध होती है या तो साझा या निरंतर मेमोरी के लिए संघर्ष करती है।" यह बहुत अच्छा है कि मैं आसानी से देख सकता हूँ कि क्या प्रॉफ़ाइलर आउटपुट को देखकर ही संघर्ष होता है। पेन और पेपर पर बैंक टकराव होने पर आप कैसे पता लगा सकते हैं। क्या आपने किसी उदाहरण या ट्यूटोरियल से सीखा?
smuggledPancakes

1
जैसा कि मैंने कहा कि बैंकों से पते की मैपिंग अपेक्षाकृत सरल है, इसलिए यह पता लगाना कठिन नहीं है कि कौन से बैंक किस बैंक में जाते हैं और इसलिए यदि बैंक में संघर्ष होते हैं। कागज केवल अधिक संघर्ष पहुंच पैटर्न के लिए है, जहां मैं इसके बिना नहीं कर सकता।
ग्रिजली

13

साझा की गई मेमोरी, जिसे समानांतर में एक्सेस किया जा सकता है, को मॉड्यूल (जिसे बैंक भी कहा जाता है) में विभाजित किया गया है। यदि एक ही बैंक में दो मेमोरी लोकेशन (पते) होते हैं, तो आपको एक बैंक संघर्ष होता है, जिसके दौरान एक्सेस को क्रमिक रूप से किया जाता है, समानांतर एक्सेस के फायदे खो देता है।


तो क्या यह तब संबंधित है जब एक आधा ताना मेमोरी को स्टोर या लोड करना चाहता है? 16 धागे एक मेमोरी लेनदेन करने की कोशिश कर रहे हैं और इस प्रकार एक से अधिक धागे के साथ एक ही बैंक तक पहुँचने के लिए क्रमबद्ध प्रसंस्करण का कारण बनता है? इसके अलावा, यह कैसे सुनिश्चित किया जा सकता है कि आपका डेटा उसी बैंक में स्टोर / लोड नहीं हो रहा है?
तस्करीपांचे

10

सरल शब्दों में, बैंक संघर्ष एक ऐसा मामला है जब कोई मेमोरी एक्सेस पैटर्न मेमोरी सिस्टम में उपलब्ध बैंकों में IO वितरित करने में विफल रहता है। निम्नलिखित उदाहरण अवधारणा को विस्तृत करते हैं: -

मान लें कि हमारे पास पूर्णांक के दो आयामी 512x512 सरणी हैं और हमारे DRAM या मेमोरी सिस्टम में 512 बैंक हैं। डिफ़ॉल्ट रूप से ऐरे डेटा एक तरह से लेआउट होगा जो गिरफ्तार किया जाता है [0] [0] बैंक में जाता है 0, गिरफ्तार [0] [1] बैंक 1 में जाता है, गिरफ्तार [0] [2] से बैंक 2 तक ...। गिरफ्तार [0] [५११] बैंक ५११ में जाता है। गिरफ्तारी को सामान्य बनाने के लिए [x] [y] बैंक नंबर y पर कब्जा कर लेता है। अब कुछ कोड (जैसा कि नीचे दिखाया गया है) कॉलम मेजर फैशन में डेटा एक्सेस करना शुरू करते हैं। y को स्थिर रखते हुए x को बदलना, तो अंतिम परिणाम यह होगा कि सभी लगातार मेमोरी एक्सेस एक ही बैंक से टकराएगी - इसलिए बैंक संघर्ष।

int arr[512][512];
  for ( j = 0; j < 512; j++ ) // outer loop
    for ( i = 0; i < 512; i++ ) // inner loop
       arr[i][j] = 2 * arr[i][j]; // column major processing

इस तरह की समस्याओं, आमतौर पर एरे को बफ़र करने या एरे में तत्वों की प्राइम संख्या का उपयोग करके संकलक से बचा जाता है।


7

(CUDA बैंक संघर्ष) मुझे आशा है कि यह मदद करेगा .. यह बहुत अच्छा स्पष्टीकरण है ...

http://www.youtube.com/watch?v=CZgM3DEBplE


1
ध्यान दें कि लिंक-केवल उत्तर हतोत्साहित किए जाते हैं, एसओ उत्तर एक समाधान के लिए खोज का अंतिम बिंदु होना चाहिए (बनाम संदर्भों का एक और ठहराव, जो समय के साथ बासी हो जाते हैं)। लिंक को संदर्भ के रूप में रखते हुए कृपया यहां एक स्टैंड-अलोन सिनोप्सिस जोड़ने पर विचार करें।
Kleopatra

कृपया ओपी की बेहतर सहायता के प्रयास में इस लिंक पर विस्तृत जानकारी दें।
पीटर फोती

1
यह वीडियो वाकई मददगार है! और मुझे पता नहीं क्यों नीचे वोट! यह एक बहुत अच्छा इनपुट है! +1
गेब्रियल

1

http://en.wikipedia.org/wiki/Memory_bank
और http://mprc.pku.cn/mentors/training/ISCAreading/1989/p380-weiss/p380-weiss.pdf

इस पृष्ठ से, आप मेमोरी बैंक के बारे में विवरण पा सकते हैं। लेकिन यह @Grizzly द्वारा कही गई बातों से थोड़ा अलग है। इस पृष्ठ में, बैंक इस तरह है

बैंक 1 2 3

पता | 0, 3, 6 ... | | 1, 4, 7 ... | | 2, 5,8 ... |

आशा है कि यह मदद करेगा

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