சி++10 தரநிலைக்கு (பின்னர் C++14க்கு) 17 மில்லியன் வரிகள் C++ குறியீட்டை எவ்வாறு மொழிபெயர்த்தோம்

சில காலத்திற்கு முன்பு (2016 இலையுதிர்காலத்தில்), 1C இன் அடுத்த பதிப்பின் வளர்ச்சியின் போது: எண்டர்பிரைஸ் தொழில்நுட்ப தளம், புதிய தரநிலையை ஆதரிப்பது குறித்து மேம்பாட்டுக் குழுவிற்குள் கேள்வி எழுந்தது. சி ++ 14 எங்கள் குறியீட்டில். ஒரு புதிய தரநிலைக்கு மாறுவது, நாங்கள் கருதியபடி, பல விஷயங்களை இன்னும் நேர்த்தியாகவும் எளிமையாகவும் நம்பகத்தன்மையுடனும் எழுத அனுமதிக்கும், மேலும் குறியீட்டின் ஆதரவையும் பராமரிப்பையும் எளிதாக்கும். குறியீட்டு அடிப்படையின் அளவு மற்றும் எங்கள் குறியீட்டின் குறிப்பிட்ட அம்சங்களுக்காக இல்லையெனில், மொழிபெயர்ப்பில் அசாதாரணமானது எதுவும் இல்லை.

தெரியாதவர்களுக்கு, 1C: எண்டர்பிரைஸ் என்பது குறுக்கு-தளம் வணிக பயன்பாடுகளின் விரைவான வளர்ச்சிக்கான சூழல் மற்றும் வெவ்வேறு OS கள் மற்றும் DBMS களில் அவற்றைச் செயல்படுத்துவதற்கான இயக்க நேரம். பொதுவாக, தயாரிப்பு கொண்டுள்ளது:

• பயன்பாட்டு சர்வர் கிளஸ்டர், விண்டோஸ் மற்றும் லினக்ஸில் இயங்குகிறது
• வாடிக்கையாளர், http(கள்) அல்லது அதன் சொந்த பைனரி நெறிமுறை வழியாக சேவையகத்துடன் பணிபுரிவது, Windows, Linux, macOS இல் வேலை செய்கிறது
• இணைய வாடிக்கையாளர், Chrome, Internet Explorer, Microsoft Edge, Firefox, Safari உலாவிகளில் இயங்குகிறது (ஜாவாஸ்கிரிப்ட்டில் எழுதப்பட்டது)
• வளர்ச்சி சூழல் (கட்டமைப்பாளர்), Windows, Linux, macOS இல் வேலை செய்கிறது
• நிர்வாக கருவிகள் பயன்பாட்டு சேவையகங்கள், விண்டோஸ், லினக்ஸ், மேகோஸ் ஆகியவற்றில் இயங்கும்
• மொபைல் கிளையன்ட், http(கள்) வழியாக சர்வருடன் இணைப்பது, Android, iOS, Windows இயங்கும் மொபைல் சாதனங்களில் வேலை செய்கிறது
• மொபைல் தளம் - Android, iOS, Windows இல் இயங்கும், ஒத்திசைக்கும் திறன் கொண்ட ஆஃப்லைன் மொபைல் பயன்பாடுகளை உருவாக்குவதற்கான ஒரு கட்டமைப்பு
• வளர்ச்சி சூழல் 1C:எண்டர்பிரைஸ் டெவலப்மெண்ட் டூல்ஸ், ஜாவாவில் எழுதப்பட்டது
• Сервер தொடர்பு அமைப்புகள்

முடிந்தவரை வெவ்வேறு இயக்க முறைமைகளுக்கு ஒரே குறியீட்டை எழுத முயற்சிக்கிறோம் - சர்வர் குறியீடு அடிப்படை 99% பொதுவானது, கிளையன்ட் குறியீடு அடிப்படை சுமார் 95% ஆகும். 1C:Enterprise தொழில்நுட்ப தளம் முதன்மையாக C++ இல் எழுதப்பட்டுள்ளது மற்றும் தோராயமான குறியீடு பண்புகள் கீழே கொடுக்கப்பட்டுள்ளன:

• C++ குறியீட்டின் 10 மில்லியன் வரிகள்,
• 14 ஆயிரம் கோப்புகள்,
• 60 ஆயிரம் வகுப்புகள்,
• அரை மில்லியன் முறைகள்.

இந்த விஷயங்கள் அனைத்தும் C++14 க்கு மொழிபெயர்க்கப்பட வேண்டும். இதை எப்படிச் செய்தோம், செயல்பாட்டில் என்ன சந்தித்தோம் என்பதை இன்று நாங்கள் உங்களுக்குச் சொல்வோம்.

மறுப்பு

மெதுவான/வேகமான வேலை, (இல்லை) பல்வேறு நூலகங்களில் நிலையான வகுப்புகளை செயல்படுத்துவதன் மூலம் அதிக நினைவக நுகர்வு பற்றி கீழே எழுதப்பட்ட அனைத்தும் ஒன்றுதான்: இது எங்களுக்கு உண்மை. நிலையான செயலாக்கங்கள் உங்கள் பணிகளுக்கு மிகவும் பொருத்தமானதாக இருக்கும். நாங்கள் எங்கள் சொந்த பணிகளிலிருந்து தொடங்கினோம்: எங்கள் வாடிக்கையாளர்களுக்கு பொதுவான தரவை நாங்கள் எடுத்தோம், அவற்றில் வழக்கமான காட்சிகளை இயக்கினோம், செயல்திறன், நுகரப்படும் நினைவகத்தின் அளவு போன்றவற்றைப் பார்த்தோம், மேலும் இதுபோன்ற முடிவுகளில் நாமும் எங்கள் வாடிக்கையாளர்களும் திருப்தியடைகிறார்களா இல்லையா என்பதை பகுப்பாய்வு செய்தோம். . மேலும் அவர்கள் சார்ந்து செயல்பட்டனர்.

எங்களிடம் என்ன இருந்தது

ஆரம்பத்தில், மைக்ரோசாஃப்ட் விஷுவல் ஸ்டுடியோவைப் பயன்படுத்தி 1C:Enterprise 8 இயங்குதளத்திற்கான குறியீட்டை எழுதினோம். இந்த திட்டம் 2000 களின் முற்பகுதியில் தொடங்கப்பட்டது, எங்களிடம் விண்டோஸ் மட்டும் பதிப்பு இருந்தது. இயற்கையாகவே, அதன் பின்னர் குறியீடு தீவிரமாக உருவாக்கப்பட்டது, பல வழிமுறைகள் முழுமையாக மீண்டும் எழுதப்பட்டுள்ளன. ஆனால் குறியீடு 1998 தரநிலையின்படி எழுதப்பட்டது, எடுத்துக்காட்டாக, எங்கள் வலது கோண அடைப்புக்குறிகள் இடைவெளிகளால் பிரிக்கப்பட்டன, இதனால் தொகுப்பு வெற்றிபெறும், இது போன்றது:

vector<vector<int> > IntV;

2006 இல், இயங்குதள பதிப்பு 8.1 வெளியீட்டுடன், நாங்கள் லினக்ஸை ஆதரிக்கத் தொடங்கினோம் மற்றும் மூன்றாம் தரப்பு நிலையான நூலகத்திற்கு மாறினோம். STLPort. மாற்றத்திற்கான காரணங்களில் ஒன்று பரந்த கோடுகளுடன் வேலை செய்வது. எங்கள் குறியீட்டில், wchar_t வகையை அடிப்படையாகக் கொண்ட std::wstring ஐப் பயன்படுத்துகிறோம். விண்டோஸில் அதன் அளவு 2 பைட்டுகள், லினக்ஸில் இயல்புநிலை 4 பைட்டுகள். இது கிளையன்ட் மற்றும் சர்வர் இடையே உள்ள எங்கள் பைனரி நெறிமுறைகள் மற்றும் பல்வேறு நிலையான தரவுகளின் இணக்கமின்மைக்கு வழிவகுத்தது. gcc விருப்பங்களைப் பயன்படுத்தி, தொகுக்கும் போது wchar_t இன் அளவும் 2 பைட்டுகள் என்று நீங்கள் குறிப்பிடலாம், ஆனால் கம்பைலரில் இருந்து நிலையான நூலகத்தைப் பயன்படுத்துவதை நீங்கள் மறந்துவிடலாம், ஏனெனில் இது glibc ஐப் பயன்படுத்துகிறது, இது 4-பைட் wchar_t க்காக தொகுக்கப்படுகிறது. மற்ற காரணங்கள் நிலையான வகுப்புகளை சிறப்பாக செயல்படுத்துதல், ஹாஷ் அட்டவணைகளுக்கான ஆதரவு மற்றும் கொள்கலன்களுக்குள் நகரும் சொற்பொருளின் எமுலேஷன், நாங்கள் தீவிரமாக பயன்படுத்தினோம். மேலும் ஒரு காரணம், அவர்கள் சொல்வது போல் கடைசியாக ஆனால் குறைந்தது அல்ல, சரம் செயல்திறன். சரங்களுக்கு எங்கள் சொந்த வகுப்பு இருந்தது, ஏனென்றால்... எங்கள் மென்பொருளின் பிரத்தியேகங்கள் காரணமாக, சரம் செயல்பாடுகள் மிகவும் பரவலாகப் பயன்படுத்தப்படுகின்றன, மேலும் இது எங்களுக்கு முக்கியமானது.

