Intel C++ - реально ли ускорить debug билд?

А насколько сильно она отличается от релизной?

Precompiled headers, forward declarations - это первое, что приходит в голову.

make -jN ещё, ага

Что не так с forward declarations и precompiled headers?

Всё так. Просто оно ускоряет компиляцию в целом, а у ТСа, видимо, какая-то значительная разница между сборкой дебага и релиза, которую он хочет уменьшить

а у ТСа, видимо, какая-то значительная разница между сборкой дебага и релиза

Да ладно:

Пробовал отключать оптимизацию, ничего не поменялось

Пробовал отключать оптимизацию, ничего не поменялось.

Может дефайны делают тебе разницу? _DEBUG всякие.

само собой что я использую Precompiled headers, forward declarations и многопоточную сборку. также взял мать на два процессора по 8 ядер, временный каталог перенёс на рамдиск, это сократило сборку с пяти минут примерно до 1.5. но ждать полторы минуты после того как сделал мелкую правку тоже напрягает. интеловский компилятор всё равно очень долго думает, гугл чего-то молчит, будто эта проблема больше никого не волнует.

Пробовал собирать другими компиляторами?

нет ещё, хотелось бы с интелом, т.к. релиз собирается именно на нём. а с другими могут возникать небольшие несовместимости. если решения не найду то прийдётся пробовать clang и тд.

Можно вынести маломодифицирующийся код в библиотеки.
Использовать #ifndef/#define/#endif вместо #pragma once.

Intel C++

Они уже перестали вставлять примерно такие палки:

...
if (cpuId.contains("AMD")) {
    for (double i = 0.0d; i < 1000000.0d; i+=0.1d) { int a = (int) i / i * 2; }
    usleep(10000);
}
...

в колёса, если код выполняется на AMD-процессоре?

по поводу палок я не знаю, код крутится на серверах, которые все на интеловской платформе. когда я тестил последний раз (года три назад) на интеловской платформе, то прирост скорости по сравнению с gcc был приличный, около 25-30%, поэтому решил на него перейти.

Можно посмотреть в сторону distcc и ccache.

да вот хочу ещё один комп собрать чтоб через distcc компилять сразу на двух. это конечно дороже, чем просто как-то отключить оптимизацию в компиляторе (как это делается в vs, например) - если она там вообще отключается ) поэтому и спросил, может кто знает волшебный ключик компилера )

будто эта проблема больше никого не волнует.

Не удивлюсь, если так и есть. Интеловский компилятор ведь, если я ничего не путаю, «подстраивается» под «общепринятый системный», в смысле под линуксом использует ГЦЦ ключи, под виндой - майкросовтовские. Так может собирать «для разработки» родным компилятором - может быстрее будет? А релизы уже интеловским.

это сократило сборку с пяти минут примерно до 1.5. но ждать полторы минуты после того как сделал мелкую правку тоже напрягает.

Мелкая правка, а собирается 1.5 минуты? Хм.

Они уже перестали вставлять примерно такие палки

А что, такое вообще было? Кто-то доказал что это факт? Невероятная наглость от ынтела...

http://habrahabr.ru/post/80050/

Разбивай код на мелкие файлы. Если ты, конечно, не покусан Александреску, тогда не поможет.

но ждать полторы минуты после того как сделал мелкую правку тоже напрягает

Мелкая правка - это один файл. Если у тебя один файл собирается полторы минуты, меняй компилятор. Если твоя система сборки не умеет пересобирать только то что изменилось и пересобирает всё - меняй систему сборки. Иначе у тебя бардак с include'ами. От precompiled headers, кстати, для скорости сборки лучше избавиться, ибо шаг влево/шаг вправо, и приходится пересобирать всё. Реального же ускорения они не дают никакого. Остаётся только по-человечески разбивать проект на модули, использовать только нужные #include (особенно в других хедерах) и использовать forward declarations во все поля.

сенкс, попробую убрать pch. ну и фиксануть бардак с инклудами тоже вариант.

Алсо, есть идиома pImpl которая позволяет почти полностью избавить header'ы от зависимостей. Но это на самом деле сомнительное решение только ради увеличения скорости компиляции.

Другое название PImpl — Compilation Firewall. Так что как раз решение адекватное и не сомнительное ни разу.

Сомнительное, потому что даёт runtime оверхед, уродует и усложняет код. Другое дело что у него могут быть полезные применения, но если единственная цель - ускорить компиляцию, то за него нужно убивать.

Сомнительное, потому что даёт runtime оверхед

Расскажи по оверхед подробнее, пожалуйста. Мне ясен только один аспект: скрытая часть класса вынуждена будет располагаться всегда в динамической памяти. Но это никакой не big deal, куча программ оперирует динамически создаваемыми объектами.

Там, кажется, не такие очевидные подставы были, а просто хитрый выбор далеко не самого оптимального набора инструкций под ту же операцию. Потому так долго и не замечали.

cmake->ninja

Очевидно же, ненужный indirection на каждый вызов метода. Что ты имел в виду под динамической памятью я не понял.

Но это никакой не big deal, куча программ оперирует динамически создаваемыми объектами.

А есть другая куча программ, где производительность всё-таки важна. И new vs стек дает охренительную разницу.

Использовать #ifndef/#define/#endif вместо #pragma once.

вау! и во сколько раз ускорится компиляция? пойду пацанам расскажу

Если я не ошибаюсь, при использовании

#pragma once

/* gcc/lipcpp/files.c */

  if (!pfile->seen_once_only)
    return true;

Насколько это может увеличить скорость сборки - не знаю, но ТС спрашивал обо всех возможных вариантах.

С другой стороны

#pragma once

Очевидно же, ненужный indirection на каждый вызов метода.

Виртуальные методы тоже запретить? pimpl - это просто более гибкая альтернатива позднему связыванию.

ninja

yaposhka!

попробуй отключить IPO (inter-procedural optimization) эта штука реально тормозит сборку... причем тормозит оно на этапе пост-компиляции (или на линковке, смотря в каком месте воткнуто), смотреть на ключи -ipo, -fast

к тебе уже выехали за раскрытие проприетарных исходников

Они уже перестали вставлять примерно такие палки:
в колёса, если код выполняется на AMD-процессоре?

Судя по данной тобой ниже ссылке на хабру, палки они втсавляют исключительно на этапе компиляции, т.е. код, собранный на Интеле, должен выполняться на АМД с соответствующим набором команд без всяких костылей.

Виртуальные методы оправдывают свой оверхед, pImpl - нет.

у меня они отключены. попробовал включить, так компилятор безвременно завис на последнем этапе )

Виртуальные методы тоже запретить?

Зачем? Виртуальные методы применяются там, где нужны. А pimpl даст оверхед вообще на любом вызове. Другое дело, что почти всегда на это пофиг.

Cнижение связности по зависимостям никогда не сомнительно :)

Виртуальные методы оправдывают свой оверхед, pImpl - нет.

Ничего, что pimpl - это виртуальные методы с ручным управлением?

Два бокала этому мсье :) У нас во время борьбы за скорость сборки на билд-серверах именно /GL /LTGC и аналоги были выпилены.

А pimpl даст оверхед вообще на любом вызове

На любом вызове через pimpl. Никто тебя не заставляет всё через pimpl вызывать, что-то можно и через статическое связывание.

Но дело не в этом, а в том, что ускорение компиляции это побочный эффект pimpl, а не основной. Он не для этого нужен, как тут пытаются втирать.

но если единственная цель - ускорить компиляцию, то за него нужно убивать.

Расскажешь заказчикам, почему они не могут получить сборку раньше чем через пол-дня - если тебя раньше не убьют :)

Он не для этого нужен, как тут пытаются втирать.

При нормальной разбивке компонентов, которой pimpl таки способствует by design, сокращение времени компиляции является бонусом :) «Оверхедофобия» без обоснований затрат на преждевременную оптимизацию (а они будут, т.к. в некоторых местах при упоротом избегании удобных способов и лени («да фу... дольше писать!») будет черезжопная борьба с перекрестными/циклическими зависимостями (форвард декларейшын спасет не всех, а кто-то закончит шизофренией с приватными заголовками (и писать код будет еще дольше :)) - что опять приведет к затратам времени и денег) - такая же религия без внятных оправданий и карго-культизм.

От precompiled headers, кстати, для скорости сборки лучше избавиться, ибо шаг влево/шаг вправо, и приходится пересобирать всё.

Если правильно ими пользовать, т.е. включать в них сторонние библиотеки, то ничего пересобирать не придется.

Реального же ускорения они не дают никакого.

4.2

-ipo, -fast

в дебаг-сборке, ага