आउटऑफ़लाइन - उच्च-प्रदर्शन C ++ अनुप्रयोगों के लिए इन-मेमोरी पैटर्न

हेडलैंड टेक्नोलॉजीज में काम करते समय, मैं सौभाग्यशाली था कि उच्च-प्रदर्शन C ++ कोड के निर्माण को सरल बनाने के लिए कई उपयोगिताओं को लिखा। यह लेख इन उपयोगिताओं में से एक का सामान्य अवलोकन प्रदान करता है, OutOfLine ।

एक उदाहरण के साथ शुरू करते हैं। मान लीजिए कि आपके पास एक सिस्टम है जो बड़ी संख्या में फाइल सिस्टम ऑब्जेक्ट्स से संबंधित है। ये साधारण फाइलें हो सकती हैं, जिसका नाम UNIX सॉकेट या पाइप है। किसी कारण के लिए, आप स्टार्टअप पर बहुत सारे फ़ाइल डिस्क्रिप्टर खोलते हैं, फिर उनके साथ गहनता से काम करते हैं, और अंत में, डिस्क्रिप्टर को बंद कर देते हैं और फ़ाइलों के लिंक हटा देते हैं (लगभग। लेन का अर्थ है अनलिंक फ़ंक्शन)।

प्रारंभिक (सरलीकृत) संस्करण इस तरह दिख सकता है:

 class UnlinkingFD { std::string path; public: int fd; UnlinkingFD(const std::string& p) : path(p) { fd = open(p.c_str(), O_RDWR, 0); } ~UnlinkingFD() { close(fd); unlink(path.c_str()); } UnlinkingFD(const UnlinkingFD&) = delete; }; 

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

लेकिन प्रदर्शन का क्या? मान लीजिए कि fd उपयोग बहुत बार किया जाता है, और किसी ऑब्जेक्ट को हटाते समय केवल path । अब सरणी में 40 बाइट्स के ऑब्जेक्ट होते हैं, लेकिन अक्सर केवल 4 बाइट्स का उपयोग किया जाता है। इसका मतलब यह है कि कैश में अधिक मिस होगा, क्योंकि आपको 90% डेटा को "स्किप" करने की आवश्यकता है।

इस समस्या का एक सामान्य समाधान संरचनाओं की एक सरणी से एक सरणी संरचना में संक्रमण है। यह वांछित प्रदर्शन प्रदान करेगा, लेकिन RAII को छोड़ने की कीमत पर। क्या कोई विकल्प है जो दोनों दृष्टिकोणों के लाभों को जोड़ता है?

एक साधारण समझौता std::string को बदलने के लिए होगा std::string 32 बाइट्स के आकार के std::string std::unique_ptr<std::string> , जिसका आकार केवल 8 बाइट्स है। यह हमारी वस्तु के आकार को 40 बाइट्स से घटाकर 16 बाइट्स कर देगा, जो एक बड़ी उपलब्धि है। लेकिन यह समाधान अभी भी कई सरणियों का उपयोग करने के लिए खो देता है।

OutOfLine एक ऐसा उपकरण है जो RAII को वस्तु के बाहर उपयोग किए गए (ठंडे) क्षेत्रों को पूरी तरह से स्थानांतरित करने के बिना छोड़ने की अनुमति देता है। आउटऑफलाइन का उपयोग CRTP बेस क्लास के रूप में किया जाता है, इसलिए टेम्प्लेट का पहला तर्क चाइल्ड क्लास होना चाहिए। दूसरा तर्क शायद ही कभी उपयोग किए जाने वाले (ठंडे) डेटा का प्रकार है जो अक्सर उपयोग की जाने वाली (मुख्य) वस्तु से जुड़ा होता है।

 struct UnlinkingFD : private OutOfLine<UnlinkingFD, std::string> { int fd; UnlinkingFD(const std::string& p) : OutOfLine<UnlinkingFD, std::string>(p) { fd = open(p.c_str(), O_RDWR, 0); } ~UnlinkingFD(); UnlinkingFD(const UnlinkingFD&) = delete; }; 

