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

Наша мета в даній статті – описати всі фактори, що впливають на продуктивність процесора та інші експлуатаційні характеристики.

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

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

Будь то перегляд відео, музика, інтернет серфінг, запис і читання в пам'яті, обробка 3D і відео, ігор. І багато чого іншого.

Тому до вибору Центрального Процессора, варто поставитися дуже ретельно. Може вийти ситуація, що ви вирішили поставити потужну відеокарту і процесор, що не відповідає її рівню. У цьому випадку процесор, не розкриватиме потенціал відеокарти, що гальмуватиме її роботу. Процесор буде повністю завантажений і буквально кипіти, а відеокарта чекатиме на свою чергу, працюючи на 60-70% від своїх можливостей.

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

Intel vs. AMD

*наздоганялки назавжди

Корпорація Intel, має величезні людські ресурси, і майже невичерпні фінанси. Багато інновацій у напівпровідниковій індустрії та нові технології йдуть саме з цієї компанії. Процесори та розробки Intel, в середньому на 1-1,5 роки випереджають напрацювання інженерів AMD. Але як відомо, за можливість мати найбільші сучасними технологіями- Доводиться платити.

Цінова політика процесорів Intel, ґрунтується як на кількості ядер, кількості кешу, але і на «свіжості» архітектури, продуктивності на тактват,техпроцесу чіпа. Значення кеш-пам'яті, «тонкощі техпроцесу» та інші важливі характеристикипроцесора розглянемо нижче. За володіння такими технологіями як і вільного множника частоти, теж доведеться викласти додаткову суму.

Компанія AMD, на відміну від компанії Intel, прагне доступності своїх процесорів для кінцевого споживача і грамотної цінової политике.

Можна навіть сказати, що AMD– « Народна марка». У її цінниках ви знайдете те, що вам потрібно за привабливою ціною. Зазвичай через рік після появи нової технологіїу компанії Intel, з'являється аналог технології від AMD. Якщо ви не женетеся за найвищою продуктивністю і більше звертаєте увагу на цінник, ніж на наявність передових технологій, то продукція компанії AMD- Саме для вас.

