🥇 Как преведохме 10 милиона реда C++ код на стандарт C++14 (а след това и на C++17)

Преди известно време (есента на 2016), при разработката на нова версия на технологичната платформа 1С:Предприятие, в екипа за разработка възникна въпросът за поддръжката на новия стандарт C++14 в нашия код. Преходът към новия стандарт, както предполагахме, щеше да ни позволи да пишем много неща по-елегантно, по-просто и по-надеждно, улеснявайки поддръжката и консервирането на кода. И в превода няма нищо екстраординарно, ако не се вземат предвид мащабите на кодовата база и специфичните характеристики на нашия код.

За тези, които не знаят, 1С:Предприятие – това е среда за бързо разработване на кросплатформени бизнес приложения и runtime за тяхното изпълнение в различни ОС и СУБД. В общи линии, в състава на продукта влизат:

Клъстер от приложения, работи на Windows и Linux
Клиент, работещ с сървър по http(s) или по собствен бинарен протокол, работи на Windows, Linux, macOS
Уеб клиент, работещ в браузърите Chrome, Internet Explorer, Microsoft Edge, Firefox, Safari (написан на JavaScript)
Среда за разработка (Конфигуратор), работи на Windows, Linux, macOS
Инструменти за администриране на приложения, работят на Windows, Linux, macOS
Мобилен клиент, свързващ се със сървъра по http(s), работи на мобилни устройства с Android, iOS, Windows
Мобилна платформа — фреймворк за създаване на офлайн мобилни приложения с възможност за синхронизация, работещи на Android, iOS, Windows
Среда за разработка Инструменти за развитие на 1С:Предприятие, написана на Java
Сървър Системи за взаимодействие

Ние се стараем максимално да пишем един код за различни ОС — кодовата база на сървъра е обща на 99%, клиентът — около 95%. Технологичната платформа 1С:Предприятие е предимно написана на C++ и по-долу са приблизителните характеристики на кода:

10 милиона реда C++ код,
14 хиляди файла,
60 хиляди класа,
половин милион метода.

И всичко това трябваше да бъде преведено на C++14. За това как го направихме и с какви предизвикателства се сблъскахме в процеса, ще разкажем днес.

Дисклеймер

Всичко, написано по-долу за бавното/бързото изпълнение и (не)голямото потребление на памет от стандартните класове в различни библиотеки, означава едно: това е валидно ЗА НАС. Възможно е стандартните реализации да работят най-добре за вашите задачи. Ние обаче се ръководехме от собствените си нужди: взехме типични данни от нашите клиенти, пуснахме ги през стандартни сценарии, анализирахме производителността, обема на потребяемата памет и т.н., и оценявахме – удовлетворяват ли ни и нашите клиенти тези резултати или не. И вземахме решения въз основа на това.

Какво имахме

Първоначално пишехме кода на платформата 1С:Предприятие 8 в Microsoft Visual Studio. Проектът започна в началото на 2000-те и имахме версия само за Windows. Разбира се, оттогава кодът активно се разви, много механизми бяха напълно пренаписани. Но кодът беше написан по стандарт от 1998 година, и, например, десните аголни скоби бяха разделени с интервали, за да може компилацията да премине успешно, така:

vector<vector > IntV;

През 2006 година, с излизането на версия 8.1 на платформата, започнахме да поддържаме Linux и преминахме на външна стандартна библиотека STLPort. Една от причините за прехода беше работата с широки низове. В нашия код навсякъде използваме std::wstring, базиран на типа wchar_t. Неговият размер в Windows е 2 байта, а в Linux по подразбиране е 4 байта. Това водеше до несъвместимост на нашите бинарни протоколи между клиента и сървъра, както и на различните персистентни данни. Опциите на gcc позволяват да се зададе размерът на wchar_t при компилация също да е 2 байта, но тогава може да забравим за използването на стандартната библиотека от компилятора, тъй като тя използва glibc, а тя от своя страна е компилирана за 4-байтна wchar_t. Други причини бяха по-качествената реализация на стандартните класове, поддръжката на хеш-таблици и дори емулатори на семантика за преместване в контейнерите, които активно използвахме. И още една причина, казват „последна, но не и по важност“, беше производителността на низовете. Имахме собствен клас за низове, тъй като заради спецификата на нашия софтуер низовите операции се използват много широко и за нас това е критично.

Нашият низ е базиран на идеите за оптимизация на низовете, изказани още в началото на 2000-те Андрей Александреску. По-късно, когато Александреску работеше във Facebook, по негова инициатива в движението на Facebook беше използвана стринг, която работи на подобни принципи (вижте библиотеката folly).

В нашия стринг бяха използвани две основни технологии за оптимизация:

За кратки стойности се използва вътрешен буфер в самия обект на стринга (не изискващ допълнителна алокация на памет).
За всички останали се използва механиката Copy On Write. Стойността на стринга се съхранява на едно място, при присвояване/модификация се използва брояч на референции.

За да ускорим компилацията на платформата, изключихме от нашия вариант на STLPort реализацията на потоците (които не използвахме), което ни даде ускорение на компилацията от около 20%. Впоследствие ни се наложи ограничено да използваме Boost. Boost активно използва потоци, по-специално в своите сервисни API (например, за логване), затова ни се наложи да го модифицираме, изключвайки използването на потоци от него. Това, от своя страна, затрудняваше прехода ни към нови версии на Boost.

Третият път

При прехода към стандарта C++14 разглеждахме следните опции:

Да повдигнем модифицирания от нас STLPort до стандарта C++14. Опцията е много сложна, тъй като поддръжката на STLPort беше прекратена през 2010 г. и щеше да трябва да поддържаме целия му код сами.
Преход на друга реализация на STL, съвместима с C++14. Силно желателно е тази реализация да бъде за Windows и Linux.
Да използваме вградена в съответния компилатор библиотека при компилация за всяка ОС.

Първият вариант беше отхвърлен веднага поради прекалено голям обем работа.

Няколко време мислехме по втория вариант; като кандидат разглеждахме libc++, но по онова време не работеше под Windows. За да портнем libc++ на Windows, щеше да трябва да свършим много работа — например, да пишем сами всичко, свързано с потоците, синхронизацията на потоките и атомарността, тъй като в libc++ в тези области се използваше POSIX API.

И ние избрахме третия път.

Преход

И така, ни предстоеше да заменим използването на STLPort с библиотеки на съответните компилатори (Visual Studio 2015 за Windows, gcc 7 за Linux, clang 8 за macOS).

За щастие, нашият код беше написан основно по насоки и не използваше всякакви хитри трикове, така че миграцията към нови библиотеки протече сравнително гладко с помощта на скриптове, заменящи в изходните файлове имената на типове, класове, пространства от имена и включвания. Миграцията засегна 10 000 изходни файла (от 14 000). wchar_t беше заменен с char16_t; решихме да се откажем от използването на wchar_t, тъй като char16_t на всички ОС заема 2 байта и не разваля съвместимостта на кода между Windows и Linux.

Не мина и без малки приключения. Например, в STLPort итероторът можеше неявно да се каства в указател към елемент, и в някои части на нашия код това беше използвано. В новите библиотеки това вече не беше възможно, и тези места трябваше да бъдат анализирани и пренаписвани ръчно.

И така, миграцията на кода приключи, кодът се компилира за всички ОС. Време е за тестове.

Тестовете след прехода показаха спад в производителността (на места до 20-30%) и увеличение на потреблението на памет (до 10-15%) в сравнение с предишната версия на кода. Това беше, в частност, свързано с неоптималната работа на стандартните низове. Затова отново трябваше да използваме наш собствен, леко преработен низ.

Също така се появи интересна особеност на реализацията на контейнерите в вградените библиотеки: празните (без елементи) std::map и std::set от вградените библиотеки алокираха памет. А в нашия код поради особеностите на реализацията на места се създават доста много празни контейнеров типа. Стандартните контейнери алокират малко памет, за един коренов елемент, но за нас това се оказа критично – в редица сценарии значително ни спадна производителността и нарасна потреблението на памет (в сравнение с STLPort). Затова заменихме в нашия код тези два типа контейнери от вградените библиотеки с тяхната реализация от Boost, където тези контейнери нямат такава особеност, и това реши проблема с забавянето и увеличеното потребление на памет.

Както често се случва след мащабни промени в големи проекти, първата итерация на изходниците не работеше без проблеми, и тук ни беше от полза, в частност, поддръжката на отладъчни итератори в Windows реализцията. Стъпка по стъпка напредвахме, и до пролетта на 2017 (версия 8.3.11 1С:Предприятия) миграцията беше завършена.

Итог

Преходът към стандарт C++14 отне около 6 месеца. По-голямата част от времето по проекта работеше един (но много опитен) разработчик, а на финалния етап се присъединиха представители на екипите, отговорни за конкретни области - UI, клъстера на сървърите, инструментите за разработка и администрация и т.н.

Преходът значително опрости работата ни по миграцията към най-новите версии на стандарта. Например, версия 1С:Предприятие 8.3.14 (в разработка, релизът е планиран за началото на следващата година) вече е преведена на стандарта C++17.

След миграцията разработчиците получиха повече възможности. Ако преди имахме своя доработена версия на STL и едно име пространство std, то сега в име пространството std се намират стандартните класове от вградените библиотеки на компилатора, в име пространството stdx - нашите, оптимизирани за нашите задачи низове и контейнери, в boost - новата версия на boost. И разработчикът използва класовете, които оптимално отговарят на решенията на задачите си.

Помага в разработката и „родната“ реализация на конструкторите за преместване (move constructors) за редица класове. Ако класът има конструктор за преместване и този клас се постави в контейнер, STL оптимизира копирането на елементи в контейнера (например, когато контейнерът се разширява и е необходимо да се промени capacity и да се реалоцира памет).

Лъжичка катран

Най-вероятно най-некошерното (но не критично) последствие от миграцията - срещнахме се с увеличаване на обема obj файлове, и крайният резултат от билда със всички междинни файлове започна да заема около 60 - 70 Гб. Такова поведение е свързано със специфичните характеристики на съвременните стандартни библиотеки, които станаха по-малко критични към обема на генерираните служебни файлове. Това не влияе на работата на компилираното приложение, но създава редица неудобства в разработката, по-специално увеличава времето за компилация. Също така се увеличават изискванията за свободно място на диска на билд сървърите и компютрите на разработчиците. Нашите разработчици паралелно работят върху няколко версии на платформата, и стотици гигабайти междинни файлове понякога създават трудности в работата. Проблемът е неприятен, но не критичен, решението му за момента отложихме. Като един от вариантите за решаване на проблема разглеждаме техниката unity build (я, в частност, я използвам Google при разработката на браузъра Chrome).

Източник: habr.com