आम्ही C++ कोडच्या 10 दशलक्ष ओळींचे C++ 14 मानक (आणि नंतर C++17) मध्ये कसे भाषांतर केले

काही काळापूर्वी (2016 च्या शरद ऋतूत), 1C: एंटरप्राइज तंत्रज्ञान प्लॅटफॉर्मच्या पुढील आवृत्तीच्या विकासादरम्यान, नवीन मानकांना समर्थन देण्याबद्दल विकास कार्यसंघामध्ये प्रश्न उद्भवला. सी ++ 14 आमच्या कोडमध्ये. आम्ही गृहीत धरल्याप्रमाणे नवीन मानकात संक्रमण केल्याने आम्हाला बऱ्याच गोष्टी अधिक सुरेख, सोप्या आणि विश्वासार्हपणे लिहिण्याची परवानगी मिळेल आणि कोडचे समर्थन आणि देखभाल सुलभ होईल. आणि कोड बेसच्या स्केलसाठी आणि आमच्या कोडच्या विशिष्ट वैशिष्ट्यांसाठी नसल्यास अनुवादामध्ये असाधारण काहीही नाही असे दिसते.

ज्यांना माहित नाही त्यांच्यासाठी, 1C:Enterprise हे क्रॉस-प्लॅटफॉर्म बिझनेस ऍप्लिकेशन्सच्या जलद विकासासाठी आणि वेगवेगळ्या OS आणि DBMS वर त्यांच्या अंमलबजावणीसाठी रनटाइमसाठी एक वातावरण आहे. सर्वसाधारणपणे, उत्पादनामध्ये हे समाविष्ट आहे:

• ऍप्लिकेशन सर्व्हर क्लस्टर, Windows आणि Linux वर चालते
• ग्राहक, HTTP(s) किंवा स्वतःच्या बायनरी प्रोटोकॉलद्वारे सर्व्हरसह कार्य करणे, Windows, Linux, macOS वर कार्य करते
• वेब क्लायंट, क्रोम, इंटरनेट एक्सप्लोरर, मायक्रोसॉफ्ट एज, फायरफॉक्स, सफारी ब्राउझर (जावास्क्रिप्टमध्ये लिहिलेले) मध्ये चालत आहे
• विकासाचे वातावरण (कॉन्फिगरेटर), Windows, Linux, macOS वर कार्य करते
• प्रशासन साधने ऍप्लिकेशन सर्व्हर, Windows, Linux, macOS वर चालतात
• मोबाइल क्लायंट, HTTP(s) द्वारे सर्व्हरशी कनेक्ट करणे, Android, iOS, Windows चालवणाऱ्या मोबाइल डिव्हाइसवर कार्य करते
• मोबाइल प्लॅटफॉर्म — Android, iOS, Windows वर सिंक्रोनाइझ करण्याच्या क्षमतेसह ऑफलाइन मोबाइल अनुप्रयोग तयार करण्यासाठी फ्रेमवर्क
• विकासाचे वातावरण 1C: एंटरप्राइज डेव्हलपमेंट टूल्स, Java मध्ये लिहिलेले
• Сервер परस्परसंवाद प्रणाली

आम्ही शक्य तितक्या वेगवेगळ्या ऑपरेटिंग सिस्टमसाठी समान कोड लिहिण्याचा प्रयत्न करतो - सर्व्हर कोड बेस 99% सामान्य आहे, क्लायंट कोड बेस सुमारे 95% आहे. 1C: एंटरप्राइज तंत्रज्ञान प्लॅटफॉर्म प्रामुख्याने C++ मध्ये लिहिलेले आहे आणि अंदाजे कोड वैशिष्ट्ये खाली दिली आहेत:

• C++ कोडच्या 10 दशलक्ष ओळी,
• 14 हजार फाइल्स,
• 60 हजार वर्ग,
• अर्धा दशलक्ष पद्धती.

आणि या सर्व गोष्टींचे C++14 मध्ये भाषांतर करावे लागले. आज आम्ही तुम्हाला सांगू की आम्ही हे कसे केले आणि प्रक्रियेत आम्हाला काय आले.

अस्वीकरण

धीमे/जलद कामाबद्दल खाली लिहिलेल्या सर्व गोष्टी, (नाही) विविध लायब्ररींमधील मानक वर्गांच्या अंमलबजावणीद्वारे मोठ्या मेमरी वापराचा अर्थ एक गोष्ट आहे: हे यूएससाठी खरे आहे. हे शक्य आहे की मानक अंमलबजावणी आपल्या कार्यांसाठी सर्वात योग्य असेल. आम्ही आमच्या स्वतःच्या कार्यांपासून सुरुवात केली: आम्ही आमच्या क्लायंटसाठी वैशिष्ट्यपूर्ण डेटा घेतला, त्यांच्यावर विशिष्ट परिस्थिती पाहिली, कार्यप्रदर्शन, वापरलेल्या मेमरीचे प्रमाण इत्यादी पाहिले आणि आम्ही आणि आमचे क्लायंट अशा परिणामांवर समाधानी आहोत की नाही याचे विश्लेषण केले. . आणि त्यांनी यावर अवलंबून अभिनय केला.

आमच्याकडे जे होते

सुरुवातीला, आम्ही मायक्रोसॉफ्ट व्हिज्युअल स्टुडिओमध्ये 1C:एंटरप्राइज 8 प्लॅटफॉर्मसाठी कोड लिहिला. प्रकल्पाची सुरुवात 2000 च्या दशकाच्या सुरुवातीस झाली आणि आमच्याकडे फक्त विंडोजची आवृत्ती होती. स्वाभाविकच, तेव्हापासून कोड सक्रियपणे विकसित केला गेला आहे, अनेक यंत्रणा पूर्णपणे पुन्हा लिहिल्या गेल्या आहेत. परंतु कोड 1998 च्या मानकानुसार लिहिला गेला होता, आणि उदाहरणार्थ, आमचे काटकोन कंस स्पेसद्वारे वेगळे केले गेले होते जेणेकरून संकलन यशस्वी होईल, याप्रमाणे:

vector<vector<int> > IntV;

2006 मध्ये, प्लॅटफॉर्म आवृत्ती 8.1 च्या रिलीझसह, आम्ही लिनक्सला समर्थन देण्यास सुरुवात केली आणि तृतीय-पक्ष मानक लायब्ररीवर स्विच केले. एसटीएलपोर्ट. संक्रमणाचे एक कारण म्हणजे रुंद रेषांसह काम करणे. आमच्या कोडमध्ये, आम्ही std::wstring वापरतो, जे wchar_t प्रकारावर आधारित आहे, संपूर्ण. विंडोजमध्ये त्याचा आकार 2 बाइट्स आहे आणि लिनक्समध्ये डीफॉल्ट 4 बाइट्स आहे. यामुळे क्लायंट आणि सर्व्हरमधील आमच्या बायनरी प्रोटोकॉलची विसंगतता, तसेच विविध पर्सिस्टंट डेटा निर्माण झाला. gcc पर्यायांचा वापर करून, आपण निर्दिष्ट करू शकता की संकलनादरम्यान wchar_t चा आकार देखील 2 बाइट्स आहे, परंतु नंतर आपण कंपाइलरमधून मानक लायब्ररी वापरणे विसरू शकता, कारण ते glibc वापरते, जे 4-बाइट wchar_t साठी संकलित केले जाते. इतर कारणे म्हणजे मानक वर्गांची चांगली अंमलबजावणी, हॅश टेबलसाठी समर्थन आणि कंटेनरच्या आत हलवण्याच्या शब्दार्थांचे अनुकरण करणे, जे आम्ही सक्रियपणे वापरले. आणि आणखी एक कारण, जसे ते शेवटचे म्हणतात परंतु किमान नाही, ते म्हणजे स्ट्रिंग कामगिरी. स्ट्रिंगसाठी आमचा स्वतःचा वर्ग होता, कारण... आमच्या सॉफ्टवेअरच्या वैशिष्ट्यांमुळे, स्ट्रिंग ऑपरेशन्स मोठ्या प्रमाणावर वापरले जातात आणि आमच्यासाठी हे गंभीर आहे.

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

