Чому для програми потрібна мінімальна кількість ядер CPU?

Чи можливо написати код (або повне програмне забезпечення, а не фрагмент коду), який не працюватиме належним чином при роботі на процесорі, що має менше N ядер? Не перевіряючи це чітко і не відмовляючись спеціально:

ЯКЩО (noOfCores <4) ТАКОЖ не запускається належним чином

Я переглядаю мінімальні системні вимоги до гри ( Dragon Age: Inquisition ), і в ній вказано мінімум чотирьохядерний процесор. Багато гравців кажуть, що НЕ працює на двоядерних процесорах і НАДЕБЛИВО на Intel Core i3s з двома фізичними та двома логічними ядрами. І це НЕ проблема обчислювальної потужності.

Наскільки я розумію, потоки повністю ізольовані від центрального процесора ОС, оскільки цього неможливо зробити.

Просто, щоб очистити речі:

Я НЕ запитую "Чи можу я дізнатись кількість ядер CPU з коду, і не вдалося відмовитися" ... Такий код був би ненавмисним (змушує купувати дорожчий процесор для запуску програми - без необхідності обчислювальної потужності). Я прошу, щоб ваш код, скажімо, мав чотири потоки та виходив з ладу, коли два потоки запускаються на одному фізичному ядрі (без явної перевірки інформації про систему та навмисно відмови) .

Коротше кажучи, чи може бути програмне забезпечення, яке вимагає декількох ядер, не потребуючи додаткової обчислювальної потужності, що надходить з декількох ядер? Було б потрібно лише N окремих фізичних ядер.

Це можливо можливо зробити «випадково» при необережному використанні основної спорідненості. Розглянемо наступний псевдокод:

• почати нитку
• у цій темі з’ясуйте, на якому ядрі він працює
• встановити спорідненість CPU до цього ядра
• починайте робити щось обчислювально інтенсивно / циклічно назавжди

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

(Якщо у вас є тривалі потоки, налаштування афінності процесора, як правило, покращує пропускну здатність)

Ідея про те, що ігрові компанії «змушують» людей купувати дорожче обладнання без поважних причин, не дуже правдоподібна. Це може втратити лише клієнтів.

Редагувати: зараз ця публікація отримала 33 відгуки, що досить багато, враховуючи, що вона заснована на освічених здогадах!

Здається, що люди отримали DA: Я керував, погано, на двоядерних системах: http://www.dsogaming.com/pc-performance-analyses/dragon-age-inquisition-pc-performance-analysis/ Цей аналіз зазначає, що ситуація сильно покращується, якщо увімкнено гіперточення. Зважаючи на те, що HT не додає більше одиниць випуску інструкцій чи кеш-пам'яті, він просто дозволяє одному ланцюгу запускатись, а інший знаходиться в стійлі кеша, що говорить про те, що він пов'язаний з чистою кількістю потоків.

Інший плакат стверджує, що зміна графічних драйверів працює: http://answers.ea.com/t5/Dragon-Age-Inquisition/Working-solution-for-Intel-dual-core-CPUs/td-p/3994141 ; зважаючи на те, що графічні драйвери, як правило, є жалюгідним вуликом накипу та віла, це не дивно. Один горезвісний набір драйверів мав режим "правильний і повільний" проти "швидкий і неправильний", який було обрано, якщо його викликали з QUAKE.EXE. Цілком можливо, що драйвери поводяться по-різному для різної кількості явних процесорів. Можливо (назад до спекуляцій) використовується інший механізм синхронізації. Зловживання спиноблоками ?

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

Редагувати 2: коментарі згадують ОС, яка намагається уникнути голодування ниток. Зауважте, що у гри може бути власний внутрішній квазі-планувальник для призначення роботи потокам, і подібний механізм буде в самій графічній карті (яка фактично є власною багатозадачною системою). Шанси на помилку в одному з таких або взаємодію між ними досить високі.

www.ecsl.cs.sunysb.edu/tr/ashok.pdf (2008) - це дипломна робота щодо кращого планування графічних карт, в якій чітко зазначається, що вони зазвичай використовують розклад перших-перших-сервісів, який легко реалізувати в непередбачувані системи. Чи покращилася ситуація? Напевно, ні.

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

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

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

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

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

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

Одним важливим показником в ігровій продуктивності є частота кадрів. Зазвичай вони працюють на 30 або 60 кадрів в секунду. Це означає, що ігровий движок повинен виводити поточний вигляд із стану гри за фіксовану кількість часу. Щоб досягти 60 кадрів в секунду, для цього потрібно трохи більше 16 мс. Ігри з графікою високого класу надзвичайно пов'язані з процесором, тому існує величезна віддача між спробами просунути більш високу якість (що вимагає більше часу) і необхідністю залишатися в цьому бюджеті часу. Таким чином, бюджет часу для кожного кадру надзвичайно жорсткий.

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

Теоретично можна було все це набити на одне ядро, але тоді все стає набагато складніше. Раптом ви повинні переконатися, що все те, що відбувається в грі, відбувається досить швидко, і дозволяє ваш рендерінг відбуватися. Ви не можете просто зробити їх двома програмними потоками, тому що немає ніякої можливості зрозуміти ОС: "Потік A повинен виконати X обсяг роботи за 16 мсек, незалежно від того, що робить B".

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

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

