Како смо превели 10 милиона линија Ц++ кода у Ц++14 стандард (а затим у Ц++17)

Пре извесног времена (у јесен 2016. године), током развоја следеће верзије технолошке платформе 1Ц:Ентерприсе, у развојном тиму се појавило питање подршке новом стандарду. Ц ++ 14 у нашем законику. Прелазак на нови стандард, као што смо претпоставили, омогућио би нам да многе ствари напишемо елегантније, једноставније и поузданије, и поједноставио би подршку и одржавање кода. И изгледа да нема ничег необичног у преводу, ако не због размера кодне базе и специфичности нашег кода.

За оне који не знају, 1Ц:Ентерприсе је окружење за брзи развој вишеплатформских пословних апликација и времена извршавања за њихово извршавање на различитим оперативним системима и ДБМС-овима. Генерално, производ садржи:

• Кластер сервера апликација, ради на Виндовс-у и Линук-у
• Цустомер, ради са сервером преко хттп(с) или сопственог бинарног протокола, ради на Виндовс, Линук, мацОС
• Веб клијент, ради у Цхроме, Интернет Екплорер, Мицрософт Едге, Фирефок, Сафари прегледачима (написано у ЈаваСцрипт-у)
• Развојно окружење (Конфигуратор), ради на Виндовс, Линук, мацОС
• Административни алати сервери апликација, који раде на Виндовс, Линук, мацОС
• Мобилни клијент, повезивање са сервером преко хттп(а), ради на мобилним уређајима који користе Андроид, иОС, Виндовс
• Мобилна платформа — оквир за креирање офлајн мобилних апликација са могућношћу синхронизације, који раде на Андроид, иОС, Виндовс
• Развојно окружење 1Ц: Алати за развој предузећа, написан на Јави
• Сервер Интеракциони системи

Трудимо се да напишемо исти код за различите оперативне системе што је више могуће - база кода сервера је 99% уобичајена, база кодова клијента је око 95%. Технолошка платформа 1Ц:Ентерприсе је првенствено написана на Ц++, а приближне карактеристике кода су дате у наставку:

• 10 милиона редова Ц++ кода,
• 14 хиљада фајлова,
• 60 хиљада часова,
• пола милиона метода.

И све ове ствари су морале бити преведене на Ц++14. Данас ћемо вам рећи како смо то урадили и на шта смо се сусрели у том процесу.

Одрицање од одговорности

Све доле написано о спором/брзом раду, (не)великој потрошњи меморије имплементацијама стандардних класа у разним библиотекама значи једно: ово важи ЗА НАС. Сасвим је могуће да ће стандардне имплементације бити најприкладније за ваше задатке. Почели смо од сопствених задатака: узели смо податке који су типични за наше клијенте, покренули типичне сценарије на њима, погледали перформансе, количину утрошене меморије, итд., и анализирали да ли смо ми и наши клијенти задовољни таквим резултатима или не . И деловали су у зависности од.

Оно што смо имали

У почетку смо написали код за платформу 1Ц:Ентерприсе 8 у Мицрософт Висуал Студио. Пројекат је започео раних 2000-их и имали смо верзију само за Виндовс. Наравно, од тада је код активно развијен, многи механизми су потпуно преписани. Али код је написан према стандарду из 1998. и, на пример, наше правоугаоне заграде су биле раздвојене размацима да би компилација успела, овако:

vector<vector<int> > IntV;

2006. године, са издавањем платформе верзије 8.1, почели смо да подржавамо Линук и прешли на стандардну библиотеку треће стране СТЛПорт. Један од разлога за транзицију био је рад са широким линијама. У нашем коду користимо стд::встринг, који је заснован на типу вцхар_т. Његова величина у Виндовс-у је 2 бајта, ау Линук-у је подразумевана 4 бајта. То је довело до некомпатибилности наших бинарних протокола између клијента и сервера, као и до разних упорних података. Користећи гцц опције, можете одредити да је величина вцхар_т током компилације такође 2 бајта, али тада можете заборавити на коришћење стандардне библиотеке из компајлера, јер користи глибц, који је заузврат компајлиран за 4-бајтни вцхар_т. Други разлози били су боља имплементација стандардних класа, подршка за хеш табеле, па чак и емулација семантике кретања унутар контејнера, што смо активно користили. И још један разлог, како кажу последњи, али не и најмање важан, био је извођење гудача. Имали смо свој час за жице, јер... Због специфичности нашег софтвера, стринг операције се користе веома широко и за нас је то критично.

Наш стринг је заснован на идејама за оптимизацију стрингова израженим још раних 2000-их Андреј Александреску. Касније, када је Александреску радио у Фејсбуку, на његов предлог, у фејсбук мотору је коришћена линија која је радила на сличним принципима (погледајте библиотеку глупост).

Наша линија је користила две главне технологије оптимизације:

1. За кратке вредности, користи се интерни бафер у самом објекту стринг (не захтева додатну алокацију меморије).
2. За све остале користи се механика Цопи Он Врите. Вредност стринга се чува на једном месту, а референтни бројач се користи током доделе/модификације.

Да бисмо убрзали компилацију платформе, искључили смо имплементацију стрима из наше СТЛПорт варијанте (коју нисмо користили), што нам је дало око 20% бржу компилацију. Након тога смо морали да користимо ограничено Појачати. Боост у великој мери користи стрим, посебно у својим АПИ-јима за услуге (на пример, за евидентирање), па смо морали да га изменимо да бисмо уклонили употребу стрима. Ово нам је заузврат отежало прелазак на нове верзије Боост-а.

Трећи начин

Приликом преласка на стандард Ц++14, размотрили смо следеће опције:

1. Надоградите СТЛПорт који смо модификовали на Ц++14 стандард. Опција је веома тешка, јер... подршка за СТЛПорт је укинута 2010. године и морали бисмо сами да направимо сав његов код.
2. Прелазак на другу СТЛ имплементацију компатибилну са Ц++14. Веома је пожељно да ова имплементација буде за Виндовс и Линук.
3. Приликом компајлирања за сваки ОС, користите библиотеку уграђену у одговарајући компајлер.

Прва опција је потпуно одбијена због превише посла.

О другој опцији размишљали смо неко време; сматра се кандидатом либц ++, али у то време није функционисао под Виндовсом. Да бисте пренели либц++ на Виндовс, морали бисте много да урадите – на пример, сами напишите све што има везе са нитима, синхронизацијом нити и атомичности, пошто се либц++ користи у овим областима ПОСИКС АПИ.

И ми смо изабрали трећи пут.

Прелаз

Дакле, морали смо да заменимо употребу СТЛПорт-а са библиотекама одговарајућих компајлера (Висуал Студио 2015 за Виндовс, гцц 7 за Линук, цланг 8 за мацОС).

Срећом, наш код је писан углавном према упутствима и није користио све врсте лукавих трикова, тако да је миграција на нове библиотеке текла релативно глатко, уз помоћ скрипти које су замениле називе типова, класа, именских простора и укључиле у извор фајлови. Миграција је утицала на 10 изворних датотека (од 000). вцхар_т је замењен са цхар14_т; одлучили смо да напустимо употребу вцхар_т, јер цхар000_т заузима 16 бајта на свим оперативним системима и не квари компатибилност кода између Виндовс-а и Линук-а.

Било је и малих авантура. На пример, у СТЛПорт-у итератор би се могао имплицитно пребацити на показивач на елемент, а на неким местима у нашем коду је то коришћено. У новим библиотекама то више није било могуће учинити и ови одломци су морали бити анализирани и преписани ручно.

Дакле, миграција кода је завршена, код је компајлиран за све оперативне системе. Време је за тестове.

Тестови након транзиције показали су пад перформанси (на неким местима и до 20-30%) и повећање потрошње меморије (до 10-15%) у поређењу са старом верзијом кода. Ово је посебно било због неоптималних перформанси стандардних жица. Стога смо поново морали да користимо сопствену, мало измењену линију.

Такође је откривена занимљива карактеристика имплементације контејнера у уграђене библиотеке: празан (без елемената) стд::мап и стд::сет из уграђених библиотека додељују меморију. А због карактеристика имплементације, на неким местима у коду се ствара доста празних контејнера овог типа. Стандардни меморијски контејнери се додељују мало, за један основни елемент, али за нас се то показало критичним - у низу сценарија, наше перформансе су значајно опали и потрошња меморије се повећала (у поређењу са СТЛПорт-ом). Због тога смо у нашем коду заменили ова два типа контејнера из уграђених библиотека њиховом имплементацијом из Боост-а, где ови контејнери нису имали такву могућност, и тиме је решио проблем успоравања и повећане потрошње меморије.

Као што се често дешава након великих промена у великим пројектима, прва итерација изворног кода није функционисала без проблема, а овде је посебно добро дошла подршка за отклањање грешака итератора у Виндовс имплементацији. Корак по корак смо ишли напред и до пролећа 2017. (верзија 8.3.11 1Ц:Ентерприсе) миграција је завршена.

Резултати

Прелазак на Ц++14 стандард нам је трајао око 6 месеци. Већину времена на пројекту је радио један (али веома квалификован) програмер, а у завршној фази су се укључили представници тимова одговорних за одређене области – УИ, серверски кластер, развојни и административни алати итд.

Прелазак је у великој мери поједноставио наш рад на преласку на најновије верзије стандарда. Тако је верзија 1Ц:Ентерприсе 8.3.14 (у развоју, издање заказано за почетак следеће године) већ пребачена на стандард Ц++17.

Након миграције, програмери имају више опција. Ако смо раније имали сопствену модификовану верзију СТЛ-а и један стд именски простор, сада имамо стандардне класе из уграђених компајлерских библиотека у стд именском простору, у стдк именском простору - наше линије и контејнери оптимизовани за наше задатке, у боост-у - најновија верзија појачања. А програмер користи оне класе које су оптимално прикладне за решавање његових проблема.

„Нативна“ имплементација конструктора покрета такође помаже у развоју (конструктори померања) за већи број часова. Ако класа има конструктор за померање и ова класа је смештена у контејнер, онда СТЛ оптимизује копирање елемената унутар контејнера (на пример, када се контејнер прошири и потребно је променити капацитет и поново доделити меморију).

Летите у масти

Можда је најнепријатнија (али не и критична) последица миграције то што смо суочени са повећањем обима обј датотеке, а потпуни резултат градње са свим средњим датотекама почео је да заузима 60–70 ГБ. Ово понашање је последица специфичности модерних стандардних библиотека, које су постале мање критичне према величини генерисаних сервисних датотека. Ово не утиче на рад компајлиране апликације, али изазива низ непријатности у развоју, посебно повећава време компилације. Захтеви за слободним простором на диску на серверима за изградњу и на машинама за програмере се такође повећавају. Наши програмери паралелно раде на неколико верзија платформе, а стотине гигабајта међуфајлова понекад стварају потешкоће у њиховом раду. Проблем је непријатан, али није критичан, за сада смо одложили његово решавање. Технологију разматрамо као једну од опција за њено решавање изградити јединство (Гоогле га посебно користи када развија Цхроме претраживач).

Извор: ввв.хабр.цом