हमें एक साधारण कोल्हू में C ++ 20 से लेकर रेंज की आवश्यकता क्यों है?

हाल ही में, सी ++ 20 मानक में शामिल की जाने वाली श्रेणियों पर काफी चर्चा की गई है, जिसमें हैबे ( एक उदाहरण जहां कई उदाहरण हैं ) शामिल हैं। अंतराल के पर्याप्त आलोचक हैं, वे कहते हैं कि

• वे बहुत सार हैं और केवल बहुत सार कोड की जरूरत है
• उनके साथ कोड की पठनीयता केवल बिगड़ती है
• अंतराल कोड धीमा

पूरी तरह से देखते हैं मजदूरों और किसानों व्यावहारिक कार्य, यह समझने के लिए कि क्या यह आलोचना वैध है और क्या यह सच है कि एरिक निबलर को बार्टोज़ मिल्स्की द्वारा काट लिया गया था और वह केवल पूर्णिमा के साथ रेंज-वी 3 लिखता है ।

हम ट्रेपेज़ॉइड विधि का उपयोग करके निम्नलिखित फ़ंक्शन को एकीकृत करेंगे:$$ $ इनलाइन $ f (t) = 3 t ^ 2 \ sin t ^ 3 $ इनलाइन $ शून्य से लेकर$$ $ इनलाइन $ \ tau $ इनलाइन $ । अगर$$ $ इनलाइन $ \ tau ^ 3 / \ pi $ इनलाइन $ एक विषम संख्या के बराबर है, तो अभिन्न 2 है।

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

एक इंटीग्रेटर फ़ंक्शन के पास क्या तर्क होना चाहिए? इंटेग्रैबल फ़ंक्शन और ग्रिड (बिंदुओं का सेट)$$ $ इनलाइन $ t_1, t_2, t_3 ... $ इनलाइन $ अभिन्न गणना करने के लिए उपयोग किया जाता है)। और अगर एकीकृत फ़ंक्शन ( std::function यहीं होगा) के साथ सब कुछ स्पष्ट है, तो ग्रिड को किस रूप में प्रेषित किया जाना चाहिए? आइए देखते हैं।

विकल्प

के साथ शुरू करने के लिए - ताकि प्रदर्शन के साथ तुलना करने के लिए कुछ हो - हम एक निरंतर समय कदम के साथ लूप के for एक सरल लिखेंगे:

 // trapezoidal rule of integration with fixed time step; // dt_fixed is the timestep; n_fixed is the number of steps double integrate() { double acc = 0; for(long long i = 1; i < n_fixed - 1; ++i) { double t = dt_fixed * static_cast<double>(i); acc += dt_fixed * f(t); } acc += 0.5 * dt_fixed * f(0); acc += 0.5 * dt_fixed * f(tau); return acc; } 

इस चक्र का उपयोग करते समय, आप फ़ंक्शन को एकीकरण अंतराल की शुरुआत और अंत में और साथ ही साथ इस एकीकरण के लिए अंकों की संख्या को पारित कर सकते हैं। स्टॉप - ट्रेपेज़ॉइड विधि एक चर चरण के साथ भी होती है, और हमारा पूर्णांक फ़ंक्शन केवल चर चरण का उपयोग करने के लिए कहता है! तो यह है, हमें एक और पैरामीटर है ($$ $ इनलाइन $ b $ इनलाइन $ ) "अस्वच्छता" को नियंत्रित करने के लिए और हमारे कदमों को, उदाहरण के लिए, इस प्रकार है:$$ $ इनलाइन $ \ Delta t (t) = \ Delta t_0 + bt $ इनलाइन $ । यह दृष्टिकोण (एक अतिरिक्त संख्यात्मक पैरामीटर परिचय) शायद एक लाख स्थानों में उपयोग किया जाता है, हालांकि, ऐसा प्रतीत होता है, इसका दोष सभी के लिए स्पष्ट होना चाहिए। और अगर हमारे पास एक अलग कार्य है? और अगर हमें अपने संख्यात्मक अंतराल के बीच में कहीं एक छोटे से कदम की आवश्यकता है? लेकिन क्या होगा अगर एक पूर्णांक फ़ंक्शन में कुछ विशेषताएं हों? सामान्य तौर पर, हमें किसी भी ग्रिड को व्यक्त करने में सक्षम होना चाहिए। (फिर भी, उदाहरणों में, बहुत अंत तक, हम वास्तविक ट्रेपोज़ॉइड विधि के बारे में "भूल जाएंगे" और सादगी के लिए हम एक निरंतर कदम के साथ इसके संस्करण पर विचार करेंगे, यह ध्यान में रखते हुए कि ग्रिड मनमाना हो सकता है)।

चूँकि ग्रिड कोई भी हो सकता है, उसके मानों को पास करते हैं$$ $ इनलाइन $ t_1, t_2, ... $ इनलाइन $ std::vector में लिपटे std::vector ।

 // trapezoidal rule of integration with fixed time step double integrate(vector<double> t_nodes) { double acc = 0; for(auto t: t_nodes) { acc += dt_fixed * f(t); } acc -= 0.5 * dt_fixed * f(0); acc -= 0.5 * dt_fixed * f(tau); return acc; } 

इस दृष्टिकोण में पर्याप्त से अधिक समुदाय हैं, लेकिन प्रदर्शन के बारे में क्या? मेमोरी खपत के साथ? यदि पहले सब कुछ प्रोसेसर पर संक्षेपित किया गया था, तो अब हमें पहले मेमोरी क्षेत्र को भरना है, और फिर इसे पढ़ना है। और स्मृति के साथ संचार एक बहुत धीमी चीज है। और स्मृति अभी भी रबर नहीं है ( और सिलिकॉन )।

आइए समस्या की जड़ को देखें। एक व्यक्ति को खुश रहने के लिए क्या आवश्यक है? अधिक सटीक रूप से, हमारे चक्र (लूप के लिए रेंज-आधारित) की क्या आवश्यकता है? begin() और end() चलने वालों, और ++ , * और != पुनरावृत्तियों के लिए कोई भी कंटेनर। तो हम लिखेंगे।

 //   ,    ,      template <typename T> double integrate(T t_nodes) { double acc = 0; for(auto t: t_nodes) { acc += dt_fixed * f(t); } acc -= 0.5 * dt_fixed * f(0); acc -= 0.5 * dt_fixed * f(tau); return acc; } // ... //      class lazy_container { public: long long int n_nodes; lazy_container() { n_nodes = n_fixed; } ~lazy_container() {} class iterator { public: long long int i; // index of the current node iterator() { i = 0; } ~iterator() {} iterator& operator++() { i+= 1; return *this; } // ! bool operator!=(const iterator& rhs) const { return i != rhs.i; } double operator* () const { return dt_fixed * static_cast<double>(i); } }; iterator begin() { return iterator(); } iterator end() { iterator it; it.i = n_nodes; return it; } }; // ... //      lazy_container t_nodes; double res = integrate(t_nodes); 

हम यहां एक नए मान की गणना कर रहे हैं।$$ $ इनलाइन $ t_i $ इनलाइन $ मांग पर, जैसा कि हमने लूप के for एक सरल में किया था। कोई मेमोरी एक्सेस नहीं है, और यह आशा की जाती है कि आधुनिक संकलक कोड को बहुत कुशलता से सरल करेंगे। उसी समय, एकीकृत फ़ंक्शन का कोड बहुत अधिक नहीं बदला है, और यह अभी भी std::vector पचा सकता है।