आमच्या ओळीने दोन मुख्य ऑप्टिमायझेशन तंत्रज्ञान वापरले:

1. लहान मूल्यांसाठी, स्ट्रिंग ऑब्जेक्टमधील अंतर्गत बफर वापरला जातो (अतिरिक्त मेमरी वाटप आवश्यक नाही).
2. इतर सर्वांसाठी, यांत्रिकी वापरली जातात कॉपी ऑन राइट. स्ट्रिंग मूल्य एकाच ठिकाणी साठवले जाते आणि असाइनमेंट/फेरफार करताना संदर्भ काउंटर वापरला जातो.

प्लॅटफॉर्म संकलनाला गती देण्यासाठी, आम्ही आमच्या STLPport प्रकारातून प्रवाह अंमलबजावणी वगळली (जे आम्ही वापरले नाही), यामुळे आम्हाला सुमारे 20% जलद संकलन मिळाले. त्यानंतर आम्हाला मर्यादित वापर करावा लागला बूस्ट. बूस्ट स्ट्रीमचा प्रचंड वापर करते, विशेषत: त्याच्या सेवा API मध्ये (उदाहरणार्थ, लॉगिंगसाठी), त्यामुळे आम्हाला प्रवाहाचा वापर काढून टाकण्यासाठी त्यात सुधारणा करावी लागली. यामुळे, आम्हाला बूस्टच्या नवीन आवृत्त्यांमध्ये स्थलांतरित करणे कठीण झाले.

तिसरा मार्ग

C++14 मानकाकडे जाताना, आम्ही खालील पर्यायांचा विचार केला:

1. आम्ही सुधारित केलेला STLPport C++14 मानकांमध्ये श्रेणीसुधारित करा. पर्याय खूप कठीण आहे, कारण... STLPport साठी समर्थन 2010 मध्ये बंद करण्यात आले होते आणि आम्हाला त्याचे सर्व कोड स्वतः तयार करावे लागतील.
2. C++14 सह सुसंगत दुसऱ्या STL अंमलबजावणीमध्ये संक्रमण. ही अंमलबजावणी Windows आणि Linux साठी असणे अत्यंत इष्ट आहे.
3. प्रत्येक OS साठी संकलित करताना, संबंधित कंपाइलरमध्ये तयार केलेली लायब्ररी वापरा.

खूप काम केल्यामुळे पहिला पर्याय पूर्णपणे नाकारण्यात आला.

आम्ही काही काळ दुसऱ्या पर्यायाचा विचार केला; उमेदवार म्हणून मानले जाते libc++, परंतु त्यावेळी ते Windows अंतर्गत कार्य करत नव्हते. विंडोजमध्ये libc++ पोर्ट करण्यासाठी, तुम्हाला खूप काम करावे लागेल - उदाहरणार्थ, थ्रेड्स, थ्रेड सिंक्रोनाइझेशन आणि अणुशक्तीशी संबंधित सर्वकाही स्वतः लिहा, कारण या भागात libc++ वापरला जातो. POSIX API.

आणि आम्ही तिसरा मार्ग निवडला.

संक्रमण

म्हणून, आम्हाला STLPport चा वापर संबंधित कंपाइलरच्या लायब्ररीसह बदलावा लागला (विंडोजसाठी व्हिज्युअल स्टुडिओ 2015, लिनक्ससाठी gcc 7, macOS साठी clang 8).

