Xoreax incredibuild что это
ru.knowledgr.com
Описание
Incredibuild предлагает следующие решения для ускорения:
1) IncrediBuild для Визуальной Студии, которая позволяет использовать IncrediBuild в качестве полной Визуальной интеграции Студии, чтобы ускорить время изготовления для всех Визуальных версий Студии, включая Визуальную Студию 2012. Удостоверенный
Visual Studio Industry Partner.
2) IncrediBuild для Делают и Строят Инструменты, который ускоряется, строят платформы включая, Делают, MSBuild, Gmake, VSimake, Пробка, nAnt, Jom, SH, Питон, VsiMake, BJam, Пробка +, и больше. Некоторые строят доступный для ускорения, включают Microsoft, Intel, Nvidia, CUDA (nvcc), Sony PlayStation, Нинтендо 3DS, Wii U, GCC и ccppc.
3) IncrediBuild для Инструментов Dev, который позволяет использованию технологии распределения IncrediBuild распределять процессы, которыми управляют, строит инструменты (сделайте варианты, SCons, ПРОБКУ и других), подлинники и пользовательские приложения. Фактически любой потенциально распределяемый основанный на MS Windows процесс может быть ускорен через эту технологию.
4) IncrediBuild для играющей промышленности.
технологии краеугольного камня позади IncrediBuild есть способность создать уникальную виртуальную окружающую среду. Независимо от которого узел выполняет особую задачу, сетка IncrediBuild, вычислительная технология гарантирует, что вычислительные задачи всегда производят надежные результаты. Это достигнуто, не имея необходимость создавать и управлять системными изображениями, используя различные типы задач.
Когда распределенные рабочие места начаты, все задачи, включающие, что определенный проект выполнен, начав среду узла (файловая система, регистрация, и т.д.).). Например, если C ++ задача компилятора бежит на отдаленном узле, она использует файловую систему узла инициирования, регистрацию, и т.д. чтобы гарантировать, что собираются правильные копии файлов исходного кода.
Продукты, основанные на XGE
IncrediBuild
IncrediBuild, коммерческий продукт, развитый израильской компанией IncrediBuild (программное обеспечение Xoreax), ускоряется, задачи Windows, такие как кодекс строит, данные строят, подлинники развития, моделирования и пользовательские приложения через XGE. Когда процессом управляют, используя IncrediBuild, его подзадачами управляют через доступные машины в местной сети, используя многократные ядра где это возможно. В результате компания утверждает, что до 20x ускорение времени выполнения процесса может быть получено.
История
IncrediBuild v1.0 был введен в 2002, предложив решение для ускорения Microsoft Visual Studio 6.0 C/C ++, кодекс строит. Инструмент стал популярным в нескольких отраслях промышленности программного обеспечения, особенно отрасли промышленности CAD/CAM и игры. В 2004 это было отобрано как победитель в Журнале Разработчика игр ежегодные Пограничные Премии.
После добавляющей поддержки Визуальной Студии.NET и Визуальной Студии 2005, IncrediBuild (программное обеспечение Xoreax) добавил новый дополнительный пакет, названный «Интерфейсы XGE» к продукту IncrediBuild. Этот пакет позволяет ускорение многих процессов, бегущих на платформе Windows через Двигатель Сетки Xoreax, сетка IncrediBuild вычислительный двигатель, выставляя ряд интерфейсов основной технологии двигателя сетки IncrediBuild.
В 2008 IncrediBuild был избран «Победителем Производительности» в 18-х ежегодных Премиях Толчка.
Интерфейсы XGE
Предложения расширения Интерфейсов XGE ряд интерфейсов командной строки к Двигателю Сетки Xoreax, чтобы позволить ускорение дополнительных процессов, бегущих на платформе Windows. Следующие интерфейсы предлагаются:
Разработчик
IncrediBuild (программное обеспечение Xoreax) является израильской компанией, базируемой в Тель-Авиве с IncrediBuild как его единственный продукт продажи.
Визуальная Студия строит ускорение
«Визуальная Студия IncrediBuild C/C ++» дополнительный пакет ускоряется, Microsoft Visual Studio C/C ++ строит, распределяя C/C ++ задачи компиляции через машины в местной сети, значительно сокращая время изготовления проекта. Пакет объединяется с Визуальным ЯЗЕМ Студии и не требует никаких изменений кодекса или файлов проекта.
IncrediBuild v4.51 поддерживает версии Microsoft Visual Studio 6.0 к 2010.
IncrediBuild: Как ускорить сборку и анализ вашего проекта
Мне нужно больше ядер!
Как вы могли заметить, речь сегодня пойдёт как раз о том, как можно ускорить компиляцию. И нет, в этот раз будут рассмотрены не какие-то специфичные механизмы, а самое обычное распараллеливание. Ну, тут всё, казалось бы, просто – выставляем доступное физически количество ядер, нажимаем на build и идём пить условный чай.
Но с ростом кодовой базы время компиляции постепенно растёт и однажды оно станет настолько большим, что полностью проект будет собираться разве что ночью. Поэтому нужно подумать о том, как бы всё это ускорить. Вокруг же сидят довольные коллеги, которые занимаются своими программистскими делами, а их машины тихо и не напрягаясь выводят немного текста на экраны.
Отдай!
Так как реквизировать машины коллег нам вряд ли кто-либо даст, будем пользоваться обходными путями. Даже если у вас и получилось убедить своих коллег поделиться железом, всё равно пользы от лишних процессоров у вас не будет, разве что можете выбрать себе тот, который пошустрее. А нам нужно то решение, которое каким-то образом позволит запускать дополнительные потоки сборки на удалённых машинах.
На ком будем проверять?
Для того, чтобы убедиться, что всё функционирует действительно хорошо, нужно было найти качественного подопытного. Так как у нас уже не раз были в статьях и Chromium и Linux, а выделиться как-то хотелось, нужно было найти что-нибудь новое. Поэтому я пошёл в сторону открытых игр (а где же ещё искать большие проекты?). И как вы увидите ниже, очень пожалел об этом решении.
Впрочем, поиск чего-то объёмного труда не составил, да и мне «повезло» повстречать открытый проект на Unreal Engine. Вдуматься только! Я действительно до момента написания этой статьи и подумать не мог, что на UE бывает Open Source.
Да будет сборка на 100+ ядер!
Итак, первым делом нужно поставить агентов на машины других разработчиков. Есть два способа:
попросить коллег в местном Slack;
воззвать к силам сисадмина.
Разумеется, как и любой другой наивный человек, я написал сперва в Slack. Спустя пару дней еле-еле дошло до 12 машин из 20. После этого я воззвал к силам сисадмина и, о чудо, заветная двадцатка была у меня в руке. Так что теперь у меня было около 145 ядер (+/- 10) 🙂
За исключением необходимости поставить агентов (делается это парой кликов в установщике), нужно было поставить себе координатора. Это делается немного сложнее, поэтому оставлю ссылку на доки.
Итак, у нас теперь есть сетка на стероидах, поэтому пришло время добраться до Visual Studio. Выбираем в плагине сборку. А вот и нет 🙂
Если вдруг вы и сами захотите попробовать, то учтите, что сперва нужно собрать проекты ShaderCompileWorker и UnrealLightmass. Так как они не большие, я собрал их локально. Вот теперь уже можно нажать на заветную кнопку:
Итак, какая же получилась разница?
Как видите, нам удалось ускорить сборку с 30 минут до почти 6! Очень даже нехило. Кстати, запуск проводился посреди рабочего дня, так что примерно таких цифр можно ожидать и не на синтетическом тесте. Впрочем, от проекта к проекту разница может быть разной.
Что ещё можно ускорить?
Помимо сборки можно натравить IncrediBuild на любую тулзу, которая плодит много подпроцессов. Как вы, может, обратили внимание, я работаю в PVS-Studio. Поэтому конечно же я не могу обойти стороной возможность скормить ему и наш анализатор.
Профит в быстром анализе примерно такой же, как и в быстрой сборке: возможность локальных прогонов перед коммитом. Конечно, всегда есть желание залить всё сразу в мастер; но обычно тимлид бывает не в восторге от подобных действий, особенно когда валятся ночные прогоны на сервере. Поверьте мне – я валил 🙁
Настраивать особенно анализатор не нужно, разве что нам не повредит указать старые-добрые 145 потоков в настройках:
Ну и стоит указать местной сборочной системе кто тут анализатор:
Итак, пришло время нажать на сборку ещё раз и насладиться ускорением:
Вышло около семи минут, что подозрительно похоже на время сборки. Тут я и подумал, что видимо забыл добавить флаг. Зашёл в настройки и увидел, что всё на месте. Такого я не ожидал, поэтому отправился курить мануалы.
Попытка запуска PVS-Studio #2
Спустя какое-то время я вспомнил про версию Unreal Engine, которая используется в этом проекте:
После пары кружек бодрящего напитка у меня возникла мысль всё-таки дочитать туториал по интеграции до конца. Помимо указанного выше способа есть ещё и мониторинг компиляции. Это как раз тот вариант, когда ничего уже не помогает.
Первым делом включим сервер мониторинга:
Эта штука будет крутиться на фоне и следить за тобой вызовами компилятора. Но она не может отслеживать происходящее в IncrediBuild, поэтому придётся один раз собрать без него.
На фоне предыдущего запуска локальная пересборка выглядит очень бедно:
Теперь сохраним то, что насобирали в отдельный файл:
Дальше можно будет пользоваться этим дампом, пока вы не добавите новый файл в проект. Да, это не так удобно, как с флагом, но ничего не поделаешь – версия движка слишком старая.
Сам же анализ запускается вот этой командой:
Только не стоит его так запускать, ведь мы же хотим его запустить под IncrediBuild. Так что закинем эту команду в analyze.bat. И создадим рядом файл profile.xml:
И теперь мы можем запустить всё с нашими 145-ю ядрами:
И как это выглядит в Build Monitor:
Что-то много ошибок на этом графике, не так ли?
К нам закралась ещё одна проблема. И в этот раз дело не в то, что кто-то что-то не поддерживает. Сборка Unreal Tournament оказалась несколько специфичной.
Попытка запуска PVS-Studio #3
Если посмотреть внимательно, то это не ошибки анализа, а неудачи при препроцессировании исходников. Причём, причина данного фейла была одна и та же:
Так в чём проблема? Всё довольно просто – препроцессор требует, чтобы только один из следующих макросов имел значение 1:
Да, вроде как всё собиралось раньше, а теперь что-то страшное вылетело. Пришлось закопаться в логи, а точнее в дамп компиляции. Там-то проблема и нашлась. Дело было в том, что эти макросы объявляются в местном precompile header, а мы хотим только препроцессировать. Так что пришлось добавить все эти макросы вручную:
Самое начало файла build.h
И уже с этим небольшим костылём элегантным решением можно запустить анализ. Причём сборка не сломается, так как мы воспользовались макросом PVS_STUDIO.
Итак, долгожданные результаты анализа:
Согласитесь, почти 15 минут вместо двух с половиной часов – это очень хорошее ускорение. Сложно представить, чтобы вы могли пить кофе 2 часа к ряду и ни у кого не возникло бы сомнений на ваш счёт. А вот 15 минутный перекур вопросов не вызывает. Наверно.
И что у нас в итоге?
Разумеется, что в идеальном мире увеличение количества потоков в N раз увеличило бы скорость сборки в N раз. Но живём мы в совершенно ином мире, поэтому стоит учитывать локальную нагрузку на агентов (удалённые машины), нагрузку на сеть, время на организацию всего этого дела и ещё много деталей, которые скрыты под капотом.
Впрочем, ускорение действительно есть и местами оно позволяет не просто запускать полную сборку или же анализ раз в день, а делать это куда чаще. Например, после каждого фикса или же перед коммитами. А теперь предлагаю посмотреть на то, как это всё выглядит в одной таблице:
Я запустил по пять раз и посчитал среднее по запускам (эти цифры вы и видели в графиках) 🙂
IncrediBuild для проверки большого проекта с помощью PVS-Studio
Об инструментах PVS-Studio и IncrediBuild
PVS-Studio выполняет анализ C/C++ кода и подсказывает программисту, где находятся возможные ошибки, или указывает на участки кода, которые могут повлечь проблемы в будущем.
Анализатор состоит из нескольких частей, и проверку каждого файла с исходным кодом выполняет процесс PVS-Studio.exe (ядро анализатора). Далее я буду использовать термин «поток», подразумевая, что в одном потоке запущен один процесс PVS-Studio.exe для проверки одного исходно файла проекта. А файлов будет очень много…
IncrediBuild — программное обеспечение для распределённых вычислений, которое позволяет с лёгкостью задействовать несколько компьютеров и ускорить работу своих приложений. При этом не нужно беспокоится за зависимости, которые присутствуют у распараллеленных процессах.
Мы будем использовать IncrediBuild, чтобы выполнить анализ проекта во много потоков, используя дополнительные компьютеры.
О проверяемом проекте
Проверяемый проект пожелал быть неназванным, но он имеет около 7 млн. строк исходного кода. Размер кодовой базы — 300 MB, и около 9000 файлов. Проверка такого проекта анализатором PVS-Studio на компьютере с процессором Intel Core i7-4770 3.40 GHz и 16 GB ОЗУ в 8 потоков занимает около 6 часов. Далее я расскажу, как с помощью инструмента IncrediBuild и нескольких компьютеров удалось сильно ускорить время анализа проекта.
Результаты
Во всех тестах использовались компьютеры примерно одной конфигурации, позволяя выполнять анализ в 8 потоков на каждом из них.
При настройке IncrediBuild на компьютерах, один из них настраивается как координатор, остальные настраиваются как агенты, которые подключаются к координатору. Т.к. проверка проекта запускалась на агенте, то на этом компьютере в настройках было задано загружать только 1 поток, чтобы излишняя нагрузка не мешала сбору результатов. Для координатора тоже было задано выполнять вычисления только в 1 поток.
Тест первый
На рисунке 1 представлена проверка проекта анализатором в 26 потоков.
Рисунок 1 — Проверка проекта анализатором в 26 потоков
Для читателей, не знакомых с IncrediBuild, поясню, что зелёной полоской обозначается 1 процесс, который успешно отработал на компьютере с именем, которое написано слева. На полоске пишется имя процесса. А по временной шкале снизу можно определить, в какой момент времени процесс стартовал и завершился, таким образом сразу видна длительность работы любого распределённого процесса.
На рисунке выше запечатлена проверка довольно крупных исходных файлов. Распараллеливание выполняется очень равномерно и эффективно при длительной загрузке потоков.
На рисунке 2 представлен анализ разных по объёму файлов исходного кода.
Рисунок 2 — Проверка мелких и крупных файлов проекта в 26 потоков
Как мы видим, быстрое завершение потоков приводит к накладным расходам на создание новых потоков и происходит небольшое простаивание некоторых компьютеров. Но в целом распараллеливание выполняется очень хорошо. Анализ проекта выполнился за 2 часа 10 минут вместо 6 часов, очень даже неплохо.
Тест второй
На рисунке 3 представлена проверка проекта анализатором в 43 потока.
Рисунок 3 — Проверка проекта анализатором в 43 потока.
Список из 43 потоков не удаётся увидеть целиком, но хорошо видно, как возросло простаивание компьютеров при проверке маленьких файлов. Но всё равно выглядит очень здорово, учитывая, что общее время анализа составило уже 1 час 24 минуты вместо 6 часов и из приложенных усилий было только быстрая установка IncrediBuild на нужные компьютеры. Для настройки PVS-Studio потребовалось изменить всего 1 пункт в настройках — задать количество потоков.
Заключение
Воспользовавшись инструментом IncrediBuild, который обычно присутствует для сборки очень крупных проектов, мы смогли ускорить время анализа проекта с помощью PVS-Studio в 4.2 раза, задействовав несколько компьютеров разработчиков, которые сидели рядом. Все настройки IncrediBuild использовались по умолчанию, а их там довольно много. Наверняка можно достичь ещё большей производительности, но нам был интересен «быстрый старт».
Если хотите поделиться этой статьей с англоязычной аудиторией, то прошу использовать ссылку на перевод: Svyatoslav Razmyslov. Using IncrediBuild to Assist Analysis of a Large Project by PVS-Studio.
Ускоряем сборку и анализ при помощи IncrediBuild
«Да сколько ты ещё будешь собирать?» – фраза, которую каждый разработчик произносил хотя бы раз посреди ночи. Да, сборка бывает долгой и от этого никуда не деться. Нельзя же просто так взять и распараллелить всё это дело не на каких-то жалких 8–12 ядер, а так, чтобы на 100+. Или всё-таки можно?
Мне нужно больше ядер!
Как вы могли заметить, речь сегодня пойдёт как раз о том, как можно ускорить компиляцию. И нет, в этот раз будут рассмотрены не какие-то специфичные механизмы, а самое обычное распараллеливание. Ну, тут всё, казалось бы, просто – выставляем доступное физически количество ядер, нажимаем на build и идём пить условный чай.
Но с ростом кодовой базы время компиляции постепенно растёт и однажды оно станет настолько большим, что полностью проект будет собираться разве что ночью. Поэтому нужно подумать о том, как бы всё это ускорить. Вокруг же сидят довольные коллеги, которые занимаются своими программистскими делами, а их машины тихо и не напрягаясь выводят немного текста на экраны.
«Взять бы у этих бездельников ядра», – могли вы подумать. И правильно бы сделали, ведь это вполне себе можно реализовать. Но не нужно, конечно, принимать мои слова близко к сердцу и вооружаться паяльником. Впрочем, это уже на ваше усмотрение 🙂
Отдай!
Так как реквизировать машины коллег нам вряд ли кто-либо даст, будем пользоваться обходными путями. Даже если у вас и получилось убедить своих коллег поделиться железом, всё равно пользы от лишних процессоров у вас не будет, разве что можете выбрать себе тот, который пошустрее. А нам нужно то решение, которое каким-то образом позволит запускать дополнительные потоки сборки на удалённых машинах.
Благо среди тысяч категорий всякого полезного ПО, затесалась и нужная нам – система распределённой сборки. Программы этой категории делают именно то, что нам было и нужно: выдают на время простаивающие ядра коллег и при этом делают это без их ведома в автоматическом режиме. Разве что сперва нужно будет поставить всё это на их машины, но об этом немного позже.
На ком будем проверять?
Для того чтобы убедиться, что всё функционирует действительно хорошо, нужно было найти качественного подопытного. Так как у нас уже не раз были в статьях и Chromium, и Linux, а выделиться как-то хотелось, нужно было найти что-нибудь новое. Поэтому я пошёл в сторону открытых игр (а где же ещё искать большие проекты?). И, как вы увидите ниже, очень пожалел об этом решении.
Впрочем, поиск чего-то объёмного труда не составил, да и мне «повезло» повстречать открытый проект на Unreal Engine. Вдуматься только! Я действительно до момента написания этой статьи и подумать не мог, что на UE бывает Open Source™.
Итак, герой этой статьи: Unreal Tournament. Только вы не спешите сразу переходить по ссылке, так как вам может понадобиться пара дополнительных кликов – подробности *тут*.
Да будет сборка на 100+ ядер!
В качестве примера системы распределённой сборки я, пожалуй, остановлюсь на IncrediBuild. Не то чтобы у меня был большой выбор – у нас была уже лицензия IncrediBuild на 20 машин. Нет, есть, конечно, открытый distcc, но он не так прост в настройке, да и к тому же практически все машины у нас под Windows.
Итак, первым делом нужно поставить агентов на машины других разработчиков. Есть два способа:
Разумеется, как и любой другой наивный человек, я написал сперва в Slack. Спустя пару дней еле-еле дошло до 12 машин из 20. После этого я воззвал к силам сисадмина, и, о чудо, заветная двадцатка была у меня в руке. Так что теперь у меня было около 145 ядер (+/- 10) 🙂
За исключением необходимости поставить агентов (делается это парой кликов в установщике), нужно было поставить себе координатора. Это делается немного сложнее, поэтому оставлю ссылку на доки.
Итак, у нас теперь есть сетка на стероидах, поэтому пришло время добраться до Visual Studio. Выбираем в плагине сборку. А вот и нет 🙂
Если вдруг вы и сами захотите попробовать, то учтите, что сперва нужно собрать проекты ShaderCompileWorker и UnrealLightmass. Так как они небольшие, я собрал их локально. Вот теперь уже можно нажать на заветную кнопку:
Итак, какая же получилась разница?
Как видите, нам удалось ускорить сборку с 30 минут до почти 6! Очень даже нехило. Кстати, запуск проводился посреди рабочего дня, так что примерно таких цифр можно ожидать и не на синтетическом тесте. Впрочем, от проекта к проекту разница может быть разной.
Что ещё можно ускорить?
Помимо сборки можно натравить IncrediBuild на любую тулзу, которая плодит много подпроцессов. Как вы, может, обратили внимание, я работаю в PVS-Studio. Поэтому, конечно же, я не могу обойти стороной возможность скормить ему и наш анализатор.
Профит в быстром анализе примерно такой же, как и в быстрой сборке: возможность локальных прогонов перед коммитом. Конечно, всегда есть желание залить всё сразу в мастер; но обычно тимлид бывает не в восторге от подобных действий, особенно когда валятся ночные прогоны на сервере. Поверьте мне – я валил 🙁
Настраивать особенно анализатор не нужно, разве что нам не повредит указать старые-добрые 145 потоков в настройках:
Ну и стоит указать местной сборочной системе, кто тут анализатор:
Итак, пришло время нажать на сборку ещё раз и насладиться ускорением:
Вышло около семи минут, что подозрительно похоже на время сборки. Тут я и подумал, что видимо забыл добавить флаг. Зашёл в настройки и увидел, что всё на месте. Такого я не ожидал, поэтому отправился курить мануалы.
Попытка запуска PVS-Studio #2
Спустя какое-то время я вспомнил про версию Unreal Engine, которая используется в этом проекте:
После пары кружек бодрящего напитка у меня возникла мысль всё-таки дочитать туториал по интеграции до конца. Помимо указанного выше способа есть ещё и мониторинг компиляции. Это как раз тот вариант, когда ничего уже не помогает.
Первым делом включим сервер мониторинга:
Эта штука будет крутиться на фоне и следить за тобой вызовами компилятора. Но она не может отслеживать происходящее в IncrediBuild, поэтому придётся один раз собрать без него.
На фоне предыдущего запуска локальная пересборка выглядит очень бедно:
Теперь сохраним то, что насобирали в отдельный файл:
Дальше можно будет пользоваться этим дампом, пока вы не добавите новый файл в проект. Да, это не так удобно, как с флагом, но ничего не поделаешь – версия движка слишком старая.
Сам же анализ запускается вот этой командой:
Только не стоит его так запускать, ведь мы же хотим его запустить под IncrediBuild. Так что закинем эту команду в analyze.bat. И создадим рядом файл profile.xml:
И теперь мы можем запустить всё с нашими 145 ядрами:
И как это выглядит в Build Monitor:
К нам закралась ещё одна проблема. И в этот раз дело не в том, что кто-то что-то не поддерживает. Сборка Unreal Tournament оказалась несколько специфичной.
Попытка запуска PVS-Studio #3
Если посмотреть внимательно, то это не ошибки анализа, а неудачи при препроцессировании исходников. Причём, причина данного фейла была одна и та же:
Так в чём проблема? Всё довольно просто – препроцессор требует, чтобы только один из следующих макросов имел значение 1:
Да, вроде как всё собиралось раньше, а теперь что-то страшное вылетело. Пришлось закопаться в логи, а точнее – в дамп компиляции. Там-то проблема и нашлась. Дело было в том, что эти макросы объявляются в местном precompile header, а мы хотим только препроцессировать. Так что пришлось добавить все эти макросы вручную:
Самое начало файла build.h
И уже с этим небольшим костылём элегантным решением можно запустить анализ. Причём сборка не сломается, так как мы воспользовались макросом PVS_STUDIO.
Итак, долгожданные результаты анализа:
Согласитесь, почти 15 минут вместо двух с половиной часов – это очень хорошее ускорение. Сложно представить, чтобы вы могли пить кофе 2 часа кряду и ни у кого не возникло бы сомнений на ваш счёт. А вот 15-минутный перекур вопросов не вызывает. Наверное.
И что у нас в итоге?
Разумеется, что в идеальном мире увеличение количества потоков в N раз увеличило бы скорость сборки в N раз. Но живём мы в совершенно ином мире, поэтому стоит учитывать локальную нагрузку на агентов (удалённые машины), нагрузку на сеть, время на организацию всего этого дела и ещё много деталей, которые скрыты под капотом.
Впрочем, ускорение действительно есть, и местами оно позволяет не просто запускать полную сборку или же анализ раз в день, а делать это куда чаще. Например, после каждого фикса или же перед коммитами. А теперь предлагаю посмотреть на то, как это всё выглядит в одной таблице:
Я запустил по пять раз и посчитал среднее по запускам (эти цифры вы и видели в графиках) 🙂