The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Проект по добавлению в GCC поддержки распараллеливания проце..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Проект по добавлению в GCC поддержки распараллеливания проце..."  +/
Сообщение от opennews (?), 15-Сен-19, 10:44 
В рамках исследовательского проекта Parallel GCC началась работа по добавлению в GCC возможности, позволяющей разделять процесс компиляции на несколько параллельно выполняемых потоков. В настоящее время для повышения скорости сборки на многоядержных системах на уровне утилиты make применяется запуск отдельных процессов компилятора, каждый из которых выполняет сборку отдельного файла с кодом. Новый проект экспериментирует с обеспечением  распараллеливания на уровне компилятора, что потенциально позволит повысить эффективность работы на многоядерных системах...

Подробнее: https://www.opennet.dev/opennews/art.shtml?num=51491

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


1. "Проект по добавлению в GCC поддержки распараллеливания проце..."  –6 +/
Сообщение от Онаним (?), 15-Сен-19, 10:44 
> Тесты на системе с CPU Intel Core i5-8250U

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

7. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +14 +/
Сообщение от Аноним (-), 15-Сен-19, 11:30 
Множество процессов компиляции неэффективно по памяти
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

94. "Проект по добавлению в GCC поддержки распараллеливания проце..."  –3 +/
Сообщение от Аноним (94), 16-Сен-19, 16:30 
Зато более эффективно по процессору, а память можно докупить
Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

101. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +/
Сообщение от Аноним (101), 18-Сен-19, 16:37 
И процессор можно докупить. Видимо только время нельзя докупить ...
Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

103. "Проект по добавлению в GCC поддержки распараллеливания проце..."  –1 +/
Сообщение от Онаним (?), 21-Сен-19, 11:51 
Память ныне стоит сущие копейки. Городить при этом какой-то огород, перепахивая кусками компилятор, в котором и так чёрт ногу сломит... работа ради работы, без цели и смысла.
Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

106. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +/
Сообщение от Алексей Михайловичemail (?), 24-Сен-19, 14:36 
То есть, никто не понимает, что разрабы пытаются удешевить (по времени, танкисты, по времени) управление памятью и ЦП вместо того, чтобы при компиляции генерировать кучу ненужных системных вызовов, только отнимающих время, и упираться по потолку производительности в шедулер? Пздц вы тупые, откуда вам вообще сюда выпустили?
Ответить | Правка | ^ к родителю #103 | Наверх | Cообщить модератору

108. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +/
Сообщение от Онаним (?), 24-Сен-19, 20:39 
> То есть, никто не понимает, что разрабы пытаются удешевить (по времени, танкисты,
> по времени) управление памятью и ЦП вместо того, чтобы при компиляции
> генерировать кучу ненужных системных вызовов, только отнимающих время, и упираться по
> потолку производительности в шедулер? Пздц вы тупые, откуда вам вообще сюда
> выпустили?

Штопрастите?

Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

12. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +2 +/
Сообщение от Аноним (12), 15-Сен-19, 11:53 
Купи им 9900K
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

87. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +3 +/
Сообщение от Аноним (87), 16-Сен-19, 07:50 
Компиляция, тем более распараллеленная гораздо лучше пойдет на R9 3950X.
Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

104. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +/
Сообщение от Онаним (?), 21-Сен-19, 11:51 
> Компиляция, тем более распараллеленная гораздо лучше пойдет на R9 3950X.

Вот да. И даже никакого дорогостоящего перепахивания компилятора не потребуется :D, а эффект будет куда выше, чем от перепахивания для всяких мобильных i5.

Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

29. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +2 +/
Сообщение от Аноним (29), 15-Сен-19, 13:56 
В Сях нужно не парралелить, а кешировать заголовки
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

30. "Проект по добавлению в GCC поддержки распараллеливания проце..."  –13 +/
Сообщение от Анонец (?), 15-Сен-19, 14:01 
Студни-хипсторы решили помучить поциента перед его окончательной кончиной.

