हमने C++ कोड की 10 मिलियन पंक्तियों का C++14 मानक (और फिर C++17) में अनुवाद कैसे किया?

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

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

• एप्लिकेशन सर्वर क्लस्टर, विंडोज़ और लिनक्स पर चलता है
• ग्राहक, http(s) या अपने स्वयं के बाइनरी प्रोटोकॉल के माध्यम से सर्वर के साथ काम करते हुए, विंडोज़, लिनक्स, मैकओएस पर काम करता है
• वेब क्लाइंट, क्रोम, इंटरनेट एक्सप्लोरर, माइक्रोसॉफ्ट एज, फायरफॉक्स, सफारी ब्राउज़र में चल रहा है (जावास्क्रिप्ट में लिखा हुआ)
• विकास पर्यावरण (कौन्फ़िगरेटर), विंडोज़, लिनक्स, मैकओएस पर काम करता है
• प्रशासन उपकरण एप्लिकेशन सर्वर, विंडोज़, लिनक्स, मैकओएस पर चलते हैं
• मोबाइल ग्राहक, http(s) के माध्यम से सर्वर से कनेक्ट होकर, Android, iOS, Windows चलाने वाले मोबाइल उपकरणों पर काम करता है
• मोबाइल प्लेटफॉर्म - एंड्रॉइड, आईओएस, विंडोज पर चलने वाले सिंक्रोनाइज़ करने की क्षमता वाले ऑफ़लाइन मोबाइल एप्लिकेशन बनाने के लिए एक रूपरेखा
• विकास पर्यावरण 1सी:उद्यम विकास उपकरण, जावा में लिखा गया है
• सेवक इंटरेक्शन सिस्टम

हम यथासंभव अलग-अलग ऑपरेटिंग सिस्टम के लिए एक ही कोड लिखने का प्रयास करते हैं - सर्वर कोड आधार 99% सामान्य है, क्लाइंट कोड आधार लगभग 95% है। 1C:एंटरप्राइज़ प्रौद्योगिकी प्लेटफ़ॉर्म मुख्य रूप से C++ में लिखा गया है और अनुमानित कोड विशेषताएँ नीचे दी गई हैं:

• C++ कोड की 10 मिलियन लाइनें,
• 14 हजार फ़ाइलें,
• 60 हजार कक्षाएं,
• आधे मिलियन तरीके।

और इन सभी चीज़ों का C++14 में अनुवाद करना पड़ा। आज हम आपको बताएंगे कि हमने यह कैसे किया और इस प्रक्रिया में हमें क्या-क्या झेलना पड़ा।

исклеймер

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

हमारे पास क्या था

प्रारंभ में, हमने Microsoft Visual Studio का उपयोग करके 1C:Enterprise 8 प्लेटफ़ॉर्म के लिए कोड लिखा था। यह परियोजना 2000 के दशक की शुरुआत में शुरू हुई थी और हमारे पास केवल विंडोज़ संस्करण था। स्वाभाविक रूप से, तब से कोड सक्रिय रूप से विकसित किया गया है, कई तंत्र पूरी तरह से फिर से लिखे गए हैं। लेकिन कोड 1998 मानक के अनुसार लिखा गया था, और, उदाहरण के लिए, हमारे समकोण कोष्ठक को रिक्त स्थान से अलग किया गया था ताकि संकलन सफल हो सके, इस तरह:

vector<vector<int> > IntV;

