કેવી રીતે અમે C++ કોડની 10 મિલિયન લાઇન્સ C++14 સ્ટાન્ડર્ડ (અને પછી C++17)માં અનુવાદિત કરી

થોડા સમય પહેલા (2016 ના પાનખરમાં), 1C:Enterprise ટેક્નોલોજી પ્લેટફોર્મના આગલા સંસ્કરણના વિકાસ દરમિયાન, નવા ધોરણને સમર્થન આપવા અંગે વિકાસ ટીમમાં પ્રશ્ન ઊભો થયો હતો. સી ++ 14 અમારા કોડમાં. નવા ધોરણમાં સંક્રમણ, જેમ આપણે ધારીએ છીએ, અમને ઘણી વસ્તુઓ વધુ સુંદર, સરળ અને વિશ્વસનીય રીતે લખવાની મંજૂરી આપશે અને કોડના સમર્થન અને જાળવણીને સરળ બનાવશે. અને કોડ બેઝના સ્કેલ અને અમારા કોડની વિશિષ્ટ વિશેષતાઓ માટે નહીં તો અનુવાદમાં અસાધારણ કંઈ જ નથી.

જેઓ જાણતા નથી તેમના માટે, 1C:Enterprise એ ક્રોસ-પ્લેટફોર્મ બિઝનેસ એપ્લીકેશનના ઝડપી વિકાસ અને વિવિધ OS અને DBMSs પર તેમના અમલ માટે રનટાઇમ માટેનું વાતાવરણ છે. સામાન્ય શબ્દોમાં, ઉત્પાદનમાં શામેલ છે:

• એપ્લિકેશન સર્વર ક્લસ્ટર, Windows અને Linux પર ચાલે છે
• ગ્રાહક, http(s) અથવા તેના પોતાના બાઈનરી પ્રોટોકોલ દ્વારા સર્વર સાથે કામ કરવું, Windows, Linux, macOS પર કામ કરે છે
• વેબ ક્લાયંટ, Chrome, Internet Explorer, Microsoft Edge, Firefox, Safari બ્રાઉઝર્સમાં ચાલી રહ્યું છે (જાવાસ્ક્રિપ્ટમાં લખાયેલ)
• વિકાસ પર્યાવરણ (રૂપરેખાકાર), 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:Enterprise 8 પ્લેટફોર્મ માટે કોડ લખ્યો હતો. આ પ્રોજેક્ટ 2000 ના દાયકાની શરૂઆતમાં શરૂ થયો હતો અને અમારી પાસે ફક્ત Windows-નું સંસ્કરણ હતું. સ્વાભાવિક રીતે, ત્યારથી કોડ સક્રિય રીતે વિકસાવવામાં આવ્યો છે, ઘણી પદ્ધતિઓ સંપૂર્ણપણે ફરીથી લખવામાં આવી છે. પરંતુ કોડ 1998 ના ધોરણ મુજબ લખવામાં આવ્યો હતો, અને, ઉદાહરણ તરીકે, અમારા જમણા ખૂણાના કૌંસને જગ્યાઓ દ્વારા અલગ કરવામાં આવ્યા હતા જેથી સંકલન સફળ થાય, જેમ કે:

vector<vector<int> > IntV;

2006 માં, પ્લેટફોર્મ સંસ્કરણ 8.1 ના પ્રકાશન સાથે, અમે Linux ને સમર્થન આપવાનું શરૂ કર્યું અને તૃતીય-પક્ષ પ્રમાણભૂત પુસ્તકાલય પર સ્વિચ કર્યું. STLPપોર્ટ. સંક્રમણ માટેનું એક કારણ વિશાળ રેખાઓ સાથે કામ કરવાનું હતું. અમારા કોડમાં, અમે std::wstring નો ઉપયોગ કરીએ છીએ, જે સમગ્ર wchar_t પ્રકાર પર આધારિત છે. વિન્ડોઝમાં તેનું કદ 2 બાઇટ્સ છે, અને લિનક્સમાં ડિફોલ્ટ 4 બાઇટ્સ છે. આનાથી ક્લાયંટ અને સર્વર વચ્ચેના અમારા દ્વિસંગી પ્રોટોકોલ્સ તેમજ વિવિધ સતત ડેટાની અસંગતતા થઈ. gcc વિકલ્પોનો ઉપયોગ કરીને, તમે સ્પષ્ટ કરી શકો છો કે સંકલન દરમિયાન wchar_t નું કદ પણ 2 બાઇટ્સ છે, પરંતુ પછી તમે કમ્પાઇલરમાંથી પ્રમાણભૂત લાઇબ્રેરીનો ઉપયોગ કરવાનું ભૂલી શકો છો, કારણ કે તે glibc નો ઉપયોગ કરે છે, જે બદલામાં 4-બાઈટ wchar_t માટે કમ્પાઈલ કરવામાં આવે છે. અન્ય કારણોમાં પ્રમાણભૂત વર્ગોનું વધુ સારું અમલીકરણ, હેશ કોષ્ટકો માટે સમર્થન અને કન્ટેનરની અંદર ખસેડવાના અર્થશાસ્ત્રનું અનુકરણ પણ હતું, જેનો અમે સક્રિયપણે ઉપયોગ કર્યો હતો. અને એક વધુ કારણ, જેમ કે તેઓ કહે છે છેલ્લું પરંતુ ઓછામાં ઓછું નહીં, સ્ટ્રિંગ પ્રદર્શન હતું. અમારી પાસે શબ્દમાળાઓ માટે અમારો પોતાનો વર્ગ હતો, કારણ કે... અમારા સૉફ્ટવેરની વિશિષ્ટતાઓને લીધે, સ્ટ્રિંગ ઑપરેશન્સનો ઉપયોગ ખૂબ જ વ્યાપકપણે થાય છે અને અમારા માટે આ મહત્વપૂર્ણ છે.

અમારી સ્ટ્રિંગ 2000 ના દાયકાની શરૂઆતમાં વ્યક્ત કરવામાં આવેલા સ્ટ્રિંગ ઑપ્ટિમાઇઝેશન વિચારો પર આધારિત છે આન્દ્રે એલેક્ઝાન્ડ્રેસ્કુ. પાછળથી, જ્યારે એલેક્ઝાન્ડ્રેસ્કુએ ફેસબુક પર કામ કર્યું, ત્યારે તેમના સૂચન પર, ફેસબુક એન્જિનમાં એક લાઇનનો ઉપયોગ કરવામાં આવ્યો જે સમાન સિદ્ધાંતો પર કામ કરે છે (લાઇબ્રેરી જુઓ મૂર્ખતા).

અમારી લાઇનમાં બે મુખ્ય ઑપ્ટિમાઇઝેશન તકનીકોનો ઉપયોગ કરવામાં આવ્યો છે:

1. ટૂંકા મૂલ્યો માટે, સ્ટ્રિંગ ઑબ્જેક્ટમાં આંતરિક બફરનો ઉપયોગ થાય છે (વધારાની મેમરી ફાળવણીની જરૂર નથી).
2. અન્ય તમામ માટે, મિકેનિક્સનો ઉપયોગ થાય છે લખવા પર નકલ કરો. શબ્દમાળા મૂલ્ય એક જગ્યાએ સંગ્રહિત થાય છે, અને સોંપણી/સુધારા દરમિયાન સંદર્ભ કાઉન્ટરનો ઉપયોગ થાય છે.

પ્લેટફોર્મ સંકલનને ઝડપી બનાવવા માટે, અમે અમારા STLPport વેરિયન્ટમાંથી સ્ટ્રીમ અમલીકરણને બાકાત રાખ્યું છે (જેનો અમે ઉપયોગ કર્યો નથી), આનાથી અમને લગભગ 20% ઝડપી સંકલન મળ્યું. ત્યારબાદ અમારે મર્યાદિત ઉપયોગ કરવો પડ્યો બુસ્ટ. બૂસ્ટ સ્ટ્રીમનો ભારે ઉપયોગ કરે છે, ખાસ કરીને તેની સર્વિસ API માં (ઉદાહરણ તરીકે, લોગીંગ માટે), તેથી અમારે સ્ટ્રીમનો ઉપયોગ દૂર કરવા માટે તેમાં ફેરફાર કરવો પડ્યો. આનાથી, અમારા માટે બૂસ્ટના નવા સંસ્કરણો પર સ્થાનાંતરિત કરવાનું મુશ્કેલ બન્યું.

ત્રીજો રસ્તો

જ્યારે C++14 સ્ટાન્ડર્ડ પર જઈએ છીએ, ત્યારે અમે નીચેના વિકલ્પોને ધ્યાનમાં લઈએ છીએ:

1. અમે C++14 ધોરણમાં ફેરફાર કરેલ STLPportને અપગ્રેડ કરો. વિકલ્પ ખૂબ જ મુશ્કેલ છે, કારણ કે ... STLPport માટે સપોર્ટ 2010 માં બંધ કરવામાં આવ્યો હતો, અને અમારે તેના તમામ કોડ જાતે બનાવવા પડશે.
2. C++14 સાથે સુસંગત અન્ય STL અમલીકરણમાં સંક્રમણ. તે ખૂબ જ ઇચ્છનીય છે કે આ અમલીકરણ Windows અને Linux માટે હોય.
3. દરેક OS માટે કમ્પાઇલ કરતી વખતે, અનુરૂપ કમ્પાઇલરમાં બનેલી લાઇબ્રેરીનો ઉપયોગ કરો.

પહેલા વિકલ્પને ખૂબ કામને કારણે સીધો જ નકારી કાઢવામાં આવ્યો હતો.

અમે થોડા સમય માટે બીજા વિકલ્પ વિશે વિચાર્યું; ઉમેદવાર તરીકે ગણવામાં આવે છે libc++, પરંતુ તે સમયે તે Windows હેઠળ કામ કરતું ન હતું. વિન્ડોઝમાં libc++ પોર્ટ કરવા માટે, તમારે ઘણું કામ કરવું પડશે - ઉદાહરણ તરીકે, થ્રેડો, થ્રેડ સિંક્રનાઇઝેશન અને એટોમિસિટી સાથે સંબંધિત હોય તે બધું જાતે લખો, કારણ કે આ વિસ્તારોમાં libc++ નો ઉપયોગ થાય છે. POSIX API.

અને અમે ત્રીજો રસ્તો પસંદ કર્યો.

સંક્રમણ

તેથી, અમારે અનુરૂપ કમ્પાઇલર્સની લાઇબ્રેરીઓ સાથે STLPport નો ઉપયોગ બદલવો પડ્યો (વિન્ડોઝ માટે વિઝ્યુઅલ સ્ટુડિયો 2015, Linux માટે gcc 7, macOS માટે ક્લેંગ 8).

સદનસીબે, અમારો કોડ મુખ્યત્વે માર્ગદર્શિકા અનુસાર લખવામાં આવ્યો હતો અને તેમાં તમામ પ્રકારની ચપળ યુક્તિઓનો ઉપયોગ કરવામાં આવ્યો ન હતો, તેથી નવી લાઇબ્રેરીઓમાં સ્થળાંતર પ્રમાણમાં સરળ રીતે આગળ વધ્યું, જેમાં સ્ક્રિપ્ટની મદદથી પ્રકારો, વર્ગો, નેમસ્પેસ અને સ્ત્રોતમાં સમાવિષ્ટોના નામ બદલાયા. ફાઈલો. સ્થળાંતરથી 10 સ્રોત ફાઇલો (000માંથી) પ્રભાવિત થઈ. wchar_t ને char14_t દ્વારા બદલવામાં આવ્યું હતું; અમે wchar_t નો ઉપયોગ છોડી દેવાનું નક્કી કર્યું, કારણ કે char000_t તમામ OS પર 16 બાઇટ્સ લે છે અને Windows અને Linux વચ્ચે કોડ સુસંગતતાને બગાડતું નથી.

કેટલાક નાના સાહસો હતા. ઉદાહરણ તરીકે, STLPort માં ઇટરરેટરને એલિમેન્ટના પોઇન્ટર પર સ્પષ્ટપણે કાસ્ટ કરી શકાય છે, અને અમારા કોડમાં કેટલીક જગ્યાએ આનો ઉપયોગ કરવામાં આવ્યો હતો. નવી લાઇબ્રેરીઓમાં આ કરવાનું હવે શક્ય નહોતું અને આ ફકરાઓનું વિશ્લેષણ અને જાતે જ ફરીથી લખવું પડતું હતું.

તેથી, કોડ સ્થાનાંતરણ પૂર્ણ થયું છે, કોડ બધી ઓપરેટિંગ સિસ્ટમો માટે સંકલિત કરવામાં આવે છે. તે પરીક્ષણો માટે સમય છે.

સંક્રમણ પછીના પરીક્ષણોએ કોડના જૂના સંસ્કરણની તુલનામાં પ્રદર્શનમાં ઘટાડો (કેટલાક સ્થળોએ 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