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

Проект по добавлению в GCC поддержки распараллеливания проце..., opennews (?), 15-Сен-19, (0) [смотреть все] Это всё, что надо знать про данные исследования Сферические теоретические кони , Онаним (?), 10:44 , 15-Сен-19, (1) –6   // Множество процессов компиляции неэффективно по памяти, Аноним (-), 11:30 , 15-Сен-19, (7) +14   // Зато более эффективно по процессору, а память можно докупить, Аноним (94), 16:30 , 16-Сен-19, (94) –3   // И процессор можно докупить Видимо только время нельзя докупить , Аноним (101), 16:37 , 18-Сен-19, (101)   Память ныне стоит сущие копейки Городить при этом какой-то огород, перепахивая , Онаним (?), 11:51 , 21-Сен-19, (103) –1   // То есть, никто не понимает, что разрабы пытаются удешевить по времени, танкисты, Алексей Михайлович (?), 14:36 , 24-Сен-19, (106)   Штопрастите , Онаним (?), 20:39 , 24-Сен-19, (108)   Купи им 9900K, Аноним (12), 11:53 , 15-Сен-19, (12) +2   // Компиляция, тем более распараллеленная гораздо лучше пойдет на R9 3950X , Аноним (87), 07:50 , 16-Сен-19, (87) +3   // Вот да И даже никакого дорогостоящего перепахивания компилятора не потребуется , Онаним (?), 11:51 , 21-Сен-19, (104)   В Сях нужно не парралелить, а кешировать заголовки, Аноним (29), 13:56 , 15-Сен-19, (29) +2   Студни-хипсторы решили помучить поциента перед его окончательной кончиной Шланг , Анонец (?), 14:01 , 15-Сен-19, (30) –13   // Шланг смотреть с улыбкой не может, у него те же болячки У него так же делается , Аноним (43), 14:48 , 15-Сен-19, (43) +5   // а чем это плохо не модно Или нужно еще сильнее дергать головки у диска - что б, Аноним (93), 13:27 , 16-Сен-19, (93)   Это плохо лишними сисколлами и отсутствием нормального интерпроцессного взаимоде, Алексей Михайлович (?), 14:37 , 24-Сен-19, (107)   Например, для целей CI, когда время сборки оказывается более существенным, чем п, Michael Shigorin (ok), 20:24 , 15-Сен-19, (74) +6   // Тоже сразу возник вопрос про связь с make -j Пока кажется, что параллелизация ч, Аноним (80), 21:17 , 15-Сен-19, (80) +1   // Да нет никакой связи с make -j кроме чистой детерминированности процесса сборки , iZEN (ok), 00:08 , 16-Сен-19, (82) +2   Простите за такую подробность, но процессор это не виртуальная машина Джавы, он , Аноним (90), 11:45 , 16-Сен-19, (90) +1   Зато новый планировщик знает об особенностях архитектуры процессора и какую нить, iZEN (ok), 20:42 , 16-Сен-19, (97)   Системы с общей памятью потоки и т д хороши далеко не для всех задач Задачи , Ю.Т. (?), 07:02 , 16-Сен-19, (85) +1   А при чём тут CI и цели Тут речь идёт о внутреннем распараллеливании сборки одн, Онаним (?), 11:54 , 21-Сен-19, (105)   Потоки Многоядерные системы В 2019 Да не это бред какой-тоЕсли бы они сущесто, Аноним (2), 11:13 , 15-Сен-19, (2) –8 // Интересно как мы так раньше всю жизнь компилировали что сабж был не нужен , Аноним (15), 12:04 , 15-Сен-19, (15) +2 // Медленно, Илья (??), 18:00 , 15-Сен-19, (66) +3 Кто о чём а вшивый о бане Анониму видимо невдамёк, что Hurd забросили сразу пос, Аноним (43), 14:50 , 15-Сен-19, (46) +1 // А что там у реакт ОС , Аноним (54), 15:25 , 15-Сен-19, (54) –1 // Да, но пока нет , Аноним (84), 06:37 , 16-Сен-19, (84) +3 Интересно, как оно грузит ядра Ибо если все 4 8 ядра на все 100 , но ускоряет с, Андрей (??), 11:16 , 15-Сен-19, (3) –3 // Судя по тексту в статье распараллелили не все этапы компиляции, Аноним (-), 11:32 , 15-Сен-19, (8) man Закон Амдала Да уж наверняка не выгодно, но на настольных компах на это осо, pda (?), 12:00 , 15-Сен-19, (14) +2 Так это оптимизация не энергозатрат, а времени выполнения , Michael Shigorin (ok), 20:26 , 15-Сен-19, (75) +4 Грузить ЦП на 100 всегда выгодно, Аноним (88), 10:08 , 16-Сен-19, (88) // Вы не правы По крайней мере на процессорах Intel серии U это не так из-за терма, Аноним (96), 19:13 , 16-Сен-19, (96) // Я говорю про нормальные процессоры, а не обрезки, максимум которых - просмотр ют, Аноним (98), 10:40 , 17-Сен-19, (98) +1 Какой Ютуб очнитесь это текстовые стратегии и консольный режим для терминалов из, Аноним (101), 16:40 , 18-Сен-19, (102) Несмотря на распараллеливание в make Co я, похоже, знаю, почему им пришлось взят, Андрей (??), 11:20 , 15-Сен-19, (4) +4 // Свопить на оптан , Аноним (6), 11:26 , 15-Сен-19, (6) –1 // Оптан стоит денег, медленнее сам по себе, кэш промахи при -jX стремятся к 100 , Аноним (24), 13:30 , 15-Сен-19, (24) +3 // По сравнению с терабайтом RAM, это хоть как-то вариант , Аноним (6), 14:49 , 15-Сен-19, (44) И где тот оптан на терабайт , Аноним (90), 15:39 , 15-Сен-19, (55) Тут https www amazon com Intel-Optane-905P-960GB-XPoint dp B07CVNS851В россии, Stax (ok), 19:58 , 15-Сен-19, (71) Ага, спасибо Тогда у меня следующий вопрос сколько ангелов уместится на булаво, Аноним (90), 11:52 , 16-Сен-19, (91) –2 Ога Но при этом один уберфайл скомпилится гораздо быстрее, чем куча мелких , vitalif (ok), 11:34 , 15-Сен-19, (9) +4 // Как не сделали Сделали и без компилятора даже https github com sakra cotire, Аноним (13), 11:54 , 15-Сен-19, (13) +1 100 КБ файл с шаблончиками - 1 ГБ ОЗУ10 МБ уберфайл - 100 ГБ ОЗУНе, не выйдет , Андрей (??), 12:39 , 15-Сен-19, (18) +1 Не сможешь делать инкрементальную сборку, т е даже при незначительном изменении, all_glory_to_the_hypnotoad (ok), 17:16 , 15-Сен-19, (63) +3 Ничего удивительного, шаблоны могут в рекурсии , Аноним (38), 14:43 , 15-Сен-19, (38) +1 Пример шаблона ф студию У меня всего 4Gb, компилирую проекты на 20Gb спокойно , Аноним (43), 14:52 , 15-Сен-19, (47) –1 // Например, установите или скомпилируйте сами библиотеку https github com ukoe, Андрей (??), 16:16 , 15-Сен-19, (58) +2 Надеюсь, это не включат по умолчанию Бывают проекты на нескольких языках, мне н, Аноним (6), 11:24 , 15-Сен-19, (5) –1 // Если ко времени выпуска впрод этот gcc м симтемой сборки будет крутится на однос, Анонимный селебрити (?), 11:48 , 15-Сен-19, (11) –1 // упрётся в память, компиляция плохо кэшируется, user (??), 17:04 , 15-Сен-19, (61) +2 Главное в этой инициативе - чтобы компилятор был NUMA-aware Т е не начал парал, InuYasha (?), 11:36 , 15-Сен-19, (10) +1 // Главное они из существующего компилятора сделают такое УГ что единственным спосо, Аноним (15), 12:05 , 15-Сен-19, (16) –2 // А Rust, кроме своих, ещё начится компилировать исходники C, C , Go, Fortran , Аноним (38), 14:48 , 15-Сен-19, (41) а ещё лет через сорок до растоманов дойдёт, что их УГ можно было собирать пар, Michael Shigorin (ok), 20:31 , 15-Сен-19, (76) –1 // Это ты к чему Раст собирает параллельно столько, сколько я с ним вожусь, то ест, Ordu (ok), 23:43 , 15-Сен-19, (81) Он и собирает параллельно При сборке firefox сначала порождается процессов скол, Аноним (90), 11:58 , 16-Сен-19, (92) Главное - чтобы оно выключалось А лучше - чтобы не попало в gcc вообще Уж что-, CrazyAlex (?), 15:20 , 15-Сен-19, (53) +2 GCC в прошлом Модные парни уже давно перешли на MUSL LLVM CLANG, Аноним (17), 12:29 , 15-Сен-19, (17) –5 // Ничего против clang не имею Но вот его баг в актуальной версии 8 0 с двойным выз, Llvm (?), 12:58 , 15-Сен-19, (19) +2 // s деструктивных деструкторов , Llvm (?), 13:00 , 15-Сен-19, (20) +1 Давно systemd собирается с MUSL , Аноним (90), 13:25 , 15-Сен-19, (22) –1 // не позорься со своим системд Такие вещи даже страшно вслух произносить нормисы , Аноним (17), 13:29 , 15-Сен-19, (23) –1 // Экий ты шустрик в переобувке Я позорюсь с твоим Модные парни , Аноним (90), 13:38 , 15-Сен-19, (25) +3 Дело не в переобувки А в сути - почему люди добровольно отказываются от Поеттер, Аноним (17), 13:52 , 15-Сен-19, (27) –1 А в чём дело Теперь ты меня спрашиваешь, почему MUSL не поддерживается в system, Аноним (90), 14:39 , 15-Сен-19, (37) Поттеринг его забросил, и как только это случилось он стал конфеткой Сейчас он , Аноним (43), 14:55 , 15-Сен-19, (50) Конечно если речь не о прод серверах там до сих пор на убунте 16 04 сидят или к, Аноним (17), 13:55 , 15-Сен-19, (28) У кого-то прод серверы на венде и им норм , Аноним (15), 14:35 , 15-Сен-19, (36) Кому и кобыла невеста , Аноним (68), 18:32 , 15-Сен-19, (68) +3 Реклама uselessd Действительно Шёл 2019 год, а ненужнод не может в Musl , Аноним (43), 14:54 , 15-Сен-19, (49) +1 Но оно же умерло вскоре после рождения, еще лет 5 назад , Stax (ok), 20:04 , 15-Сен-19, (72) Как запилить тулчейн musl clang и кросскомпилить под i586 Так и не нашел гайдов, Лох (?), 13:52 , 15-Сен-19, (26) +1 // Простой 32-битный чрут не выручит часом , Michael Shigorin (ok), 20:33 , 15-Сен-19, (77) Модно, стильно, молодёжно , Аноним (38), 14:49 , 15-Сен-19, (45) +2 А почему нет новостей как Столман отжигает в своем репертуаре , Аноним (21), 13:13 , 15-Сен-19, (21) –3 // Потому что ты эту новость не написал , Аноним (15), 14:07 , 15-Сен-19, (31) +1 Подсказка https www opennet ru announce_news shtml, Аноним (15), 14:08 , 15-Сен-19, (32) +1 Он уже _ИЗВИНИЛСЯ_ перед сжв https stallman org archives 2019-jul-oct html 14_, лексус торнварцс (?), 14:43 , 15-Сен-19, (39) А может быть, Столман это поддержит , Аноним (38), 14:53 , 15-Сен-19, (48) Дядя типереча тормознутые исходники на C будут быстро компилится , Аноним (-), 14:34 , 15-Сен-19, (35) +1 Из серии Давно пора , Корец (?), 14:48 , 15-Сен-19, (42) –1 В итоге оптимальным вариантом будет что-то вроде сочитания gcc -j N и make -j M , nm0i (ok), 16:00 , 15-Сен-19, (57) +1 // Идеальным вариантом по-прежнему будет make -j N просто хотя бы из-за большого ко, all_glory_to_the_hypnotoad (ok), 17:22 , 15-Сен-19, (64) +1 // То есть в большинстве случаев использования компилятора , Ordu (ok), 18:20 , 15-Сен-19, (67) Кстати, а вот make-овый jobserver как раз может скумекать, когда собирает _одну_, Michael Shigorin (ok), 20:39 , 15-Сен-19, (78) –2 // make чаще собирает одну цель когда линкует, а не компилирует Проблема решается , all_glory_to_the_hypnotoad (ok), 21:05 , 15-Сен-19, (79) новый стандарт - ненужен , пох. (?), 18:43 , 17-Сен-19, (100) Т е , забив четыре потока, компиляция ускорится всего в полтора раза Почему не п, Anonimous (?), 16:35 , 15-Сен-19, (59) +1 // я когда генту впервые пилил ставил -j30 и норм работает, Аноним (17), 17:03 , 15-Сен-19, (60) // надеюсь не на hdd а то сложно предстаить какой там треск стоял , Аноним (70), 19:34 , 15-Сен-19, (70) // На HDD Никакой не стоял Средний объём исходника и какой это объём данных и IOP, Аноним (83), 01:53 , 16-Сен-19, (83) +1 и в мейк файл MAKEOPTS -j256, Аноним (17), 17:08 , 15-Сен-19, (62) +1 Надеюсь в апстрим не примут Всё замечательно параллелится мейком, усложнение ко, Аноним (83), 18:59 , 15-Сен-19, (69) Берешь 16 ядерный проц и ssd диск ставишь make -j16 и все быстро , а если у тебя, Griggorii (?), 07:25 , 16-Сен-19, (86) // Рекомендуется -j n 1 , Аноним (89), 10:36 , 16-Сен-19, (89) +1 Так то да Можно рискуть еще активизировать funroll-loops 03, а лучше выставить , Аноним (17), 16:53 , 16-Сен-19, (95) На Intel R Core TM i7-2600 CPU 3 40GHz 4 ядра даблтред gcc 9 2 в полном , Аноним (99), 13:03 , 17-Сен-19, (99) 1,2,3,4,5,10,17,21,35,42,57,59,62,69,86

Сообщения

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

1. "Проект по добавлению в GCC поддержки распараллеливания проце..."	–6 +/–
Сообщение от Онаним (?), 15-Сен-19, 10:44
> Тесты на системе с CPU Intel Core i5-8250U Это всё, что надо знать про данные исследования. Сферические теоретические кони в вакууме. Зачем оно, вообще, если сборка любого мало-мальски крупного проекта и так отлично распараллеливается тупо запуском множества процессов компиляции.
Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

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

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

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

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

	104. "Проект по добавлению в GCC поддержки распараллеливания проце..."	+/–
	Сообщение от Онаним (?), 21-Сен-19, 11:51
	> Компиляция, тем более распараллеленная гораздо лучше пойдет на R9 3950X. Вот да. И даже никакого дорогостоящего перепахивания компилятора не потребуется :D, а эффект будет куда выше, чем от перепахивания для всяких мобильных i5.
	Ответить | Правка | Наверх | 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 (запуск множества процессов шланга).
	Ответить | Правка | Наверх | Cообщить модератору

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

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

	82. "Проект по добавлению в GCC поддержки распараллеливания проце..."	+2 +/–
	Сообщение от iZEN (ok), 16-Сен-19, 00:08
	Да нет никакой связи с make -j кроме чистой детерминированности процесса сборки - когда компиляция одного куска кода зависит от результата компиляции другого. Вся суть многопоточной, а не многопроцессной компиляции в том, чтобы родственные нити выполнялись на одном или соседних ядрах с общим кэшем инструкций и данных - так уменьшается вероятность перезагрузки кэшей и в разы ускоряется доступ к данным. Планировщики современных операционных систем учитывают особенности многоядерности и топологию их вычислительных модулей. Для Ryzen 3xxx даже специальные исправления выходили по привязыванию отдельных нитей, использующих общие данные, к одному CCX (каждая нить исполняется на "своём" ядре внутри CCX) - что исключает операции по синхронизации кэшей отдельных CCX и увеличивает быстродействие.
	Ответить | Правка | Наверх | Cообщить модератору

	90. "Проект по добавлению в GCC поддержки распараллеливания проце..."	+1 +/–
	Сообщение от Аноним (90), 16-Сен-19, 11:45
	> Вся суть многопоточной, а не многопроцессной компиляции в том, чтобы родственные нити > выполнялись на одном или соседних ядрах с общим кэшем инструкций и > данных - так уменьшается вероятность перезагрузки кэшей и в разы ускоряется > доступ к данным. Простите за такую подробность, но процессор это не виртуальная машина Джавы, он ничего не знает про процессы. Если образ одного и того же исполняемого файла отображается в разные адресные пространства, то физические страницы с кодом должны быть везде одни и те же, соответственно и кеш инструкций когерентен. Что касается данных, я не просто возьму из головы некие "разы", а поделю 1000мб, которые процесс компилятора занял в памяти под AST (где Т означает не последовательно расположенные данные, а дерево), на объём кэша, и скажу, что вероятность не изменилась.
	Ответить | Правка | Наверх | 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). Это оверхед.
	Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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