Решил переписать пример из предыдущего топика дабы исключить printf ( ради чистоты эксперимента ). Вот что получилось —

#include <iostream>

extern int a = 567;

int main()
{    
    while(true)
    {        
        a = a* rand() % 9999;
    }    

    return 0;
}

PS. Уж не знаю насколько корректно так загружать проц — если кто получше предложит будет здорово.

Вот результат запуска на 2-ядерной машине ( отчетливо видно что загрузка обеих ядер резко возросла когда приложение было запущено ) — см. график ниже.
Вопрос — при чем здесь второе ядро вообще? откуда берется его загрузка?
Ведь приложение однопоточное...Неужели Windows Scheduler так часто переключает контексты и каждый раз выделяет этому приложению кванты на разных ядрах ?
НО ЗАЧЕМ ? Ведь кроме этого приложения проц почти никто не жрет в системе ( на графике видно что до запуска утилизация обеих ядер была всего несколько процентов )

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

O>НО ЗАЧЕМ ? Ведь кроме этого приложения проц почти никто не жрет в системе ( на графике видно что до запуска утилизация обеих ядер была всего несколько процентов )
затем чтобы твои яйца ядра не поджарились и не ушли в троттлинг, а так они остаются холодными и шелковистыми, что позволяет им работать на максимальных частотах ( Turbo Boost ) длительное время.

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

O>Вот результат запуска на 2-ядерной машине ( отчетливо видно что загрузка обеих ядер резко возросла когда приложение было запущено ) — см. график ниже.

Красивый график.
Средняя нагрузка получается 50+%, как и должно быть. На каждый квант времени выделяется одно "случайное" ядро которое лопатит твою программу.
Второе ядро, в среднем, простаивает.

Такое фиксится через настройки affinity, при острой необходимости.

O>Вот результат запуска на 2-ядерной машине ( отчетливо видно что загрузка обеих ядер резко возросла когда приложение было запущено ) — см. график ниже.
O>Вопрос — при чем здесь второе ядро вообще? откуда берется его загрузка?
Ну значит скачет поток на другие ядра иногда и сам по себе. Он же не прибит к какому-то одному. У меня кстати другие процессоры нагружаются этим кодом не так сильно как у вас на скриншоте, видимо зависит от окружения — если есть драйвер/софт у которого есть рабочие потоки привязанные на процессор, то чтобы их иногда исполнять — требуется твой поток оттуда вытеснить на другое ядро, где он немного покрутится, пока его оттуда опять не потеснит ктонить.
Только компилятор тут совершенно непричем, это приколы шедулера.

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

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

O>>Вот результат запуска на 2-ядерной машине ( отчетливо видно что загрузка обеих ядер резко возросла когда приложение было запущено ) — см. график ниже.

J>Красивый график.
одно время была популярная тема как жрать 100% ЦП, но чтобы мониторы винды или никсов показывали предельно низкую загрузку.
не существует никаких способов _точного_ измерения "загрузки" ЦП. мониторы отображают готовность системы предоставить процессорное время если оно кому-то нужно.

эксперимент: через N итераций (N подбирается опытным путем) вызываем Sleep(0). если N велико, то цикл (не вечный разумеется) завершится приблизительно за тоже самое время как и без Sleep, но загрузка ЦП резко упадет (особенно хорошо это заметно на машинах с одним ядром).

почему? потому что Sleep(0) говорит планировщику, что поток еще не успел использовать отведенному ему времени, как уже предлагает поделиться с остальными. если в системе нет никаких других потоков, нагружающих ЦП, то управление возвращается нашему потоку и он ботает почти 100% времени, хотя индикатор нагрузки ЦП показывает совсем другое значение.

кстати, двухядерный ЦП это все-таки не двухпроцессорный ЦП. если протестировать этот код на двухпроцессорном ЦП, то загрузка будет ниже. все-таки многоядерность это не полноценная многопроцессорность и потому загрузка выше 50%. хотя по любому этот график показывает лишь оценочную загрузку. плюс, особенности реализации гуя и видео на винде приводят к дополнительной нагрузке на ЦП в ситуации, когда одно ядро загружено на 100%. если просто логгировать счетчики производительности, то картина будет несколько иная.

короче кривой эксперимент и в этом легко убедиться. и да. еще. консольное окно все-таки перерисовывается даже когда нет никакого вывода (ну работает оно так в виндах) и для чистоты эксперимента желательно создать гуйвый exe.

твойкроликпишет...

Не надокло такой х-ней на форуме программистов заниматься?
Тот бред о котором ты пишешь проверяется на раз-два любым подручным дизассемблером.
На крайняк если сам не осилиш, кидай бинарь другие посмотрят.

p.s.
З.Ы. и task-manager нормальный поставь: https://technet.microsoft.com/en-us/sysinternals/processexplorer.aspx

У меня по теме все. Не пойму что тут вообще можно обсуждать по картинкам?

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

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

O>>НО ЗАЧЕМ ? Ведь кроме этого приложения проц почти никто не жрет в системе ( на графике видно что до запуска утилизация обеих ядер была всего несколько процентов )
A>затем чтобы твои яйца ядра не поджарились и не ушли в троттлинг, а так они остаются холодными и шелковистыми, что позволяет им работать на максимальных частотах ( Turbo Boost ) длительное время.

Какой там троттлинг ... до перегрева там как до луны ... ладно бы через пару минут работы такая картина нарисовалась — тогда было бы понятно, а когда сразу после старта приложения оно начинает скакать по ядрам туда-сюда (при том что других серьезных потребителей CPU в системе нет)- это ведь жутко неэффективно (постоянные переключения контекста).

Эффективнее (в такой ситуации) видится алгоритм который позволил бы приложению исполняться на одном ядре до того как оно подогреется до некоего порога, потом аналогично на другом, а потом уж начинать скакать туда-сюда.

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

O>Неужели Windows Scheduler так часто переключает контексты

Конечно. В системе тьма фоновых потоков, многие из которых просыпаются сотни раз в секунду.

O>и каждый раз выделяет этому приложению кванты на разных ядрах ?

Не каждый — в зависимости от загрузки ядер.

O>кроме этого приложения проц почти никто не жрет в системе ( на графике видно что до запуска утилизация обеих ядер была всего несколько процентов )

Что вы все уперлись в эти несчастные проценты? Посмотите лучше количество переключений контекста в секунду — откуда оно, по-Вашему, берется, если "почти никто не жрет проц"?

Фишка в том, что загрузка процессора измеряется (по крайней мере, в винде) лишь косвенно, очень примитивными методами. В итоге изрядная доля "короткой" активности, особенно обработчиков прерываний и DPC, не учитывается вообще, а между тем каждую секунду процессор исполняет десятки миллионов непустых команд.

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

М>кстати, двухядерный ЦП это все-таки не двухпроцессорный ЦП. если протестировать этот код на двухпроцессорном ЦП, то загрузка будет ниже. все-таки многоядерность это не полноценная многопроцессорность

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

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

O>Какой там троттлинг ... до перегрева там как до луны ...

У Вас есть открытый кристалл и направленный на него тепловизор, чтобы отследить мгновенный нагрев по локальным участкам?

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

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

O>>Какой там троттлинг ... до перегрева там как до луны ...

ЕМ>У Вас есть открытый кристалл и направленный на него тепловизор, чтобы отследить мгновенный нагрев по локальным участкам?

Стандартных датчиков на ядрах для этой цели не достаточно? Хотите сказать, что некоторые локальные участки могут быть намного горячее чем то что показывают датчики?

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

O>Стандартных датчиков на ядрах для этой цели не достаточно?

Датчик более-менее точно воспринимает температуру лишь малого участка кристалла непосредственно вокруг себя, и опрашается достаточно редко. Локальные и кратковременные всплески тепловыделения доходят до датчиков усредненными по площади и времени.

O>Хотите сказать, что некоторые локальные участки могут быть намного горячее чем то что показывают датчики?

Конечно, и намного.

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

O>>Хотите сказать, что некоторые локальные участки могут быть намного горячее чем то что показывают датчики?

ЕМ>Конечно, и намного.

А с чем связана неравномерность нагрева? Физической неоднородностью кристалла или неравномерным распределением нагрузки внутри кристалла?

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

O>или неравномерным распределением нагрузки внутри кристалла?

В первую очередь — именно этим. Невозможно ведь за единицу времени переключить все транзисторы на кристалле примерно одинаковое количество раз. Какие-то группы неизбежно будут переключаться чаще, какие-то — реже. А если пытаться распределить эти группы по кристаллу равномерно, насильственно удаляя друг от друга электрически смежные блоки — возрастут количество и длина проводников, а это опять же скажется на тепловыделении.