எங்கள் சரம் 2000 களின் முற்பகுதியில் வெளிப்படுத்தப்பட்ட சரம் தேர்வுமுறை யோசனைகளை அடிப்படையாகக் கொண்டது ஆண்ட்ரி அலெக்ஸாண்ட்ரெஸ்கு. பின்னர், அலெக்ஸாண்ட்ரெஸ்கு ஃபேஸ்புக்கில் பணிபுரிந்தபோது, ​​அவருடைய ஆலோசனையின்படி, இதேபோன்ற கொள்கைகளில் வேலை செய்யும் ஃபேஸ்புக் இயந்திரத்தில் ஒரு வரி பயன்படுத்தப்பட்டது (நூலகத்தைப் பார்க்கவும் முட்டாள்தனம்).

எங்கள் வரி இரண்டு முக்கிய தேர்வுமுறை தொழில்நுட்பங்களைப் பயன்படுத்தியது:

1. குறுகிய மதிப்புகளுக்கு, சரம் பொருளிலேயே உள்ளக இடையகம் பயன்படுத்தப்படுகிறது (கூடுதல் நினைவக ஒதுக்கீடு தேவையில்லை).
2. மற்ற அனைவருக்கும், இயக்கவியல் பயன்படுத்தப்படுகிறது எழுத்தில் நகல். சரம் மதிப்பு ஒரே இடத்தில் சேமிக்கப்படுகிறது, மேலும் பணி/மாற்றத்தின் போது குறிப்பு கவுண்டர் பயன்படுத்தப்படும்.

பிளாட்ஃபார்ம் தொகுப்பை விரைவுபடுத்த, எங்களின் STLPort மாறுபாட்டிலிருந்து ஸ்ட்ரீம் செயல்படுத்தலை நாங்கள் தவிர்த்துவிட்டோம் (இதை நாங்கள் பயன்படுத்தவில்லை), இது எங்களுக்கு 20% வேகமான தொகுப்பை வழங்கியது. அதன்பிறகு நாம் குறைந்த அளவே பயன்படுத்த வேண்டியிருந்தது பூஸ்ட். பூஸ்ட் ஸ்ட்ரீமை அதிகமாகப் பயன்படுத்துகிறது, குறிப்பாக அதன் சேவை APIகளில் (உதாரணமாக, பதிவு செய்வதற்கு), எனவே ஸ்ட்ரீமின் பயன்பாட்டை அகற்ற அதை மாற்றியமைக்க வேண்டியிருந்தது. இது, பூஸ்டின் புதிய பதிப்புகளுக்கு இடம்பெயர்வதை கடினமாக்கியது.

மூன்றாவது வழி

C++14 தரநிலைக்கு நகரும் போது, ​​பின்வரும் விருப்பங்களை நாங்கள் பரிசீலித்தோம்:

1. நாங்கள் மாற்றியமைத்த STLPort ஐ C++14 தரநிலைக்கு மேம்படுத்தவும். விருப்பம் மிகவும் கடினம், ஏனென்றால் ... STLPort க்கான ஆதரவு 2010 இல் நிறுத்தப்பட்டது, மேலும் அதன் அனைத்து குறியீட்டையும் நாமே உருவாக்க வேண்டும்.
2. C++14 உடன் இணக்கமான மற்றொரு STL செயலாக்கத்திற்கு மாறுதல். இந்தச் செயலாக்கம் விண்டோஸ் மற்றும் லினக்ஸில் இருப்பது மிகவும் விரும்பத்தக்கது.
3. ஒவ்வொரு OS க்கும் தொகுக்கும்போது, ​​தொடர்புடைய கம்பைலரில் கட்டமைக்கப்பட்ட நூலகத்தைப் பயன்படுத்தவும்.

அதிக வேலை காரணமாக முதல் விருப்பம் முற்றிலும் நிராகரிக்கப்பட்டது.

இரண்டாவது விருப்பத்தைப் பற்றி சிறிது நேரம் யோசித்தோம்; வேட்பாளராக கருதப்படுகிறது libc++, ஆனால் அந்த நேரத்தில் அது விண்டோஸின் கீழ் வேலை செய்யவில்லை. Libc++ ஐ விண்டோஸுக்கு போர்ட் செய்ய, நீங்கள் நிறைய வேலைகளைச் செய்ய வேண்டியிருக்கும் - எடுத்துக்காட்டாக, இந்த பகுதிகளில் libc++ பயன்படுத்தப்பட்டதால், நூல்கள், நூல் ஒத்திசைவு மற்றும் அணுசக்தி ஆகியவற்றுடன் தொடர்புடைய அனைத்தையும் நீங்களே எழுதுங்கள். POSIX API.

நாங்கள் மூன்றாவது வழியைத் தேர்ந்தெடுத்தோம்.

மாற்றம்

எனவே, STLPort இன் பயன்பாட்டை தொடர்புடைய கம்பைலர்களின் நூலகங்களுடன் மாற்ற வேண்டியிருந்தது (விண்டோஸுக்கான விஷுவல் ஸ்டுடியோ 2015, Linux க்கு gcc 7, macOS க்கு clang 8).

அதிர்ஷ்டவசமாக, எங்கள் குறியீடு முக்கியமாக வழிகாட்டுதல்களின்படி எழுதப்பட்டது மற்றும் அனைத்து வகையான புத்திசாலித்தனமான தந்திரங்களையும் பயன்படுத்தவில்லை, எனவே புதிய நூலகங்களுக்கு இடம்பெயர்வது ஒப்பீட்டளவில் சீராக தொடர்ந்தது, வகைகள், வகுப்புகள், பெயர்வெளிகள் மற்றும் மூலத்தில் உள்ள பெயர்களை மாற்றியமைக்கும் ஸ்கிரிப்ட்களின் உதவியுடன். கோப்புகள். இடம்பெயர்வு 10 மூல கோப்புகளை பாதித்தது (000 இல்). wchar_t char14_t ஆல் மாற்றப்பட்டது; wchar_t பயன்பாட்டை கைவிட முடிவு செய்தோம், ஏனெனில் char000_t அனைத்து OSகளிலும் 16 பைட்டுகளை எடுக்கும் மற்றும் விண்டோஸ் மற்றும் லினக்ஸுக்கு இடையே குறியீடு இணக்கத்தன்மையை கெடுக்காது.

சில சிறிய சாகசங்கள் இருந்தன. எடுத்துக்காட்டாக, STLPort இல், ஒரு உறுப்புக்கான சுட்டிக்காட்டிக்கு ஒரு மறு செய்கை மறைமுகமாக அனுப்பப்படலாம், மேலும் எங்கள் குறியீட்டில் சில இடங்களில் இது பயன்படுத்தப்பட்டது. புதிய நூலகங்களில் இதை இனி செய்ய முடியாது, மேலும் இந்த பத்திகளை பகுப்பாய்வு செய்து கைமுறையாக மீண்டும் எழுத வேண்டும்.

எனவே, குறியீடு இடம்பெயர்வு முடிந்தது, குறியீடு அனைத்து இயக்க முறைமைகளுக்கும் தொகுக்கப்பட்டுள்ளது. சோதனைகளுக்கான நேரம் இது.

