Как преведохме 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, звън на 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:Предприятие) миграцията беше завършена.

Резултати от

Преходът към стандарта 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