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