Войти
ФлеймФорумПрограммирование

Модули C++ (30 стр)

Страницы: 126 27 28 29 30 31 Следующая »
#435
7:30, 12 окт 2023

kipar
> означает ли "x < a > b" два сравнения или объявление переменной
Вот же гадство

#436
9:07, 12 окт 2023

1Man1
> Смысл модулей - быстрая компиляция, когда на Pentium 1 Delphi 3 конпилирует со
> скоростью света

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

#437
9:52, 12 окт 2023

0iStalker
Неправильно - либо модули, либо инлайны и шаблоны

#438
(Правка: 4:19) 4:11, 13 окт 2023

1Man1
> Смысл модулей - быстрая компиляция, когда на Pentium 1 Delphi 3 конпилирует со
> скоростью света и Code Completion мгновенно выводит (надо сказать в C# тоже самое)
Поговаривают, что при остутствуии модулей, сборка проекта параллелится легче.
Зависимостей нет, и каждый объектный файл ты собираешь отдельно. (зависимости вылезут, но только на стадии линковки)
При модульной сборке у тебя есть зависимости и ты не можешь начать собирать модули, пока все их зависимости нескомпилированы.

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

Во времени Pentium 1 и Delphi 3, многоядерность многопроцессорность была серверным балавством, и на декстопах не водилась.
(И даже была мода писать две версии кода: многопотчный и однопоточный).
Но в 2023 основной приростот производительности софта - параллелизм.


ЗЫ: даже нагуглил, что-то такого умного:
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1441r1.pdf
(там красивый график на 128 потоков)

5. Conclusion
With the limitations of the capabilities of current compilers one can only conclude that modular builds are very advantageous at lower parallelism levels environments. But that it’s unclear if they are an advantage in highly parallel build environments. In other words, that modules currently do not scale in the same ways as traditional compilation

5. Вывод
Учитывая ограничения возможностей текущих компиляторов, можно только заключить, что модульные сборки очень выгодны в средах с более низкими уровнями параллелизма. Но неясно, являются ли они преимуществом в высокопараллельных средах сборки. Другими словами, эти модули в настоящее время не масштабируются так же, как традиционная компиляция.

т.е. любителям масштабировать на модули в масштабировании отказано!

ЗЗЫ: модули стали культурным явлением. В языках, где модули есть - они есть. В языках, где модулей нет - они просто не нужны!

ЗЗЗЫ: важно заметить, что отдельный Вася скажет: "да ладно! я же не будут проект постоянно с нуля собирать". И будет прав, но, мода на CI/CD, как бы поощерает сборки вчистую.

#439
5:25, 13 окт 2023

skalogryz
> А при сборке всего проекта с нуля, модули вполне могут и проиграть.

Это они просто энергоэффективность не учитывали - у объектников больше способность параллелится в этом ключе именно потому что каждый параллельный поток делает одну и ту же алгоритмическую работу по парсингу одних и тех же текстов - о да, мы можем много потоков запустить параллельно, но выполнять они будут одни и те же задачи с тем же результатом.
Поэтому вменяемый модульный билдер с анализаторами зависимостей будет на реальных проектах скорее всего и быстрее и энергоэффективнее, чем объектники, причём последнее в разы умноженные на количество потоков.
А почему он всё-равно окажется в реальных проектах быстрее оставляю на подумать.

#440
8:33, 13 окт 2023

skalogryz
> Поговаривают
А глаза видят обратное
> Зависимостей нет
Что в них плохого, перекомпилируются только измененные по дате файлы
> при сборке всего проекта с нуля
Делается один раз

#441
8:35, 13 окт 2023

=A=L=X=
> каждый параллельный поток делает одну и ту же алгоритмическую работу по парсингу одних и тех же текстов - о да, мы можем много потоков запустить параллельно, но выполнять они будут одни и те же задачи с тем же результатом.
+

#442
8:44, 13 окт 2023

=A=L=X=
по-моему парсинг занимает процентов 10 от времени компиляции, постановка шаблонов намного больше. Так что ускорение будет зависеть от того как будут дела с шаблонами.

#443
8:59, 13 окт 2023

kipar
парсинг значительно сокращает обьем текста заменой идентификаторов на id-шники

#444
10:56, 13 окт 2023

1Man1
да, но это происходит и с модулями и без модулей

#445
11:17, 13 окт 2023

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

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

#446
12:01, 13 окт 2023

=A=L=X=
А где оптимизация?

#447
12:16, 13 окт 2023

Имбирная Ведьмочка
> А где оптимизация?
"phase opt and generate"

#448
(Правка: 13:04) 12:50, 13 окт 2023

Когда инклудишь все cpp в один файл (unity build), парсить ведь меньше не приходится (?), а полный ребилд ускорялся в 10 раз у меня, когда я последний раз пробовал.

#449
(Правка: 13:53) 13:48, 13 окт 2023

entryway
> Когда инклудишь все cpp в один файл (unity build), парсить ведь меньше не
> приходится (?)
Приходится. В юнити билде каждый хидер парсится ровно один раз (#pragma once и бутлег-аналоги), тогда как в классическом — повторно на каждую единицу трансляции, в которой использован — так что суммарный объём для парсинга оказывается больше.

Страницы: 126 27 28 29 30 31 Следующая »
ФлеймФорумПрограммирование