Що таке виконання поза замовленням?

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

Від субскалярного до суперскалярного

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

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

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

Підтримка конвеєрів, що живляться даними

Основною проблемою продуктивності комп’ютерів зазвичай є затримка пам’яті. Багато інструкцій працюють з даними, тому ці дані повинні бути доступними для виконання інструкції. Питання полягає в тому, що ви робите, якщо вам потрібно дочекатися цих даних, оскільки вони не відразу доступні? Традиційно відповіддю було просто зупинитися та дочекатися, поки він стане доступним. Це залишає весь конвеєр порожнім, потенційно для сотень циклів ЦП. Ситуація стає ще гіршою, коли дві інструкції в паралельних конвеєрах повинні чекати пам’яті, оскільки перша затримає навіть запит на дані другої. Хоча кеш-пам’ять процесора може допомогти вирішити цю проблему, вона все одно не може її вирішити. Для її вирішення потрібна була нова парадигма. Цією зміною парадигми стало «виконання поза замовленням» або OOO.

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

Критичні залежності

Цей процес передбачає дві речі. Перш за все, що можна надійно ідентифікувати і обробляти справжні залежності. По-друге, ви можете надійно обробляти та ідентифікувати помилкові залежності. Яка різниця? Що ж, справжня залежність — це залежність, яку взагалі неможливо пом’якшити в системі OOO. Найпростішим прикладом є читання після запису. Якщо у вас є одна інструкція, яка має записати деякі дані, а інша — прочитати ці дані, неможливо змінити порядок цих інструкцій. Їх потрібно заповнювати в тому порядку, в якому вони були представлені, інакше ви отримаєте безглузді дані.

Помилкова залежність – це залежність, яку можна приховати іншим хитрим прийомом. Візьмемо для прикладу запис-після-читання. На перший погляд ви можете подумати, що ви не можете перезаписати дані, поки не прочитаєте їх. Проте все не так просто. Що, якщо у вас є інше місце, де ви можете записати нові дані, а потім ви можете просто поміняти місцями нові та старі дані, коли старі дані будуть прочитані? Це процес перейменування реєстру, і він є критичним для обробки OOO.

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

Висновок

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