सुदैवाने, आमचा कोड मुख्यत: मार्गदर्शक तत्त्वांनुसार लिहिला गेला होता आणि सर्व प्रकारच्या चतुर युक्त्या वापरल्या गेल्या नाहीत, म्हणून नवीन लायब्ररींचे स्थलांतर तुलनेने सहजतेने झाले, स्क्रिप्टच्या सहाय्याने, ज्याने प्रकार, वर्ग, नेमस्पेस आणि स्त्रोतामध्ये समाविष्ट असलेली नावे बदलली. फाइल्स स्थलांतरामुळे 10 स्त्रोत फायलींवर परिणाम झाला (000 पैकी). wchar_t ची जागा char14_t ने घेतली; आम्ही wchar_t चा वापर सोडून देण्याचा निर्णय घेतला, कारण char000_t सर्व OS वर 16 बाइट्स घेते आणि विंडोज आणि लिनक्समधील कोड सुसंगतता खराब करत नाही.

काही छोटे साहस होते. उदाहरणार्थ, STLPport मध्ये एक पुनरावृत्ती करणारा घटकाच्या पॉइंटरवर स्पष्टपणे कास्ट केला जाऊ शकतो आणि आमच्या कोडमध्ये काही ठिकाणी हे वापरले गेले. नवीन लायब्ररींमध्ये हे करणे आता शक्य नव्हते आणि या परिच्छेदांचे विश्लेषण करून ते व्यक्तिचलितपणे पुन्हा लिहावे लागले.

तर, कोड स्थलांतर पूर्ण झाले आहे, कोड सर्व ऑपरेटिंग सिस्टमसाठी संकलित केला आहे. चाचण्यांची वेळ आली आहे.

संक्रमणानंतरच्या चाचण्यांमध्ये कोडच्या जुन्या आवृत्तीच्या तुलनेत कामगिरीत घट (काही ठिकाणी 20-30% पर्यंत) आणि मेमरी वापरामध्ये (10-15% पर्यंत) वाढ दिसून आली. हे, विशेषतः, मानक स्ट्रिंगच्या सबऑप्टिमल कामगिरीमुळे होते. म्हणून, आम्हाला पुन्हा आमची स्वतःची, थोडी सुधारित ओळ वापरावी लागली.

एम्बेडेड लायब्ररीमध्ये कंटेनरच्या अंमलबजावणीचे एक मनोरंजक वैशिष्ट्य देखील उघड झाले: रिक्त (घटकांशिवाय) std::map आणि std:: बिल्ट-इन लायब्ररीमधून सेट मेमरी वाटप. आणि अंमलबजावणीच्या वैशिष्ट्यांमुळे, कोडमध्ये काही ठिकाणी या प्रकारचे बरेच रिकामे कंटेनर तयार केले जातात. एका मूळ घटकासाठी मानक मेमरी कंटेनर थोडेसे वाटप केले जातात, परंतु आमच्यासाठी हे गंभीर ठरले - अनेक परिस्थितींमध्ये, आमची कामगिरी लक्षणीयरीत्या कमी झाली आणि मेमरी वापर वाढला (STLPport च्या तुलनेत). म्हणून, आमच्या कोडमध्ये आम्ही या दोन प्रकारचे कंटेनर्स बिल्ट-इन लायब्ररीमधून त्यांच्या बूस्टच्या अंमलबजावणीसह बदलले, जेथे या कंटेनरमध्ये हे वैशिष्ट्य नव्हते आणि यामुळे मंदी आणि मेमरी वापर वाढण्याची समस्या सोडवली.

जसे की मोठ्या प्रकल्पांमध्ये मोठ्या प्रमाणात बदल झाल्यानंतर, स्त्रोत कोडची पहिली पुनरावृत्ती समस्यांशिवाय कार्य करत नाही आणि येथे, विशेषतः, विंडोज अंमलबजावणीमध्ये डीबगिंग पुनरावृत्तीसाठी समर्थन उपयुक्त ठरले. टप्प्याटप्प्याने आम्ही पुढे गेलो आणि 2017 च्या वसंत ऋतुपर्यंत (आवृत्ती 8.3.11 1C:Enterprise) स्थलांतर पूर्ण झाले.

परिणाम

