Здравствуйте, SaZ, Вы писали:
SaZ>Здравствуйте,
SaZ>Хочу использовать clang для сборки под windows. Никак не получается распараллелить сборку, она всегда идёт в один поток. Окружение: CLion, CMake, CLang 10, msvc2019, nmake. Флаги компилятору передаю через переменную окружения, например CL=/EHa. Пробовал передавать -j12, /MP и прочие — не помогает. Подскажите, как можно заставить в CLion собираться проект с помощью clang в несколько потоков?
Нет ли возможности заменить nmake на jom?
Он совсем как nmake (понимает файлы nmake-а), но понимает ключ -j 12. (Не использовать вместе с /MP!)
Здравствуйте, PM, Вы писали:
PM>Стратегия у каждого своя. Мне удобнее максимально быстро получить результат сборки, и ninja с этим справляется быстрее, чем make. Проблем с десктопом не будет,
Мой основной поинт был, что ninja всё так же конфигурируется через -j. И да — ninja очень быстр и прост.
PS: Хотя во многом зависит и то, что он вызывает. Когда видишь в msbuild tracker.exe как родитель, ясно что интерфейс с компилятором говно. Когда каждый clang-cl порожденный ниндзей порождает еще один clang-cl — понимаешь что порою перемудрили с врапперами. Хотя на сейчас этих закидонов уже в основном не вижу. (Не связано с ninja ессно, просто качество тулчейна напрямую влияет на время.)
PPS: Трюк с idle (можно и приоритет io настроить) просто позволяет работать дальше с чем-то иным, практически без лагов.
Хочу использовать clang для сборки под windows. Никак не получается распараллелить сборку, она всегда идёт в один поток. Окружение: CLion, CMake, CLang 10, msvc2019, nmake. Флаги компилятору передаю через переменную окружения, например CL=/EHa. Пробовал передавать -j12, /MP и прочие — не помогает. Подскажите, как можно заставить в CLion собираться проект с помощью clang в несколько потоков?
Здравствуйте, Chorkov, Вы писали:
C>Здравствуйте, SaZ, Вы писали:
SaZ>>Здравствуйте,
SaZ>>Хочу использовать clang для сборки под windows. Никак не получается распараллелить сборку, она всегда идёт в один поток. Окружение: CLion, CMake, CLang 10, msvc2019, nmake. Флаги компилятору передаю через переменную окружения, например CL=/EHa. Пробовал передавать -j12, /MP и прочие — не помогает. Подскажите, как можно заставить в CLion собираться проект с помощью clang в несколько потоков?
C>Нет ли возможности заменить nmake на jom? C>Он совсем как nmake (понимает файлы nmake-а), но понимает ключ -j 12. (Не использовать вместе с /MP!)
C>https://wiki.qt.io/Jom
Спасибо, я думаю что есть такая возможность. Поиграюсь с CLion + JOM. Я просто удивлён, что никому такое требование пока в голову не приходило . Или я что-то делаю не так.
Здравствуйте, SaZ, Вы писали:
SaZ>Здравствуйте,
SaZ>Хочу использовать clang для сборки под windows. Никак не получается распараллелить сборку, она всегда идёт в один поток. Окружение: CLion, CMake, CLang 10, msvc2019, nmake. Флаги компилятору передаю через переменную окружения, например CL=/EHa. Пробовал передавать -j12, /MP и прочие — не помогает. Подскажите, как можно заставить в CLion собираться проект с помощью clang в несколько потоков?
во-первых, привычные к clang'у используют тот же cmake, примерно таким вот образом:
во-вторых, компилятор из visual studio тоже собирает не в несколько потоков, а запускается системой сборки в несколько разных инстанцев на каждый cpp-файл.
в-третьих, в MSVS можно подключить clang в виде toolset'а (вместо штатного компилятора), причём в двух вариантах — один майкрософта, а второй от llvm project.
Здравствуйте, SaZ, Вы писали:
SaZ>Хочу использовать clang для сборки под windows. Никак не получается распараллелить сборку, она всегда идёт в один поток. Окружение: CLion, CMake, CLang 10, msvc2019, nmake. Флаги компилятору передаю через переменную окружения, например CL=/EHa. Пробовал передавать -j12, /MP и прочие — не помогает. Подскажите, как можно заставить в CLion собираться проект с помощью clang в несколько потоков?
Я не использовал CLion, но CMake это ведь meta-build system. Она генерирует файлы для разных систем сборки — make, Visual Studio (aka msbuild), ninja и остальной экзотики.
Параллельная сборка задается для каждой системы сборки особым способом. Для make -j %NUMBER_OF_PROCESSORS%, для msbuild /MP, для ninja ничего не надо, оно само параллелит сборку по максимуму.
Здравствуйте, PM, Вы писали:
PM>Параллельная сборка задается для каждой системы сборки особым способом. Для make -j %NUMBER_OF_PROCESSORS%, для msbuild /MP, для ninja ничего не надо, оно само параллелит сборку по максимуму.
Если и само по максимум, то ninja вполне понимает -j. В большинстве случаев стратегия параллелить по максимуму — ущербная стратегия, поэтому либо подбирайте комфортные величины, либо задавайте правильный приоритет процесса (например low/idle) — потому что иначе десктоп првращается в УГ.
Здравствуйте, Mystic Artifact, Вы писали: PM>>Параллельная сборка задается для каждой системы сборки особым способом. Для make -j %NUMBER_OF_PROCESSORS%, для msbuild /MP, для ninja ничего не надо, оно само параллелит сборку по максимуму. MA> Если и само по максимум, то ninja вполне понимает -j. В большинстве случаев стратегия параллелить по максимуму — ущербная стратегия, поэтому либо подбирайте комфортные величины, либо задавайте правильный приоритет процесса (например low/idle) — потому что иначе десктоп првращается в УГ.
Стратегия у каждого своя. Мне удобнее максимально быстро получить результат сборки, и ninja с этим справляется быстрее, чем make. Проблем с десктопом не будет,
Здравствуйте, SaZ, Вы писали:
SaZ>Здравствуйте,
SaZ>Хочу использовать clang для сборки под windows. Никак не получается распараллелить сборку, она всегда идёт в один поток. Окружение: CLion, CMake, CLang 10, msvc2019, nmake. Флаги компилятору передаю через переменную окружения, например CL=/EHa. Пробовал передавать -j12, /MP и прочие — не помогает. Подскажите, как можно заставить в CLion собираться проект с помощью clang в несколько потоков?
Спасибо всем за советы. Установка jom проблему не решила, на выходе получил "jom: parallel job execution disabled for Makefile". Сам Makefile создавался средствами CLion для clang под windows (-G "NMake Makefiles JOM"). Последняя надежда на Ninja. Лагов десктопа не боюсь, boost в 9 потоков отлично собирался и не ложил систему.
Здравствуйте, PM, Вы писали:
PM>Стратегия у каждого своя. Мне удобнее максимально быстро получить результат сборки, и ninja с этим справляется быстрее, чем make.
Мне всегда было интересно, почему это ninja быстрее? Основное время тратится на компиляцию и линковку и тут работает тот же компилятор/линковщик, не важно, чем собирать, хоть make, хоть ninja, хоть msbuild.
По факту попробовав перевести наш продукт на ninja — получили сходное время сборки.
Здравствуйте, boomer, Вы писали:
B>Мне всегда было интересно, почему это ninja быстрее? Основное время тратится на компиляцию и линковку и тут работает тот же компилятор/линковщик, не важно, чем собирать, хоть make, хоть ninja, хоть msbuild. B>По факту попробовав перевести наш продукт на ninja — получили сходное время сборки.
Здесь вопрос масштаба и потребностей, ну и применимости.
ninja легко справляется с десятками тысяч модулей, и думаю это не предел. Оно и понятно почему он работает — задача не сложная. Преимущество над всеми видами make весьма простое — это кросс-платформенный продукт, который просто работает и достаточно единообразно.
И тем не менее — это скорее часть исполнительной сборочной машины. Впрочем в документации они и позиционируют это как некоторый ассемблер к которому нужен генератор.
MSBuild, напротив — к тому времени или выжрет немерянно памяти, или окопается в свопе, так или иначе ухудшая время сборки. Но и он претендует всё же на немного другую роль, в обычном случае.
Сейчас лишний гигабайт памяти может быть и не проблема (пока ее достаточно), но пока она (лишняя работа) выполняется — ты за нее платишь — своим временем.
Для C# в msbuild параноидальное дублирование артефактов в obj и bin. На одном слабом билд сервере с убитым IO после включения хард-линков (штатная опция в бесконечных стандартных targets)- время сборки упало с более чем часа до считанных минут.
В целом качество тулчейна будет влиять непропорционально, ввиду нашего искривленного время восприятия. Когда единицы измерений переходят с минут на часы — начинаешь ценить полезняшки.
Я вот не проверял на последнем мс компиляторе (в связке с мсбилдом) как он работает с респонс-файлами, но не так давно каждый инвок компилятора — это запись в %temp% этого самого рнспонс файла... Разумеется такие подходы не дают выжать полную скорость, при чем, чем больше ядер, тем больше затыков.
PS: Иначе говоря когда инфраструктурные затраты станут видимыми/значимыми — тогда и эффект будет более значимым. А так, конечно, если выиграл 10мс то чего париться.
Здравствуйте, boomer, Вы писали:
PM>>Стратегия у каждого своя. Мне удобнее максимально быстро получить результат сборки, и ninja с этим справляется быстрее, чем make.
B>Мне всегда было интересно, почему это ninja быстрее? Основное время тратится на компиляцию и линковку и тут работает тот же компилятор/линковщик, не важно, чем собирать, хоть make, хоть ninja, хоть msbuild. B>По факту попробовав перевести наш продукт на ninja — получили сходное время сборки.
При полной переборке большого проекта, естественно, на первое место выходит быстродействие железа, и разница в несколько секунд становится незаметна при общем времени билда 20 с лишним минут.
Здравствуйте, PM, Вы писали:
PM>В документации вроде написано: https://ninja-build.org/manual.html#_comparison_to_make PM>На инкрементальной сборке невооруженным глазом заметно, что ninja быстрее Makefile, сгенерированного из CMake.
Я не верю, что время, потраченное самой тулой, а не компиляцией будет заметно быстрее, чем компиляция. А пересобрать нужно одинаковое количество файлов, вне зависимости от системы сборки.
PM>При полной переборке большого проекта, естественно, на первое место выходит быстродействие железа, и разница в несколько секунд становится незаметна при общем времени билда 20 с лишним минут.
Когда один файл комилируется секунд 20, что для плюсового кода с большим количеством шаблоров — не редкость, разница будет незаметна не только глазу, но и инструментально.
Для голого C это действительно может быть критично. Но сдается мне, что для маленьких и средних проектов разница будет с гулькин нос.
. Или я что-то делаю не так.
Разумеется такие подходы не дают выжать полную скорость, при чем, чем больше ядер, тем больше затыков.