Почему цикл ест так много CPU?

Почему обычный бесконечный цикл "ест" аж ~35% CPU?

0

На одноядерном процессоре без HT он и 100% сожрёт

0

VTsaregorodtsev, процессор двухядерный i7-7500U, а откуда так много? точнее почему?

0

Ну, процессор же должен постоянно выполнять команду перехода на адрес самОй себя (к началу этой команды).
Вот он этим и занят.

0

Сообщение от ReYalp а откуда так много? точнее почему?

Откуда вопрос такой возник? Любой выполняющийся код всегда ест 100% "своего" ядра CPU (за исключением специальных команд, назначением которых как раз и является "усыпление" ядра процессора). Как же еще?

А уже какой процент получится в общем итоге зависит от общего количества ядер.

P.S. Я помню в каких-то поколениях процессоров была (есть?) функциональность распознавания тривиального бесконечного цикла, т.е. цикла, из которого процессор можно было вывести только внешним воздействием. Эта функциональность автоматически переводила ядро в спящий режим ожидания этого внешнего воздействия. Но может я что-то путаю... В любом случае, видно, что в вашем случае процессор просто честно колбасится в бесконечном цикле.

0

VTsaregorodtsev, а как работают все GUI приложения ? разве "внутри" у них не находится тот самый бесконечный(не совсем бесконечный) цикл? к примеру барузер мозила требует всего 5% , почему так?

Добавлено через 3 минуты
TheCalligrapher, от непонимания как работают приложения со стороны процессора

Сообщение от TheCalligrapher Откуда вопрос такой возник?

0

Это хорошо. Так и должно быть. Приложения - "летают".
Это достижение инопланетных существ.

0

TheCalligrapher, кстати вот такая штука интересная, если приложение использует 100% от ядра(допустим есть процессор с двумя ядрами), что будет если я запущу такое же приложение ещё раз? Они будут на разных ядрах запущены, или будут делить одно ядро напополам? Как это работает?

0

Сообщение от ReYalp к примеру барузер мозила требует всего 5% , почему так?

Если приложение по своей природе таково, что большую часть времени ему просто "нечего делать", то при грамотном программировании такого приложения, оно не будет потреблять ресурс CPU в режиме ожидания, т.е. оно ни в коему случае не будет заниматься вот таким бессмысленным циклированием, как в вашем примере.

Например, практически все интерактивные приложения попадают в этот класс: большую часть времени потокам в таких приложениях "нечего делать", ибо они ожидают ввода от пользователя или какого-то другого внешнего события. В такой ситуации правильно запрограммированное приложение переводит свой поток в режим ожидания системного события (например, появления нового сообщения о действиях пользователя) через средства системного API. Поток, который ожидает системного события, кладется системой в "спячку" и полностью перестает потреблять ресурс CPU.

Другими словами, когда вашему потоку выполнения "нечего делать", ни в коем случае нельзя реализовывать ожидание как тупой цикл (как в вашем примере). Вместо этого вы при помощи системного вызова должны положить свое приложения "спать" в режиме ожидания какого-то интересующего вас события. Когда это событие произойдет, ОС "разбудит" ваш поток и он продолжит выполнение.

Вот именно поэтому "браузер мозила" и потребляет всего 5% CPU. Потоки браузера мозила бОльшую часть времени просто "спят" и не потребляют CPU вообще. Они "просыпаются" только тогда, когда им нужно что-то сделать: обработать ввод пользователя, отрисовать новый кадр анимированной гифки и т.п. После чего они снова "засыпают".

Ожидание без укладывания потока в "спячку" называется busy waiting ("занятое ожидание"). Ваш цикл - как раз пример busy waiting цикла, который грузит ядро на 100%. В большинстве случае busy waiting - плохая практика, именно потому, что она жрет ресурс процессора впустую.

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

Такой цикл после выполнения неуспешной проверки будет отдавать остаток своего кванта процессорного времени другим потокам (это делает Sleep(0)). Можно также увеличить аргумент Sleep, чтобы такой цикл потреблял еще меньше ресурсов CPU.

Попробуйте для эксперимента

и посмотрите, какая будет загрузка CPU в этом случае. Попробуйте также поувеличивать период спячки.

1

TheCalligrapher, а могут два ядра работать с одной программой? Если да то как они делят ресурсы?

0

Сообщение от ReYalp VTsaregorodtsev, а как работают все GUI приложения ? разве "внутри" у них не находится тот самый бесконечный(не совсем бесконечный) цикл? к примеру барузер мозила требует всего 5% , почему так?

Они вызывают функцию "разбудите, когда произойдет что-то интересное". Вернее, существует широкий класс подобных функций.

Сообщение от ReYalp TheCalligrapher, кстати вот такая штука интересная, если приложение использует 100% от ядра(допустим есть процессор с двумя ядрами), что будет если я запущу такое же приложение ещё раз?

Без разницы сколько ядер. По истечении определенного кванта времени система принудительно приостановит приложение и передаст ядро кому ни будь еще. Возможно что и только что приостановленному приложению. Само приложение при этом обычно не замечает что у него периодически отбирают ядро. Хотя, при должной кривизне рук, таки может нарваться на побочки от этого действа.

Сообщение от ReYalp TheCalligrapher, а могут два ядра работать с одной программой? Если да то как они делят ресурсы?

Могут. Называется "многопоточность". Делят захватывая мьютекс "я эти данные читаю, кому надо их переписать - обождите".

0

ReYalp, https://www.cyberforum.ru/blog... g4913.html

1

Сообщение от ReYalp TheCalligrapher, а могут два ядра работать с одной программой? Если да то как они делят ресурсы?

Не могут.
Исключение - потоки, но тут отдельный вопрос считать их той же программой или нет. В ядре-то у них идентификаторы разные, а все "складывание" в одну программу делается элегантными костылями.
Смотрите: вот операционка запускает исполняемый файл. Этот файл - линейная последовательность инструкций процессора (от введения инструкций перехода ничего не изменится, так что не будем акцентировать на них внимание). Выполняться они также будут последовательно. Более того, при старте программы ОС выделяет ей в персональное пользование участок оперативки для переменных и прочего. То есть мы получили неплохо изолированную однопоточную программу, у которой просто нет ресурсов, которые надо с кем-то делить.
А теперь в коде программы встречается системный вызов создания нового процесса. Да хотя бы system(). Управление передается ядру ОС, которое для нового процесса выделяет новый участок памяти, не пересекающийся со старым, с получается уже два изолированных процесса. Изоляция тут, конечно, довольно условная: они могут посылать друг другу сигналы, использовать общие файлы и т.д., но вот напрямую друг в друга лазить не могут. Так что конкуренции за ресурсы все еще нет.
И наконец самая интересная разновидность процессов - потоки. В этом случае ОС не выделяет новый участок памяти новому процессу, так что память у них общая. Но для ОС это разные процессы, с разными идентификаторами, разными указателями на выполняемую инструкцию. И вот тут уже начинаются проблемы с синхронизацией, поскольку один процесс не знает, в какую ячейку памяти полезет другой. Более того, большая часть работы с данным не атомарна, то есть состоит из какого-то количества более простых операций. Да хотя бы прочитать из буфера - как-то изменить - записать обратно. А ОС может в любой момент отобрать управление у одного потока и передать другому (может и другому процессу с другим адресным пространством, но он от нас изолирован и в нашу память не влезет). В частности, когда один уже считал из буфера, его могут прервать, и тут в тот же буфер будет писать второй поток. Таким образом данные в буфере окажутся причудливой смесью продуктов жизнедеятельности обоих потоков.
Чтобы этой ситуации избежать, операции делают атомарными. В простейшем случае это функции вида __sync_add_and_fetch, но они работают для маленьких типов данных. Если же хочется большего, атомарность обеспечивается мьютексами: один процесс поднимает флажок "я буду работать с такими-то данными", и если с ними хочет работать кто-то еще, но видит флажок - приходится подождать. И третий способ межпроцессного взаимодействия - каналы. Это специальный тип файлов, не хранящихся на диске. Просто один процесс туда пишет, второй читает, а защитой от коллизий занимается операционная система.
P.S. пока искал где объявлены __sync_add_and_fetch наткнулся на https://habr.com/ru/post/147099/ Может чего полезного найдете там.

1

В качестве дополнения.
Для синхронизации потоков, кроме мьютексов, есть масса других возможностей:
1) критические секции;
2) события;
3) семафоры;
и, наконец
4) существует ряд функций, позволяющих работать с глобальными переменными из всех нитей, не заботясь о синхронизации, т.к. эти функции сами за ней следят – их выполнение атомарно. Это функции InterlockedIncrement, InterlockedDecrement, InterlockedExchange, InterlockedExchangeAdd и InterlockedCompareExchange. Например, функция InterlockedIncrement атомарно увеличивает значение 32-битной переменной на единицу, что удобно использовать для различных счетчиков.
Последнее, признаюсь, "не щупал"

1

Сообщение от ReYalp а могут два ядра работать с одной программой? Если да то как они делят ресурсы?

В самом вопросе видны какие-то необоснованные предположения.

Упрощенно выражаясь, все программы всегда работает на всех ядрах процессора. Любой поток выполнения получает квантованные кусочки времени CPU, и когда этому потоку приходит время выполняться, он попадает на совершенно непредсказуемое ядро процессора. Когда этот же самый поток получит следующий квант времени выполнения, он будет выполняться на совсем другом ядре процессора. То есть поток постоянно "прыгает" с ядра на ядро. С любой программой работают все ядра процессора по очереди.

Это упрощенный, но основополагающий принцип выполнения потоков на множественных ядрах.

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

Поэтому сам ваш вопрос не имеет большого смысла: в обычном режиме все ядра процессора работают со всеми программами. Одновременно, т.е. поочередно.

1

TheCalligrapher, как это все выглядит для ядер? не хватает знаний в этом плане, как все работает на аж таком низком уровне

0

Сообщение от liv Это функции InterlockedIncrement

Это аналог __sync_add_and_fetch что ли? А какому заголовочнику они принадлежат? Я пока увидел только в winnt.h, но тогда ими невозможно воспользоваться на чем-то кроме винды.

Сообщение от ReYalp TheCalligrapher, как это все выглядит для ядер?

Для ядер это выглядит просто как поток инструкций. Потом прилетает прерывание от таймера и выполнение передается в другое место.
А то, что по этому другому месту расположен обработчик именно операционки, который по каким-то своим алгоритмам управляет стеком, адресами возврата и тому подобным процессора не волнует.
Если хотите получить самое-самое общее представление, можете посмотреть цикл лекций
https://www.youtube.com/watch?... R8hkMQoEva - как все это выглядит для ядра (ассемблер)
https://www.youtube.com/watch?... o3ll6a9dPZ - как все это работает потом (ОС)
Научиться чему-то по видеолекциям, конечно, невозможно, но вот общее представление составить - вполне.

1

Сообщение от COKPOWEHEU Это аналог __sync_add_and_fetch что ли?

Вполне возможно
Я ж говорю, не пользовался. Просто увидел упоминание и привел для комплекта.

0