लाइटकॉइन खनन अनुकूलन

सभी को नमस्कार! मैंने आपको इस बारे में बताने का फैसला किया कि मैंने लाइटकूप के लिए खनन एल्गोरिदम को कैसे अनुकूलित किया। और मैं अपनी कहानी एक डायरी के रूप में प्रस्तुत करूंगा।

दिन ०: मैं एक ऐसे विषय पर आया था, जहाँ समुदाय के साथ कुछ हद तक कुछ हद तक खनन में तेजी लाने के लिए साझा किया गया। उसने खुद से पूछा: मैं उससे भी बदतर क्यों हूँ? मैंने कोड का विश्लेषण करना शुरू कर दिया।
दिन 1: मुझे वाक्यविन्यास याद है, मुझे ओपनसीएल के कार्यों के बारे में जानकारी मिली है।
दिन 2: मैं कोड की बहुत अजीब लाइनों में आया:

#define Coord(x,y,z) x+y*(x ## SIZE)+z*(y ## SIZE)*(x ## SIZE) #define CO Coord(z,x,y) 

दूसरी में पहली पंक्ति तैयार की, मिली

 #define CO z+x*zSIZE+y*xSIZE*zSIZE 

बगीचे की बाड़ लगाना क्यों आवश्यक था - मुझे समझ में नहीं आ रहा है, इसके अलावा, अप्रयुक्त चर ySIZE scrypt_core फ़ंक्शन में पाया गया था।
इसके अलावा खोज फ़ंक्शन में मुझे i * 2 के कई उपयोग मिलते हैं, जिसे रोटल (i, 1U) द्वारा प्रतिस्थापित किया गया है। इससे प्रदर्शन लाभ नहीं मिला, लेकिन इसे रहने दो।

दिन 3: मुझे एहसास हुआ कि ज्ञान के वर्तमान स्तर पर कुछ को अनुकूलित करने का मेरा एकमात्र मौका है, "सीओ" के साथ कंपाइलर की मदद करना, क्योंकि डिफ़ॉल्ट सेटिंग्स पर, z + x * zSIZE + y * xSIZE * zSIZE 8704 बार माना जाता है। सबसे अधिक संभावना है, कंपाइलर किसी तरह इन गणनाओं का अनुकूलन करता है, लेकिन यह इसे थोड़ी मदद करने से नहीं रोकता है :) इसके अलावा, zSIZE 8 के बराबर एक स्थिर है, और xSIZE प्रोग्राम सेटिंग्स से प्राप्त एक निरंतर है।
उन्होंने पहले चक्र का पता लगाना शुरू किया जिसमें "CO" का उपयोग किया जाता है:

  for(uint y=0; y<1024/LOOKUP_GAP; ++y) { #pragma unroll for(uint z=0; z<zSIZE; ++z) lookup[CO] = X[z]; //    } 

यह देखा जा सकता है कि x * zSIZE एक स्थिर है, क्योंकि लूप के निष्पादन के दौरान x नहीं बदलता है। यह भी स्पष्ट है कि लूप के प्रत्येक पुनरावृत्ति के साथ y 1 से बढ़ता है।

इसे समझते हुए, यह एक सीओ वैरिएबल के निर्माण की शुरुआत करता है जिसमें x * zSIZE शुरू में संग्रहीत किया जाएगा, और लूप के प्रत्येक पुनरावृत्ति के साथ, xSIZE * zSIZE को इसमें जोड़ा जाएगा।

और इसलिए कि चर z हमारे साथ हस्तक्षेप नहीं करता है, हम लूप के अंदर एक स्थानीय चर बनाएंगे, जिसमें हम आंतरिक लूप के प्रत्येक पुनरावृत्ति के बाद एक जोड़ देंगे।

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

परिणाम निम्नलिखित कोड है:

  uint CO=rotl(x,3U);// x*zSIZE uint CO_tmp=rotl(xSIZE,3U);//xSIZE*zSIZE for(uint y=0; y<1024/LOOKUP_GAP; ++y, CO+=CO_tmp) { uint CO_reg=CO; #pragma unroll for(uint z=0; z<zSIZE; ++z, ++CO_reg) lookup[CO_reg] = X[z]; //    } 

दिन 4: मैं "CO" के निम्नलिखित उपयोगों का विश्लेषण करता हूं। मैं प्रीप्रोसेसर में कोड को छोड़ता हूं, क्योंकि इसका उपयोग केवल एक बार ही किया जाता है।

  for (uint i=0; i<1024; ++i) { uint4 V[8]; uint j = X[7].x & K[85];//K[85]=0x000003FFU uint y = (j/LOOKUP_GAP); #pragma unroll for(uint z=0; z<zSIZE; ++z) V[z] = lookup[CO]; //    } 

यह देखा जा सकता है कि y एक जटिल एल्गोरिथ्म के अनुसार बदलता रहता है, इस चर के मूल्य की भविष्यवाणी करने की संभावना नहीं है।
इसलिए, मैं केवल इतना कर सकता हूं कि अग्रिम में x * zSIZE और xSIZE * zSIZE की गणना करें।

  CO_tmp=rotl(x,3U); CO=rotl(xSIZE,3U); for (uint i=0; i<1024; ++i) { uint4 V[8]; uint j = X[7].x & K[85]; uint y = (j/LOOKUP_GAP); uint CO_reg=CO_tmp+CO*y; for(uint z=0; z<zSIZE; ++z, ++CO_reg) V[z] = lookup[CO_reg]; //    } 

दिन 5: मैं संकलन करता हूं, और ~ 3% के मेरे विन्यास में वृद्धि का निरीक्षण करता हूं। कई बार परिणामों की जांच करने के बाद, मैं कोड को एक मानव रूप में लाता हूं, दूसरे चक्र के रूप में प्रीप्रोसेसर अनुभाग में कोड का अनुकूलन करता हूं, और पहले से बनाए गए प्रतिस्थापन * i 2 को रोटल (i, 1U) द्वारा हटा देता हूं।

"साफ" कोड के परीक्षणों के बाद, परिणाम ने मुझे आश्चर्यचकित किया - मेरे अनुकूलन की शुरुआत से पहले गति बहुत कम हो गई है। थोड़ी जांच के बाद, मुझे पता चला कि इसका कारण रोटल (i, 1U) के बजाय i * 2 की वापसी है।
ऐसा लगता है कि प्रतिस्थापन स्वयं कुछ भी नहीं देता है - मैंने इसे कई बार जांचा, लेकिन मेरी आशाओं के साथ यह गति को बढ़ाता है।

मैं अपने काम के परिणामों को कॉन कॉलिवस के मेल पर भेजता हूं।

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

दिन 13: पाया गया कि प्रदर्शन ड्रॉप i * 2 के रोलेट (i, 1U) के समान रहस्यमय प्रतिस्थापन के कारण होता है। लेकिन, इस प्रतिस्थापन को हटाने से, गति प्रारंभिक स्तर पर लौट आती है।

मैं समझता हूं कि मुझे अनुकूलन के दो संस्करण करने होंगे: 13.4 के लिए, और ड्राइवरों के पुराने संस्करणों के लिए।

दिन 13-40: 13.1 पर टूटे हुए अनुकूलन की रिपोर्ट करने वालों के बीच स्वैच्छिक परीक्षकों को एकत्रित करना, मैं काम शुरू करता हूं।
परीक्षणों के दौरान, लोहे पर निर्भर अनुकूलन का पता लगाया जाता है, जिसे मैं तुरंत मना कर देता हूं (उदाहरण के लिए, 1024 तत्वों की एक सरणी बनाकर जो गणना की गई y * xSIZE * zSIZE मानों को y = 0..1023 के लिए संग्रहीत करता है - अनुकूलन ने मेरे लिए काम किया। कोई परीक्षक नहीं हैं), साथ ही कुछ अनुकूलन के परिणामों पर आवृत्तियों के गैर-रैखिक प्रभाव भी हैं: मेरे 7850 पर 1000/1300 की आवृत्ति पर, असामान्य परिणाम जारी किए गए थे, जैसे ~ 13 की तीव्रता पर प्रति सेकंड ~ 340 किलोहिच (यह आपको कंप्यूटर पर चुपचाप काम करने की अनुमति देता है, उस समय बिना जुगलबंदी के। जब ग्राफिक्स कार्ड मेरा है टी), ~ के बजाय मेरे अनुकूलन के बिना प्रति सेकंड 200 kiloheshey और / या अन्य आवृत्तियों पर।

लेकिन, मुझे इस तरह के अनुकूलन से इनकार करना पड़ा (लगभग, खुद के लिए मैंने इस संस्करण को बचा लिया)।

Thethread-concurency सेटिंग का "मैजिक वैल्यू" भी पाया गया, जिस पर गति बढ़ती है, 2 ^ n + 1 के बराबर, उदाहरण के लिए 4097 या 16385। किसी भी अन्य मूल्य के लिए, खनन गति कम है।

मेरी धारणा है कि यह संभव है कि 2 ^ n + 1 से गुणा सबसे तेज है, लेकिन यह पूरी तरह से तार्किक नहीं है, क्योंकि 2 ^ n से गुणा करना बाईं ओर एक सरल बिट शिफ्ट है, और, सिद्धांत रूप में, यह तेज होना चाहिए ...

मैं निम्नलिखित कोड के साथ समाप्त हुआ:

  uint CO_tmp=xSIZE<<3U;//xSIZE*zSIZE uint CO_tmp2=x<<3U;//x*zSIZE for(uint y=0; y<1024/LOOKUP_GAP; ++y) { uint CO=y*CO_tmp+CO_tmp2; #pragma unroll for(uint z=0; z<zSIZE; ++z,++CO) lookup[CO] = X[z]; //    } //  for (uint i=0; i<1024; ++i) { uint4 V[8]; uint j = X[7].x & K[85]; uint y = (j/LOOKUP_GAP); uint CO=y*CO_tmp+CO_tmp2; #pragma unroll for(uint z=0; z<zSIZE; ++z) V[z] = lookup[CO+z]; //    } 

एक ही मंच पर 13.4 से अधिक उम्र के ड्राइवरों के लिए एक संस्करण प्रकाशित किया गया, जिसमें "जादू मूल्य" का उल्लेख किया गया था - इस तरह से-सहमति। और अपने काम को पूरा पाया।

मुझे उम्मीद है कि जानकार लोग मुझे बता पाएंगे कि क्या होता है जब i * 2 को रोटल (i, 1U) से बदल दिया जाता है, साथ ही साथ - thethread-concurency पैरामीटर के "जादुई मूल्य" की प्रकृति।

Lightcoins मंच पर मेरा विषय: forum.litecoin.net/index.php?topic=4082.0

पुनश्च सभी कार्य scrypt.cl फ़ाइल में किए गए थे, जो कि लाइटकोइन खनन का समर्थन करने वाले किसी भी खनिक के लिए किट में शामिल है।