Очевидно, якщо потоки в режимі реального часу чекають на щось, що не дозволяє їм спати (наприклад, спінлок), дизайнер програми накрутив.

Перш за все, програмні потоки не мають нічого спільного з апаратними потоками і часто змішуються. Програмні потоки - це фрагменти коду, ніж їх можна відправляти та запускати самостійно в контексті процесу. Апаратні потоки здебільшого керуються ОС і є розсилками до ядра процесора, коли йдеться про звичайні програми. Ці апаратні нитки розсилаються залежно від навантаження; диспетчер апаратних потоків діє більш-менш як балансир навантаження.

Однак, що стосується ігор, особливо ігор високого класу, іноді апаратними нитками керує сама гра або гра дає інструкції диспетчеру апаратних потоків, що робити. Це тому, що кожне завдання або група завдань не має такого ж пріоритету, як у звичайній програмі. Оскільки вік дракона походить від ігрової студії високого класу, що використовує ігрові двигуни високого класу, я можу уявити, що він використовує "ручну" відправлення, і тоді кількість ядер стає мінімальною системною вимогою. Будь-яка програма вийде з ладу, коли я надсилаю фрагмент коду до 3-го фізичного ядра, що працює на машині, що має лише 1 або 2 ядра.

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

Тобто не можна писати програмне забезпечення, яке завжди зупинятиметься на меншій ніж N ядер.

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

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

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

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

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

Is it possible to write code (or complete software, rather than a piece of code) that won't work properly when run on a CPU that has less than N number of cores?

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

Щодо додатків user-land: Ваша припущення, що перевірка заданої кількості потоків для запуску обов'язково є зловмисною у намірі, не є правильним. Наприклад, у вас можуть бути два тривалі завдання, що вимагають високої продуктивності, які потребують ядра для себе. Незалежно від швидкості роботи центрального процесора, спільне використання ядра з іншими потоками може бути серйозним і неприйнятним зниженням продуктивності внаслідок розтирання кешу разом із звичайними штрафами, що виникають при комутації потоків (які є досить значними.) У цьому випадку було б цілком розумно, особливо для гри, щоб встановити кожен з цих потоків, щоб мати спорідненість лише по одному конкретному ядру для кожного з них, а потім встановити всі ваші інші потоки так, щоб вони не мали спорідненості на цих 2 ядрах. Для того, щоб це зробити,

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

Уявімо, наприклад, виробник, який подає завдання до черги, яка обслуговує 4 споживчих потоку. Є тільки два ядра:

Виробник намагається отримати спінлок, але його тримає споживач, який працює на іншому ядрі. Дві сердечники виконуються замком, поки виробник крутиться, чекаючи, коли замок буде відпущений. Це вже погано, але не так вже й погано, як вийде.
На жаль, споживча нитка знаходиться в кінці свого часового кванту, тому її викуповують, а інша споживча нитка запланована. Він намагається зачепити замок, але, звичайно, замок беруть, тож тепер два ядра крутяться і чекають чогось, що неможливо статися.
Виробнича нитка доходить до кінця свого часового відрізка і викуповується, інший споживач прокидається. Знову ж таки, два споживачі чекають звільнення блокування, і це просто не відбудеться до того, як пройдуть ще два кванти часу.
[...] Нарешті споживач, який тримав спінлок, звільнив замок. Це негайно бере той, хто крутиться на іншому ядрі. Є 75% шансів (від 3 до 1), що це ще одна споживча нитка. Іншими словами, це 75% ймовірності, що виробник все ще затримується. Звичайно, це означає, що і споживачі зупиняються. Без продуманих завдань, що виробники, їм нічого не обійтися.

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

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

Якщо я розумію, про що ви просите, це можливо, але це дуже, дуже погано.

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

Ця залежність між часом та правильністю - це те, що інформатика називає умовою гонки .

Умови перегонів часто уникають, використовуючи механізми синхронізації, щоб переконатися, що потоки, які хочуть оперувати частиною спільних даних, повинні отримувати відповідність для доступу. Описаний вище лічильник може використовувати для цього блокування читання-запису .

Без доступу до внутрішнього дизайну епохи Дракона: інквізиція , кожен, хто може зробити, - міркувати, чому він поводиться так, як це робить. Але я буду ходити на основі деяких речей, які я бачив, зроблених на власному досвіді:

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

Запуск такої програми на що-небудь менш здатному, ніж середовище, на яке вона була налаштована, вносить зміни в часі, які є результатом того, що код не працює так швидко, або, що швидше, контекстні комутатори. Контекстні комутатори відбуваються у фізичному (тобто фізичні ядра ЦП перемикаються між роботою, в якій тримаються логічні ядра) та логічним (тобто ОС на процесорі призначає роботу ядрам) способами, але або є суттєвим розбіжністю з тим, що буде "очікуваним" терміном виконання. Це може виявити погану поведінку.

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

Для цього Windows має вбудований функціонал: функція GetLogicalProcessorInformation знаходиться в API Windows . Ви можете зателефонувати на цю програму, щоб отримати інформацію про ядра, віртуальні ядра та гіперточування.

Тож відповідь на ваше запитання була б: Так.