Почему ваш код не должен использовать 100% CPU? [закрыто]

Я говорю конкретно о программе на C # .NET 4, работающей на Windows XP или выше, но общие ответы также приемлемы.

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

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

Это правда? И если так, то почему? Раньше у меня было впечатление, что 100% загрузка ЦП предпочтительнее для интенсивной или длительной работы, и я не мог найти достойных источников по этому вопросу в любом случае.

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

Так что да, на запыленном ноутбуке 100% загрузка процессора может вызвать временные проблемы, но ничего не сломается и не «ухудшится» (что бы это ни значило).

Для проблем, связанных с процессором, 100% загрузка процессора - правильный путь.

Что касается отзывчивости приложений (UI), это отдельная концепция от использования ЦП. Вполне возможно иметь неотвечающее приложение, которое использует 1% CPU, или адаптивное приложение, которое использует 100% CPU. Отзывчивость пользовательского интерфейса сводится к объему работы, выполненной в потоке пользовательского интерфейса, и приоритету потока пользовательского интерфейса по сравнению с другими потоками.

Программы Windows (winforms / WPF) должны всегда реагировать. С наивной реализацией процесса, который использует ресурсы процессора на 100%, слишком просто заставить вашу программу или даже вашу систему казаться вялой и зависающей.

С хорошей реализацией (например: используйте отдельный поток с более низким приоритетом) это не должно быть проблемой.

Вы не должны беспокоиться о том, что ваш процессор сломается раньше.

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

Наибольшие ситуации, когда использование 100% ЦП плохо, это когда:

• Приложение занято в ожидании какого-либо события, которое не будет ускоряться постоянным опросом [и может фактически быть отложено, если потраченная впустую проверка, выполненная ли задача, занимает ресурсы ЦП, которые в противном случае могли бы быть потрачены на выполнение задачи].

• Приложение перерисовывает дисплей слишком часто. Определение «чрезмерно часто» будет в некоторой мере зависеть от природы устройства отображения и отображаемого контента. Если аппаратное обеспечение дисплея может отображать 120 кадров в секунду, могут быть случаи, когда анимация может отображаться со скоростью 120 кадров в секунду без добавления размытия в движении, но не может быть отображена чисто при более низкой частоте кадров без ее добавления. Если рендеринг кадра с размытым движением займет намного больше времени, чем рендеринг без него, то рендеринг со скоростью 120 кадров в секунду на оборудовании, которое его поддерживает, на самом деле может быть не более дорогостоящим, чем рендеринг с более низкой частотой кадров с размытым движением. [Простая ситуация: колесо с 29 спицами, вращающееся со скоростью один оборот в секунду. При 120 кадрах в секунду колесо, кажется, вращается с правильной скоростью и направлением; на скорости 60 кадров в секунду,

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

«Современные процессоры дешевы и быстро деградируют при 100% процессоре».

Я не думаю, что кто-то на самом деле обратился к «унизительной» части этого вопроса. Микросхемы ухудшатся, когда температура матрицы превысит пределы производителя. Микросхемы обычно рассчитаны на работу до 125 ° С, хотя каждое увеличение на 10 ° С сокращает срок службы на 50%.

Процессоры не всегда имели терморегуляцию. Затем у некоторых AMD Durons возникли проблемы (якобы можно было их уничтожить, если бы они работали без радиатора). Теперь все процессоры ПК будут иметь встроенные датчики температуры, которые возвращаются в тактовую частоту процессора и замедляют тактовую частоту, чтобы предотвратить повреждение. Таким образом, вы можете обнаружить, что ваша программа использует 100% доступного процессора, но процессор работает только на 75% своей номинальной скорости, потому что его охлаждение неадекватно.

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

Как в Windows, так и в Linux есть центральные процессорные системы, которые будут управлять производительностью и температурным режимом. Поскольку это делается на уровне ОС, он может учитывать общее потребление ресурсов ЦП. Операционная система несет ответственность за управление оборудованием и предотвращение его неправильного использования пользовательскими программами. Ответственность за поддержание чистоты и работы вентиляторов несет владелец оборудования , а производитель в первую очередь должен установить соответствующие радиаторы и вентиляторы.

Есть несколько случаев, когда устройства имеют недостаточное охлаждение, но поток отдачи учит производителей не делать этого.

Чтобы сыграть защитника дьявола: В некотором смысле, программа, которая не может достичь 100% использования, может вызвать худший износ: если она не приостановлена ​​в ожидании нажатия клавиши, есть вероятность, что она приостановлена ​​в ожидании дискового ввода-вывода большую часть времени. А диски - это (до сих пор обычно) большие механические устройства, которые подвержены механическому износу или риску удара / гироскопического воздействия при их перемещении, не говоря уже о потребляемой мощности.

«... современные процессоры дешевы и быстро деградируют при 100% процессоре».

Вам не нужно беспокоиться о «деградации процессора» вообще. Современные процессоры не менее качественны, чем в прежние времена.

Это очень дорого (и дорожает каждые несколько лет) , чтобы сделать процессоры, несколько миллиардов , чтобы построить новый ФАБ не редкость (ссылка).

http://en.wikipedia.org/wiki/Semiconductor_fabrication_plant

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

Я могу перечислить ряд причин, по которым я считаю, что современные процессоры имеют тенденцию быть более качественными, чем в «прежние времена».

Но только самое главное: преимущества в тестировании. Современная электроника «предназначена для испытаний». Будь то программное или аппаратное обеспечение, общее представление о том, как оценивать тесты почти во всем остальном, не так уж и старо. Для процессоров даже проводятся тесты для формирования различных ценовых и частотных типов, например, лучшие процессоры продаются с самыми высокими частотами. Несмотря на это, более дешевые процессоры очень часто способны работать с более высокой частотой, чем проданные, - они наносят ущерб только по той причине, что производитель хочет продавать некоторые процессоры «высокого уровня» по более высоким ценам.

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

Есть еще больше причин не беспокоиться о деградации процессора для вашей программы:

• Первая причина заключается в том, что современные процессоры снижают частоту или дроссель, если они становятся слишком горячими.

  Должно быть ясно, что если вы используете CPU 100% 24/7 в течение всего года, он обычно умирает раньше, чем CPU, используемый только каждую вторую неделю один час. Но это верно и для автомобилей, кстати. Только в таких случаях я бы подумал об использовании процессора и возможном сне.

• Вторая причина в том, что на самом деле очень сложно написать программу, которая использует 100% ЦП от ОС (например, в Windows). Кроме того, современные процессоры (обычно) имеют как минимум 2-4 ядра. Таким образом, традиционный алгоритм, который имеет тенденцию использовать 100% одноядерного ЦП, теперь имеет только 50% для двухъядерного ЦП (упрощенный, но наблюдаемый в реальных сценариях).

• Более того, операционная система контролирует ЦП, а не вашу программу, поэтому, если есть другие приложения с таким же или более высоким приоритетом (что является значением по умолчанию), ваша программа получает только столько ЦП, сколько возможно, но другие приложения не будут голодать. (Конечно, это только упрощенная теория, и, конечно, многозадачность Windows, Linux и других не идеальна, но в целом я бы посчитал это верным).

«Ранее у меня сложилось впечатление, что 100% загрузка ЦП предпочтительнее для интенсивной или длительной работы».

Да, оставайся с этим. Но, например, если вы ожидаете и зацикливаетесь на другом процессе, другими словами, ничего не делая, было бы неплохо, если бы вы выполняли Thread.Sleep () несколько миллисекунд в этом цикле, предоставляя дополнительное время другим. В то время как это не является необходимым для хорошей многозадачной ОС, я решил некоторые проблемы с этим, например, для Windows 2000. (Это, конечно, не означает использование Sleep () в вычислениях, например ..)

Такая деградация теоретически возможна и называется « электромиграцией ». Электромиграция зависит от температуры и ускоряется при повышении температуры. Является ли это практической проблемой для современных процессоров, обсуждается. Современная практика проектирования СБИС компенсирует электромиграцию, и микросхемы с большей вероятностью выйдут из строя по другим причинам.

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

Скорость электромиграции зависит от температуры чипа, а срок службы удваивается на каждые (очень приблизительно) 10 ° C. Фактически это является основой теста под названием «HTOL» (срок службы при высоких температурах), который измеряет, сколько времени понадобится кристаллу, чтобы умереть, скажем, при 125 ° C. Микросхема, работающая при 125 ° C, выйдет из строя примерно в 100 раз быстрее, чем микросхема, работающая при 55 ° C, поэтому, если она рассчитана на срок не менее 10 лет при 55 ° C, чип может выйти из строя в течение 1 месяца при 125 ° C. Если чип работает при более приемлемой температуре, например, 85 ° C, такой чип все равно выйдет из строя как минимум в 5-10 раз быстрее, чем он был предназначен.

Конечно, процессоры обычно проектируются с учетом более высоких температур, поэтому обычно они могут работать годами при температуре 85 ° C в режиме 24/7 при 100% нагрузке. Поэтому я бы посоветовал вам не беспокоиться о «изнашивании» процессора, а беспокоиться только о том, подходит ли 100% загрузка с точки зрения разработки программного обеспечения.

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

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

Таким образом, ситуация такова: у вас есть некоторый код, который выполняется, скажем, в течение пяти часов, используя 100% всех процессоров, который оптимизирован настолько, насколько вы можете, владелец машины в порядке с машиной, которую невозможно использовать в течение пяти часов, и ваш коллега утверждает, что было бы лучше запустить ваш код за 6 часов, используя 83,33% всех процессоров, потому что это снижает нагрузку на компьютер.

Это зависит от компьютера, который вы используете. Я знаю, что производитель компьютеров отказался от гарантийного ремонта в течение гарантийного срока на дешевых домашних компьютерах, которые использовались в научных условиях, работающих круглосуточно. Они явно хотели, чтобы клиент купил их более дорогие серверы или «деловые» компьютеры. Были ли они успешными, я не знаю.

Каждый мой Mac в какой-то момент имеет жизненный код при 100% -ной загрузке ЦП в течение нескольких дней. В одном случае мне пришлось выключить дисплей, потому что у меня не было оригинального зарядного устройства для ноутбука, а с 4 ядрами и гиперпоточностью оно потребляло больше энергии, чем поставляемое зарядное устройство - поэтому батарея разрядилась, и когда она достигла 5 процентов компьютер замедлял тактовую частоту, пока батарея не достигла 10%! (С выключенным дисплеем он работал на полной скорости в течение нескольких дней). Ни в коем случае никаких побочных эффектов.

Так что с хорошо спроектированным компьютером вы правы. С плохо спроектированным дешевым компьютером ваш коллега может оказаться прав. С другой стороны, вы можете сравнить стоимость вашего времени ожидания со стоимостью покупки заменяющего компьютера.

Если вы можете, сделайте свой код задачей с более низким приоритетом, и убедитесь, что поток с высокой загрузкой процессора отделен от графического интерфейса. Тогда вы можете использовать его на 100%, но пользователь всегда может выполнять другие задачи и оставаться отзывчивым. Сам по себе процессор рассчитан на то, чтобы какое-то время работать на 100%, иначе он не будет освобожден. Если конечный пользователь не внес серьезные и опасные изменения в свое оборудование, вы не сможете ничего повредить.