2006 में, प्लेटफ़ॉर्म संस्करण 8.1 की रिलीज़ के साथ, हमने लिनक्स का समर्थन करना शुरू किया और एक तृतीय-पक्ष मानक लाइब्रेरी पर स्विच किया। एसटीएलपोर्ट. परिवर्तन का एक कारण चौड़ी लाइनों के साथ काम करना था। हमारे कोड में, हम std::wstring का उपयोग करते हैं, जो कि wchar_t प्रकार पर आधारित है। विंडोज़ में इसका आकार 2 बाइट्स है, और लिनक्स में डिफ़ॉल्ट 4 बाइट्स है। इससे क्लाइंट और सर्वर के साथ-साथ विभिन्न लगातार डेटा के बीच हमारे बाइनरी प्रोटोकॉल की असंगति हो गई। जीसीसी विकल्पों का उपयोग करके, आप निर्दिष्ट कर सकते हैं कि संकलन के दौरान wchar_t का आकार भी 2 बाइट्स है, लेकिन फिर आप कंपाइलर से मानक लाइब्रेरी का उपयोग करने के बारे में भूल सकते हैं, क्योंकि यह glibc का उपयोग करता है, जिसे बदले में 4-बाइट wchar_t के लिए संकलित किया जाता है। अन्य कारणों में मानक कक्षाओं का बेहतर कार्यान्वयन, हैश तालिकाओं के लिए समर्थन और यहां तक ​​कि कंटेनरों के अंदर जाने के शब्दार्थ का अनुकरण भी शामिल था, जिसका हमने सक्रिय रूप से उपयोग किया। और एक और कारण, जैसा कि वे अंतिम लेकिन महत्वपूर्ण बात कहते हैं, स्ट्रिंग प्रदर्शन था। स्ट्रिंग्स के लिए हमारी अपनी कक्षा थी, क्योंकि... हमारे सॉफ़्टवेयर की विशिष्टताओं के कारण, स्ट्रिंग ऑपरेशंस का उपयोग बहुत व्यापक रूप से किया जाता है और हमारे लिए यह महत्वपूर्ण है।

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

हमारी लाइन में दो मुख्य अनुकूलन तकनीकों का उपयोग किया गया है:

1. छोटे मानों के लिए, स्ट्रिंग ऑब्जेक्ट में ही एक आंतरिक बफर का उपयोग किया जाता है (अतिरिक्त मेमोरी आवंटन की आवश्यकता नहीं होती है)।
2. अन्य सभी के लिए यांत्रिकी का उपयोग किया जाता है लिखने पर नकल. स्ट्रिंग मान को एक स्थान पर संग्रहीत किया जाता है, और असाइनमेंट/संशोधन के दौरान एक संदर्भ काउंटर का उपयोग किया जाता है।

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

तीसरा रास्ता

C++14 मानक की ओर बढ़ते समय, हमने निम्नलिखित विकल्पों पर विचार किया:

1. हमारे द्वारा संशोधित STLPort को C++14 मानक में अपग्रेड करें। विकल्प बहुत कठिन है, क्योंकि... एसटीएलपोर्ट के लिए समर्थन 2010 में बंद कर दिया गया था, और हमें इसके सभी कोड स्वयं बनाने होंगे।
2. C++14 के साथ संगत किसी अन्य STL कार्यान्वयन में संक्रमण। यह अत्यधिक वांछनीय है कि यह कार्यान्वयन विंडोज़ और लिनक्स के लिए हो।
3. प्रत्येक ओएस के लिए संकलन करते समय, संबंधित कंपाइलर में निर्मित लाइब्रेरी का उपयोग करें।

काम ज्यादा होने के कारण पहला विकल्प सिरे से खारिज कर दिया गया।

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

और हमने तीसरा रास्ता चुना.

संक्रमण

इसलिए, हमें STLPort के उपयोग को संबंधित कंपाइलरों की लाइब्रेरी (विंडोज के लिए विजुअल स्टूडियो 2015, लिनक्स के लिए जीसीसी 7, मैकओएस के लिए क्लैंग 8) से बदलना पड़ा।

सौभाग्य से, हमारा कोड मुख्य रूप से दिशानिर्देशों के अनुसार लिखा गया था और इसमें सभी प्रकार की चतुर युक्तियों का उपयोग नहीं किया गया था, इसलिए नए पुस्तकालयों में माइग्रेशन अपेक्षाकृत आसानी से आगे बढ़ गया, स्क्रिप्ट की मदद से, जिसने प्रकार, वर्ग, नामस्थान के नामों को बदल दिया और स्रोत में शामिल किया फ़ाइलें. माइग्रेशन ने 10 स्रोत फ़ाइलों (000 में से) को प्रभावित किया। wchar_t को char14_t द्वारा प्रतिस्थापित किया गया; हमने wchar_t का उपयोग छोड़ने का निर्णय लिया, क्योंकि char000_t सभी ओएस पर 16 बाइट्स लेता है और विंडोज़ और लिनक्स के बीच कोड संगतता को खराब नहीं करता है।

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

तो, कोड माइग्रेशन पूरा हो गया है, कोड सभी ऑपरेटिंग सिस्टम के लिए संकलित है। यह परीक्षण का समय है.

संक्रमण के बाद परीक्षणों में कोड के पुराने संस्करण की तुलना में प्रदर्शन में गिरावट (कुछ स्थानों पर 20-30% तक) और मेमोरी खपत में वृद्धि (10-15% तक) देखी गई। यह, विशेष रूप से, मानक स्ट्रिंग्स के उप-इष्टतम प्रदर्शन के कारण था। इसलिए, हमें फिर से अपनी खुद की, थोड़ी संशोधित लाइन का उपयोग करना पड़ा।

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

जैसा कि अक्सर बड़ी परियोजनाओं में बड़े पैमाने पर बदलाव के बाद होता है, स्रोत कोड का पहला पुनरावृत्ति समस्याओं के बिना काम नहीं करता था, और यहां, विशेष रूप से, विंडोज कार्यान्वयन में डिबगिंग इटरेटर के लिए समर्थन काम आया। कदम दर कदम हम आगे बढ़े और 2017 के वसंत तक (संस्करण 8.3.11 1सी:एंटरप्राइज) माइग्रेशन पूरा हो गया।

परिणाम

C++14 मानक में परिवर्तन में हमें लगभग 6 महीने लगे। अधिकांश समय, एक (लेकिन बहुत उच्च योग्य) डेवलपर ने परियोजना पर काम किया, और अंतिम चरण में विशिष्ट क्षेत्रों के लिए जिम्मेदार टीमों के प्रतिनिधि शामिल हुए - यूआई, सर्वर क्लस्टर, विकास और प्रशासन उपकरण, आदि।

इस परिवर्तन ने मानक के नवीनतम संस्करणों में माइग्रेट करने के हमारे काम को बहुत सरल बना दिया। इस प्रकार, संस्करण 1C:एंटरप्राइज़ 8.3.14 (विकास में, अगले वर्ष की शुरुआत में रिलीज़ होने वाला) पहले ही मानक में स्थानांतरित कर दिया गया है सी ++ 17.

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

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

मरहम में उड़ना

शायद प्रवासन का सबसे अप्रिय (लेकिन गंभीर नहीं) परिणाम यह है कि हमें मात्रा में वृद्धि का सामना करना पड़ता है ओबीजे फ़ाइलें, और सभी मध्यवर्ती फ़ाइलों के साथ निर्माण का पूरा परिणाम 60-70 जीबी तक लगने लगा। यह व्यवहार आधुनिक मानक पुस्तकालयों की विशिष्टताओं के कारण है, जो उत्पन्न सेवा फ़ाइलों के आकार के प्रति कम महत्वपूर्ण हो गए हैं। यह संकलित एप्लिकेशन के संचालन को प्रभावित नहीं करता है, लेकिन यह विकास में कई असुविधाओं का कारण बनता है, विशेष रूप से, यह संकलन समय को बढ़ाता है। बिल्ड सर्वर और डेवलपर मशीनों पर मुफ्त डिस्क स्थान की आवश्यकताएं भी बढ़ रही हैं। हमारे डेवलपर प्लेटफ़ॉर्म के कई संस्करणों पर समानांतर में काम करते हैं, और सैकड़ों गीगाबाइट मध्यवर्ती फ़ाइलें कभी-कभी उनके काम में कठिनाइयाँ पैदा करती हैं। समस्या अप्रिय है, लेकिन गंभीर नहीं, हमने इसका समाधान फिलहाल टाल दिया है. हम इसके समाधान के लिए प्रौद्योगिकी पर एक विकल्प के रूप में विचार कर रहे हैं।' एकता निर्माण (विशेष रूप से, Google Chrome ब्राउज़र विकसित करते समय इसका उपयोग करता है)।

स्रोत: www.habr.com