Почему следующий код загружает все 4 ядра на 4-ядерной машине?

int main ()
{

for( ; ; )
{
printf("This loop will run forever.\n");
}

return 0;
}

Здравствуйте, octopuses, Вы писали:

Это что за чудо компилятор такой? И какая платформа?

Здравствуйте, octopuses, Вы писали:

O>Почему следующий код загружает все 4 ядра на 4-ядерной машине?
Потому что ты его запустил в 4х экземплярах.
Следующий!

Здравствуйте, koenjihyakkei, Вы писали:

K>Здравствуйте, octopuses, Вы писали:

K>Это что за чудо компилятор такой? И какая платформа?

Пробовал и на Windows ( VC++ 15 ) и на Linux ( gcc )

Здравствуйте, bazis1, Вы писали:

B>Здравствуйте, octopuses, Вы писали:

O>>Почему следующий код загружает все 4 ядра на 4-ядерной машине?
B>Потому что ты его запустил в 4х экземплярах.
B>Следующий!

Мсье шутник?
Ну попробуй сам тогда — думаю, удивишься как и я.
Task Manager показывает загрузку всех ядер при 1 запущенном экземпляре.

Здравствуйте, octopuses, Вы писали:

O>Мсье шутник?
O>Ну попробуй сам тогда — думаю, удивишься как и я.
O>Task Manager показывает загрузку всех ядер при 1 запущенном экземпляре.
Запустил на 16-ядерной машине. CPU usage этого процесса 0%. VS2015. Ты что-то не то меряешь. Посмотри в Task Manager-е, сколько у него потоков для начала.

Здравствуйте, octopuses, Вы писали:

O>Пробовал и на Windows ( VC++ 15 ) и на Linux ( gcc )

Проверил на x86, Linux, gcc, 4 ядра — htop показывает, что прога грузит только одно ядро.
Может неправильно смотришь? Точно это приложение загружает все ядра?

printf (если stdout не заредирекчен в файл) — это LPC вызов в другой поток, другого процесса, который заведует консольным окошком. В зависимости от версия виндов это или csrss или conhost. Так что с высокой вероятностью поток, вызывающий printf, и поток, обрабатывающий LPC вызовы (а там скорее всего вообще пул потоков), будут скакать между ядрами. Но каждое ядро в итоге будет нагружено менее чем на 100%, а суммарная нагрузка по ядрам будет максимум эквивалентна полной нагрузке одного ядра.
[upd]
впрочем если подумать, то свою лапу могут приложить еще и DWM и видеодрайвера — фиг знает что они могут при этом в фоне делать вследствии постоянной перерисовки консольного окна.

Здравствуйте, koenjihyakkei, Вы писали:

K>Проверил на x86, Linux, gcc, 4 ядра — htop показывает, что прога грузит только одно ядро.

А вот это как раз странно — по-хорошему, ОС на многопроцессорном железе должна распределять нагрузку по процессорам (винда всегда так и делает, если явно не привязывать процесс). Линукс, по уму, должен делать так же.

K>>Проверил на x86, Linux, gcc, 4 ядра — htop показывает, что прога грузит только одно ядро.
ЕМ>А вот это как раз странно — по-хорошему, ОС на многопроцессорном железе должна распределять нагрузку по процессорам (винда всегда так и делает, если явно не привязывать процесс). Линукс, по уму, должен делать так же.
Не странно. В данном конкретном случае процесс — один.
Автоматически разделить единственный последовательный процесс на несколько во время компиляции — не решенная задача.
Деление на треды — это пока задача программиста.

Здравствуйте, LaptevVV, Вы писали:

LVV>Не странно. В данном конкретном случае процесс — один.

Э-э-э... Вы никогда не слышали о квантовании процессорного времени, распределении нагрузки и подобных вещах в многозадачных/многопроцессорных ОС?

LVV>>Не странно. В данном конкретном случае процесс — один.
ЕМ>Э-э-э... Вы никогда не слышали о квантовании процессорного времени, распределении нагрузки и подобных вещах в многозадачных/многопроцессорных ОС?
Я настолько стар, что читал еще Джермейна первое издание...
Повторяю. В данном случае процесс — ОДИН. Последовательный.
Поэтому отработав часть работы на одном ядре, он может быть перекинут осью на другое ядро.
Но первое ядро он освободит в этом случае.
Другое дело, что переключение происходит так быстро, что для человека создается иллюзия одновременной работы всех 4 ядер.
Но это — иллюзия.

Здравствуйте, LaptevVV, Вы писали:

LVV>Поэтому отработав часть работы на одном ядре, он может быть перекинут осью на другое ядро.
LVV>Но первое ядро он освободит в этом случае.

Тогда о чем мы спорим? Именно так все и происходит, и загрузка всех ядер должна быть примерно одинаковой (если общая — 100%, по каждому ядру должно быть примерно 100/N). Автор же утверждает, что процесс грузит только одно ядро — это как раз и странно.

Здравствуйте, octopuses, Вы писали:

O>Почему следующий код загружает все 4 ядра на 4-ядерной машине?
Попробуй задать процессу affinity к одному ядру и повтори эксперимент.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Здравствуйте, LaptevVV, Вы писали:

LVV>>Поэтому отработав часть работы на одном ядре, он может быть перекинут осью на другое ядро.
LVV>>Но первое ядро он освободит в этом случае.

ЕМ>Тогда о чем мы спорим? Именно так все и происходит, и загрузка всех ядер должна быть примерно одинаковой (если общая — 100%, по каждому ядру должно быть примерно 100/N). Автор же утверждает, что процесс грузит только одно ядро — это как раз и странно.

А что здесь странного? Если у вас один активный поток в системе, то не имеет смысла переключать его каждый раз на новое ядро. Будет просадка в производительности из-за необходимости перегружать данные из кэша в кэш. Так что планировщик тут действует правильно.

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

Здравствуйте, Шахтер, Вы писали:

Ш>Если у вас один активный поток в системе

Если в системе только один активный поток — все верно. Только вот поинтересуйтесь, сколько таких потоков в Вашей системе.

Здравствуйте, ononim, Вы писали:

O>printf (если stdout не заредирекчен в файл) — это LPC вызов в другой поток, другого процесса, который заведует консольным окошком. В зависимости от версия виндов это или csrss или conhost. Так что с высокой вероятностью поток, вызывающий printf, и поток, обрабатывающий LPC вызовы (а там скорее всего вообще пул потоков), будут скакать между ядрами. Но каждое ядро в итоге будет нагружено менее чем на 100%, а суммарная нагрузка по ядрам будет максимум эквивалентна полной нагрузке одного ядра.
O>[upd]
O>впрочем если подумать, то свою лапу могут приложить еще и DWM и видеодрайвера — фиг знает что они могут при этом в фоне делать вследствии постоянной перерисовки консольного окна.

Там скорее всего консольная программа запущена из-под какого-нибудь консольного файлового менеджера (например far). Цикл пуляет строками в stdout, stdout перехватывает фар, что-то делает с этим флудом и перепуливает дальше в терминал или консоль, который рисует картинку. Минимум 3 ядра можно загрузить. Остальное наверно уходить на графический драйвер. Итого 4 ядра заняты полезным делом.

Здравствуйте, octopuses, Вы писали:

O>Почему следующий код загружает все 4 ядра на 4-ядерной машине?

Снимите ETW-трейсы и посмотрите или выложите сюда.

O>>[upd]
O>>впрочем если подумать, то свою лапу могут приложить еще и DWM и видеодрайвера — фиг знает что они могут при этом в фоне делать вследствии постоянной перерисовки консольного окна.
_>Там скорее всего консольная программа запущена из-под какого-нибудь консольного файлового менеджера (например far). Цикл пуляет строками в stdout, stdout перехватывает фар, что-то делает с этим флудом и перепуливает дальше в терминал или консоль, который рисует картинку. Минимум 3 ядра можно загрузить. Остальное наверно уходить на графический драйвер. Итого 4 ядра заняты полезным делом.
Фар тут не причем. Еще раз: консольное окошко создается не самой консольой апликухой, а вспомогательным системным процессом, с которым апликуха общается по LPC до десятки, а в десятке — через IPC, предоставляемый condrv.sys.
При сигнале ивента винда будит поток, который его ждет, отправляя его на первое попавшееся под руку ядро. Потому потоки, которые активно взаимодействуют — активно скачут по ядрам. Что кстати крайне негативно сказывается на производительности, желающие могут набросать простой пример с двумя тредами, взаимодействующими путем сигнала/ожидания на паре ивентов и посмотреть какова будет производительность при дефолтовой афинити, и какова будет при афинити, установленной на одно общее ядро. Когдато когда я мерял разница получалась в разы — в пользу потоков на одном ядре.
Я интереса ради запустил этот код в чистой консоли. Как и предполагал — жрется 4 ядра, но каждое — только слегка, топ жрущих процессов, по убыванию: conhost, csrss, апликуха. Общий отжор TM показыват чуть менее 30%, что эквивалентно загрузке одного ядра + оверхед на чересчур активное переключение контекстов. Если всех из этой троицы посадить на одно и тоже ядро — становится аккурат 25%, при колной загрузке этого одного ядра.

Здравствуйте, ononim, Вы писали:

O>Я интереса ради запустил этот код в чистой консоли. Как и предполагал — жрется 4 ядра, но каждое — только слегка, топ жрущих процессов, по убыванию: conhost, csrss, апликуха. Общий отжор TM показыват чуть менее 30%, что эквивалентно загрузке одного ядра + оверхед на чересчур активное переключение контекстов. Если всех из этой троицы посадить на одно и тоже ядро — становится аккурат 25%, при колной загрузке этого одного ядра.

Тоже для интереса запустил на linux: 1)xterm и 2)xterm + mc(midnight commander)
В первом случае процессор жрет сама программа 60%, xterm 70%, X — 5%. Система загружена на 40%
Во втором случае программа — 60%, mc — 50%, xterm — 70%, X — 5%. Система загружена 55%
То есть промежуточное звено в пути прохождения выводимой строки тоже дополнительно грузит процессор. Что логично, так как mc надо писать в свой буфер.

Про то что какой процесс как и что запускает и как они скачут по ядрам мне не интересно.