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

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

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

• Клъстер на сървър за приложения, работи на 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
• Среда за развитие 1C: Средства за разработка на предприятия, написан на Java
• сървър Системи за взаимодействие

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

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

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

Опровержение

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

Това, което имахме

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

vector<vector<int> > 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 двигателя, който работи на подобни принципи (виж библиотеката безумие).

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

1. За кратки стойности се използва вътрешен буфер в самия низов обект (не изисква допълнително разпределение на паметта).
2. За всички останали се използва механика Копиране при запис. Стойността на низа се съхранява на едно място и се използва брояч на справки по време на присвояване/модифициране.

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

Трети начин

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

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

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

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

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

Преход

Така че трябваше да заменим използването на 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 1C:Enterprise) миграцията приключи.

Резултати от

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

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

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

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

Полет в мехлема

Може би най-неприятната (но не критична) последица от миграцията е, че сме изправени пред увеличаване на обема obj файлове, а пълният резултат от компилацията с всички междинни файлове започна да заема 60–70 GB. Това поведение се дължи на особеностите на съвременните стандартни библиотеки, които са станали по-малко критични към размера на генерираните сервизни файлове. Това не засяга работата на компилираното приложение, но причинява редица неудобства при разработката, по-специално увеличава времето за компилиране. Изискванията за свободно дисково пространство на сървъри за изграждане и на машини за разработчици също се увеличават. Нашите разработчици работят паралелно върху няколко версии на платформата и стотици гигабайти междинни файлове понякога създават затруднения в работата им. Проблемът е неприятен, но не и критичен, засега отлагаме решаването му. Разглеждаме технологията като един от вариантите за решаването му изграждане на единство (по-специално Google го използва при разработването на браузъра Chrome).

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