Шланг смотрит на всё это со снисходительной улыбкой

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

43. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +5 +/
Сообщение от Аноним (43), 15-Сен-19, 14:48 
Шланг смотреть с улыбкой не может, у него те же болячки. У него так же делается "распаралеливание" как и у GCC (запуск множества процессов шланга).
Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

93. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +/
Сообщение от Аноним (93), 16-Сен-19, 13:27 
а чем это плохо? не модно ?
Или нужно еще сильнее дергать головки у диска - что бы скорость упала.
Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

107. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +/
Сообщение от Алексей Михайловичemail (?), 24-Сен-19, 14:37 
Это плохо лишними сисколлами и отсутствием нормального интерпроцессного взаимодействия. Тредами рулить удобнее и дешевле, чем полноценными инстансами.
Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

74. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +6 +/
Сообщение от Michael Shigorinemail (ok), 15-Сен-19, 20:24 
Например, для целей CI, когда время сборки оказывается более существенным, чем при единичном запуске...

Мне другое непонятно -- при всей востребованности распараллеливания сборки _единичной_ цели как они собираются это увязывать с распараллеливанием средствами того же make?  Пока напрашивается разве что массовый переход сборочных систем на использование -l вместо -j как минимум в нормальном make, но при изолированных окружениях это потребует пробрасывания как минимум настоящего /proc/loadavg в чруты.

Мы обдумывали нечто перекликающееся в плане оптимизации плотности использования сборочных узлов в условиях, когда параллельно запускаемые сборки могут параллелиться, а могут и нет.  Пока применяю gnu parallel для некоторых задач, но в случае "девятого вала" хорошо параллелящихся тяжёлых сборок узлам бывает грустно.

А сейчас представил себе параллелизацию третьего порядка (пакеты, цели, и затем внутренняя по каждой цели вдобавок) -- для aarch64 это было бы полезно вотпрямщас, на ppc64le с его горой потоков тоже бы уже пригодилось, но как с этим всем управляться -- пока вопрос.

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

80. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +1 +/
Сообщение от Аноним (80), 15-Сен-19, 21:17 
Тоже сразу возник вопрос про связь с make -j. Пока кажется, что параллелизация через make будет эффективнее. Сколько раз смотрел на загрузку ядер при сборке make -j по количеству ядер, всегда все ядра на 100% использовались. А тут что-то идеального повышения производительности не видно пока.
Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

82. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +2 +/
Сообщение от iZENemail (ok), 16-Сен-19, 00:08 
Да нет никакой связи с make -j кроме чистой детерминированности процесса сборки - когда компиляция одного куска кода зависит от результата компиляции другого.

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

Планировщики современных операционных систем учитывают особенности многоядерности и топологию их вычислительных модулей. Для Ryzen 3xxx даже специальные исправления выходили по привязыванию отдельных нитей, использующих общие данные, к одному CCX (каждая нить исполняется на "своём" ядре внутри CCX) - что исключает операции по синхронизации кэшей отдельных CCX и увеличивает быстродействие.

Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

90. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +1 +/
Сообщение от Аноним (90), 16-Сен-19, 11:45 
> Вся суть многопоточной, а не многопроцессной компиляции в том, чтобы родственные нити
> выполнялись на одном или соседних ядрах с общим кэшем инструкций и
> данных - так уменьшается вероятность перезагрузки кэшей и в разы ускоряется
> доступ к данным.

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

Что касается данных, я не просто возьму из головы некие "разы", а поделю 1000мб, которые процесс компилятора занял в памяти под AST (где Т означает не последовательно расположенные данные, а дерево), на объём кэша, и скажу, что вероятность не изменилась.

Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

97. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +/
Сообщение от iZEN (ok), 16-Сен-19, 20:42 
>> Вся суть многопоточной, а не многопроцессной компиляции в том, чтобы родственные нити
>> выполнялись на одном или соседних ядрах с общим кэшем инструкций и
>> данных - так уменьшается вероятность перезагрузки кэшей и в разы ускоряется
>> доступ к данным.
> Простите за такую подробность, но процессор это не виртуальная машина Джавы, он
> ничего не знает про процессы. Если образ одного и того же
> исполняемого файла отображается в разные адресные пространства, то физические страницы
> с кодом должны быть везде одни и те же, соответственно и
> кеш инструкций когерентен.

