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

"Проект по добавлению в GCC поддержки распараллеливания проце..."	+/–
Сообщение от opennews (?), 15-Сен-19, 10:44
В рамках исследовательского проекта Parallel GCC началась работа по добавлению в GCC возможности, позволяющей разделять процесс компиляции на несколько параллельно выполняемых потоков. В настоящее время для повышения скорости сборки на многоядержных системах на уровне утилиты make применяется запуск отдельных процессов компилятора, каждый из которых выполняет сборку отдельного файла с кодом. Новый проект экспериментирует с обеспечением  распараллеливания на уровне компилятора, что потенциально позволит повысить эффективность работы на многоядерных системах... Подробнее: https://www.opennet.me/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 поддержки распараллеливания проце..."	+/–
	Сообщение от Алексей Михайлович (?), 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 поддержки распараллеливания проце..."	+/–
	Сообщение от Алексей Михайлович (?), 24-Сен-19, 14:37
	Это плохо лишними сисколлами и отсутствием нормального интерпроцессного взаимодействия. Тредами рулить удобнее и дешевле, чем полноценными инстансами.
	Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

	74. "Проект по добавлению в GCC поддержки распараллеливания проце..."	+6 +/–
	Сообщение от Michael Shigorin (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 +/–
	Сообщение от iZEN (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 Shigorin (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 +/–
	Сообщение от Анонимный селебрити (?), 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 Shigorin (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 Shigorin (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.me/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 Shigorin (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 поддержки распараллеливания проце..."	+/–
Сообщение от Griggorii (?), 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 | Индекс форумов | Темы | Пред. тема | След. тема