- =A=L=X=
- Постоялец
skalogryz
> А при сборке всего проекта с нуля, модули вполне могут и проиграть.
Это они просто энергоэффективность не учитывали - у объектников больше способность параллелится в этом ключе именно потому что каждый параллельный поток делает одну и ту же алгоритмическую работу по парсингу одних и тех же текстов - о да, мы можем много потоков запустить параллельно, но выполнять они будут одни и те же задачи с тем же результатом.
Поэтому вменяемый модульный билдер с анализаторами зависимостей будет на реальных проектах скорее всего и быстрее и энергоэффективнее, чем объектники, причём последнее в разы умноженные на количество потоков.
А почему он всё-равно окажется в реальных проектах быстрее оставляю на подумать.
skalogryz
> Поговаривают
А глаза видят обратное
> Зависимостей нет
Что в них плохого, перекомпилируются только измененные по дате файлы
> при сборке всего проекта с нуля
Делается один раз
=A=L=X=
> каждый параллельный поток делает одну и ту же алгоритмическую работу по парсингу одних и тех же текстов - о да, мы можем много потоков запустить параллельно, но выполнять они будут одни и те же задачи с тем же результатом.
+
=A=L=X=
по-моему парсинг занимает процентов 10 от времени компиляции, постановка шаблонов намного больше. Так что ускорение будет зависеть от того как будут дела с шаблонами.
kipar
парсинг значительно сокращает обьем текста заменой идентификаторов на id-шники
1Man1
да, но это происходит и с модулями и без модулей
kipar
> по-моему парсинг занимает процентов 10 от времени компиляции, постановка
> шаблонов намного больше.
У gcc есть флаг -ftime-report который показывает статистику.
На hello, world с iostream-ами он у меня показывает так:
Time variable usr sys wall GGC phase parsing : 0,33 ( 88%) 24094 kB ( 88%) phase lang. deferred : 0,03 ( 8%) 2124 kB ( 8%) phase opt and generate : 0,01 ( 2%) 197 kB ( 1%) |name lookup : 0,04 ( 11%) 931 kB ( 3%) |overload resolution : 0,03 ( 7%) 1931 kB ( 7%) callgraph construction : 0,01 ( 2%) 152 kB ( 1%) preprocessing : 0,05 ( 12%) 842 kB ( 3%) parser (global) : 0,06 ( 17%) 10403 kB ( 38%) parser struct body : 0,08 ( 21%) 3839 kB ( 14%) parser function body : 0,02 ( 6%) 970 kB ( 4%) parser inl. func. body : 0,02 ( 6%) 776 kB ( 3%) parser inl. meth. body : 0,03 ( 9%) 2037 kB ( 7%) template instantiation : 0,09 ( 24%) 7310 kB ( 27%) TOTAL : 0,38 27287 kB
Руки чешутся на каком нибудь более тяжёлом модуле тяжелого проекта, но у меня возможности сейчас ограничены.
=A=L=X=
А где оптимизация?
Имбирная Ведьмочка
> А где оптимизация?
"phase opt and generate"
Когда инклудишь все cpp в один файл (unity build), парсить ведь меньше не приходится (?), а полный ребилд ускорялся в 10 раз у меня, когда я последний раз пробовал.
entryway
> Когда инклудишь все cpp в один файл (unity build), парсить ведь меньше не
> приходится (?)
Приходится. В юнити билде каждый хидер парсится ровно один раз (#pragma once и бутлег-аналоги), тогда как в классическом — повторно на каждую единицу трансляции, в которой использован — так что суммарный объём для парсинга оказывается больше.
Имбирная Ведьмочка
> В юнити билде каждый хидер парсится ровно один раз
+
gcc 15.1.0 вышел с улучшенной поддержкой модулей, наконец то добавили std и std.compact
Кто уже опробовал на чем-то большом?
Aroch
> на чем-то большом?
Все прям ринулись пробовать. Особенно те, кому по большому, лол
Ghost2
> Все прям ринулись пробовать. Особенно те, кому по большому, лол
зачем все? Достаточно одного, впрочем я уже нашел такого. Кекай дальше.