Исходное сообщение
"Linux Mint начал формирование классического пакета с Chromiu..." Отправлено Ordu, 02-Ноя-20 00:25
Но при этом, чем больше у тебя памяти, тем меньше смысла запускать количество потоков большее, чем количество ядер. 5 потоков на 4 ядрах будут производить больше работы чем 4 потока на тех же ядрах только в том случае, если потоки регулярно блокируются на вводе/выводе. Причём не просто блокируются пока ядро пишет из юзерспейс буфера в ядерный буфер в дисковом кеше (процессор при этом всё равно занят необходимой работой, которую всё равно придётся выполнять), а когда ядро упирается в то, что свободного буфера нет, и поэтому надо освободить кусок памяти записав его содержимое на диск. Или то же самое но с чтением -- когда gcc натыкается на #include<header.h>, и этот хидер не найден в дисковом кеше в оперативки, и поэтому ядро блокирует поток до тех пор, пока диск не отдаст содержимое этого хидера. Или может ядро ждёт не хидера, а пачку .o файлов, которые процесс сборки при помощи ld объединяет в один .la. Чем больше ОЗУ, тем реже такие блокировки. Чем реже блокировки, тем меньше смысла иметь запасные потоки, которые можно выполнять, пока другие заблокированы.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	> Но при этом, чем больше у тебя памяти, тем меньше смысла запускать > количество потоков большее, чем количество ядер. 5 потоков на 4 ядрах > будут производить больше работы чем 4 потока на тех же ядрах > только в том случае, если потоки регулярно блокируются на вводе/выводе. Причём > не просто блокируются пока ядро пишет из юзерспейс буфера в ядерный > буфер в дисковом кеше (процессор при этом всё равно занят необходимой > работой, которую всё равно придётся выполнять), а когда ядро упирается в > то, что свободного буфера нет, и поэтому надо освободить кусок памяти > записав его содержимое на диск. Или то же самое но с > чтением -- когда gcc натыкается на #include<header.h>, и этот хидер не > найден в дисковом кеше в оперативки, и поэтому ядро блокирует поток > до тех пор, пока диск не отдаст содержимое этого хидера. Или > может ядро ждёт не хидера, а пачку .o файлов, которые процесс > сборки при помощи ld объединяет в один .la. > Чем больше ОЗУ, тем реже такие блокировки. Чем реже блокировки, тем меньше > смысла иметь запасные потоки, которые можно выполнять, пока другие заблокированы.
	Введите код, изображенный на картинке: