2012-09-12 15 views
14

का आउटपुट आउटपुट आउटपुट मैं हाथ से लिखित कर्नेल के लिए अपने प्रत्येक CUDA थ्रेड के लिए संसाधन उपयोग को समझने की कोशिश कर रहा हूं।--ptxas-options = -v

मैं nvcc -arch=sm_20 -ptxas-options=-v

के साथ एक kernel.o फाइल करने के लिए मेरी kernel.cu फ़ाइल संकलित और मैं निम्नलिखित उत्पादन

ptxas info : Compiling entry function '_Z12searchkernel6octreePidiPdS1_S1_' for 'sm_20' 
ptxas info : Function properties for _Z12searchkernel6octreePidiPdS1_S1_ 
    72 bytes stack frame, 0 bytes spill stores, 0 bytes spill loads 
ptxas info : Used 46 registers, 176 bytes cmem[0], 16 bytes cmem[14] 

ऊपर उत्पादन को देखते हुए मिल गया, यह कहना सही है कि

  • प्रत्येक CUDA धागा 46 रजिस्टरों का उपयोग कर रहा है?
  • स्थानीय मेमोरी में कोई पंजीकरण नहीं है?

मुझे आउटपुट को समझने के साथ कुछ समस्याएं भी हैं।

  • मेरे गिरी __device__ कार्यों की एक पूरी बहुत कुछ बुला रहा है। __global__ और __device__ फ़ंक्शंस के स्टैक फ्रेम के लिए मेमोरी के 7212 बाइट्स योग-कुल है?

  • 0 byte spill stores और 0 bytes spill loads

  • बीच क्या अंतर है क्यों cmem के लिए जानकारी विभिन्न आंकड़ों के साथ दो बार दोहराए गए (जो मैं यह सोचते हैं रहा हूँ निरंतर स्मृति है) है? कर्नेल के भीतर मैं किसी निरंतर मेमोरी का उपयोग नहीं कर रहा हूं। क्या इसका मतलब यह है कि संकलक हुड के तहत, कुछ स्थिर स्मृति का उपयोग करने के लिए GPU को बताने जा रहा है?

+0

'प्रयुक्त 46 रजिस्टरों' इंगित करता है संकलक संकलित कर्नेल के लिए धागा प्रति 46 रजिस्टरों आरक्षित किया गया है और अन्य रजिस्टरों गिरा रहे हैं। आप कर्नेल के पीटीएक्स में इस्तेमाल किए गए रजिस्टर की कुल संख्या से इस नंबर (46) को घटाकर स्पिल्ल्ड रजिस्टरों की संख्या पा सकते हैं। – ahmad

+2

@ अहमद: आप पहली वाक्य सही है, लेकिन दूसरा नहीं है। एक कर्नेल प्रति थ्रेड अधिकतम स्वीकार्य रजिस्टरों से कम उपयोग कर सकता है और स्थानीय मेमोरी में कोई स्पिल नहीं है। – talonmies

+1

talonmies उत्तर पर विस्तृत करने के लिए, पीटीएक्स अनंत रजिस्टरों के साथ एक उच्च स्तरीय अमूर्त है। ऐसा इसलिए है क्योंकि इसे जीपीयू की कई पीढ़ियों के लिए संकलित किया जा सकता है और रजिस्टरों की संख्या अलग हो सकती है। यह तभी होता है जब आप मशीन विशिष्ट कोड पर संकलित करते हैं जिसे आप वास्तव में रजिस्टर उपयोग को देख सकते हैं। किसी भी मामले में, ptxas (मशीन-विशिष्ट कोड में पीटीएक्स संकलित) आपको स्पिल की मात्रा बताता है। – Tom

उत्तर

13
  • प्रत्येक CUDA धागा 46 रजिस्टरों का उपयोग कर रहा है? हां, सही
  • स्थानीय मेमोरी में कोई पंजीकरण नहीं है? हां, सही
  • __global__ और __device__ फ़ंक्शंस के ढेर फ्रेम के लिए स्मृति की कुल योग 72 बाइट्स है? हां, सही
  • 0 बाइट स्पिल स्टोर्स और 0 बाइट्स स्पिल लोड के बीच क्या अंतर है?
    • उचित प्रश्न, लोड स्टोर से अधिक हो सकते हैं क्योंकि आप एक गणना मूल्य बढ़ा सकते हैं, इसे एक बार लोड कर सकते हैं, इसे छोड़ दें (यानी उस रजिस्टर में कुछ और स्टोर करें) फिर इसे फिर से लोड करें (यानी इसका पुन: उपयोग करें)। अद्यतन: टिप्पणी भी कि फैल लोड/दुकान गिनती के रूप में नीचे
  • क्यों cmem के लिए जानकारी है टिप्पणी में @njuffa द्वारा वर्णित स्थिर विश्लेषण के आधार पर दोहराया (जो मैं यह सोचते हैं रहा हूँ निरंतर स्मृति है) दो बार विभिन्न आंकड़ों के साथ? कर्नेल के भीतर मैं किसी निरंतर स्मृति का उपयोग नहीं कर रहा हूं। क्या इसका मतलब है कि संकलक हुड के नीचे है, जीपीयू को कुछ निरंतर स्मृति का उपयोग करने के लिए कहने जा रहा है?
    • लगातार स्मृति __constant__ चर और गिरी तर्क सहित कुछ प्रयोजनों के लिए प्रयोग किया जाता है, विभिन्न "बैंकों" उपयोग किया जाता है, कि एक सा विस्तृत प्राप्त करने के लिए लेकिन जब तक आप अपने __constant__ चर के लिए 64KB से भी कम समय और 4KB से भी कम समय का उपयोग शुरू होता है कर्नेल तर्क के लिए आप ठीक रहेगा।
+2

में निरंतर स्मृति का उपयोग नहीं करते हैं, ध्यान दें कि लोड और स्टोर्स को स्थिर रूप से गिना जाता है, यानी स्थानीय लोड और स्थानीय स्टोर निर्देशों की संख्या चौड़ाई से गुणा हो जाती है प्रत्येक लोड/स्टोर की पहुंच। वे बाइट्स के लिए सामान्यीकृत होते हैं क्योंकि संकलक स्पिल लोड/स्टोर्स को सदिश करने में सक्षम हो सकता है यदि उसके पास संरेखण के बारे में पर्याप्त जानकारी है और आवंटन पंजीकृत करने की अनुमति देता है। चूंकि गणना स्थिर होती है, यह सीधे स्पिल के लिए यातायात का एक उपाय नहीं है, क्योंकि स्पिल/भरें लूप के अंदर हो सकती हैं। यदि स्पिल किए गए डेटा का पुनः उपयोग किया जाता है तो स्पिल लोड स्पिल स्टोर्स से अधिक हो सकता है। यह इंगित करेगा कि स्पिल लोड बाइट्स> = स्पिल स्टोर बाइट्स। – njuffa

+2

धन्यवाद @njuffa - उत्कृष्ट अंक। कंपाइलर लूप के लिए यात्रा-गणना नहीं जानता (जब तक कि संकलन-समय स्थिर न हो)। वास्तव में स्पिल/भरने की लागत का विश्लेषण करने का सबसे अच्छा तरीका एनएसइट (या स्टैंडअलोन एनवीवीपी) जैसे प्रोफाइलर का उपयोग करना है, जो आपको संकलन के बजाय निष्पादन के आधार पर डेटा देगा। – Tom

+0

प्रोफाइलिंग के संबंध में सहमत हुए। कंपाइलर के स्पिल आंकड़े पहले-पंक्ति संकेतकों के रूप में हल्के रूप से उपयोगी होते हैं। यदि कोई स्पिलिंग नहीं है, तो चिंता करने की कोई बात नहीं है। यदि संख्याएं छोटी हैं (उदा। <32 बाइट्स) एल 1 कैश को प्रदर्शन प्रभाव के बिना उनका ख्याल रखना चाहिए (याद रखें कि प्रति थ्रेड हैं, क्योंकि स्प्रेड के लिए थ्रेड-स्थानीय मेमोरी का उपयोग किया जाता है)। यदि संख्याएं हजारों में हैं तो ऋणात्मक peformance प्रभाव की संभावना है और यह अधिक विस्तृत विश्लेषण के लिए समय हो सकता है। – njuffa

संबंधित मुद्दे