लचीलापन कहां है? वास्तव में, अब हम ++ ऑपरेटर में कोई भी फ़ंक्शन लिख सकते हैं। यही है, यह दृष्टिकोण, वास्तव में, एक एकल संख्यात्मक पैरामीटर के बजाय एक फ़ंक्शन को स्थानांतरित करने की अनुमति देता है। मक्खी पर उत्पन्न ग्रिड कोई भी हो सकता है, और हम भी (शायद) प्रदर्शन नहीं खोते हैं। हालाँकि, किसी भी तरह से किसी भी तरह से ग्रिड को विकृत करने के लिए हर बार एक नया lazy_container लिखने के लिए बिल्कुल भी ऐसा महसूस नहीं होता है (यह वही 27 लाइनें हैं!)। बेशक, आप ग्रिड को हमारे एकीकृत फ़ंक्शन के एक पैरामीटर को उत्पन्न करने के लिए फ़ंक्शन को जिम्मेदार बना सकते हैं, और lazy_container भी lazy_container हैं, अर्थात, मुझे बहाना, इसे lazy_container करें।

आप पूछते हैं - तो फिर कुछ गलत होगा? हाँ! सबसे पहले, एकीकरण के लिए अंकों की संख्या को अलग-अलग प्रेषित करना आवश्यक होगा, जिससे त्रुटि हो सकती है। दूसरे, बनाई गई गैर-मानक साइकिल को किसी के द्वारा समर्थित और संभवतः विकसित करना होगा। उदाहरण के लिए, क्या आप तुरंत सोच सकते हैं कि कैसे, इस दृष्टिकोण के साथ, ++ ऑपरेटर में कार्यों के लिए एक संयोजन रचना करने के लिए?

30 से अधिक वर्षों के लिए सी ++। इस उम्र में कई के पास पहले से ही बच्चे हैं, और सी ++ में मानक आलसी कंटेनर / पुनरावृत्त भी नहीं हैं। एक बुरा सपना! लेकिन सब कुछ (पुनरावृत्तियों के अर्थ में, बच्चे नहीं) अगले साल की शुरुआत में बदल जाएंगे - मानक (संभवतः आंशिक रूप से) में रेंज-वी 3 पुस्तकालय शामिल होगा, जिसे कई वर्षों से एरिक निबलर द्वारा विकसित किया गया है। हम इसके फलों के कार्यों का उपयोग करेंगे। कोड यह सब अपने लिए कहता है:

 #include <range/v3/view/iota.hpp> #include <range/v3/view/transform.hpp> //... auto t_nodes = ranges::v3::iota_view(0, n_fixed) | ranges::v3::views::transform( [](long long i){ return dt_fixed * static_cast<double>(i); } ); double res = integrate(t_nodes); 

एकीकृत कार्य समान रहता है। यानी हमारी समस्या को हल करने के लिए केवल 3 लाइनें! यहाँ iota_view(0, n) एक आलसी अंतराल (रेंज, एक ऐसी वस्तु उत्पन्न करता है जो सामान्य रूप से शुरू और समाप्त होता है, एक आलसी रेंज एक दृश्य है), जो, जब प्रत्येक चरण पर पुनरावृत्ति करता है, तो रेंज में अगले नंबर की गणना करता है [0, n)। यह मजेदार है कि नाम ι (ग्रीक अक्षर iota) 50 साल पहले APL भाषा को संदर्भित करता है । छड़ी | आपको अंतराल संशोधक की पाइपलाइनों को लिखने की अनुमति देता है, और transform , वास्तव में, ऐसा एक संशोधक है जो एक साधारण लंबो फ़ंक्शन का उपयोग करके, श्रृंखला में पूर्णांकों के अनुक्रम को बदल देता है।$$ $ इनलाइन $ t_1, t_2, ... $ इनलाइन $ । सब कुछ सरल है, जैसे कि एक परी कथा हास्केल।