Зато новый планировщик знает об особенностях архитектуры процессора и какую нить прицепить к какому ядру среди нескольких CCX. В Ryzen общий кэш распределённый между CCX, а скорость доступа данных нити, привязанной к одному ядру, зависит от того, в каком участке кэша находятся её и родственной нити данные. Если в участке кэша, связанным с другим CCX, то нужна пересылка этих данных оттуда по протоколу обмена данными между CCX, принаджежащих разным CCD, с задействованием I/O-чиплета — работа замедляется на время этой чисто аппаратной операции. Если две нити работают на разных ядрах одного CCX, то задержки не возникает — их разделяемые данные находятся в участке кэша CCX.

"В один блок CCX объединяется 4 ядра и 16 Мбайт общей кеш-памяти третьего уровня. Пара CCX располагается на одном 7-нм полупроводниковом кристалле и формирует процессорный чиплет, получивший аббревиатуру CCD (Core Complex Die). В зависимости от того, о каком процессоре семейства Ryzen 3000 идёт речь, он может состоять либо из двух, либо из трёх чиплетов. В процессорах с числом ядер восемь и менее применяется один CCD-чиплет и один I/O-чиплет. В процессорах с числом ядер более восьми CCD-чиплетов становится уже два. Однако нужно понимать, что процессор при этом всё равно остаётся единым целым. За счёт того, что в любых Ryzen 3000 контроллер памяти находится в I/O-чиплете и он всего один, любое из ядер может гладко обращаться к любым её областям: никаких NUMA-конфигураций, которые портили жизнь владельцам процессоров Threadripper, в случае Zen 2 не будет."

С процессами это осуществить сложнее, так как нити в раздельных процессах имеют защиту памяти и нуждаются в отдельном протоколе обмена межпроцессного взаимодействия (IPC). Это оверхед.

Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

85. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +1 +/
Сообщение от Ю.Т. (?), 16-Сен-19, 07:02 
Системы с общей памятью (потоки и т.д.) хороши далеко не для всех задач. Задачи трансляции-компоновки хорошо авто-параллелятся далеко не во всех случаях. ))
Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

105. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +/
Сообщение от Онаним (?), 21-Сен-19, 11:54 
А при чём тут CI и цели? Тут речь идёт о внутреннем распараллеливании сборки одного-единственного файла. Зачем это - ума не приложу. Любителей собирать многомегабайтные монолиты вроде не осталось.
Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

2. "Проект по добавлению в GCC поддержки распараллеливания проце..."  –8 +/
Сообщение от Аноним (2), 15-Сен-19, 11:13 
>Новый проект экспериментирует с обеспечением распараллеливания на уровне компилятора, что потенциально позволит повысить эффективность работы на многоядерных системах.

Потоки? Многоядерные системы? В 2019? Да не это бред какой-то
Если бы они сущестовали то наверняка их поддержка появилась бы в GNU HURD

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

15. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +2 +/
Сообщение от Аноним (15), 15-Сен-19, 12:04 
Интересно как мы так раньше всю жизнь компилировали что сабж был не нужен.
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

66. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +3 +/
Сообщение от Илья (??), 15-Сен-19, 18:00 
Медленно
Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

46. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +1 +/
Сообщение от Аноним (43), 15-Сен-19, 14:50 
Кто о чём а вшивый о бане. Анониму видимо невдамёк, что Hurd забросили сразу после первого выпуска Linux. То, что они делают сейчас -- предсмертные конвульсии. Какие-то жалкие попытки 1.5 анонимов допилить ядро, примерно то же, что происходит с React OS.
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

54. "Проект по добавлению в GCC поддержки распараллеливания проце..."  –1 +/
Сообщение от Аноним (54), 15-Сен-19, 15:25 
А что там у реакт ОС?
Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

84. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +3 +/
Сообщение от Аноним (84), 16-Сен-19, 06:37 
Да, но пока нет.
Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

3. "Проект по добавлению в GCC поддержки распараллеливания проце..."  –3 +/
Сообщение от Андрей (??), 15-Сен-19, 11:16 
Интересно, как оно грузит ядра. Ибо если все 4/8 ядра на все 100%, но ускоряет суммарно в 2,5 раза, то получается, наверняка, энергетически невыгодно.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

8. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +/
Сообщение от Аноним (-), 15-Сен-19, 11:32 
Судя по тексту в статье распараллелили не все этапы компиляции
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

14. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +2 +/
Сообщение от pda (?), 15-Сен-19, 12:00 
man "Закон Амдала"

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

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

75. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +4 +/
Сообщение от Michael Shigorinemail (ok), 15-Сен-19, 20:26 
Так это оптимизация не энергозатрат, а времени выполнения.
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

88. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +/
Сообщение от Аноним (88), 16-Сен-19, 10:08 
Грузить ЦП на 100% всегда выгодно
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

96. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +/
Сообщение от Аноним (96), 16-Сен-19, 19:13 
Вы не правы. По крайней мере на процессорах Intel серии U это не так из-за термального режима, на который они конструктивно рассчитаны, и соответственно thermal throttling'а. Другими словами - ограничив нагрузку до 80-90%, получаем в среднем меньший вольтаж и более быструю результирующую компиляцию из-за меньшего троттлинга (штеуд перестраховывается? может быть). Полагаю, с штатными кулерами AMD, которые идут в комплекте с последними Ryzen - всё так же, но менее выражено в %.
Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

98. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +1 +/
Сообщение от Аноним (98), 17-Сен-19, 10:40 
>По крайней мере на процессорах Intel серии U это не так из-за термального режима, на который они конструктивно рассчитаны, и соответственно thermal throttling'а. Другими словами - ограничив нагрузку до 80-90%

Я говорю про нормальные процессоры, а не обрезки, максимум которых - просмотр ютуба

Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

102. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +/
Сообщение от Аноним (101), 18-Сен-19, 16:40 
Какой Ютуб очнитесь это текстовые стратегии и консольный режим для терминалов из 80-х всякие там имаксы и прочая чепушень
Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

4. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +4 +/
Сообщение от Андрей (??), 15-Сен-19, 11:20 
Несмотря на распараллеливание в make&Co я, похоже, знаю, почему им пришлось взяться за компилятор. Это всё C++. С помощью его шаблончиков можно сваять сравнительно небольшой исходник, который будет компилироваться несколько минут и отхватит несколько гигов памяти. Тут никакой "-j4" не поможет.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

6. "Проект по добавлению в GCC поддержки распараллеливания проце..."  –1 +/
Сообщение от Аноним (6), 15-Сен-19, 11:26 
Свопить на оптан?
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

24. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +3 +/
Сообщение от Аноним (24), 15-Сен-19, 13:30 
Оптан стоит денег, медленнее сам по себе, кэш промахи при -jX стремятся к 100%.
Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

44. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +/
Сообщение от Аноним (6), 15-Сен-19, 14:49 
По сравнению с терабайтом RAM, это хоть как-то вариант.
Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

55. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +/
Сообщение от Аноним (90), 15-Сен-19, 15:39 
> По сравнению с терабайтом RAM, это хоть как-то вариант.

И где тот оптан на терабайт?

Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

71. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +/
Сообщение от Stax (ok), 15-Сен-19, 19:58 
Тут? https://www.amazon.com/Intel-Optane-905P-960GB-XPoint/dp/B07...
В россии, конечно, подороже https://www.citilink.ru/catalog/computers_and_notebooks/hdd/.../

Но все равно в 8 раз дешевле оперативки.

Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

91. "Проект по добавлению в GCC поддержки распараллеливания проце..."  –2 +/
Сообщение от Аноним (90), 16-Сен-19, 11:52 
> Тут?

Ага, спасибо. Тогда у меня следующий вопрос: сколько ангелов уместится на булавочной головке?

Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

9. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +4 +/
Сообщение от vitalif (ok), 15-Сен-19, 11:34 
Ога. Но при этом один уберфайл скомпилится гораздо быстрее, чем куча мелких ))) потому что как раз заголовки, шаблоны и т.п. только 1 раз обрабатываются.

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

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

13. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +1 +/
Сообщение от Аноним (13), 15-Сен-19, 11:54 
Как не сделали? Сделали! и без компилятора даже: https://github.com/sakra/cotire
Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

18. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +1 +/
Сообщение от Андрей (??), 15-Сен-19, 12:39 
> Но при этом один уберфайл скомпилится гораздо быстрее, чем куча мелких )))

100 КБ файл с шаблончиками -> 1 ГБ ОЗУ
10 МБ уберфайл -> 100 ГБ ОЗУ
Не, не выйдет.

> почему до сих пор не сделали компилятор, который всё лепил бы в один файл

Тут и специфический компилятор не нужен. При сборке Chromium есть опция JUMBO build. Эффект, вроде, как раз тот.

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

63. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +3 +/
Сообщение от all_glory_to_the_hypnotoad (ok), 15-Сен-19, 17:16 
Не сможешь делать инкрементальную сборку, т.е. даже при незначительном изменении будет нужно пересобирать всё. Есть костыли типа precompiled headers и может быть после появления модулей плюсы научатся делать нормальные промежуточные сборки модулей.
Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

38. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +1 +/
Сообщение от Аноним (38), 15-Сен-19, 14:43 
Ничего удивительного, шаблоны могут в рекурсии.
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

47. "Проект по добавлению в GCC поддержки распараллеливания проце..."  –1 +/
Сообщение от Аноним (43), 15-Сен-19, 14:52 
> С помощью его шаблончиков можно сваять сравнительно небольшой исходник, который будет компилироваться несколько минут и отхватит несколько гигов памяти.

Пример шаблона ф студию. У меня всего 4Gb, компилирую проекты на 20Gb спокойно.

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

58. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +2 +/
Сообщение от Андрей (??), 15-Сен-19, 16:16 
Например, установите (или скомпилируйте сами) библиотеку https://github.com/ukoethe/vigra и соберите крошечный набор enblend-enfuse https://sourceforge.net/projects/enblend/files/enblend-enfus...
Что при компиляции enblend, что enfuse в составе этого проекта наблюдаются задержки и рост потребления памяти.
Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

5. "Проект по добавлению в GCC поддержки распараллеливания проце..."  –1 +/
Сообщение от Аноним (6), 15-Сен-19, 11:24 
Надеюсь, это не включат по умолчанию. Бывают проекты на нескольких языках, мне нафиг не упёрлось собирать их в 146 потоков.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

11. "Проект по добавлению в GCC поддержки распараллеливания проце..."  –1 +/
Сообщение от Анонимный селебритиemail (?), 15-Сен-19, 11:48 
Если ко времени выпуска впрод этот gcc м симтемой сборки будет крутится на односокетном 128-ми ядерном epyc 7003, то why not?
Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

61. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +2 +/
Сообщение от user (??), 15-Сен-19, 17:04 
упрётся в память, компиляция плохо кэшируется
Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

10. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +1 +/
Сообщение от InuYasha (?), 15-Сен-19, 11:36 
Главное в этой инициативе - чтобы компилятор был NUMA-aware. Т.е. не начал параллелить одну компиляцию на разные физические процессоры или модули, а только на ядра, имеющие общий блок памяти. Иначе будет замедление.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

16. "Проект по добавлению в GCC поддержки распараллеливания проце..."  –2 +/
Сообщение от Аноним (15), 15-Сен-19, 12:05 
Главное они из существующего компилятора сделают такое УГ что единственным способом решения его проблем станет переход на раст.
Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

41. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +/
Сообщение от Аноним (38), 15-Сен-19, 14:48 
А Rust, кроме своих, ещё начится компилировать исходники C, C++, Go, Fortran.
Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

76. "Проект по добавлению в GCC поддержки распараллеливания проце..."  –1 +/
Сообщение от Michael Shigorinemail (ok), 15-Сен-19, 20:31 
...а ещё лет через сорок до растоманов дойдёт, что их УГ можно было собирать параллельно...
Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

81. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +/
Сообщение от Ordu (ok), 15-Сен-19, 23:43 
Это ты к чему? Раст собирает параллельно столько, сколько я с ним вожусь, то есть с 2014 года как минимум.
Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

92. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +/
Сообщение от Аноним (90), 16-Сен-19, 11:58 
> ...а ещё лет через сорок до растоманов дойдёт, что их УГ можно
> было собирать параллельно...

Он и собирает параллельно. При сборке firefox сначала порождается процессов сколько надо, потом из них 1-2 начинают собирать rust и кол-во потоков утраивается. Как этот новый транслятор выйдет, так С его догонит по кол-ву лишних потоков.

Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

53. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +2 +/
Сообщение от CrazyAlex (?), 15-Сен-19, 15:20 
Главное - чтобы оно выключалось. А лучше - чтобы не попало в gcc вообще. Уж что-что, а компиляция в разных процессах работает отлично, и при этом хорошо контролируется при нужде - хоть по нагрузке, хоть по памяти, хоть как.
Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

17. "Проект по добавлению в GCC поддержки распараллеливания проце..."  –5 +/
Сообщение от Аноним (17), 15-Сен-19, 12:29 
GCC в прошлом. Модные парни уже давно перешли на MUSL + LLVM + CLANG
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

19. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +2 +/
Сообщение от Llvm (?), 15-Сен-19, 12:58 
Ничего против clang не имею.
Но вот его баг в актуальной версии 8.0 с двойным вызовом деструктивных при исключении в лямбде реально достаёт. Баг есть, а фиксить не спешат.
Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

20. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +1 +/
Сообщение от Llvm (?), 15-Сен-19, 13:00 
s/деструктивных/деструкторов/
Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

22. "Проект по добавлению в GCC поддержки распараллеливания проце..."  –1 +/
Сообщение от Аноним (90), 15-Сен-19, 13:25 
> GCC в прошлом. Модные парни уже давно перешли на MUSL + LLVM
> + CLANG

Давно systemd собирается с MUSL?

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

23. "Проект по добавлению в GCC поддержки распараллеливания проце..."  –1 +/
Сообщение от Аноним (17), 15-Сен-19, 13:29 
не позорься со своим системд. Такие вещи даже страшно вслух произносить.
нормисы юзают S6/runint
Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

25. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +3 +/
Сообщение от Аноним (90), 15-Сен-19, 13:38 
> не позорься со своим системд. Такие вещи даже страшно вслух произносить.

Экий ты шустрик в переобувке. Я позорюсь с твоим "Модные парни".

> нормисы юзают S6/runint

Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

27. "Проект по добавлению в GCC поддержки распараллеливания проце..."  –1 +/
Сообщение от Аноним (17), 15-Сен-19, 13:52 
Дело не в переобувки. А в сути - почему люди добровольно отказываются от Поеттеринга во всех его проявлениях, будь то pulseaudio, systemd и еще что-нибудь.
Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

37. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +/
Сообщение от Аноним (90), 15-Сен-19, 14:39 
> Дело не в переобувки. А в сути - почему люди добровольно отказываются
> от Поеттеринга во всех его проявлениях, будь то pulseaudio, systemd и
> еще что-нибудь.

А в чём дело? Теперь ты меня спрашиваешь, почему MUSL не поддерживается в systemd. Мне то откуда знать, почему ты заявил что модный парень Поеттеринг перешёл на MUSL, когда это не так.

Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

50. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +/
Сообщение от Аноним (43), 15-Сен-19, 14:55 
> будь то pulseaudio

Поттеринг его забросил, и как только это случилось он стал конфеткой. Сейчас он что-то новое там хочет пилить, замена пульсе.

Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

28. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +/
Сообщение от Аноним (17), 15-Сен-19, 13:55 
Конечно если речь не о прод серверах. там до сих пор на убунте 16.04 сидят или кастрированной Centos.
Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

36. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +/
Сообщение от Аноним (15), 15-Сен-19, 14:35 
У кого-то прод серверы на венде и им норм.
Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

68. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +3 +/
Сообщение от Аноним (68), 15-Сен-19, 18:32 
Кому и кобыла невеста.
Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

49. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +1 +/
Сообщение от Аноним (43), 15-Сен-19, 14:54 
> не позорься со своим системд.

Реклама uselessd?

> Такие вещи даже страшно вслух произносить.

Действительно. Шёл 2019 год, а ненужнод не может в Musl.

Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

72. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +/
Сообщение от Stax (ok), 15-Сен-19, 20:04 
> Реклама uselessd?

Но оно же умерло вскоре после рождения, еще лет 5 назад.

Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

26. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +1 +/
Сообщение от Лох (?), 15-Сен-19, 13:52 
Как запилить тулчейн musl+clang и кросскомпилить под i586? Так и не нашел гайдов, под такой же кейс, но с gcc, гайдов куча. Может поможет кто-нибудь?

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

77. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +/
Сообщение от Michael Shigorinemail (ok), 15-Сен-19, 20:33 
Простой 32-битный чрут не выручит часом?
Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

45. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +2 +/
Сообщение от Аноним (38), 15-Сен-19, 14:49 
>MUSL + LLVM + CLANG

Модно, стильно, молодёжно!

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

21. "Проект по добавлению в GCC поддержки распараллеливания проце..."  –3 +/
Сообщение от Аноним (21), 15-Сен-19, 13:13 
А почему нет новостей как Столман отжигает в своем репертуаре?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

31. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +1 +/
Сообщение от Аноним (15), 15-Сен-19, 14:07 
Потому что ты эту новость не написал.
Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

32. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +1 +/
Сообщение от Аноним (15), 15-Сен-19, 14:08 
Подсказка https://www.opennet.dev/announce_news.shtml
Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

39. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +/
Сообщение от лексус торнварцс (?), 15-Сен-19, 14:43 
Он уже _ИЗВИНИЛСЯ_ перед сжв https://stallman.org/archives/2019-jul-oct.html#14_September...(Sex_between_an_adult_and_a_child_is_wrong)
Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

48. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +/
Сообщение от Аноним (38), 15-Сен-19, 14:53 
А может быть, Столман это поддержит?
Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

35. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +1 +/
Сообщение от Аноним (-), 15-Сен-19, 14:34 
Дядя типереча тормознутые исходники на C++ будут быстро компилится?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

42. "Проект по добавлению в GCC поддержки распараллеливания проце..."  –1 +/
Сообщение от Корец (?), 15-Сен-19, 14:48 
Из серии "Давно пора"
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

57. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +1 +/
Сообщение от nm0i (ok), 15-Сен-19, 16:00 
В итоге оптимальным вариантом будет что-то вроде сочитания gcc -j N и make -j M -l K, да?..
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

64. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +1 +/
Сообщение от all_glory_to_the_hypnotoad (ok), 15-Сен-19, 17:22 
Идеальным вариантом по-прежнему будет make -j N просто хотя бы из-за большого кол-ва исходников в  проектах. Распараллеливать gcc имеет смысл только если пересобирать небольшую часть проекта во время разработки.
Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

67. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +/
Сообщение от Ordu (ok), 15-Сен-19, 18:20 
> Распараллеливать gcc имеет смысл только если пересобирать небольшую часть проекта во время разработки.

То есть в большинстве случаев использования компилятора.

Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