तो यह वर्ग कैसा है?

 template <class FastData, class ColdData> class OutOfLine { 

बुनियादी कार्यान्वयन का विचार एक वैश्विक साहचर्य कंटेनर का उपयोग करना है जो मुख्य वस्तुओं की ओर संकेत करता है और ठंडी डेटा वाली वस्तुओं की ओर संकेत करता है।

  inline static std::map<OutOfLine const*, std::unique_ptr<ColdData>> global_map_; 

OutOfLine का उपयोग किसी भी प्रकार के ठंडे डेटा के साथ किया जा सकता है, जिसका एक उदाहरण मुख्य ऑब्जेक्ट के साथ स्वचालित रूप से बनाया और जुड़ा हुआ है।

  template <class... TArgs> explicit OutOfLine(TArgs&&... args) { global_map_[this] = std::make_unique<ColdData>(std::forward<TArgs>(args)...); } 

मुख्य वस्तु को हटाने से संबंधित ठंड वस्तु का स्वत: निष्कासन होता है:

  ~OutOfLine() { global_map_.erase(this); } 

जब मुख्य ऑब्जेक्ट का मूवमेंट (मूव कंस्ट्रक्टर / मूव असाइनमेंट ऑपरेटर) किया जाता है, तो संबंधित कोल्ड ऑब्जेक्ट नए मुख्य उत्तराधिकारी ऑब्जेक्ट के साथ स्वचालित रूप से संबद्ध हो जाएगा। नतीजतन, आपको किसी स्थानांतरित वस्तु से ठंडे डेटा तक नहीं पहुंचना चाहिए।

  explicit OutOfLine(OutOfLine&& other) { *this = other; } OutOfLine& operator=(OutOfLine&& other) { global_map_[this] = std::move(global_map_[&other]); return *this; } 

उपरोक्त कार्यान्वयन उदाहरण में, OutOfLine को सादगी के लिए OutOfLine जाता है। यदि आवश्यक हो, तो कॉपी ऑपरेशन को जोड़ना आसान है, उन्हें बस एक ठंडी वस्तु की प्रतिलिपि बनाने और लिंक करने की आवश्यकता है।

 OutOfLine(OutOfLine const&) = delete; OutOfLine& operator=(OutOfLine const&) = delete; 

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

  ColdData& cold() noexcept { return *global_map_[this]; } ColdData const& cold() const noexcept { return *global_map_[this]; } 

वे ठंडे डेटा के लिए उपयुक्त प्रकार का संदर्भ देते हैं।

यह लगभग सभी है। यह UnlinkingFD विकल्प आकार में 4 बाइट्स होगा, fd फ़ील्ड में कैश-फ्रेंडली एक्सेस प्रदान करेगा और RAII के लाभों को बनाए रखेगा। किसी वस्तु के जीवन चक्र से संबंधित सभी कार्य पूरी तरह से स्वचालित हैं। जब मुख्य बार-बार उपयोग की जाने वाली वस्तु चलती है, तो शायद ही कभी उपयोग किए जाने वाले ठंडे डेटा इसके साथ चलते हैं। जब मुख्य ऑब्जेक्ट हटा दिया जाता है, तो संबंधित कोल्ड ऑब्जेक्ट भी हटा दिया जाता है।

कभी-कभी, हालांकि, आपके डेटा को आपके जीवन को जटिल बनाने के लिए साजिश रची जाती है - और आपको एक ऐसी स्थिति का सामना करना पड़ता है जिसमें मूल डेटा पहले बनाया जाना चाहिए। उदाहरण के लिए, उन्हें ठंडे डेटा के निर्माण की आवश्यकता होती है। OutOfLine पेशकश के सापेक्ष रिवर्स ऑर्डर में ऑब्जेक्ट बनाने की आवश्यकता है। ऐसे मामलों के लिए, एक "बैक-अप" हमारे लिए इनिशियलाइज़ेशन और डी-इनिशियलाइज़ेशन ऑर्डर को नियंत्रित करने के लिए उपयोगी है।

  struct TwoPhaseInit {}; OutOfLine(TwoPhaseInit){} template <class... TArgs> void init_cold_data(TArgs&&... args) { global_map_.find(this)->second = std::make_unique<ColdData>(std::forward<TArgs>(args)...); } void release_cold_data() { global_map_[this].reset(); } 

यह एक और OutOfLine कंस्ट्रक्टर है जिसका उपयोग बाल वर्गों में किया जा सकता है; यह TwoPhaseInit टाइप का टैग स्वीकार करता है। यदि आप इस तरह से OutOfLine बनाते हैं, तो कोल्ड डेटा को इनिशियलाइज़ नहीं किया जाएगा, और ऑब्जेक्ट आधा निर्मित रहेगा। दो-चरण के निर्माण को पूरा करने के लिए, आपको init_cold_data विधि को कॉल करने की आवश्यकता है (इसमें टाइप ColdData का ऑब्जेक्ट बनाने के लिए आवश्यक तर्क पास करना)। याद रखें कि आप एक ऐसी वस्तु पर .cold() कॉल नहीं कर सकते हैं जिसका ठंडा डेटा अभी तक आरंभीकृत नहीं किया गया है। सादृश्य से, ठंड डेटा को जारी करने से पहले हटा दिया जा सकता है ~OutOfLine destructor को ~OutOfLine करने से पहले release_cold_data को कॉल करके।

 }; // end of class OutOfLine 

अब यह सब है। तो कोड की ये 29 लाइनें हमें क्या देती हैं? वे प्रदर्शन और उपयोग में आसानी के बीच एक और संभावित व्यापार आधार हैं। ऐसे मामलों में जहां आपके पास कोई वस्तु होती है, जिनके कुछ सदस्यों को दूसरों की तुलना में अधिक बार उपयोग किया जाता है, OutOfLine कैश का अनुकूलन करने के लिए एक आसान-से-उपयोग के रूप में काम कर सकता है, शायद ही कभी उपयोग किए गए डेटा तक पहुंच को धीमा करने की कीमत पर।

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

मैंने एक परीक्षण तैयार किया ताकि आप अंतर देख सकें और उसका मूल्यांकन कर सकें।

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

अनुवादक से ध्यान दें

लेख में प्रदान किया गया कोड विचार प्रदर्शित करने का कार्य करता है और उत्पादन कोड का प्रतिनिधि नहीं है।