लेकिन एक चर चरण कैसे बनाया जाए? सब कुछ सरल है:

 #include <range/v3/view/drop.hpp> #include <range/v3/view/iota.hpp> #include <range/v3/view/transform.hpp> //... // trapezoidal rule of integration; step size is not fixed template <typename T> double integrate(T t_nodes) { double acc = 0; double t_prev = *(t_nodes.begin()); double f_prev = f(t_prev); for (auto t: t_nodes | ranges::v3::views::drop(1)) { double f_curr = f(t); acc += 0.5 * (t - t_prev) * (f_curr + f_prev); t_prev = t; f_prev = f_curr; } return acc; } //... auto step_f = [](long long i) { if (static_cast<double>(i) <= 1 / a) { return pow(2 * M_PI, 1/3.0) * a * static_cast<double>(i); } else { return tau * pow(static_cast<double>(i) / static_cast<double>(n), 1/3.0); } }; auto t_nodes = ranges::v3::iota_view(0, n) | ranges::v3::views::transform(step_f); double res = integrate(t_nodes); 

एक चौकस पाठक ने उल्लेख किया कि हमारे उदाहरण में, चर चरण ने हमें तीन के एक कारक द्वारा ग्रिड बिंदुओं की संख्या को कम करने की अनुमति दी, जबकि इसके अलावा, कंप्यूटिंग के लिए ध्यान देने योग्य व्यय हैं$$ $ इनलाइन $ t_i $ इनलाइन $ । लेकिन अगर हम दूसरा लें$$ $ इनलाइन $ f (t) $ इनलाइन $ अंकों की संख्या बहुत अधिक बदल सकती है ... (लेकिन यहां लेखक पहले से ही आलसी होता जा रहा है)।

इतना समय

हमारे पास निम्नलिखित विकल्प हैं:

• v1 - सरल लूप
• v2 -$$ $ इनलाइन $ t_i $ इनलाइन $ std::vector में झूठ std::vector
• v3 - lazy_container साथ lazy_container
• v4 - C ++ 20 (रेंज) से अंतराल
• v5 - फिर से चलता है, लेकिन केवल यहाँ चर विधि एक चर पिच का उपयोग करते हुए लिखा गया है

यहाँ यह क्या है (सेकंड में) के लिए$$ $ इनलाइन $ \ tau = (10 \, 000 \, 001 \ गुना \ pi) ^ {1/3} $ इनलाइन $ के लिए, जीई ++ 8.3.0 और इंटेल® Xeon® CPU® X5550 पर क्लेंग 8.0.0 के बारे में (चरणों की संख्या)$$ $ इनलाइन $ 1.5 \ गुना 10 ^ 8 $ इनलाइन $ , v5 को छोड़कर, जहां चरण तीन गुना कम हैं (सभी तरीकों से गणना का परिणाम दो से भिन्न होता है 0.07 से अधिक नहीं):

सामान्य तौर पर, मक्खी पूरे क्षेत्र में चली गई, मक्खी को एक सिक्का मिला!

परिणाम

यहां तक ​​कि एक बहुत ही सरल कार्य में, रेंज बहुत उपयोगी निकलीं: 20+ लाइनों पर स्व-निर्मित पुनरावृत्तियों के साथ कोड के बजाय, हमने 3 पंक्तियों को लिखा, जबकि कोड की पठनीयता या इसके प्रदर्शन के साथ कोई समस्या नहीं थी।

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

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

मैं समोवर खरीदने बाजार गया था।

उपयोगी लिंक

रेंज- v3 घर

प्रलेखन और केस स्टडीज v3

इस लेख से github पर कोड

तुलना के लिए हैसेल में सूची

धन्यवाद

यह सब लिखने में मदद करने के लिए धन्यवाद!

पुनश्च

मुझे आशा है कि कोई व्यक्ति ऐसी विषमताओं पर टिप्पणी करता है: i) यदि आप एकीकरण अंतराल को 10 गुना छोटा लेते हैं, तो मेरे Xeon पर v2 उदाहरण v1 की तुलना में 10% तेज है, और v4 v1 की तुलना में तीन गुना तेज है। ii) कभी-कभी इंटेल कंपाइलर (icc 2019) इन उदाहरणों में कोड बनाता है जो संकलित g ++ की तुलना में दोगुना है। क्या वैश्वीकरण को दोष देना है? क्या जी ++ को भी ऐसा करने के लिए मजबूर किया जा सकता है?