Я слышал что есть способы кэшировать и не перекомпилировать весь проект целиком. Но вопрос. Почему компилятор долго работает? Ведь вся суть компилятора сводится к конкатенации всех файлов и парсингу AST-дерева, затем подмене конструкций на ассемблерные инструкции. Если отключены оптимизации, так невероятно долго работает подмена одного на другое?
Даже если простой хелловорлд прогнать через препроцессор, получится гигантский листинг с тоннами шаблонов, которые компилятор должен как-то переварить.
Евгений Шатунов, так не работает так как я себе представляю. Вопрос — почему. Там же ничего сложного кроме оптимизаций. Если их отключить — то останется подмена одного на другое. Разработчики компиляторов же не дураки делать медленные компиляторы? Или :)
zeuss56, моё "Я тебя не понимаю" относится именно к обоснованию твоих требований. Я не понимаю, от каких аналогов (может быть в других языках?) ты отталкивался при формировании вот этих своих требований.
Я ведь тоже могу всякого навыдумывать, кто и что прямо сейчас мне должен. Но вопрос ведь в обоснованности.
Если у тебя нет базы для твоих требований, ты можешь просто так и сказать. Ничего сильно страшного в этом нет, кроме, конечно, необоснованности требований.
zeuss56, ну ладно. Сольем тогда тему на требования от балды. :)
Транслятор C++ не делает вообще всего того, о чем ты написал в вопросе. Кеширование процесса сборки у транслятора есть сразу на нескольких уровнях. За счет этого кеширования достигается максимальная производительность параллельной сборки.
Про оптимизации во время трансляции ты явно не понимаешь. Оптимизации есть разные. Есть оптимизации предпочтений (это убрать, важно время вызова, память сжать, SSE/AVX использовать) и они отключаются. А есть понятие неопределенного поведения, позволяющее выполнять асимптотические оптимизации кода вне зависимости от предпочтений. this никогда не может быть nullptr, иначе это UB. int никогда не переполняется, иначе это UB. Понятие UB позволяет очень жестко оптимизировать код. Еще к таким асимптотическим правкам относится удаление неиспользуемых объектов, участков недостижимого кода, развертка циклов или свертка планарных конструкций. Эти оптимизации не отключаются, т.к. они заложены в сам язык, в процесс трансляции. Еще к таким оптимизациям относится перестановка блоков бинарного кода для случаев, когда результат не меняется, а вот бранчинг кода резко снижается.
Неграмотная организация и слабая макроархитектура преокта могут катастрофически сказаться на времени сборки. На моем 9900K сборка моего фреймворка полностью с нуля занимает 1 минуту. Сборка же известного коммерческого движка со сравнимым объемом кода ровно в том же окружении занимает 25 минут просто потому что в этом движке очень слабая организация проекта и полностью отсутствует (с моей т.з.) макроархитектура.
И это при том, что коммерческий движок использует и PCH, и Incredibuild, и prebuilt library, а я полностью весь свой фреймворк под все платформы собираю целиком из исходников, без PCH и исключительно стандартными средствами сборки для целевой платформы.
Код C++ никогда прямо не отображается в asm, но используется как указание того, какое поведение бинарного кода необходимо разработчику. И ключевым тут является именно то, что код C++ выступает как инструкция, а не как представление бинарного кода. Без квалификации в трансляторах с этой темой так просто не разобраться.
zeuss56, а зачем?
Над ответом на твой вопрос, с моей т.з, необходимо поработать раза в два-три больше чем я просидел над этим потоком сознания. Я не могу считать это ответом и предпочел передать информацию в несколько упрощенном виде потому что не располагаю временем для оформления достаточного ответа.
Евгений Шатунов, всё супер, просто я неправильно настроил свой Makefile и не использовал make -j :) Быстро собирает объектные файлы, всё хорошо.
Но вообще для всего сообщества проблема актуальна, и теперь я уже узнал почему компилятор так долго работает — оказывается это не простая трансляция c++ в asm с заменой по словарю AST-дерева на ассемблерные инструкции, а намного более сложная и долгая процедура.
Лично меня это больше уже не беспокоит, всё летает.
zeuss56, а... конкурентная сборка. :)
Ктож мог подумать что у тебя она не включена. Хорошо что теперь она работает. Я, в свое время и давным давно, тоже не сразу про нее узнал и транслировался по 30-40 минут. Когда указал "-j" на все ядра, время полной сборки того проекта сократилось до 3-5 минут.
Я могу еще такое рассказать. На время трансляции сильно влияет и сам код. Например, обилие макросов в коде очень сильно повышает время трансляции. Буквально катастрофически. На моем богатом опыте, увеличение времени от обилия макросов достигает +40..60% общего времени трансляции. Неправильное использование форм директивы #include может привести к увеличению времени трансляции до +20%. Т.н. "include guard"-ы [?] спокойно увеличивают время трансляции до +5..10%. Любая эвристика с логарифмической трудоемкостью в шаблонах и при обильном использовании приводит к увеличению времени трансляции до +8%.
Факторов увеличения времени трансляции C++ кода вообще довольно много. Поэтому большие проекты на C++ обычно собираются порядка часа или двух. Даже при условии распределенной сборки.
Тут главное - это просто понимать неизбежность последствий использования тех или иных конструкций языка.
Евгений Шатунов,
> эвристика с логарифмической трудоемкостью
Кстати где можно почитать точно и кратко про сложности O(N) самых популярных алгоритмов и сортировок?
А то надоели если честно на собеседованиях спрашивать какая сложность пузырьковой там. Я прекрасно понимаю алгоритмы и какой будет быстрее, я пишу эффективные и с математической оптимизацией если надо, не дурак, но там логарифмическая, линейно-логарифмическая, полиномиальная, квадратичная вообще хрен знает. Мне без разницы, по коду вижу какой будет быстрее, но всякие яндексы спрашивают эти теории. Кто-то может заучить O(N) но вообще не соображать, я как раз наоборот. Правильно мыслить вообще более ценно чем что-то заучить. Но мне выучить тоже надо.
Евгений Шатунов,
> "include guard"-ы
Вместо этой динозаврской штуки пишу `#pragma once` как белый человек. Да, эту директиву помечали устаревшей, но на сегодняшний день ее вернули в стандарт потому что удобно и она теперь намного лучше оптимизируется. Многие могут об этом не знать и считать ее плохим тоном, а всё ровно наоборот.
Компилятор долго оптимизирует код. Смотрит, что где используется, что можно выкинуть, где можно переставить местами что-то неважное, где цикл развернуть, где еще чего. Очень много оптимизаций. Обработка каждого файла - долгое дело.
Архаичная система заголовочных файлов же приводит к тому, что при изменении небольшой части проекта, фактически меняется куча файлов, которые все надо заново парсить и оптимизировать.
zeuss56, это ни фига не простая замена, особенно для C++ с его перегрузкой функций, сложной системой типов, константными и неконстантными доступами и всё такое.
И что касается заголовков - вот маленькая демонстрация:
725 строк после препроцессинга в программе, в которую включен всего один не самый сложный заголовочный файл. А что бывает в сложных проектах с десятками подключаемых заголовочных файлов, содержащих сложные структуры данных и множество функций? Даже прекомпиляция заголовков не исключает необходимости всё это перебирать для проверки того, какие идентификаторы что означают в компилируемом коде.
(Правда, справедливости ради, осмысленных строк после выкидывания мусора остаётся 266)
нет, precompiled headers, не ускоряют build.
Если Вы ещё раз прочитаете пост о
а. создании промежуточного буфера трансляции ( в быстрой памяти )
б. процессе построения древа формальных инструкций выполнимого
в. собственно трансляции этого древа на ранних этапах в двоичный код, а со временем в инструкции языка ассемблера
Вы увидите, что создание слоя предварительного анализа заголовков никак не может помочь ускорению трансляции в стадии в, поскольку она полностью сменяет все, что построено в секциях а и б.
И поскольку в финальной стадии все надо строить заново, то длительность выполнения всей операции только растет, при чем весьма серьёзно.
Единственный случай, когда это помогает со скоростью, это когда в коде ничего не изменилось. Тогда компилятор может действительно быстро удостовериться, что все осталось как было и ничего не делать намного быстрее.
Единственный надежный способ ускорять стадию в это минимизировать количество операций связанных с этим шагом.
Именно для этого используется режим компиляции только нового / обновленного кода, совмещенный с созданием буфера предварительного анализа формальных операций ( так называемый "объектный код" ).
В этом случае компилятор оценивает в первую очередь, что именно изменилось, и изменяет или добавляет только эти инструкции в конечный выполнимый.
У этого подхода есть проблема.
В случае, если Вы требуете включить опции оптимизирующие код ( их ведь включают отдельно ) транслятору придется отказаться от быстрого выполнения стадии в и вернуться к полному выполнению всех стадий трансляции кода. Но это ведь можно делать отдельно. Поскольку доверие к сегодняшним трансляторам очень высокое. И если первый, пусть не самый оптимальный вариант выполнимого, может использоваться для поиска дефектов и добавления различных фишек, то высоко оптимизированный вариант продукта всегда можно создать, когда дефекты и фишки признаны на удовлетворительно уровне.
Мирон, всё более-менее нормально, просто я неправильно настроил свой Makefile и не использовал make -j :) Быстро собирает объектные файлы, всё хорошо.
Но вообще для всего сообщества проблема актуальна, и теперь я уже узнал почему компилятор так долго работает — оказывается это не простая трансляция c++ в asm с заменой по словарю AST-дерева на ассемблерные инструкции, а намного более сложная и долгая процедура.
