«Да сколько ты ещё будешь собирать?» — фраза, которую каждый разработчик произносил хотя бы раз посреди ночи. Да, сборка бывает долгой и от этого никуда не деться. Нельзя же просто так взять и распараллелить всё это дело не на каких-то жалких 8 – 12 ядер, а так, чтобы на 100+. Или всё-таки можно?
Мне нужно больше ядер!
Как вы могли заметить, речь сегодня пойдёт как раз о том, как можно ускорить компиляцию. И нет, в этот раз будут рассмотрены не какие-то специфичные механизмы, а самое обычное распараллеливание. Ну, тут всё, казалось бы, просто – выставляем доступное физически количество ядер, нажимаем на build и идём пить условный чай.
Но с ростом кодовой базы время компиляции постепенно растёт и однажды оно станет настолько большим, что полностью проект будет собираться разве что ночью. Поэтому нужно подумать о том, как бы всё это ускорить. Вокруг же сидят довольные коллеги, которые занимаются своими программистскими делами, а их машины тихо и не напрягаясь выводят немного текста на экраны.
Беседа об ускорителе CPU-интенсивных вычислений / Виктор Гершгорн (IncrediBuild)
«Взять бы у этих бездельников ядра» — могли вы подумать. И правильно бы сделали, ведь это вполне себе можно реализовать. Но не нужно, конечно, принимать мои слова близко к сердцу и вооружаться паяльником. Впрочем, это уже на ваше усмотрение 🙂
Отдай!
Так как реквизировать машины коллег нам вряд ли кто-либо даст, будем пользоваться обходными путями. Даже если у вас и получилось убедить своих коллег поделиться железом, всё равно пользы от лишних процессоров у вас не будет, разве что можете выбрать себе тот, который пошустрее. А нам нужно то решение, которое каким-то образом позволит запускать дополнительные потоки сборки на удалённых машинах.
Благо среди тысяч категорий всякого полезного ПО, затесалась и нужная нам — система распределённой сборки. Программы этой категории делают именно то, что нам было и нужно: выдают на время простаивающие ядра коллег и при этом делают это без их ведома в автоматическом режиме. Разве что сперва нужно будет поставить всё это на их машины, но об этом немного позже.
На ком будем проверять?
Для того, чтобы убедиться, что всё функционирует действительно хорошо, нужно было найти качественного подопытного. Так как у нас уже не раз были в статьях и Chromium и Linux, а выделиться как-то хотелось, нужно было найти что-нибудь новое. Поэтому я пошёл в сторону открытых игр (а где же ещё искать большие проекты?). И как вы увидите ниже, очень пожалел об этом решении.
Впрочем, поиск чего-то объёмного труда не составил, да и мне «повезло» повстречать открытый проект на Unreal Engine. Вдуматься только! Я действительно до момента написания этой статьи и подумать не мог, что на UE бывает Open Source.
Итак, герой этой статьи: Unreal Tournament. Только вы не спешите сразу переходить по ссылке, так как вам может понадобиться пара дополнительных кликов — подробности *тут*.
Мощный метод проверки кода на баги
Да будет сборка на 100+ ядер!
В качестве примера системы распределённой сборки я, пожалуй, остановлюсь на IncrediBuild. Не то, чтобы у меня был большой выбор — у нас была уже лицензия IncrediBuild на 20 машин. Нет, есть, конечно, открытый distcc, но он не так прост в настройке, да и к тому же практически все машины у нас под Windows.
Итак, первым делом нужно поставить агентов на машины других разработчиков. Есть два способа:
- попросить коллег в местном Slack;
- воззвать к силам сисадмина.
Разумеется, как и любой другой наивный человек, я написал сперва в Slack. Спустя пару дней еле-еле дошло до 12 машин из 20. После этого я воззвал к силам сисадмина и, о чудо, заветная двадцатка была у меня в руке. Так что теперь у меня было около 145 ядер (+/- 10) 🙂
За исключением необходимости поставить агентов (делается это парой кликов в установщике), нужно было поставить себе координатора. Это делается немного сложнее, поэтому оставлю ссылку на доки.
Итак, у нас теперь есть сетка на стероидах, поэтому пришло время добраться до Visual Studio. Выбираем в плагине сборку. А вот и нет 🙂
Если вдруг вы и сами захотите попробовать, то учтите, что сперва нужно собрать проекты ShaderCompileWorker и UnrealLightmass. Так как они не большие, я собрал их локально. Вот теперь уже можно нажать на заветную кнопку:
Итак, какая же получилась разница?
Как видите, нам удалось ускорить сборку с 30 минут до почти 6! Очень даже нехило. Кстати, запуск проводился посреди рабочего дня, так что примерно таких цифр можно ожидать и не на синтетическом тесте. Впрочем, от проекта к проекту разница может быть разной.
Что ещё можно ускорить?
Помимо сборки можно натравить IncrediBuild на любую тулзу, которая плодит много подпроцессов. Как вы, может, обратили внимание, я работаю в PVS-Studio. Поэтому конечно же я не могу обойти стороной возможность скормить ему и наш анализатор.
Профит в быстром анализе примерно такой же, как и в быстрой сборке: возможность локальных прогонов перед коммитом. Конечно, всегда есть желание залить всё сразу в мастер; но обычно тимлид бывает не в восторге от подобных действий, особенно когда валятся ночные прогоны на сервере. Поверьте мне – я валил 🙁
Настраивать особенно анализатор не нужно, разве что нам не повредит указать старые-добрые 145 потоков в настройках:
Ну и стоит указать местной сборочной системе кто тут анализатор:
Итак, пришло время нажать на сборку ещё раз и насладиться ускорением:
Вышло около семи минут, что подозрительно похоже на время сборки. Тут я и подумал, что видимо забыл добавить флаг. Зашёл в настройки и увидел, что всё на месте. Такого я не ожидал, поэтому отправился курить мануалы.
Попытка запуска PVS-Studio #2
Спустя какое-то время я вспомнил про версию Unreal Engine, которая используется в этом проекте:
Не то, чтобы это плохо само по себе, но флаг -StaticAnalyzer появился много позже. Поэтому интегрироваться напрямую не то, чтобы было возможно. Примерно на этом моменте я уже начал задумываться о том, чтобы забить на всё это дело и уйти пить кофе.
После пары кружек бодрящего напитка у меня возникла мысль всё-таки дочитать туториал по интеграции до конца. Помимо указанного выше способа есть ещё и мониторинг компиляции. Это как раз тот вариант, когда ничего уже не помогает.
Первым делом включим сервер мониторинга:
CLMonitor.exe monitor
Эта штука будет крутиться на фоне и следить за тобой вызовами компилятора. Но она не может отслеживать происходящее в IncrediBuild, поэтому придётся один раз собрать без него.
На фоне предыдущего запуска локальная пересборка выглядит очень бедно:
Total build time: 1710,84 seconds (Local executor: 1526,25 seconds)
Теперь сохраним то, что насобирали в отдельный файл:
CLMonitor.exe saveDump -d dump.gz
Дальше можно будет пользоваться этим дампом, пока вы не добавите новый файл в проект. Да, это не так удобно, как с флагом, но ничего не поделаешь – версия движка слишком старая.
Сам же анализ запускается вот этой командой:
CLMonitor.exe analyzeFromDump -l UE.plog -d dump.gz
Только не стоит его так запускать, ведь мы же хотим его запустить под IncrediBuild. Так что закинем эту команду в analyze.bat. И создадим рядом файл profile.xml:
И теперь мы можем запустить всё с нашими 145-ю ядрами:
ibconsole /command=analyze.bat /profile=profile.xml
И как это выглядит в Build Monitor:
К нам закралась ещё одна проблема. И в этот раз дело не в то, что кто-то что-то не поддерживает. Сборка Unreal Tournament оказалась несколько специфичной.
Попытка запуска PVS-Studio #3
Если посмотреть внимательно, то это не ошибки анализа, а неудачи при препроцессировании исходников. Причём, причина данного фейла была одна и та же:
. Build.h(42): fatal error C1189: #error: Exactly one of [UE_BUILD_DEBUG UE_BUILD_DEVELOPMENT UE_BUILD_TEST UE_BUILD_SHIPPING] should be defined to be 1
Так в чём проблема? Всё довольно просто – препроцессор требует, чтобы только один из следующих макросов имел значение 1:
- UE_BUILD_DEBUG;
- UE_BUILD_DEVELOPMENT;
- UE_BUILD_TEST;
- UE_BUILD_SHIPPING.
Да, вроде как всё собиралось раньше, а теперь что-то страшное вылетело. Пришлось закопаться в логи, а точнее в дамп компиляции. Там-то проблема и нашлась. Дело было в том, что эти макросы объявляются в местном precompile header, а мы хотим только препроцессировать. Так что пришлось добавить все эти макросы вручную:
#ifdef PVS_STUDIO #define _DEBUG #define UE_BUILD_DEVELOPMENT 1 #define WITH_EDITOR 1 #define WITH_ENGINE 1 #define WITH_UNREAL_DEVELOPER_TOOLS 1 #define WITH_PLUGIN_SUPPORT 1 #define UE_BUILD_MINIMAL 1 #define IS_MONOLITHIC 1 #define IS_PROGRAM 1 #define PLATFORM_WINDOWS 1 #endif
Самое начало файла build.h
И уже с этим небольшим костылём элегантным решением можно запустить анализ. Причём сборка не сломается, так как мы воспользовались макросом PVS_STUDIO.
Итак, долгожданные результаты анализа:
Согласитесь, почти 15 минут вместо двух с половиной часов – это очень хорошее ускорение. Сложно представить, чтобы вы могли пить кофе 2 часа к ряду и ни у кого не возникло бы сомнений на ваш счёт. А вот 15 минутный перекур вопросов не вызывает. Наверно.
И что у нас в итоге?
Разумеется, что в идеальном мире увеличение количества потоков в N раз увеличило бы скорость сборки в N раз. Но живём мы в совершенно ином мире, поэтому стоит учитывать локальную нагрузку на агентов (удалённые машины), нагрузку на сеть, время на организацию всего этого дела и ещё много деталей, которые скрыты под капотом.
Впрочем, ускорение действительно есть и местами оно позволяет не просто запускать полную сборку или же анализ раз в день, а делать это куда чаще. Например, после каждого фикса или же перед коммитами. А теперь предлагаю посмотреть на то, как это всё выглядит в одной таблице:
Источник: habr.com
Виртуальный геймерский суперкомпьютер
Компания The Coalition преобразует виртуальные машины Azure в «виртуальный суперкомпьютер» IncrediBuild с 700 ядрами, выпуская по две игры класса AAA в год
By Пресс-центр 25 December, 2017
Студия разработки игр The Coalition, являющаяся подразделением корпорации Microsoft, проторила себе путь на вершину индустрии игр класса AAA. Как понятно из названия, The Coalition занимается исключительно разработкой, поддержкой и внедрением инноваций в один из ведущих шутеров от первого лица — Gears of War после того, как Microsoft приобрела франчайзинговую лицензию у другого клиента IncrediBuild — Epic Games.
200 сотрудников студии, базирующейся в живописном районе Ванкувера (Британская Колумбия), напряженно работали над рекордной серией игр Gears с тем, чтобы миллионы геймеров могли погрузиться в постапокалиптическую атмосферу планеты Сера на платформах Xbox One и Windows 10.
Пользуясь решением IncrediBuild в течение длительного времени, разработчики The Coalition интегрировали его с Microsoft Azure, чтобы беспрепятственно расширяться до сотен дополнительных ядер в среде гибридного облака.
Проблема
2016 год стал поистине невероятным годом для поклонников Gears по всему миру. С выходом обеих версий Gears of War: Ultimate Edition — высококачественного ремейка первой игры легендарной серии и вышедшей позднее следующей части саги — Gears of War 4, ажиотаж достиг своего предела. Разработчикам The Coalition было необходимо справиться с ним и преодолеть внешние и внутренние проблемы производства.
Во внутренней среде постоянное интенсивное использование игрового движка Unreal Engine 4 (UE4), по словам руководителя ИТ-подразделения The Coalition Джо Вогта (Joe Vogt), представляло собой существенную проблему. «Мы используем Unreal Editor 4 компании Epic в качестве основного инструмента для создания такого содержимого, как уровни, персонажи и средства передвижения. Редактору требуется скомпилировать все шейдеры заранее, в некоторых ситуациях открытие уровня может занимать до 30 минут». Так как более 100 членов команды ежедневно используют UE4, для ускорения времени компиляции шейдеров требовалось конкретное решение. «Если начать делать расчеты, выясняется, что 30 минут времени уходит только на открытие уровня, 4–5 раз за день, то есть третью часть своего рабочего дня можно потратить впустую», — утверждает Вогт.
На внешнем уровне ряд сторонних партнеров по аутсорсингу в сотрудничестве с The Coalition предоставлял студии возможность производства с элементами дополненной реальности. Среди этих партнеров были более мелкие компании, не имевшие доступа к выделенным машинам IncrediBuild, которые требовались для компиляции шейдеров и эффективного использования UE4. В такой ситуации у партнеров возникла острая потребность в решении.
«Платформа IncrediBuild вне всякого сомнения влияет на нашу способность выполнять итерации и двигаться вперед. Без нее мы не смогли бы добиться каких-либо результатов», – Джо Вогт, руководитель ИТ-подразделения, студия The Coalition.
Решение, предложенное IncrediBuild
Являясь самостоятельной студией разработки в составе корпорации Microsoft, The Coalition может воспользоваться преимуществами платформы облачных вычислений Azure. Платформа Microsoft Azure предоставила студии The Coalition простой и эффективный способ развертывания сотен выделенных ядер ЦП, предназначенных для ускорения локальных процессов компиляции шейдеров.
The Coalition освоила уникальную технологию виртуализации IncrediBuild на уровне процессов, чтобы увеличить производительность Azure сверх возможностей отдельной виртуальной машины Azure. В студии были развернуты десятки 64-ядерных виртуальных машин Azure, работающих под управлением IncrediBuild. Они предоставлялись в качестве «виртуального суперкомпьютера» для локальных художников-аниматоров, которым требовалось использовать такие ресурсы для компиляции шейдеров.
Используя возможности виртуальных машин Azure, платформа IncrediBuild «на лету» формирует виртуальную среду, в которой все ядра работают совместно для единого выполнения процессов. Реализуемое таким образом масштабирование платформы позволяет удовлетворить очень обширные потребности в выполнении процессов и без особых усилий ускорить не только компиляцию шейдеров, но и время загрузки уровней в UE4 для разработчиков, программистов и дизайнеров.
Внутреннее ускорение: масштабирование Azure в пределах компании
Студии The Coalition потребовалось почти три года на создание игры Gears of War 4. В течение этого времени выделенные ресурсы IncrediBuild использовались в локальной среде для роста производительности UE4 и ускоренной компиляции кода. Как это обычно бывает при крупномасштабной разработке игр, самый разгар работы пришелся на последние шесть месяцев производства, так как студия приложила все усилия, чтобы выпустить игру в срок. Во время этого критического этапа студии The Coalition требовался способ расширить ресурсы IncrediBuild, не добавляя дополнительного локального оборудования.
Студии The Coalition удалось развернуть крупную ферму IncrediBuild на основе технологий Azure с подключениями, реализуемыми за счет цепей Microsoft Azure ExpressRoute.
В результате агенты, работающие на основе Azure, отображаются для ответственного за процесс производства сотрудника The Coalition в качестве «локальных» ресурсов. Таким способом было развернуто 700 ядер, которые использовались на этапе производства итоговой версии Gears of War 4, что позволило существенно сократить время компиляции шейдеров и кода.
По словам Вогта, «платформа IncrediBuild вне всякого сомнения влияет на нашу способность выполнять итерации и двигаться вперед. В наш итеративный процесс входит создание сборки игры, тестирование ее выполнения, поиск ошибок и информирование о них, устранение этих ошибок и производство очередной сборки, иногда два раза в день. Затем цикл повторяется. Суть в том, чтобы пользователь мог максимально оперативно получить самую последнюю версию всех данных и вернуться к работе. Без IncrediBuild наш процесс разработки бы остановился».
Внешнее ускорение: предоставление небольшим компаниям-партнерам столь необходимой подпитки
Для обеспечения производительности внешних партнеров ресурсы Azure и IncrediBuild были переданы на аутсорсинг, чтобы придать кратковременный, но решающий импульс и поддержать партнеров, испытывающих нехватку вычислительных мощностей. «В одном случае, — вспоминает Вогт, — партнеру не удалось предоставить на месте выделенных емкостей фермы IB, что привело к длительному ожиданию пользователей при открытии масштабных уровней Gears of War 4 в UE4».
И на этот раз студия The Coalition использовала гибкие особенности служб на основе Azure и технологию параллельных вычислений IncrediBuild в одном пакете. Единственным отличием на этот раз стало то, что студия предоставила внешним партнерам возможность изменять уровень своей производительности, добившись при этом непревзойденного ускорения работы вне зависимости от того, насколько ограниченными ресурсами они изначально обладали.
«Мы развернули в общедоступном центре данных Azure примерно 160 ядер и настроили VPN типа «сеть-сеть» с размещением у партнера. Это позволило небольшой группе локальных пользователей Unreal Engine воспользоваться преимуществами емкости фермы IB в Azure и ускорить свою работу».
Поскольку такое взаимодействие продолжалось недолго, как и многие другие микрозадачи, входящие в процесс разработки игры, команда The Coalition использовала службы на основе Azure посредством серии гибридных облаков в течение ограниченного времени, которое требовалось для поддержки IncrediBuild, вместо того, чтобы покупать дорогостоящее оборудование, которое не позволило бы в полной мере оценить его практическую ценность.
Подводя итоги
Выпустив две игры класса AAA за год, команда The Coalition добилась невозможного. Она смогла справиться с этой задачей отчасти благодаря:
- Раскрытию полного потенциала Azure с помощью IncrediBuild. Высокопроизводительные возможности платформы IncrediBuild позволили создать виртуальный суперкомпьютер Azure с 700 ядрами, значительно превосходящий ограничение самой мощной обособленной виртуальной машины Azure. В результате The Coalition достигла поистине космических масштабов развертывания и смогла обеспечить максимальное ускорение.
- Борьбе с ненужными «пожирателями времени». Использование вычислительных мощностей Azure предоставило IncrediBuild возможность существенным образом сократить время компиляции шейдеров и сборки кода. При этом изменилось и время загрузки уровней UE4, а занятый на этапе производства персонал теперь может не ждать, а продолжать работать.
- Ускорению работы сторонних исполнителей-партнеров. Ограниченные ресурсы партнеров не являлись препятствием, поскольку компания The Coalition выделила ядра Azure, работавшие под управлением платформы IncrediBuild, для помощи сторонним компаниям, не обладавшим достаточными мощностями.
- Экономии ресурсов и гибкому развертыванию. Масштабирование в соответствии с внутренними и внешними потребностями, осуществляемое в режиме реального времени, позволило The Coalition выделять решения на любой период времени и точно в том объеме, который требуется.
Источник: news.microsoft.com