C++ 14 मानकात संक्रमण होण्यासाठी आम्हाला सुमारे 6 महिने लागले. बहुतेक वेळा, एक (परंतु अत्यंत पात्र) विकासकाने प्रकल्पावर काम केले आणि अंतिम टप्प्यावर विशिष्ट क्षेत्रांसाठी जबाबदार असलेल्या संघांचे प्रतिनिधी सामील झाले - UI, सर्व्हर क्लस्टर, विकास आणि प्रशासन साधने इ.

संक्रमणाने मानकांच्या नवीनतम आवृत्त्यांकडे स्थलांतरित करण्याचे आमचे कार्य मोठ्या प्रमाणात सुलभ केले. अशाप्रकारे, आवृत्ती 1C:एंटरप्राइझ 8.3.14 (विकासात, पुढील वर्षाच्या सुरुवातीला रिलीज होणार) आधीच मानकांकडे हस्तांतरित केले गेले आहे. C++17.

स्थलांतरानंतर, विकासकांकडे अधिक पर्याय आहेत. जर पूर्वी आमच्याकडे STL ची स्वतःची सुधारित आवृत्ती आणि एक std नेमस्पेस असेल, तर आता आमच्याकडे std नेमस्पेसमध्ये, stdx नेमस्पेसमध्ये अंगभूत कंपायलर लायब्ररीचे मानक वर्ग आहेत - आमच्या कार्यांसाठी ऑप्टिमाइझ केलेल्या आमच्या लाइन आणि कंटेनर, बूस्टमध्ये - बूस्टची नवीनतम आवृत्ती. आणि विकसक अशा वर्गांचा वापर करतो जे त्याच्या समस्यांचे निराकरण करण्यासाठी सर्वात योग्य आहेत.

मूव्ह कन्स्ट्रक्टरची "नेटिव्ह" अंमलबजावणी देखील विकासास मदत करते (कन्स्ट्रक्टर हलवा) अनेक वर्गांसाठी. जर क्लासमध्ये मूव्ह कन्स्ट्रक्टर असेल आणि हा वर्ग कंटेनरमध्ये ठेवला असेल, तर STL कंटेनरमधील घटकांची कॉपी ऑप्टिमाइझ करते (उदाहरणार्थ, जेव्हा कंटेनरचा विस्तार केला जातो आणि क्षमता बदलणे आणि मेमरी पुनर्स्थित करणे आवश्यक असते).

मलम मध्ये उडणे

स्थलांतराचा कदाचित सर्वात अप्रिय (परंतु गंभीर नाही) परिणाम म्हणजे आपल्याला व्हॉल्यूममध्ये वाढ होण्याचा सामना करावा लागतो. obj फाइल्स, आणि सर्व इंटरमीडिएट फाइल्ससह बिल्डचा पूर्ण परिणाम 60-70 GB घेऊ लागला. हे वर्तन आधुनिक मानक लायब्ररींच्या वैशिष्ट्यांमुळे आहे, जे व्युत्पन्न केलेल्या सेवा फायलींच्या आकारासाठी कमी गंभीर झाले आहेत. हे संकलित केलेल्या ऍप्लिकेशनच्या ऑपरेशनवर परिणाम करत नाही, परंतु यामुळे विकासामध्ये अनेक गैरसोयी होतात, विशेषतः, ते संकलन वेळ वाढवते. बिल्ड सर्व्हर आणि डेव्हलपर मशिन्सवरील मोकळ्या डिस्क स्पेसची आवश्यकता देखील वाढत आहे. आमचे डेव्हलपर समांतरपणे प्लॅटफॉर्मच्या अनेक आवृत्त्यांवर कार्य करतात आणि शेकडो गीगाबाइट्स इंटरमीडिएट फाइल्स कधीकधी त्यांच्या कामात अडचणी निर्माण करतात. समस्या अप्रिय आहे, परंतु गंभीर नाही; आम्ही त्याचे निराकरण आत्तासाठी पुढे ढकलले आहे. ते सोडवण्यासाठी आम्ही तंत्रज्ञानाचा एक पर्याय म्हणून विचार करत आहोत एकता निर्माण (विशेषतः, Google Chrome ब्राउझर विकसित करताना ते वापरते).

स्त्रोत: www.habr.com