Comments 32
Я слышал, что когда-нибудь в C++ изобретут модули.
Я знаю :(. Вот когда их поддержку завезут вендоры, наверное можно будет попробовать. С тем же успехом можно выносить код в либы.
Их с тех пор как добавили, никаких новых комитов в компилятор по этой теме не было, всем пофиг
Комиты на модули в GCC идут еженедельно. Clang тоже неплохо уже модули поддерживает.
В MSVC\STL тоже всё хорошо. Видно что модули у них в высоком приоритете https://github.com/microsoft/STL/issues/4700 и видно что процесс движется https://github.com/microsoft/STL/issues/1694
Модули хотят очень многие вендоры - возможность ускорить сборку в 3-10 раз, это очень крутое преимущество.
Но модули затрагивают сразу очень много различных частей языка, что и усложняет их внедрение и разработку:
компилятор - новый синтаксис, новое поведение с сериализацией внутреннего представления, немереное количество проблем с краевыми случаями
оптимизатор - новые области видимости позволяют новые оптимизации
линкер (или его аналог) - участвует при формировании файла модуля
сборочные тулчейны - они должны автоматически обнаруживать зависимости исходников от модуля
препроцессор - нужен режим для тулчейнов, для обнаружения модулей (порой делается отдельной утилитой)
ABI - появляются сущности, "прикреплённые" к модулю
стандартная библиотека - большая работа по созданию модуля std и его тестированию (макросы больше не экспортируются, модуль должен нормально работать с include из стандартной библиотеки)
Умножьте всё это на 2 (модули же работают в двух режимах: import "header" и import module), а для MSVC умножьте ещё на 2 (IDE использует другой компиляторный фронтенд для подсветки синтаксиса и подсказок) :-(
Скажите, а по новинкам C++26 вы будете статью делать? Очень люблю ваш цикл статей про современные стандарты и как там дела у компиляторов с их поддержкой (если я не ошибаюсь, в clang всё никак не завезут std::jthread и std::expected)
Я очень хочу попробовать модули и чтобы они не лагали; в последний раз билд с ними был медленнее чем обычная связка .h/.cpp, а в шланге так вообще приходилось руками прописывать карту линковки модулей в отдельном файле, а ещё в gcc от фазы луны зависит не взорвётся ли у тебя кэш компиляции. Жду ( T _ T )
Мы так и не смогли модули поднять в студии. То студия упадёт, то ошибки странные сыпятся, то билд подвисает. Вообщем пока неживое
На моих пет-проектах использую msvc, полёт нормальный.
Мой личный ноутбук довольно слабоват и меня дико удручало что мои проекты/мета-либы пересобираются по 5 минут, а я люблю часто делать мелкие правки и смотреть что получилось. Начал пилить абсолютно всё на модули, в самом простом их исполнении без приватных секций и прочего. Итого - время сборки с 0 практически не поменялось, а вот пересборка уже занимает не 5 минут а секунд ~15.
Счастье моё длилось не долго, ибо когда начал переносить всё на основную работу оказалось что там повсюду старые компиляторы и всё ломается если хоть что-то поменять.
Анализ зависимостей и растаскивание иерархий хедеров позволило сэкономить три минуты, время сборки проекта стало 11:25с. На всю эту работу, протаскивание этих задач через таски ушло пару месяцев рабочего времени, проект большой, за раз все не починишь, плюс приходится согласовывать свои изменения с другими командами.
А оно того стоило, с точки зрения бизнеса? Обычно при таком соотношении трудозатрат/оптимизации просто ставят железку помощнее для билд агента. Получается дешевле чем стоимость работы программиста.
Я конечно понимаю что билдов собирается довольно много, особое если проект ААА. У нас на небольшом мобильном игровом проекте может до нескольких десятков сборок собираться в течении для. Но все таки - пару месяцев работы ради 3х минут сборки, кажется чересчур.
Это суммарно, я объяснил почему так получилось. Залить комит просто так не получится, особенно если он затрагивал какое-то легаси или чужой код на несколько тысяч строк, которое надо было разделить, согласовать с лидами других команд изменения, иногда убедить и показать снижение, 10-15 итераций на ревью это было ещё термином "проскочил неглядя" ;) и потом я не помню когда в час было меньше десятка комитов, собственно время компиляции и было основным мотиватором
В какой-то момент проблема перестаёт затыкаться железом, если мы говорим про локальные сборки. Может помочь распределённая компиляция и кеши, например Incredibuild. Но тут нужно смотреть на стоимость лицензий. Да и весь отдел должен находиться локально в одном офисе.
25K строк c++23 с пИмплами и урезаниями хедеров в многопотоке компилятся 2 мин (Ryzen 1700). Столько будет компилится хедер-онли код в 2К, если все файлы будут в .h
А у вас сборка проекта на индивидуальных машинах всегда полная? Каждый пересобирает себе все 27 тыс файлов? Не думали зашарить например на команду дневные бинарные билды и пусть разработчики качают их себе и пересобирают локально только свои компоненты?
Вот тут еще (статье почти 7 лет) https://habr.com/ru/companies/pvs-studio/articles/344534/, пробовали incredibuild, icecream. Но похоже проект все же не настолько большой, чтобы почувстовать профит от инкредибилд, который к тому же требует от компаний больше 100 человек помашинную оплату на разработчика, тут уже дешевле еще пару лишних агентов поднять. Icecream подтупливал по сетке и профита не получалось. Плюс с нашими pch когда даже гиговый pch начинает перекидываться между агентами, то тоже ничего хорошего не выходит. Первая сборка после синка репы полная, стоило наверное рассказать об этом, часть хедеров генерится из конфигов, которые могут менять дизайнеры, это осознное решение, лучше один раз перекомпилить, чем потом ловить странные баги в игре. Потом уже докомпиливается конечно, на агента сборка всегда полная.
Нужно ли каждый раз собирать с нуля проект, после подтягивания репы? Даже если вы генерируете файлы, обычно правильная настройка add_custom_command в CMake позволяет отдать триггеры ребилда на откуп билд системе. В DEPENDS или в DEPFILE прописываются конфиги и перегенерация хедеров будет происходить только при изменении конфигов. https://blog.kangz.net/posts/2016/05/26/integrating-a-code-generator-with-cmake/
По моему опыту использования проблем с таким подходом нет, но может у вас что-то сильно экзотическое.
Статья классная, поставил плюс) Сам хотел поделиться опытом использования тулинга по профайлингу компиляции, но Вы опередили.
По pch - если архитектура проекта позволяет, можно использовать SHARED_PCH, экономя место на диске и переиспользуя pch между таргетами.
У -ftime-trace clang есть проблема с агрегацией данных по всем файлам. Удобно использовать такую утилиту:
https://github.com/aras-p/ClangBuildAnalyzer
Для сборки сninja скрипт построит flamegraph со всеми файлами:
https://github.com/nico/ninjatracing
После прочтения появились вопросы:
Вы часто собираете релизные билды локально? Как так вышло, что lto попал в локальные билды разработчикам?
Нет ли проблем в процессе с выключенными аналзаторами? Вроде работа сделана, ПР залит в дев ветку, после сборки на агенте ещё ПР делать на исправление)
На билд агентах не используете unity батчинг? Локально, как я понял, не используете.
Пробовали ли extern template?
А вы пробовали такие вещи как “unity build” (там правда свои нюансы появляются)? Или тот же sccache, который вроде как бесплатный, но не факт что умеет с msvc фронтендом (с clang-cl вроде должен работать)?
Se la vi, как говорится
Если это про французский, то правильно c'est la vie :-)
С одной стороны, вроде как, серьезно ускорили компиляцию. Хотя, если честно, меня удивило, что программисты, собирающие в MS Visual Studio, изначально не использовали precompiled headers. Если в ней создаешь даже простейший проект на MFC, в нем изначально pch уже есть.
C другой стороны, Вы пишете:
А вот оставшиеся 15% или около 15 минут мы занимались "настоящей работой", собирали сердце проекта - бинарь.
Даже если бы вы сократили время компиляции до нуля, полная сборка с двух часов ускорилась до часа 40 минут? И это при том, что:
На всю эту работу, протаскивание этих задач через таски ушло пару месяцев рабочего времени, проект большой, за раз все не починишь, плюс приходится согласовывать свои изменения с другими командами.
Оно точно того стоило? При переделке большого проекта можно и ошибок кучу внести, да и вообще серьезно поломать что-нибудь, а проявиться оно может когда-нибудь потом. Может, и правда, дешевле было бы машину для сборки помощнее собрать?
Del
Unity build не пробовали?
Я разделил код по частоте изменений: сторонние либы, движок, тулзы и тд. Перекомпилируется отдельно, а дальше либы цепляются.
Было бы классно если бы кто-нибудь поделился реальным опытом сборки роботов для высокочастотной алгоритмической торговли. Платформы и технологии, насколько я понимаю, примерно те же самые. Но вот лайфхаки вроде отключить юнит-тесты там точно не работают. А при этом требования к времени сборки наверняка более жесткие. Потому что время-деньги-цигель-цигель.
Ну вы же понимаете, что локально вот эти 3к тестов обычному разработчику никак не помогут, они даже не запускались после сборки редактора. Так зачем их компилировать? А время они тратят, и прилично так тратят.
Я могу чего-то не догонять, но изменения в торговые стратегии могут вноситься (как минимум) несколько раз в день, часть этих изменений обеспечивается настройками/параметрами, а часть требует внесения изменений в код. И выпускать новую версию робота без прогонки всех юнит-тестов - ну такое.
А тут мы экономили время на компиляции, если компиляции проходила успешно комит отправляется на мерж. Назовём его миникомит. Следом стартовал уже полноценный коммит с тестами, анализом кода, сборкой билда и тд. Ситуация что прям с колен оно уйдёт в прод нереальная, между комитом в дев ветку и когда оно дойдёт то qa тимы на тестирование обычно проходит пару дней
Возможно там над стратегиями есть какой-то общий сервис-наблюдатель, который неудачной стратегии понижает приоритет либо вообще отключает. И параллельно куча стратегий бегает, поэтому отказ или устаревания нескольких штук некритичны.
Но опыта в высокочастотной торговле у меня нет, это то как я бы сделал, было бы интересно послушать тех кто этим занимался.
Судя по тому, что просачивается на reddit, к примеру, есть люди которые именно такой подход и используют:
I run 20 or strategies all of the time - plus I have another 30 in my back pocket which I use during specific situations
currently running 40 short/medium term strategies, and one longer term portfolio
4 live
Хотя есть и те у кого она (стратегия) одна единственная:
I try to trade one idea per market
I have one model for everything. We tweak the model and not a “strategy.”
А кто-то работает с адаптивными моделями
Но это уже куда-то в сторону, в тему обсуждаемой статьи (сокращение времени на компиляцию C++) не вписывается.
Спасибо за статью
Я ничерта не шарю за плюсы, но все равно спрошу - а почему нельзя собирать только то, что изменилось с прошлого билда? Или как уже сказали другие - почему нельзя разбить код на либы и не компилить их, а использовать готовые бинари?
можно, если это локальная машина разработчика. Для билдфермы, которая поднимает образ в облаке на каждый комит смысла хранить промежуточные данные нет, больше времени уйдет на синк. Есть решения хранить объектники отдельно от сорцов и подтягивать только изменившееся по хешам, но чтото они не прижились, Есть решения распределенного билда, но при здоровенных pch профит от них стремится к нулю. Опять же для этого приходится держать физические агенты постоянно. Так что в какойто моменты мы пришли к сборкам и тестам в облаке, оно к тому же и по деньгам получалось на порядок дешевле, но это все лирика, не я этим занимался. Да и при утреннем синке лучше сделать полный ребилд, была куча странных багов связанных с либами у которых поменялись хедеры но остались старые объектники. Насчет либ, чтото в либах, чтото нет.
Тяжелый H[header]