மாற்றத்திற்குப் பிறகு சோதனைகள் செயல்திறன் வீழ்ச்சியைக் காட்டியது (சில இடங்களில் 20-30% வரை) மற்றும் குறியீட்டின் பழைய பதிப்போடு ஒப்பிடும்போது நினைவக நுகர்வு (10-15% வரை) அதிகரித்தது. இது, குறிப்பாக, நிலையான சரங்களின் துணை செயல்திறன் காரணமாக இருந்தது. எனவே, நாங்கள் மீண்டும் எங்கள் சொந்த, சற்று மாற்றியமைக்கப்பட்ட வரியைப் பயன்படுத்த வேண்டியிருந்தது.

உட்பொதிக்கப்பட்ட நூலகங்களில் கொள்கலன்களை செயல்படுத்துவதில் ஒரு சுவாரஸ்யமான அம்சம் வெளிப்பட்டது: வெற்று (உறுப்புகள் இல்லாமல்) std::map மற்றும் std:: உள்ளமைக்கப்பட்ட நூலகங்களிலிருந்து அமைக்கப்பட்டவை நினைவகத்தை ஒதுக்குகின்றன. செயல்படுத்தும் அம்சங்கள் காரணமாக, குறியீட்டில் சில இடங்களில் இந்த வகை வெற்று கொள்கலன்கள் நிறைய உருவாக்கப்படுகின்றன. நிலையான நினைவக கொள்கலன்கள் ஒரு ரூட் உறுப்புக்காக சிறிது ஒதுக்கப்பட்டுள்ளன, ஆனால் எங்களுக்கு இது முக்கியமானதாக மாறியது - பல சூழ்நிலைகளில், எங்கள் செயல்திறன் கணிசமாகக் குறைந்தது மற்றும் நினைவக நுகர்வு அதிகரித்தது (STLPort உடன் ஒப்பிடும்போது). எனவே, எங்கள் குறியீட்டில் உள்ளமைக்கப்பட்ட நூலகங்களிலிருந்து இந்த இரண்டு வகையான கொள்கலன்களை பூஸ்டிலிருந்து செயல்படுத்துவதன் மூலம் மாற்றினோம், இந்த கொள்கலன்களில் இந்த அம்சம் இல்லை, மேலும் இது மந்தநிலை மற்றும் அதிகரித்த நினைவக நுகர்வு ஆகியவற்றில் சிக்கலைத் தீர்த்தது.

பெரிய திட்டங்களில் பெரிய அளவிலான மாற்றங்களுக்குப் பிறகு அடிக்கடி நடப்பது போல, மூலக் குறியீட்டின் முதல் மறு செய்கை சிக்கல்கள் இல்லாமல் வேலை செய்யவில்லை, மேலும் இங்கே, குறிப்பாக, விண்டோஸ் செயலாக்கத்தில் பிழைத்திருத்த மறுதொடக்கங்களுக்கான ஆதரவு கைக்கு வந்தது. நாங்கள் படிப்படியாக முன்னேறினோம், 2017 வசந்த காலத்தில் (பதிப்பு 8.3.11 1C: எண்டர்பிரைஸ்) இடம்பெயர்வு முடிந்தது.

முடிவுகளை

C++14 தரநிலைக்கு மாற எங்களுக்கு 6 மாதங்கள் பிடித்தன. பெரும்பாலான நேரங்களில், ஒரு (ஆனால் மிகவும் தகுதியான) டெவலப்பர் திட்டத்தில் பணிபுரிந்தார், மேலும் இறுதி கட்டத்தில் குறிப்பிட்ட பகுதிகளுக்கு பொறுப்பான குழுக்களின் பிரதிநிதிகள் இணைந்தனர் - UI, சர்வர் கிளஸ்டர், மேம்பாடு மற்றும் நிர்வாக கருவிகள் போன்றவை.

இந்த மாற்றம் தரநிலையின் சமீபத்திய பதிப்புகளுக்கு இடம்பெயர்வதற்கான எங்கள் வேலையை பெரிதும் எளிதாக்கியது. எனவே, பதிப்பு 1C: எண்டர்பிரைஸ் 8.3.14 (வளர்ச்சியில், அடுத்த ஆண்டு தொடக்கத்தில் வெளியிட திட்டமிடப்பட்டுள்ளது) ஏற்கனவே தரநிலைக்கு மாற்றப்பட்டுள்ளது சி++17.