78. "Проект по добавлению в GCC поддержки распараллеливания проце..."  –2 +/
Сообщение от Michael Shigorinemail (ok), 15-Сен-19, 20:39 
Кстати, а вот make-овый jobserver как раз может скумекать, когда собирает _одну_ цель -- и научиться добавлять компилятору уже _его_ -j или что там... тогда проблему неуправляемого параллелизма в квадрате вроде как получается решить.

Ну или пущать с -jJ/N, условно говоря, где J -- сколько потоков разрешили самому make, N -- количество собираемых сейчас целей; но тут есть "уязвимость" к случаю, когда цели собираются с сильным разлётом длительности и предположение об N (кроме N == 1) перекашивает на протяжении заметной части общего времени сборки.

Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

79. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +/
Сообщение от all_glory_to_the_hypnotoad (ok), 15-Сен-19, 21:05 
make чаще собирает одну цель когда линкует, а не компилирует. Проблема решается засовыванием всех процессов в cgroup-у. Т.е. make со всеми дочерними процессами должет отжирать примрно одинаковое кол-во CPU независимо от кол-ва процессов. Или можно костылить завышением nice всем процессам сборки. Опция -j N у компилятора может быть полезной, но ставить её лучше в фиксированное небольшое значение типа 2-3.
Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

100. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +/
Сообщение от пох. (?), 17-Сен-19, 18:43 
> Проблема решается засовыванием всех процессов в cgroup-у.

"новый стандарт" - ненужен.

Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

59. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +1 +/
Сообщение от Anonimous (?), 15-Сен-19, 16:35 
Т.е., забив четыре потока, компиляция ускорится всего в полтора раза?

Почему не приведено сравнение с вариантом, когда в четыре потока запускаются разные процессы, и какой выигрыш/проигрыш в этом случае по сравнению с новыми разработками.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

60. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +/
Сообщение от Аноним (17), 15-Сен-19, 17:03 
я когда генту впервые пилил ставил -j30 и норм работает
Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

70. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +/
Сообщение от Аноним (70), 15-Сен-19, 19:34 
надеюсь не на hdd? а то сложно предстаить какой там треск стоял:)
Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

83. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +1 +/
Сообщение от Аноним (83), 16-Сен-19, 01:53 
На HDD. Никакой не стоял. Средний объём исходника и какой это объём данных и IOPS в 30 потоков посчитать несложно, чтобы чуши больше не писать.
Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

62. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +1 +/
Сообщение от Аноним (17), 15-Сен-19, 17:08 
и в мейк файл MAKEOPTS=-j256
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

69. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +/
Сообщение от Аноним (83), 15-Сен-19, 18:59 
Надеюсь в апстрим не примут. Всё замечательно параллелится мейком, усложнение кода не оправдано.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

86. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +/
Сообщение от Griggoriiemail (?), 16-Сен-19, 07:25 
Берешь 16 ядерный проц и ssd диск ставишь make -j16 и все быстро , а если у тебя проц 2 ядерный то выставить ты можешь только make -j2 или же хоть make -j32 все равно будет работать как j2 потому что проц двух ядерный , а не ишь че захотел 32 ядерный 32 потока. Но это ладно мне вот интересно что компилятор все время проц требует чем много процессорнее тем лучше , а где хоть один созданный компилятор который будет требовать скорость диска и чем больше скорость ssd тем быстрее было ехало , т.е я примерно докину свою мысль если бы я знал как программить компилятор то я бы драйвер процессорности заменил на драйвер диска.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

89. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +1 +/
Сообщение от Аноним (89), 16-Сен-19, 10:36 
Рекомендуется -j(n+1)
Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

95. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +/
Сообщение от Аноним (17), 16-Сен-19, 16:53 
Так то да. Можно рискуть еще активизировать funroll-loops 03, а лучше выставить все возможные опти флаги
Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

99. "Проект по добавлению в GCC поддержки распараллеливания проце..."  +/
Сообщение от Аноним (99), 17-Сен-19, 13:03 
На Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz (4 ядра & даблтред) gcc 9.2 в полном комплекте собирается полчаса в 16 потоков make (make -j 16) при неполной загрузке дисковой подсистемы.
Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру