Чому ваш код не повинен використовувати 100% процесор? [зачинено]

Я конкретно кажу про програму C # .NET 4, що працює на Windows XP або новішої версії, але загальні відповіді також прийнятні.

Припустимо вже оптимізовану та ефективну програму. Проблема тут полягає лише у впливі високого використання процесора на апаратне забезпечення, а також про те, чи слід використовувати програму з високим рівнем використання, щоб зменшити знос, а не на те, чи ефективна моя реалізація.

Сьогодні колега припустив, що я не повинен прагнути до 100% використання процесора в процесах завантаження даних, оскільки "сучасні процесори дешеві і швидко погіршаться при 100% процесора".

Це правда? А якщо так, то чому? Раніше у мене було враження, що 100-відсоткове використання процесора краще для інтенсивної або тривалої роботи, і я не міг знайти жодних поважних джерел з цього питання.

Якщо охолодження недостатнє, процесор може перегрітися. Але всі вони (ну, принаймні, всі сучасні ПК) мають різні механізми теплового захисту, які дозволять зменшити тактову частоту або, в кінцевому рахунку, вимкнути.

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

Для проблем, пов'язаних з процесором, 100% завантаження процесора - це правильний шлях.

Що стосується чутливості програми (UI), то це окрема концепція від використання процесора. Цілком можливо мати невідповідний додаток, який використовує 1% процесора, або чуйну програму, яка використовує 100% процесора. Реактивність користувальницького інтерфейсу зводиться до кількості роботи, виконаної в потоці користувальницького інтерфейсу, і пріоритету потоку користувальницького інтерфейсу порівняно з іншими потоками.

Програми Windows (winforms / WPF) повинні завжди залишатися чуйними. З наївною реалізацією процесу, який використовує 100% ресурсів процесора, все занадто просто зробити вашу програму чи навіть вашу систему здаватися млявими та звисаючими.

При хорошій реалізації (наприклад: використовувати окрему нитку з нижчим пріоритетом) це не повинно бути проблемою.

Ви не повинні турбуватися про те, що ваш процесор зламається раніше.

Взагалі немає нічого поганого в тому, що програма, що використовує 100% ЦП, хоча насправді робить корисну роботу і не забирає часу на щось більш важливе . Якщо конкретна апаратна платформа, наприклад, здатна використовувати протягом 100 секунд безперервно протягом 100 секунд, перш ніж вона повинна відступити до 50%, щоб уникнути перегріву, як правило, краще для програми, яка має корисну роботу для виконаннязапустити якомога швидше і дозволити процесору чи ОС обробляти будь-яке необхідне дроселювання, ніж для програми, щоб здогадатися, наскільки швидко він повинен "працювати". Якщо програма або потік має роботу з низьким пріоритетом, яка була б корисною, але не завжди критичною, ОС може бути корисною для обмеження використання CPU з низькою пріоритетністю до 50%, так що, якщо ЦП потрібно робити щось швидко воно буде готове "спринтувати" на секунду, але додаток не повинен турбуватися про такі речі, крім того, щоб вимагати низького пріоритету потоку.

Найбільші ситуації, коли погано використовувати 100% процесор, це коли:

• Додаток зайнятий-чекає якоїсь події, яку не вдасться поспішити постійним опитуванням [і насправді може бути відкладено, якщо витрачені зусилля перевірять, чи виконується завдання, займають ресурси процесора, які в іншому випадку можна витратити на виконання завдання].

• Програма надмірно часто малює дисплей. Визначення "надмірно часто" певною мірою залежатиме від характеру пристрою відображення та вмісту, що відображається. Якщо апаратне забезпечення дисплея може відображати 120 кадрів в секунду, можуть бути випадки, коли анімація може бути показана зі швидкістю 120 кадрів в секунду без додавання розмитості руху, але вона не може бути чітко показана при менших частотах кадрів, не додаючи її. Якщо візуалізація кадру з розмиттям руху займе набагато більше часу, ніж її візуалізація, тоді рендерінг зі швидкістю 120 кадрів в секунду на апаратному забезпеченні, яке його підтримує, насправді може бути не більш дорогим, ніж візуалізація з меншою швидкістю кадру із розмиттям руху. [Проста ситуація: колесо з 29 спицями, що обертається з одним оборотом в секунду. При 120 кадрів в секунду, здавалося б, колесо обертається з відповідною швидкістю та напрямком; зі швидкістю 60 кадрів в секунду,

Перший чітко впізнається як поганий. Друга - трохи більш тонка. Якщо хтось орієнтується на мобільну платформу, в деяких випадках може бути дозволено дозволити користувачам вибирати бажану частоту кадрів анімації, оскільки деякі користувачі можуть не турбуватися про ресурс акумулятора, але бажають анімації найкращої якості, а інші приймають нижчу якість анімація в обмін на кращий ресурс акумулятора. Замість того, щоб програма намагалася вгадати, де має бути компроміс, це може бути корисно дозволити користувачеві його налаштувати.

"сучасні процесори дешеві і швидко погіршаться при 100% процесора".

Я не думаю, що ніхто насправді не вирішив "деградуючу" частину цього питання. ІС погіршаться, коли температура штампу перевищить межі виробника. ІМС зазвичай розроблені для роботи до 125С, хоча кожне збільшення на 10С скорочує термін служби на 50%

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

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

І в Windows, і в Linux є системи процесора "govenor", які дозволять виконувати продуктивність і управління термічним режимом. Оскільки це робиться на рівні ОС, він може враховувати загальне споживання системного процесора. Це відповідальність за операційну систему, щоб керувати обладнанням і не допускати, щоб користувацькі програми зловживали ним. Власник апаратури є обов'язком утримувати вентилятори в чистоті та роботі, а виробник в першу чергу встановлювати відповідні радіатори та вентилятори.

Є кілька випадків, коли пристрої мають недостатнє охолодження, але паводка привчає виробників цього не робити.

Щоб грати в захисника диявола: певним чином програма, яка не може досягти 100% використання, може спричинити гірший знос: Якщо вона не буде призупинена в очікуванні натискання клавіші, велика ймовірність, що вона буде призупинена в очікуванні дискового вводу / виводу більшу частину часу. А диски - це (як правило, великі) механічні пристрої, які піддаються механічному зносу або ризику удару / гіроскопічного впливу при їх переміщенні, не кажучи вже про споживання електроенергії.

"..сучасні процесори дешеві і швидко погіршаться при 100% процесора".

Ви не повинні турбуватися про "деградацію процесора" взагалі. Сучасні процесори не менш якісні, ніж у колишні часи.

Це дуже дорого (і стає коштовнішим кожні пару років) робити процесори, кілька мільярдів на створення нового файлу - не рідкість (див. Посилання).

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

Виробничі витрати центрального процесора залежать максимум від не. вироблених одиниць. Це добре відомий факт в економіці. Ось чому їх можна продати (відносно) "дешево". (Я думаю, тут не потрібно посилання)

Я можу перерахувати низку причин, чому я вважаю, що сучасні процесори мають більш високу якість, ніж у "колишні часи".

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

(З іншого боку, звичайно, можливе більше помилок для процесора з більш ніж 1,5 мільйонами транзисторів, як і зараз, ніж для деяких тисяч транзисторів процесора сімдесятих. Але це не суперечить моїй відповіді IMO. Процесори взагалі як правило, є багато відомих помилок, принаймні, у мікрокоді, але це не стосується тут.)

Є ще більше причин не турбуватися про знецінення процесора для вашої програми:

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

  Повинно бути зрозуміло, що якщо ви використовуєте процесор 100% 24/7 цілий рік, він зазвичай загине раніше, ніж процесор, що використовується лише кожен другий тиждень на одну годину. Але це стосується і машин, до речі. Тільки в таких випадках я б задумався про використання процесора та потенційний сон.

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

• Більше того, операційна система має контроль над процесором, а не над вашою програмою, тому, якщо є інші додатки з тим самим або більшим пріоритетом (що за замовчуванням), ваша програма отримує лише якомога більше процесора, але інші програми не будуть голодувати. (Звичайно, це лише спрощена теорія, і, звичайно, багатозадачність Windows, Linux та інших не є ідеальною, але в цілому я вважаю це справжнім).

"Раніше я мав враження, що 100-відсоткове використання процесора було б кращим для інтенсивної чи тривалої роботи."

Так, залишайтеся з цим. Але, наприклад, якщо ви чекаєте і циклуєте інший процес, інакше кажучи, нічого не роблячи, було б не так вже й погано, якби ви Thread.Sleep () кілька мілісекунд в цьому циклі, надаючи додатковий час іншим. Оскільки для хорошої багатозадачної ОС це не потрібно, я вирішив деякі проблеми з цим, наприклад, для Windows 2000. (Це НЕ означає, звичайно, використовувати Sleep () для розрахунків, наприклад.

Така деградація теоретично можлива і називається " електроміграцією ". Електроміграція залежить від температури, прискорюється в міру підвищення температури. Чи є це практичною проблемою для сучасних процесорів, обговорюється питання. Сучасна практика проектування VLSI компенсує електроміграцію, а мікросхеми, швидше за все, не спрацюють з інших причин.

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

Швидкість електроміграції залежить від температури мікросхеми, час життя подвоюється на кожні (дуже приблизно) 10 ° C. Фактично, це основа випробування під назвою "HTOL" (високотемпературний термін експлуатації), який вимірює, скільки часу потрібно, щоб мікросхема померла, скажімо, при 125 ° С. Мікросхема, що працює при 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% усіх процесорів, оскільки це зменшує знос комп'ютера.

Це залежить від комп'ютера, яким ви користуєтесь. Я знаю, що виробник комп'ютерів відмовився від гарантійного ремонту протягом гарантійного часу на дешевих домашніх комп’ютерах, які використовувались у науковій роботі 24/7. Вони, очевидно, хотіли, щоб клієнт придбав свої більш дорогі сервери або "бізнес" комп'ютери. Чи були вони успішними, я не знаю.

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

Тож з добре розробленим комп’ютером ви маєте рацію. З погано сконструйованим дешевим комп’ютером, ваш колега може мати рацію. З іншого боку, ви можете врахувати вартість вашого часу очікування порівняно з вартістю придбання комп’ютера, що заміняється.

Якщо ви можете, зробіть свій код завданням нижчого пріоритету та не забудьте тримати важкий процесорний потік окремо від графічного інтерфейсу. Тоді ви можете мати 100% використання, але користувач завжди може виконувати інші завдання та залишатись чуйними. Сам по собі процесор розроблений таким чином, щоб він деякий час працював на 100%, інакше його не випускатимуть. Якщо кінцевий користувач не зробив серйозних і небезпечних модифікацій свого обладнання, ви нічого не можете пошкодити.