இடம்பெயர்வுக்குப் பிறகு, டெவலப்பர்களுக்கு கூடுதல் விருப்பங்கள் உள்ளன. முன்னதாக எங்களிடம் STL இன் மாற்றியமைக்கப்பட்ட பதிப்பு மற்றும் ஒரு std பெயர்வெளி இருந்தால், இப்போது std பெயர்வெளியில் உள்ளமைக்கப்பட்ட கம்பைலர் நூலகங்களிலிருந்து நிலையான வகுப்புகள் உள்ளன, stdx பெயர்வெளியில் - எங்கள் கோடுகள் மற்றும் கொள்கலன்கள் எங்கள் பணிகளுக்கு உகந்ததாக, ஊக்கத்தில் - ஊக்கத்தின் சமீபத்திய பதிப்பு. டெவலப்பர் தனது பிரச்சினைகளைத் தீர்க்க உகந்ததாக இருக்கும் அந்த வகுப்புகளைப் பயன்படுத்துகிறார்.

மூவ் கன்ஸ்ட்ரக்டர்களின் "சொந்த" செயலாக்கமும் வளர்ச்சிக்கு உதவுகிறது (கட்டமைப்பாளர்களை நகர்த்தவும்) பல வகுப்புகளுக்கு. ஒரு வகுப்பில் மூவ் கன்ஸ்ட்ரக்டர் இருந்தால், இந்த கிளாஸ் ஒரு கொள்கலனில் வைக்கப்பட்டிருந்தால், STL ஆனது கொள்கலனுக்குள் உள்ள உறுப்புகளை நகலெடுப்பதை மேம்படுத்துகிறது (உதாரணமாக, கொள்கலன் விரிவடைந்து, திறனை மாற்றுவது மற்றும் நினைவகத்தை மறு ஒதுக்கீடு செய்வது அவசியம்).

தைப்பூசத்தில் பறக்கவும்

இடப்பெயர்வின் மிகவும் விரும்பத்தகாத (ஆனால் முக்கியமானதல்ல) விளைவு என்னவென்றால், ஒலி அளவு அதிகரிப்பதை நாம் எதிர்கொள்கிறோம். obj கோப்புகள், மற்றும் அனைத்து இடைநிலை கோப்புகளுடனும் உருவாக்கத்தின் முழு முடிவு 60-70 ஜிபி வரை எடுக்கத் தொடங்கியது. இந்த நடத்தை நவீன தரநிலை நூலகங்களின் தனித்தன்மையின் காரணமாக உள்ளது, அவை உருவாக்கப்பட்ட சேவை கோப்புகளின் அளவைக் குறைவாக விமர்சிக்கின்றன. இது தொகுக்கப்பட்ட பயன்பாட்டின் செயல்பாட்டை பாதிக்காது, ஆனால் இது வளர்ச்சியில் பல சிரமங்களை ஏற்படுத்துகிறது, குறிப்பாக, இது தொகுக்கும் நேரத்தை அதிகரிக்கிறது. பில்ட் சர்வர்கள் மற்றும் டெவலப்பர் மெஷின்களில் இலவச வட்டு இடத்திற்கான தேவைகளும் அதிகரித்து வருகின்றன. எங்கள் டெவலப்பர்கள் தளத்தின் பல பதிப்புகளில் இணையாக வேலை செய்கிறார்கள், மேலும் நூற்றுக்கணக்கான ஜிகாபைட் இடைநிலை கோப்புகள் சில நேரங்களில் தங்கள் வேலையில் சிரமங்களை உருவாக்குகின்றன. பிரச்சனை விரும்பத்தகாதது, ஆனால் சிக்கலானது அல்ல; தற்போது அதன் தீர்வை ஒத்திவைத்துள்ளோம். அதைத் தீர்ப்பதற்கான விருப்பங்களில் ஒன்றாக தொழில்நுட்பத்தை நாங்கள் கருதுகிறோம் ஒற்றுமை உருவாக்க (குறிப்பாக, குரோம் பிரவுசரை உருவாக்கும்போது கூகுள் இதைப் பயன்படுத்துகிறது).

ஆதாரம்: www.habr.com