GHC के तहत हास्केल फास्ट प्रिंसिपल्स

जीएचसी (ग्लासगो हास्केल कंपाइलर) मानक हास्केल कंपाइलर है। जीएचसी दुनिया में सबसे अच्छे संकलकों में से एक है, लेकिन दुर्भाग्य से अतिरिक्त इशारों के बिना, इसके द्वारा संकलित कार्यक्रम अधिक व्याख्या किए गए लोगों की तरह हैं, अर्थात्, वे बहुत धीमी गति से काम करते हैं। हालाँकि, यदि आप संकलक की पूरी क्षमता को हटाते हैं, तो Haskell C में समान कोड के प्रदर्शन में आता है।

इस लेख में, मैं Yarr डेटाफ्लो फ्रेमवर्क बनाते समय GHC से अधिकतम को निचोड़ने के अनुभव को संक्षेप में प्रस्तुत करता हूं।

लेख में अलग-अलग नहीं बल्कि अलग-अलग अवलोकन शामिल हैं, लेकिन मुझे लगता है कि यह विषय में एक ज्ञापन या एक शुरुआत के रूप में सूट करेगा। वर्णित सिद्धांत अनुभवजन्य हैं, मुझे GHC की आंतरिक संरचना का पता नहीं है। मैं संकलक के सिद्धांत को नहीं जानता, इसलिए यदि किसी कारण से आम तौर पर स्वीकृत शर्तें हैं, तो टिप्पणियों में सुझाव दें।

जीएचसी का वर्तमान संस्करण 7.6.1 है।

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

---

जीएचसी का संचालन करने वाले अनुकूलन के 2 मुख्य क्षेत्र हैं:

• डेटा टुकड़ों को प्राथमिक टुकड़ों में विभाजित करना और उनके साथ सीधे काम करने के लिए फ़ंक्शंस बदलना ( अनबॉक्स किए गए प्रकार और आदिम संचालन देखें )
• इनलाइन और फ़ीचर विशेषज्ञता

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

डेटा प्रकार

कई कंस्ट्रक्टर के साथ डेटा प्रकार से बचें

हो सकता है, या तो और सूचियों सहित, कोई फर्क नहीं पड़ता कि वे "मानक" कैसे हैं। कारण स्पष्ट है - ऐसे डेटा प्रकारों को विघटित नहीं किया जा सकता है, क्योंकि यह सांख्यिकीय रूप से ज्ञात नहीं है कि उनकी संरचना क्या है।

एकमात्र अपवाद मापदंडों के बिना कई निर्माणकर्ताओं के साथ गणना प्रकार है: Bool , Ordering , आदि।

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

इन्हें भी देखें: HaskellWiki - प्रदर्शन / डेटा प्रकार ।

संरचनाओं को कठोर घोषित करने के लिए फ़ील्ड घोषित करें जब तक कि आपको यह पता न हो कि उन्हें आलसी क्यों होना चाहिए

एक नियमित, आलसी क्षेत्र एक बंद का संदर्भ है जो क्षेत्र के मूल्य को लौटाएगा। सख्त फ़ील्ड - फ़ील्ड मान का संदर्भ। अंतर्निहित (अनबॉक्स) फ़ील्ड स्वयं मूल्य है (यदि यह एक संरचना भी है, तो यह पूरी तरह से माता-पिता में एम्बेडेड है)। अंतर्निहित फ़ील्ड को सख्त क्षेत्र में निर्देश {-# UNPACK #-} को जोड़कर प्राप्त किया जाता है।

1 विकल्प के बिना, जैसा कि सूचियों के मामले में है, यह वास्तव में जीने में बहुत अच्छा है। प्रत्येक मामले में, 2 या 3 विकल्पों के पक्ष में एक सूचित विकल्प बनाएं। संदर्भ द्वारा फ़ील्ड कभी-कभी अधिक मेमोरी कुशल होती हैं, संरचना बनाते समय, समानता के लिए जाँच। पढ़ते समय बिल्ट-इन फ़ील्ड तेज़ होते हैं। यदि आपको अक्सर अंतर्निहित फ़ील्ड (सबसे अधिक संभावना) की आवश्यकता होती है, तो -funbox-strict-fields ध्वज के साथ संकलित करें और " {-# NOUNPACK #-} " {-# NOUNPACK #-} निर्देश को "संदर्भ" फ़ील्ड में जोड़ें।

इसे भी देखें: हास्केल स्टाइल गाइड / आलस से निपटना

पुन: उपयोग से पहले स्पष्ट रूप से संरचनाओं की गणना करें

उदाहरण में, वेक्टर को प्रदर्शित करते समय संरचना t कई बार किया जाता है:

 import Data.Vector as V ... data T = T !Int !Int fSum (T xy) = x + y ... -- t :: T V.map (+ (fSum t)) longVectorOfInts 

GHC "लूप" से संरचना गणना नहीं लेता है:

 --   GHC    V.map (\x -> case t of (T yz) -> x + y + z) longVectorOfInts 

मशीन कोड में, प्रत्येक पुनरावृत्ति पर, हम लिंक का अनुसरण करेंगे और समान फ़ील्ड पढ़ेंगे।

हालाँकि, यदि आप लूप के बाहर संकलक को "बता" देते हैं, तो वह ASD (अमूर्त सिंटैक्स ट्री) में पहले से कहीं ऊपर की गई गणनाओं को नहीं दोहराता है:

 case t of (T xy) -> V.map (+ (fSum t)) longVectorOfInts -- GHC  : case t of (T xy) -> let s = x + y in V.map (\x -> x + s) longVectorOfInts 

मामलों को मैन्युअल रूप से लिखने के बजाय, आप डीपसीक पैकेज से जेनेरिक नियंत्रण प्रवाह का उपयोग कर सकते हैं।

उदाहरण बहुत सफल नहीं है, क्योंकि t संरचना का उपयोग एक बार किया जाता है और आप बस fSum t को एक चर के रूप में चुन सकते हैं, लेकिन मुझे लगता है कि तकनीक का सार स्पष्ट है।

कार्यों

नियम नंबर 1: INLINE निर्देश को सभी छोटे, अक्सर (रनटाइम पर) कहा जाता है, जो कि SDA मूल कार्यों से बहुत दूर है। यदि फ़ंक्शन एम्बेडेड नहीं हैं, तो इस अनुभाग में दिए गए सुझाव हानिकारक हो जाते हैं।

अधिक कार्य, लंबोदर, करी!

या इसे स्मार्ट तरीके से रखें, निरंतरता गुजर शैली का उपयोग करें।

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

उदाहरण के लिए, Yarr फ्रेमवर्क में, मैं कॉन्फ़िगरेशन संरचनाओं के बजाय गणनाओं को मानकीकृत करने के लिए फ़ंक्शन की एक पूरी प्रणाली का उपयोग करता हूं। आरेख फ़ंक्शन प्रकारों के पदानुक्रम को दिखाता है, तीर "ए → बी" का अर्थ है "बी को ए से आंशिक आवेदन प्राप्त होता है", तर्क बरगंडी के साथ हाइलाइट किए जाते हैं, जो बदले में भी कार्य हैं:


यह सुनिश्चित करने के लिए कि आंशिक रूप से लागू फ़ंक्शन विशिष्ट होगा, परिभाषा में लंबोदर के साथ तर्कों को तोड़ें:

 f :: A -> B -> C {-# INLINE f #-} fab = ... -- body where ... -- declarations --> fa \b -> let ... -- declarations in ... -- body 

यह ट्रिक GHC डॉक्यूमेंटेशन के INLINE प्राग्मा सेक्शन में वर्णित है।

सामान्य कार्यों से सावधान रहें

एक सामान्यीकृत फ़ंक्शन (अनिवार्य भाषाओं में एक ला वास्तविक बहुरूपता) की कॉल परिभाषा द्वारा इनलाइन नहीं हो सकती है। इसलिए, ऐसे कार्यों को कॉल के स्थान पर विशेष रूप से आवश्यक होना चाहिए। यदि जीएचसी वास्तव में तर्क के प्रकार को जानता है और जेनेरिक फ़ंक्शन स्वयं INLINE निर्देश के साथ प्रदान किया जाता है, तो यह आमतौर पर होता है। जब सामान्यीकरण को कई स्तरों के कार्यों में विस्तारित किया जाता है, तो यह विशेषज्ञ नहीं होता है।

आप जो कुछ भी कर सकते हैं उसे प्रकारों के स्तर पर ले जाएं

यदि लक्ष्य एक उत्पादक कार्यक्रम प्राप्त करना है, तो इसे निष्पादित करने की तुलना में लंबे समय तक संकलित करना बेहतर है। हास्केल के पास संकलन चरण में कम्प्यूटेशन स्थानांतरित करने के लिए कई तंत्र हैं ।

येर में, मैंने स्थिर दोहरी प्रेषण , स्थिर अंकगणित ( टाइप-स्तरीय पुस्तकालय में तैयार अंकगणित और तर्क के लिए) और कुछ अन्य चीजों के लिए मार्कर इंडेक्स प्रकारों का उपयोग किया।

संकलन के झंडे

-O2 - हमेशा।

के बारे में -funbox-strict-fields ऊपर लिखे गए हैं।

दुर्लभ मामलों को छोड़कर, तेज मशीन कोड अब LLVM -fllvm -optlo-O3 उत्पन्न करता है: -fllvm -optlo-O3 ।

इसलिए कि जीएचसी कॉफी के आधार पर भाग्यवती नहीं करता है और वे जो कुछ भी कहते हैं उसका निर्माण करते हैं, बेन लिप्मीयर ने -funfolding-use-threshold1000 -funfolding-keeness-factor1000 का उपयोग करने की सिफारिश की है ।