Цінова політика AMD, Більше ґрунтується на кількості ядер і зовсім небагато - на кількості кеш пам'яті, наявності архітектурних покращень. У деяких випадках, за можливість мати кеш пам'яттю третього рівня, доведеться трохи доплатити ( Phenomмає кеш пам'ять 3 рівня, Athlonзадовольняється лише обмеженою, 2 рівня). Але іноді AMD«балує» своїх фанатів можливість розблокуватиДешевші процесори, до дорожчих. Можна розблокувати ядра або кеш-пам'ять. Поліпшити Athlonдо Phenom. Таке можливе завдяки модульній архітектурі та при нестачі деяких дешевших моделей, AMDпросто відключає деякі блоки на кристалі дорожчих (програмно).

Ядра– залишаються практично незмінними, відрізняється лише їх кількість (справедливо для процесорів 2006-2011 років). За рахунок модульності своїх процесорів компанія добре справляється зі збутом відбракованих чіпів, які при відключенні деяких блоків, стають процесором з менш продуктивної лінійки.

Компанія багато років працювала над абсолютно новою архітектурою під кодовим ім'ям Bulldozer, але на момент виходу в 2011 Цього року, нові процесори показали не найкращу продуктивність. AMDгрішила на операційні системи, що вони не розуміють архітектурних особливостей здвоєних ядер та «іншої багатопоточності».

За словами представників компанії, слід чекати особливих виправлень та латок, щоб відчути всю продуктивність даних процесорів. Однак на початку 2012 року, представники компанії відклали вихід оновлення для підтримки архітектури Bulldozerна другу половину року.

Частота процесора, кількість ядер, багатопоточність.

За часів Pentium 4і до нього – частота процесорабула головним фактором продуктивності процесора при виборі процесора.

Це не дивно, адже архітектури процесорів спеціально розроблялися для досягнення високої частоти, особливо це відбилося якраз у процесорі Pentium 4на архітектурі NetBurst. Висока частота була неефективна при тому довгому конвеєрі, що був використаний в архітектурі. Навіть Athlon XPчастотою 2Ггц, за рівнем продуктивності був вище Pentium 4 c 2,4Ггц. Так що це був чистої води маркетинг. Після цієї помилки, компанія Intelусвідомила свої помилки та повернулася на бік добрапочала працювати над частотної складової, а над продуктивністю на такт. Від архітектури NetBurstдовелося відмовитись.

Щож нам дає багатоядерність?

Чотирьох-ядерний процесор із частотою 2,4 ГГц, в багатопотокових додатках, теоретично буде зразковим еквівалентом, одноядерного процесора з частотою 9,6 Ггцабо 2-х ядерному процесору з частотою 4,8 ГГц. Але це тільки теоретично. Практичнож, два двоядерних процесора в двох сокетних материнських платах, будуть швидше одного 4-ядерного, на тій же частоті функціонування. Обмеження за швидкістю шини і затримки пам'яті даються взнаки.

* за умови однакових архітектур та кількості кеш пам'яті

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

Програми, які «люблять» і використовуютьбагатопоточність: архіватори, плеєри та кодувальники відео, антивіруси, програми дефрагментатори, графічні редактори , браузери, Flash.

Також, до «аматорів» багатопоточності, можна віднести такі операційні системи як Windows 7і Windows Vista , а також багато ОС, засновані на ядрі Linux, які працюють помітно швидше за наявності багатоядерного процесора.

Більшості ігор, буває цілком достатньо 2-х ядерного процесора на високій частоті. Зараз однак виходить все більше ігор «заточених» під багатопоточність. Взяти хоча б такі SandBoxігри, як GTA 4або Prototype, у яких на 2-х ядерному процесорі з частотою нижче 2,6 ГГц- Комфортно себе не відчуваєш, фреймрейт провалюється нижче 30 кадрів в секунду. Хоча в даному випадку, найімовірніше причиною таких казусів є «слабка» оптимізація ігор, нестача часу або «не прямі» руки тих, хто переносив ігри з консолей. PC.

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

Кеш пам'ять процесора.

– це виділена область кристала процесора, в якій обробляються та зберігаються проміжні дані між процесорними ядрами, оперативною пам'яттю та іншими шинами.

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

Через неї нестачі, процесор може простоювати в трудомістких завданнях, чекаючи поки в кеш надійдуть нові дані для обробки. Також кеш-пам'ять служить длязаписи часто повторюваних даних, які за необхідності можуть бути швидко відновлені без зайвих обчислень, не змушуючи процесор витрачати час ними знову.

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

Такий прийом, зараз використовується для кеш пам'яті 3-го рівня. У процесорів Intelіснували процесори з об'єднаною кеш пам'яттю 2-го рівня ( C2D E 7***,E 8***), завдяки яким і з'явився даний спосібзбільшити багатопотокову продуктивність.

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

Загалом, що більше кеш пам'яті, то швидшепроцесор. У яких саме додатках?

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

Сприятливо до великій кількостікеш-пам'яті відносяться ігри. Особливо стратегії, авто-симулятори, RPG, SandBox та всі ігри, де є багато дрібних деталей, частинок, елементів геометрії, потоків інформації та фізичних ефектів.

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

Кеш пам'ять, завжди оснащується захистом від можливих помилок (ECC), при виявленні яких, ведеться їхнє виправлення. Це дуже важливо, адже маленька помилка в кеш пам'яті, при обробці може перетворитися на гігантську, суцільну помилку, від якої ляже вся система.

Фірмові технології.

(Гіпер-поточність, HT)–

вперше технологія була застосована у процесорах Pentium 4, але працювала який завжди коректно і часто більше гальмувала процесор, ніж прискорювала. Причиною був занадто довгий конвеєр і не доведена до ладу система передбачення розгалужень. Застосовується компанією Intel, аналогів технології поки немає, якщо не вважати аналогом? що реалізували інженери компанії AMDв архітектурі Bulldozer.

Принцип системи такий, що на кожне фізичне ядро, що створюється за два обчислювальні потокизамість одного. Тобто, якщо у вас 4-х ядерний процесор HT (Core i 7), то віртуальних потоків у вас 8 .

Приріст продуктивності досягається рахунок того, що в конвеєр можуть надходити дані вже в його середині, а не обов'язково спочатку. Якщо якісь блоки процесора, здатні виконати цю дію простоюють, вони отримують завдання до виконання. Приріст продуктивності не такий як у реальних фізичних ядер, але можна порівняти (~50-75%, залежно від роду докладання). Досить рідко буває, що в деяких програмах, HT негативно впливаєна продуктивність. Пов'язано це з поганою оптимізацією додатків під цю технологію, неможливість зрозуміти, що є потоки «віртуальні» та відсутність обмежувачів для навантаження потоків поступово.

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

, 3 dnow!інструкції. Призначені для прискорення роботи процесора в мультимедіаобчисленнях (відео, музика, 2D/3D графіка і т.д.), а також прискорюють роботу таких програм як архіватори, програми для роботи із зображеннями та відео (за підтримки інструкцій даними програмами).

3dnow! - Досить стара технологія AMD, яка містить додаткові інструкціїз обробки мультимедіа контенту, крім SSEпершої версії.

*А саме можливість потокової обробки дійсних чисел одинарної точності.

Наявність самої нової версії– є великим плюсом, процесор починає ефективніше виконувати певні завдання за належної оптимізації ПЗ. Процесори AMDносять схожі назви, але трохи інші.

* Приклад - SSE 4.1 (Intel) - SSE 4A (AMD).

До того ж дані набори інструкцій не ідентичні. Це аналоги, які мають невеликі відмінності.

Cool’n’Quiet, SpeedStep, CoolCore, Enchanced Half State(C1E) іт. д.

Дані технології, при низькому навантаженні зменшують частоту процесора, зменшенням множника і напруги на ядрі, відключення частини КЕШу і т.д. Це дозволяє процесору набагато менше грітися та споживати менше енергії, менше шуміти. Якщо знадобиться потужність, то процесор повернеться у нормальний стан за частки секунди. На стандартних налаштуваннях Biosпрактично завжди включені, за бажання їх можна відключити, зменшення можливих «фризів» при перемиканні в 3D іграх.

Деякі з цих технологій управляють швидкістю обертання вентиляторів у системі. Наприклад, якщо процесор не потребує посиленого відведення тепла і не навантажений, швидкість вентилятора процесора зменшується ( AMD Cool'n'Quiet, Intel Speed ​​Step).

Intel Virtualization Technologyі AMD Virtualization.

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

Execute Disable BitіNo eXecute Bit – технологія, покликана захистити комп'ютер від вірусних атак та програмних помилок, які можуть спричинити крах системи за допомогою переповнення буфера.

Intel 64 , AMD 64 , EM 64 T - дана технологія дозволяє процесору працювати як в ОС з 32-х бітною архітектурою, так і в ОС з 64-х бітною. Система 64 bit- З погляду вигоди, для рядового користувача відрізняється тим, що в даній системі можна використовувати більше 3.25Гб оперативної пам'яті. У 32-х бітних системах, використовувати б пробільший обсяг оперативної пам'яті неможливо, через обмеженого обсягу адресируемой пам'яті* .

Більшість додатків з 32-бітною архітектурою, можна запустити на системі з 64-бітною ОС.

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

Додатково.

Пари слів про .

На цей пункт варто звернути пильну увагу. Чим тонший техпроцес, тим менше процесорспоживає енергії і як наслідок – менше гріється. І, крім усього іншого, має більш високий запас міцності для розгону.

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

Вбудований процесор .

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

До того ж ті ядра, що вбудовані в процесор, годяться тільки для завантаження ОС, інтернет серфінгу та перегляду відео (і то не будь-якої якості).

Тенденції на ринку все ж таки змінюються і можливість купити продуктивний процесор від Intelбез відео ядра випадає все рідше. Політика примусового нав'язування вбудованого відео ядра з'явилася з процесорів Intelпід кодовою назвою Sandy Bridge, основне нововведення яких і було вбудоване ядро ​​на тому самому техпроцесі. Відео-ядро, знаходиться спільноз процесором на одному кристалі, і не таке просте як у попередніх поколіннях процесорів Intel. Для тих хто його не використовує, є мінуси у вигляді деякої переплати за процесор, зміщення джерела нагріву щодо центру тепло-розподільної кришки. Проте є плюси. Вимкнене відео ядро, можна використовувати для швидкого кодування відео за допомогою технології Quick Syncразом зі спеціальним, що підтримує цю технологію ПЗ. В майбутньому, Intelобіцяє розширити горизонти використання вбудованого відео ядра для паралельних обчислень.

Сокети для процесорів. Терміни життя платформ.

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

Компанія AMD, веде протилежну політику сумісності На її платформу AM 3, будуть підходити всі процесори майбутніх поколінь, які підтримують DDR3. Навіть при виході платформи на AM 3+і пізніших, окремо будуть випускатися або нові процесори під AM 3, або нові процесори будуть сумісні зі старими материнськими платами, і можна буде зробити безболісний для гаманця апгрейд, помінявши лише процесор (без зміни мат.плати, ОЗУ тощо) і прошив материнської плати. Єдині нюанси несумісності можуть бути при зміні типу , так як буде потрібно інший контролер пам'яті, вбудований в процесор. Отже, сумісність обмежена і підтримується далеко не всіма материнськими платами. Але в цілому, економному користувачеві або тим, хто не звик міняти платформу повністю кожні 2 роки, вибір виробника процесора зрозумілий. AMD.

Охолодження процесора.

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

Висновок.

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

• Вибрати виробника
• Архітектура процесора
• Техпроцес
• Частота процесора
• Кількість ядер процесора
• Розмір та тип кеш-пам'яті процесора
• Підтримка технологій та інструкцій
• Якісне охолодження

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

saul 9 вересня 2015 о 13:38

Реалізація багатопоточної архітектури ігрового двигуна

• Блог компанії Intel
• Розробка ігор
• Паралельне програмування
• Розробка веб-сайтів

• Переклад

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

1. Введення

1.1. Огляд

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

Для розуміння представлених матеріалів потрібно добре розумітися на сучасних методах створення. комп'ютерних ігор, підтримки багатопоточності для ігрових двигунів або поліпшення продуктивності додатків загалом.

2. Стан паралельного виконання

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

2.1 Стану виконання

Щоб менеджер станів виконання працював ефективно, рекомендується синхронізувати операції з певним тактовим імпульсом. Це дозволяє всім системам працювати одночасно. У цьому частота тактів необов'язково відповідати частоті передачі кадрів. Та й тривалість тактів може залежати від частоти. Її можна вибрати таким чином, щоб один такт відповідав часу, необхідному для передачі одного кадру (незалежно від його розміру). Іншими словами, частоту чи тривалість тактів визначає конкретна реалізація менеджера станів. На малюнку 1 показаний «вільний» покроковий режим роботи, у якому не потрібно, щоб усі системи завершували виконання операції за той самий такт. Режим, у якому всі системи завершують виконання операцій за такт, називається «жорстким» покроковим режимом. Він схематично зображений малюнку 2.

Рисунок 1. Стан виконання у вільному покроковому режимі

2.1.1. Вільний покроковий режим

У вільному покроковому режимі всі системи працюють безперервно протягом попередньо заданого проміжку часу, необхідного для завершення чергової порції обчислень. Однак назву «вільний» не слід розуміти буквально: системи синхронізуються не в довільний момент часу, вони лише «вільні» у виборі числа тактів, необхідного на виконання чергового етапу.
Як правило, в цьому режимі недостатньо надіслати менеджеру станів просте повідомлення про зміну стану. Також необхідно передати оновлені дані. Це викликано тим, що система, яка змінила загальні дані, може перебувати у стані виконання, тоді як інша система, яка чекає на ці дані, вже готова виконати оновлення. У цьому випадку потрібно більше пам'яті, тому що потрібно створювати більше копій даних. Тому «вільний» режим не можна вважати універсальним рішенням на всі випадки життя.

2.1.2. Жорсткий покроковий режим

У цьому режимі виконання всіх систем завершується за один такт. Такий механізм простіше у реалізації і вимагає передачі оновлених даних разом із повідомленням. Справді, за необхідності одна система може запросити нові значення в інший системи (зрозуміло, наприкінці циклу виконання).
У жорсткому режимі можна реалізувати псевдовільний покроковий режим роботи, розподіляючи обчислення між різними кроками. Зокрема це може знадобитися для розрахунків ІІ, де за перший такт обчислюється початкова «загальна мета», яка поступово уточнюється на наступних етапах.

Рисунок 2. Стан виконання у жорсткому покроковому режимі

2.2. Синхронізація даних

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

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

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

3. Двигун

При створенні двигуна основна увага приділяється гнучкості, яка потрібна на подальше розширення його функціональності. Це дозволить оптимізувати його для використання в умовах певних обмежень (наприклад, пам'яті).
Двигун можна умовно поділити на дві частини: фреймворк та менеджери. Фреймворк (див. розділ 3.1) включає частини гри, які тиражуються в процесі виконання, тобто існують в декількох примірниках. До нього також входять елементи, що у виконанні основного циклу гри. Менеджери (див. розділ 3.2) є Singleton-об'єктами, що відповідають за виконання логічної складової гри.
Нижче представлена ​​схема ігрового двигуна.

Рисунок 3. Загальна архітектура двигуна

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

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

Фактично, всі системи незалежні одна від одної (див. розділ 2, «Стан одночасного виконання»), тобто вони можуть виконувати дії паралельно, не впливаючи на роботу інших систем. Проте будь-яка зміна даних спричинить певні складності, оскільки системам доведеться взаємодіяти між собою. Обмін інформацією між системами необхідний у таких випадках:

• щоб повідомити іншу систему про зміну загальних даних (наприклад, положення або орієнтацію об'єктів);
• щоб виконати функції, недоступні для даної системи (наприклад, система ІІ звертається до системи розрахунку геометричних або фізичних властивостей об'єкта, щоб виконати тест на перетин променів).

У першому випадку для керування обміном інформацією можна використовувати менеджер станів, описаний у попередньому розділі. (Докладніше про менеджера станів див. розділ 3.2.2, «Менеджер станів».)
У другому випадку необхідно реалізувати спеціальний механізм, який дозволить надати служби однієї системи для використання іншої. Повний описцього механізму наведено у розділі 3.2.3, «Менеджер служб».

3.1. Фреймворк

Фреймворк служить об'єднання всіх елементів движка. У ньому відбувається ініціалізація двигуна, крім менеджерів, екземпляри яких створюються глобально. У ньому також зберігається інформація про сцену. Щоб досягти більшої гнучкості, сцена реалізується як так званої універсальної сцени, що містить універсальні об'єкти. Вони є контейнерами, що об'єднують різні функціональні частини сцени. Детальну інформацію наведено в розділі 3.1.2.
Основний цикл гри також реалізований у фреймворку. Схематично його можна подати в такий спосіб.

Рисунок 4. Основний цикл гри

Двигун працює у віконному середовищі, тому на першому етапі циклу гри необхідно обробити всі незавершені повідомлення вікон ОС. Якщо цього не зробити, двигун не реагуватиме на повідомлення ОС. На другому етапі планувальник призначає завдання за допомогою менеджера завдань. Цей процес докладно описаний у розділі 3.1.1. Після цього менеджер станів (див. розділ 3.2.2) розсилає інформацію про виконані зміни систем двигуна, на роботу яких вона може вплинути. На останньому кроці, залежно від статусу виконання, фреймворк визначає, чи слід завершити або продовжити роботу движка, наприклад, для переходу до наступної сцени. Інформація про стан двигуна зберігається у менеджера середовища. Докладніше див. у розділі 3.2.4.

3.1.1. Планувальник

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

3.1.2. Універсальна сцена та об'єкти

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

Рисунок 5. Розширення універсальної сцени та об'єкта

Розглянемо принцип роботи розширень на прикладі. Допустимо, виконано розширення універсальної сцена розширена на використання використання графічних, фізичних та інших властивостей. У цьому випадку за ініціалізацію дисплея відповідатиме «графічна» частина розширення, а за реалізацію фізичних законів для твердих тіл, наприклад, сили тяжіння, - його «фізична» частина. Сцени містять об'єкти, тому універсальна сцена теж буде включати кілька універсальних об'єктів. Універсальні об'єкти також можна розширити і можуть бути розширені для використання графічних, фізичних та інших властивостей. Наприклад, промальовування об'єкта на екрані буде реалізована графічними функціями розширення, а розрахунок взаємодії твердих тіл – фізичними.

Детальна схема взаємодії двигуна та систем наведена в додатку B, «Схема взаємодії двигуна та систем».
Слід зазначити, що універсальна сцена та універсальний об'єкт відповідають за реєстрацію всіх своїх «розширень» у менеджері станів, щоб всі розширення могли отримувати повідомлення про зміни, внесені іншими розширеннями (тобто іншими системами). Як приклад можна навести графічне розширення, зареєстроване для отримання повідомлень про зміни положення та орієнтації, виконані фізичним розширенням.
Докладнішу інформацію про компоненти системи див. у розділі 5.2, «Компоненти системи».

3.2. Менеджери

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

3.2.1. Менеджер завдань

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

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

Рисунок 6. Приклад пулу потоків, використовуваного менеджером завдань

Крім обробки запитів планувальника щодо доступу до основних завдань, менеджер завдань може працювати в режимі ініціалізації. Він послідовно опитує системи кожного потоку, щоб вони могли ініціалізувати локальні сховища даних, необхідні для роботи.
Поради щодо реалізації менеджера завдань дано в додатку D, «Поради щодо реалізації завдань».

3.2.2. Менеджер станів

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

Механізм працює в такий спосіб. 1. Спостерігач повідомляє контролера змін (або менеджера станів), зміни яких суб'єктів він хоче відслідковувати. 2. Суб'єкт повідомляє контролер про всі свої зміни. 3. За сигналом фреймворку контролер повідомляє спостерігача про зміни суб'єкта. 4. Наглядач надсилає суб'єкту запит на отримання оновлених даних.

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

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

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

Рисунок 7. Повідомлення про внутрішні зміни універсального об'єкта

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

3.2.3. Менеджер служб

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

Рисунок 8. Приклад менеджера служб

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

3.2.4. Менеджер середи

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

3.2.5. Менеджер платформи

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

Менеджер платформи також відповідає за надання інформації про процесор, наприклад про підтримувані SIMD-інструкції, та за ініціалізацію певного режиму роботи процесів. Інші функції формування запитів системи використовувати не можуть.

4. Інтерфейси

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

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

4.1. Інтерфейси суб'єкта та спостерігача

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

4.2. Інтерфейси менеджерів

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

4.3. Інтерфейси системи

Щоб фреймворк міг отримати доступ до компонентів системи, їй потрібні інтерфейси. Без них підтримку кожної нової системидвигуна довелося б продавати окремо.
Кожна система включає чотири компоненти, тому і інтерфейсів має бути чотири. А саме: система, сцена, об'єкт та завдання. Докладний описдив. у розділі 5, «Системи». Інтерфейси – це засоби отримання доступу до компонентів. Інтерфейси системи дозволяють створювати та видаляти сцени. Інтерфейси сцени, у свою чергу, дозволяють створювати та знищувати об'єкти, а також запитувати інформацію про основне завдання системи. Інтерфейс задач в основному використовується менеджером задач при постановці задач у пул потоків.
Оскільки сцена та об'єкт, як частини системи, повинні взаємодіяти один з одним та з універсальною сценою та об'єктом, до яких вони прив'язані, їх інтерфейси також створюють на основі інтерфейсів суб'єкта та спостерігача.

4.4. Інтерфейси змін

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

5. Системи

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

5.1. Типи

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

5.2. Компоненти системи

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

Рисунок 9. Компоненти системи

Детальна схема зв'язків між системами двигуна наведена в додатку B, «Схема взаємодії двигуна та систем».

5.2.1. Система

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

5.2.2. Сцена

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

5.2.3. Об'єкт

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

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

5.2.4. Завдання

Компонент «завдання» або системне завдання використовується для обробки сцени. Завдання отримує команду оновлення сцени від менеджера завдань. Це сигнал для запуску системних функцій на сцені.
Виконання завдання можна розбити на підзавдання, розподіляючи їх також з допомогою менеджера завдань ще більше потоків. Це зручний спосібмасштабування двигуна на кілька процесорів. Такий метод називають декомпозицією даних.
Інформація про зміну об'єктів у процесі оновлення завдань сцени передається менеджеру станів. Докладнішу інформацію про менеджера станів див. у розділі 3.2.2.

6. Поєднуючи всі компоненти

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

6.1. Етап ініціалізації

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

• Фреймворк викликає завантажувач сцени.
• Визначивши, які системи сцена використовуватиме, завантажувач викликає менеджера платформи для завантаження відповідних модулів.
• Менеджер платформи завантажує відповідні модулі та передає їх менеджеру інтерфейсів, потім викликає їх до створення нової системи.
• Модуль повертає завантажувачу покажчик на екземпляр системи, що реалізує системний інтерфейс.
• Менеджер служб реєструє всі служби, які надає системний модуль.

Рисунок 10. Ініціалізація менеджерів та систем движка

6.2. Етап завантаження сцени

Керування повертається до завантажувача, який завантажує сцену.

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

Рисунок 11. Ініціалізація універсальної сцени та об'єкта

6.3. Етап циклу гри

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

6.3.1. Виконання завдання

Управління переходить менеджеру задач.

• Він формує чергу з усіх отриманих завдань, потім, з появою вільних потоків, починає їх виконання. (Процес виконання завдань різниться залежно від систем. Системи можуть працювати лише з одним завданням або обробляти одночасно кілька завдань із черги, реалізуючи таким чином паралельне виконання.)
• У процесі виконання завдання можуть працювати з усією сценою або лише з певними об'єктами, змінюючи їх внутрішні дані.
• Системи повинні отримувати сповіщення про будь-які зміни загальних даних (наприклад, позиції або орієнтації). Тому під час виконання завдання системна сцена чи об'єкт інформують спостерігача будь-які зміни. І тут спостерігач фактично виконує роль контролера змін, що є частиною менеджера станів.
• Контролер змін формує чергу повідомлень про зміни для подальшої обробки. Він ігнорує зміни, які не стосуються цього спостерігача.
• Щоб скористатися певними службами, завдання звертається до менеджера служб. Менеджер служб також дає змогу змінювати властивості інших систем, недоступні для передачі в механізмі обміну повідомленнями (наприклад, система введення даних змінює розширення екрана - властивість графічної системи).
• Завдання також можуть звертатися до менеджера середовища для отримання змінних середовища та зміни стану виконання (припинення виконання, перехід до наступної сцени та ін.).

Рисунок 12. Менеджер завдань та завдання

6.3.2. Оновлення даних

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

• Менеджер станів по черзі викликає кожен із своїх контролерів змін для розсилки накопичених повідомлень. Контролер перевіряє, яким спостерігачам надсилати повідомлення про зміни для кожного із суб'єктів.
• Потім він викликає потрібного спостерігача і повідомляє йому про зміну (повідомлення також включає покажчик на інтерфейс суб'єкта). У режимі вільного покрокового виконання спостерігач отримує змінені дані від контролера змін, але в режимі жорсткого покрокового виконання він повинен запитувати їх у суб'єкта.
• Зазвичай спостерігачами, зацікавленими в отриманні повідомлень про зміни системного об'єкта, є інші системні об'єкти, пов'язані з тим самим універсальним об'єктом. Це дозволяє розділити процес внесення змін на кілька завдань, які можна виконувати паралельно. Щоб спростити процес синхронізації, можна об'єднати в одному завданні пов'язані розширення універсального об'єкта.

6.3.3. Перевірка виконання та вихід

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

7. Висновок

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

Шаблон «Наглядач» - це функція механізму обміну повідомленнями. Важливо добре розуміти принцип роботи, щоб вибрати оптимальний спосіб її реалізації для двигуна. Фактично це механізм взаємодії між різними системами, що забезпечує синхронізацію загальних даних.

Важливу роль розподілі навантажень грає управління завданнями. У додатку D наведені поради щодо створення ефективного менеджера завдань для ігрового двигуна.

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

Додаток A. Схема движка

Запуск обробки виконується з основного циклу гри (див. рис. 4, «Основний цикл гри»).

 

Додаток B. Схема взаємодії двигуна та систем

 

Додаток C. Спостерігач (шаблон проектування)

Шаблон «Наглядач» докладно описаний у книзі «Прийоми об'єктно-орієнтованого проектування. Паттерни проектування», Е. Гамма, Р. Хельм, Р. Джонсон, Дж. Вліссідес ​​(«Design Patterns: Elements of Reusable Object-Oriented Software», Gamma E., Helm R., Johnson R., Vlissides J.). На англійськоювона вперше була видана в 1995 видавництвом Addison-Wesley.

Основна ідея даної моделі полягає в наступному: якщо якимось елементам необхідно отримувати повідомлення про зміни інших елементів, вони не зобов'язані переглядати список усіх можливих змін, намагаючись знайти у ньому потрібні дані. Модель передбачає наявність суб'єкта та спостерігача, які використовуються для надсилання повідомлень про зміни. Спостерігач відстежує будь-які зміни суб'єкта. Контролер змін виступає у ролі посередника між цими двома даними компонентами. Наступна схема ілюструє цей зв'язок.

Малюнок 13. Шаблон «Спостерігач»

Нижче описано процес використання цієї моделі.

1. Контролер змін реєструє спостерігача та суб'єкта, повідомлення про яке він хоче отримувати.
2. Контролер змін є фактично спостерігачем. Замість спостерігача разом із суб'єктом він реєструє самого себе. Контролер змін також зберігає свій список спостерігачів та зареєстрованих із ними суб'єктів.
3. Суб'єкт вносить спостерігача (тобто контролера змін) до свого списку спостерігачів, які хочуть отримувати повідомлення про його зміни. Іноді додатково вказується тип змін, який визначає, у яких саме змінах зацікавлений спостерігач. Це дозволяє оптимізувати процес розсилки повідомлень про зміни.
4. Змінюючи дані або стан, суб'єкт повідомляє спостерігача через механізм зворотного виклику і передає інформацію про змінені типи.
5. Контролер змін формує чергу повідомлень про зміни та чекає сигналу для їх розподілу по об'єктах та системах.
6. Під час розподілу контролер змін звертається до реальних спостерігачів.
7. Спостерігачі запитують інформацію про змінені дані або стан у суб'єкта (або отримують їх разом із повідомленнями).
8. Перед видаленням спостерігача або якщо йому більше не потрібно отримувати повідомлення про суб'єкта, він видаляє підписку на цей суб'єкт у контролері змін.

Існує безліч різних способівреалізувати розподіл завдань. Однак найкраще підтримувати кількість робочих потоків рівним кількості доступних логічних процесорів платформи. Намагайтеся не прив'язувати завдання до певного потоку. Час виконання завдань різних систем який завжди збігається. Це може призвести до нерівномірного розподілу навантаження між робочими потоками та позначитися на ефективності. Щоб спростити цей процес, використовуйте бібліотеки керування завданнями, наприклад

Розібравшись із теорією багатопоточності, розглянемо практичний приклад - Pentium 4. Уже етапі розробки цього процесора інженери Intel продовжували роботу над підвищенням його швидкодії без внесення змін у програмний інтерфейс. Розглядалося п'ять найпростіших способів:
1. Підвищення тактової частоти.
2. Розміщення однією мікросхемі двох процесорів.
3. Запровадження нових функціональних блоків.
1. Подовження конвеєра.
2. Використання багатопоточності.
Найочевидніший спосіб підвищення швидкодії у тому, щоб підвищити тактову частоту, не змінюючи інші параметри. Як правило, кожна наступна модель процесора має більш високу тактову частоту, ніж попередня. На жаль, при прямолінійному підвищенні тактової частоти розробники стикаються із двома проблемами: збільшенням енергоспоживання (що актуально для портативних комп'ютерів та інших обчислювальних пристроїв, що працюють на акумуляторах) та перегрівом (що потребує створення більш ефективних тепловідводів).
Другий спосіб - розміщення на мікросхемі двох процесорів - порівняно простий, але він пов'язаний із подвоєнням площі, яку займає мікросхема. Якщо кожен процесор забезпечується власною кеш-пам'яттю, кількість мікросхем на пластині зменшується вдвічі, але це означає подвоєння витрат за виробництво. Якщо обох процесорів передбачається загальна кеш-пам'ять, значного збільшення займаної площі вдається уникнути, проте у разі виникає інша проблема - обсяг кеш-пам'яті у перерахунку кожен процесор зменшується вдвічі, але це неминуче позначається продуктивності. Крім того, якщо професійні серверні програми здатні повністю задіяти ресурси кількох процесорів, то у звичайних настільних програмах внутрішній паралелізм розвинений значно меншою мірою.
Введення нових функціональних блоків також не становить складності, але тут важливо дотриматися балансу. Який сенс у десятці блоків АЛУ, якщо мікросхема не може видавати команди на конвеєр із такою швидкістю, що дозволяє завантажити всі ці блоки?
Конвеєр зі збільшеним числом ступенів, здатний розділяти завдання на дрібніші сегменти та обробляти їх за короткі періоди часу, з одного боку, підвищує продуктивність, з іншого, посилює негативні наслідки невірного прогнозування переходів, кеш-промахів, переривань та інших подій, що порушують нормальний хід обробки команд у процесорі. Крім того, щоб повністю реалізувати можливості розширеного конвеєра, необхідно підвищити тактову частоту, а це, як ми знаємо, призводить до підвищеного енергоспоживання та тепловіддачі.
Нарешті, можна продати багатопоточність. Перевага цієї технології полягає у введенні додаткового програмного потоку, що дозволяє ввести в дію ті апаратні ресурси, які інакше простоювали б. За результатами експериментальних досліджень розробники Intel з'ясували, що збільшення площі мікросхеми на 5% при реалізації багатопоточності для багатьох програм дає приріст продуктивності на 25%. Першим процесором Intel із підтримкою багатопоточності став Xeon 2002 року. Згодом, починаючи з частоти 3,06 ГГц, багатопоточність була впроваджена в лінійку Pentium 4. Intel називає реалізацію багатопоточності Pentium 4 гіперпоточністю (hyperthreading).
Основний принцип гіперпоточності – одночасне виконання двох програмних потоків (або процесів – процесор не відрізняє процеси від програмних потоків). Операційна система розглядає гіперпоточний процесор Pentium 4 як двопроцесорний комплекс із загальними кешами та основною пам'яттю. Планування операційної системи виконує для кожного програмного потоку окремо. Таким чином, в один і той же час можуть виконуватися дві програми. Наприклад, поштова програмаможе надсилати або приймати повідомлення в фоновому режимі, поки користувач взаємодіє з інтерактивним додатком - тобто демон і програма користувача виконуються одночасно, начебто системі доступно два процесори.
Прикладні програми, що передбачають можливість виконання у вигляді кількох програмних потоків, можуть задіяти обидва «віртуальні процесори». Наприклад, програми редагування відеоданих зазвичай дозволяють користувачам застосовувати фільтри до всіх кадрів. Такі фільтри коригують яскравість, контраст, колірний баланс та інші характеристики кадрів. У такій ситуації програма може призначити один віртуальний процесор обробки парних кадрів, а інший - обробки непарних. При цьому два процесори працюватимуть абсолютно незалежно один від одного.
Оскільки програмні потоки звертаються до тих самих апаратних ресурсів, необхідна координація цих потоків. У контексті гіперпоточності розробники Intel виділили чотири корисні стратегії управління спільним споживанням ресурсів: дублювання ресурсів, а також жорстке, порогове та повне поділ ресурсів. Розглянемо ці стратегії.
Почнемо з дублювання ресурсів (resource duplication). Як відомо, деякі ресурси для організації програмних потоків дублюються. Наприклад, оскільки кожному програмному потоку потрібно індивідуальне управління, потрібен другий лічильник команд. Крім того, необхідно ввести другу таблицю відображення архітектурних регістрів (ЕАХ, ЕВХ тощо) на фізичні регістри; аналогічно, дублюється контролер переривань, оскільки обробка переривань для кожного потоку проводиться індивідуально.
Далі слідує методика жорсткого поділуресурсів (partitioned resource sharing) між програмними потоками. Наприклад, якщо у процесорі передбачена черга між двома функціональними ступенями конвеєра, то половину слотів можна віддавати потоку 1, іншу половину - потоку 2. Поділ ресурсів легко реалізується, не веде до дисбалансу та забезпечує повну незалежність програмних потоків один від одного. При повному поділі всіх ресурсів один процесор фактично перетворюється на два. З іншого боку, може скластися така ситуація, за якої один програмний потік не використовує ресурси, які могли б стати в нагоді другому потоку, але щодо яких він не має повноважень доступу. В результаті, ресурси, які в іншій ситуації могли б бути задіяні, простоюють.
Протилежність жорсткого поділу – повний поділ ресурсів (full resource sharing). У цій схемі до потрібних ресурсів може отримати доступ будь-який програмний потік, а вони обслуговуються в порядку надходження запитів на доступ. Розглянемо ситуацію, в якій швидкий потік, що складається переважно з операцій складання та віднімання, співіснує з повільним потоком, що реалізує операції множення та поділу. Якщо команди викликаються з пам'яті швидше, ніж виконуються операції множення та поділу, кількість команд, викликаних у рамках повільного потоку та поставлених у чергу на конвеєр, поступово зростатиме. Зрештою, ці команди заповнять чергу, в результаті швидкий потік через брак місця в ній зупиниться. Повний поділ ресурсів вирішує проблему неоптимального витрачання загальних ресурсів, але створює дисбаланс їх споживання - один потік може уповільнити чи зупинити інший.
Проміжна схема реалізується у межах порогового поділу ресурсів (threshold resource sharing). Відповідно до цієї схеми будь-який програмний потік може динамічно отримувати певний (обмежений) обсяг ресурсів. Стосовно реплікованих ресурсів цей підхід забезпечує гнучкість без загрози простою одного з програмних потоків через неможливість отримання ресурсів. Якщо, наприклад, заборонити кожному з потоків займати більше 3/4 черги команд, підвищене споживання ресурсів повільним потоком не завадить виконання швидкого.
Модель гіперпоточності Pentium 4 поєднує різні стратегії поділу ресурсів. Таким чином, робиться спроба вирішити всі проблеми, пов'язані з кожною стратегією. Дублювання реалізується щодо ресурсів, доступ яких постійно потрібен обох програмним потокам (зокрема, щодо лічильника команд, таблиці відображення регістрів і контролера переривань). Дублювання цих ресурсів збільшує площу мікросхеми лише на 5 % - погодьтеся, цілком розумна плата за багатопоточність. Ресурси, доступні в такому обсязі, що практично виключається можливість їх захоплення одним потоком (наприклад, рядки кешу), розподіляються динамічно. Доступ до ресурсів, що контролюють роботу конвеєра (зокрема, його численні черги), поділяється – кожному програмному потоку надається половина слотів. Головний конвеєр архітектури Netburst, реалізованої Pentium 4, зображений на рис. 8.7; білі та сірі області на цій ілюстрації позначають механізм розподілу ресурсів між білим та сірим програмними потоками.
Як бачимо, всі черги на цій ілюстрації розділені – кожному програмному потоку виділяється по половині слотів. Жоден із програмних потоків неспроможна обмежити роботу іншого. Блок розподілу та заміни також поділяється. Ресурси планувальника поділяються динамічно, але на основі якогось порогового значення - таким чином, жоден із потоків не може зайняти всі слоти черги. Для решти щаблів конвеєра має місце повний поділ.
Втім, із багатопоточністю не все так просто. Навіть така прогресивна методика має недоліки. Жорстке поділ ресурсів пов'язані з серйозними витратами, тоді як динамічний поділ, особливо з урахуванням порогових величин, вимагає відстежувати споживання ресурсів на етапі виконання. Крім того, в деяких випадках програми значно краще працюють без багатопоточності, ніж із нею. Припустимо, наприклад, що з двох програмних потоків для нормального функціонування кожному їх потрібно 3/4 кеша. Якби вони виконувалися по черзі, кожен показав би достатню ефективність при невеликій кількості кеш-промахів (як відомо, пов'язаних із додатковими витратами). У разі паралельного виконання кеш-промахів у кожного було б значно більше, і кінцевий результат виявився б гіршим, ніж без багатопоточності.
Додаткові відомості про механізм багатопоточності РепПіт 4 можна отримати в .

Розібравшись із теорією багатопоточності, розглянемо практичний приклад - Pentium 4. Уже етапі розробки цього процесора інженери Intel продовжували роботу над підвищенням його швидкодії без внесення змін у програмний інтерфейс. Розглядалося п'ять найпростіших способів:

Підвищення тактової частоти;

Розміщення однією мікросхемою двох процесорів;

Введення нових функціональних блоків;

Подовження конвеєра;

Використання багатопоточності.

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

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

Введення нових функціональних блоків також не становить складності, але тут важливо дотриматися балансу. Який сенс у десятці блоків АЛУ, якщо мікросхема не може видавати команди на конвеєр із такою швидкістю, що дозволяє завантажити всі ці блоки?

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

Нарешті, можна продати багатопоточність. Перевага цієї технології полягає у введенні додаткового програмного потоку, що дозволяє ввести в дію ті апаратні ресурси, які інакше простоювали б. За результатами експериментальних досліджень розробники Intel з'ясували, що збільшення площі мікросхеми на 5% при реалізації багатопоточності для багатьох програм дає приріст продуктивності на 25%. Першим процесором Intel з підтримкою багатопоточності став Хеон 2002 року. Згодом, починаючи з частоти 3,06 ГГц, багатопоточність була впроваджена в лінійку Pentium 4. Intel називає реалізацію багатопоточності Pentium 4 гіперпоточністю (hyperthreading).

Вступ. Комп'ютерна техніка розвивається швидкими темпами. Обчислювальні пристрої стають потужнішими, компактнішими, зручнішими, проте останнім часом підвищення продуктивності пристроїв стало великою проблемою. У 1965 році Гордон Мур (один із засновників Intel) дійшов висновку, що «кількість транзисторів, що розміщуються на кристалі інтегральної схеми, подвоюється кожні 24 місяці».

Перші розробки в галузі створення багатопроцесорних систем розпочалися у 70-х роках. Тривалий час продуктивність звичних одноядерних процесорів підвищувалася рахунок збільшення тактової частоти (до 80% продуктивності визначала лише тактова частота) з одночасним збільшенням числа транзисторів на кристалі. Фундаментальні закони фізики зупинили цей процес: чіпи стали перегріватися, технологічний став наближатися до розмірів атомів кремнію. Всі ці фактори призвели до того, що:

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

Багатопроцесорні системи (як один із способів вирішення проблеми) не отримали широкого застосування, тому що вимагали дорогих і складних у виробництві багатопроцесорних материнських плат. Виходячи з цього, продуктивність підвищувалася іншими шляхами. Ефективною виявилася концепція багатопоточності - одночасна обробка кількох потоків команд.

Hyper-Threading Technology (HTT) або технологія надпотокової обробки даних, що дозволяє процесору на одному ядрі виконувати кілька програмних потоків. Саме HTT, на думку багатьох фахівців, стала передумовою для створення багатоядерних процесорів. Виконання процесором одночасно кілька програмних потоків називається паралелізмом на рівні потоків (TLP-thread-level parallelism).

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

1. Загальні поняття

Архітектура у сенсі – це опис складної системи, що з безлічі елементів.

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

Мікропроцесор (або процесор) – це основний компонент комп'ютера. Він обробляє інформацію, виконує програми та керує іншими пристроями системи. Від потужності процесора залежить, наскільки швидко виконуватимуться програми.

Ядро – основа будь-якого мікропроцесора. Воно складається з мільйонів транзисторів, що розташовані на кристалі кремнію. Мікропроцесор розбитий на спеціальні осередки, які називаються регістрами загального призначення(РН). Робота процесора в загальній складності полягає у вилученні з пам'яті у певній послідовності команд та даних та їх виконанні. Крім того, для підвищення швидкодії ПК, мікропроцесор забезпечений внутрішньою кеш-пам'яттю. Кеш-пам'ять - це внутрішня пам'ятьпроцесора, що використовується як буфер (для захисту від перебоїв зі зв'язком з оперативною пам'яттю).

Процесори Intel, що використовуються в IBM – сумісних ПК, налічують понад тисячу команд і відносяться до процесорів із розширеною системою команд – CISC-процесорів (CISC – Complex Instruction Set Computing).

1.1 Високопродуктивні обчислення. Паралелізм

Темпи розвитку обчислювальної техніки легко простежити: від ENIAC (перший електронний цифровий комп'ютер загального призначення) з продуктивністю кілька тисяч операцій за секунду до суперкомп'ютера Tianhe-2 (1000 трильйонів операцій із плаваючою комою за секунду). Це означає, що швидкість обчислень збільшилася в трильйон разів за 60 років. Створення високопродуктивних обчислювальних систем – одне з найскладніших науково-технічних завдань. При тому, що швидкість обчислень технічних засобівзросла лише кілька мільйонів разів, загальна швидкість обчислень зросла в трильйони разів. Цей ефект досягнуто рахунок застосування паралелізму усім стадіях обчислень. Паралельні обчислення вимагають пошуку раціонального розподілу пам'яті, надійних способів передачі та координації обчислювальних процесів.

1.2 Симетрична мультипроцесорність

Symmetric Multiprocessing (скорочено SMP) або симетричне мультипроцесування – це особлива архітектура мультипроцесорних систем, де кілька процесорів мають доступом до загальної пам'яті. Це дуже поширена архітектура, що досить широко використовується останнім часом.

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

З огляду на перераховані вище особливості, SMP-системи застосовується виключно у науковій сфері, промисловості, бізнесі, вкрай рідко у робочих офісах. Крім високої вартості апаратної реалізації, такі системи потребують дуже дорогого та якісного програмного забезпечення, що забезпечує багатопоточне виконання завдань. Звичайні програми (ігри, текстові редактори) не будуть ефективно працювати в SMP-системах, так як у них не передбачена така міра розпаралелювання. Якщо адаптувати будь-яку програму для SMP-системи, вона стане вкрай неефективно працювати на однопроцессорных системах, що призводить до необхідності створення кількох версій однієї й тієї програми для різних систем. Винятком є, наприклад, програма ABLETON LIVE (призначена для створення музики та підготовка Dj-сетів), що має підтримку мультипроцесорних систем. Якщо запустити звичайну програму на мультипроцесорній системі, вона все-таки працюватиме трохи швидше, ніж в однопроцесорній. Це з так званим апаратним перериванням (зупинка програми обробки ядром), яке виконується іншому вільному процесорі.

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

Оскільки у процесорів загальна пам'ять, виникає необхідність раціонального її використання та узгодження даних. У мультипроцесорної системі виходить так, що кілька кешів працюють для ресурсу пам'яті, що розділяється. Сache coherence (когерентність кешу) – властивість кеша, що забезпечує цілісність даних, що зберігаються в індивідуальних кешах для ресурсу, що розділяється. Це поняття- окремий випадок поняття когерентності пам'яті, де кілька ядер мають доступ до загальної пам'яті (повсюдно зустрічається в сучасних багатоядерних системах). Якщо описати дані поняття загалом, то картина буде такою: той самий блок даних може бути завантажений у різні кеші, де дані обробляються по-різному.

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

SMP-системи є підгрупою MIMD (multi in-struction multi data - обчислювальна система з множинним потоком команд та множинним потоком даних) класифікації обчислювальних систем за Флінном (професор Стенфордського університету, співзасновник Palyn Associates). Відповідно до цієї класифікації, майже всі різновиди паралельних систем можна зарахувати до MIMD.

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

багатопроцесорних систем - multiprocessors (мультипроцесорні системи із загальною пам'яттю, що розділяється) і multicomputers (системи з роздільною пам'яттю). Загальні дані, які використовуються при паралельних обчисленнях, вимагають синхронізації. Завдання синхронізація даних – одна з найважливіших проблем, і її вирішення розробки багатопроцесорних і багатоядерних і, відповідно, необхідного програмного забезпеченняє пріоритетним завданням інженерів та програмістів. Загальний доступ до даних може бути зроблений за фізичного розподілу пам'яті. Цей підхід називається неоднорідним доступом до пам'яті (non-uniform memory access або NUMA).

Серед цих систем можна виділити:

• Системи де тільки індивідуальна кеш-пам'ять процесорів використовується для представлення даних (cache-only memory architecture).
• Системи із забезпеченням когерентності локальних кешів для різних процесорів (cache-coherent NUMA).
• Системи із забезпеченням загального доступу до індивідуальної пам'яті процесорів без на апаратному рівні когерентності кеша (non-cache coherent NUMA).

Спрощення проблеми створення мультипроцесорних систем досягається використанням розподіленої спільної пам'яті (distributed shared memory), проте цей спосіб призводить до значного підвищення складності паралельного програмування.

1.3 Одночасна багатопоточність

Виходячи з усіх вищеперелічених недоліків симетричної мультипроцесорності, має сенс розробка та розвиток інших способів підвищення продуктивності. Якщо проаналізувати роботу кожного окремого транзистора в процесорі, можна звернути увагу цікавий факт– за виконання більшості обчислювальних операцій задіяні далеко ще не всі компоненти процесора (згідно з останніми дослідженнями – близько 30% всіх транзисторів). Таким чином, якщо процесор виконує, скажімо, нескладну арифметичну операцію, то більшість процесора простоює, отже, її можна використовувати для інших обчислень. Так, якщо в даний момент процесор виконує речові операції, то у вільну частину можна завантажити цілу арифметичну операцію. Щоб збільшити навантаження на процесор, можна створити спекулятивне (або випереджувальне) виконання операцій, що потребує великого ускладнення апаратної логіки процесора. Якщо програмі заздалегідь визначити потоки (послідовності команд), які можуть виконуватися незалежно друг від друга, це помітно спростить завдання (даний спосіб легко реалізується на апаратному рівні). Ця ідея, що належить Діну Тулсену (розроблена ним 1955 р в університеті Вашингтона), отримала назву одночасної багатопоточності (simul-taneous multithreading). Пізніше вона була розвинена компанією Intel під назвою гіперпотоки (hyper threading). Так, один процесор, що виконує безліч потоків, сприймається операційною системою Windowsяк кілька процесорів. Використання цієї технології знову-таки вимагає відповідного рівня програмного забезпечення. Максимальний ефект застосування технології багатопоточності становить близько 30%.

1.4 Багатоядерність

Технологія багатопоточності – реалізація багатоядерності на програмному рівні. Подальше збільшення продуктивності, як завжди, потребує змін в апаратній частині процесора. Ускладнення систем та архітектур не завжди виявляється дієвим. Існує зворотна думка: "все геніальне - просто!". Дійсно, щоб підвищити продуктивність процесора зовсім необов'язково підвищувати його тактову частоту, ускладнювати логічну та апаратну складові, оскільки достатньо провести раціоналізацію і доопрацювання існуючої технології. Такий спосіб дуже вигідний - не потрібно вирішувати проблему підвищення тепловиділення процесора, розробку нового дорогого обладнання для виробництва мікросхем. Цей підхід і було реалізовано рамках технології багатоядерності – реалізація одному кристалі кількох обчислювальних ядер. Якщо взяти вихідний процесор і порівняти приріст продуктивності при реалізації кількох способів підвищення продуктивності, очевидно, що застосування технології багатоядерності є оптимальним варіантом.

Якщо порівнювати архітектури симетричного і багатоядерного мультипроцесора, то вони виявляться практично ідентичними. Кеш-пам'ять ядер може бути багаторівневою (локальною та загальною, причому дані з оперативної пам'яті можуть завантажуватися в кеш-пам'ять другого рівня безпосередньо). Виходячи з розглянутих переваг багатоядерної архітектури процесорів, виробники наголошують саме на ній. Дана технологіявиявилася досить дешевою в реалізації та універсальною, що дозволило вивести її на широкий ринок. Крім того, дана архітектура внесла свої корективи до закону Мура: «кількість обчислювальних ядер у процесорі подвоюватиметься кожні 18 місяців».

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