Стаття у Вікіпедії про EPIC вже окреслила багато небезпек, спільних для VLIW та EPIC.
Якщо хтось не вловлює почуття фаталізму з цієї статті, дозвольте мені виділити це:
Завантаження відповідей з ієрархії пам'яті, що включає кеші процесора та DRAM, не мають детермінованої затримки.
Іншими словами, будь-яка апаратна конструкція, яка не справляється з (*) недетермінованою затримкою доступу до пам’яті, просто стане вражаючою помилкою.
(*) "Впораючись з", необхідно досягти досить хороших показників виконання (іншими словами, "економічно вигідних"), що вимагає не дозволяти процесору простоювати на десятки до сотень циклів так часто.
Зауважте, що стратегія подолання, застосована EPIC (згадана у згаданій вище статті Вікіпедії), насправді не вирішує проблему. Це просто говорить, що тягар вказівки залежності даних тепер лягає на компілятор. Це добре; у компілятора вже є ця інформація, тому компілятору дотримуватися її просто. Проблема полягає в тому, що процесор все ще збирається працювати в режимі очікування на десятки-сотні циклів через доступ до пам'яті. Іншими словами, це зовнішньоекспертизу, але все ще не справляється з первинною відповідальністю.
Питання можна перефразовувати так: "Враховуючи апаратну платформу, яка судилася бути провальною, чому (1) не (2) не змогли автори-компілятори докласти героїчних зусиль, щоб викупити її?"
Я сподіваюся, що моє перефразування зробить відповідь на це питання очевидною.
Є другий аспект відмови, який також є смертельним.
Стратегії подолання (згадані в тій же статті) передбачають, що попереднє завантаження на основі програмного забезпечення може бути використане для відновлення принаймні частини втрати продуктивності через недетерміновану затримку доступу до пам'яті.
Насправді попереднє завантаження вигідне лише в тому випадку, якщо ви виконуєте потокові операції (читання пам'яті послідовно або дуже передбачувано).
(Однак, якщо ваш код робить частий доступ до деяких локалізованих областей пам'яті, кешування допоможе.)
Однак більшість програм загального призначення повинні робити безліч випадкових доступів до пам'яті. Якщо ми розглянемо наступні кроки:
- Обчисліть адресу, а потім
- Прочитайте значення, а потім
- Використовуйте це в деяких розрахунках
У більшості програмного забезпечення загального призначення ці три програми повинні виконуватися швидко. Іншими словами, не завжди вдається (в межах програмної логіки) обчислити адресу вперед або знайти достатню роботу, щоб заповнити стійла між цими трьома кроками.
Щоб пояснити, чому не завжди вдається знайти достатньо роботи для заповнення кіосків, ось як можна було б її уявити.
- Скажімо, для ефективного приховування кіосків нам потрібно заповнити 100 інструкцій, які не залежать від пам’яті (тому не буде страждати від додаткової затримки).
- Тепер, як програміст, завантажте будь-яке програмне забезпечення на ваш вибір у розбирач. Виберіть випадкову функцію для аналізу.
- Чи можете ви десь визначити послідовність із 100 інструкцій (*), які виключно не мають доступу до пам'яті?
(*) Якби ми могли коли-небудь зробити NOPкорисну роботу ...
Сучасні процесори намагаються впоратися з тим же самим, використовуючи динамічну інформацію - одночасно відстежуючи хід кожної інструкції під час їх циркуляції по трубопроводах. Як я вже згадував вище, частина цієї динамічної інформації обумовлена недетермінованою затримкою пам’яті, тому компілятори не можуть передбачити в якійсь мірі точності. Взагалі просто немає достатньої кількості інформації, яка була доступна під час збирання для прийняття рішень, які могли б заповнити ці місця.
У відповідь на відповідь AProgrammer
Справа не в тому, що "компілятор ... витягнути паралелізм важко".
Переупорядкування пам'яті та арифметичних інструкцій сучасними компіляторами є свідченням того, що у неї немає проблеми з ідентифікацією операцій, які є незалежними і, таким чином, одночасно виконуються.
Основна проблема полягає в тому, що затримка пам’яті без детермінації означає, що незалежно від того, «яке командування поєднується» для процесора VLIW / EPIC, в кінцевому підсумку буде зупинено доступ до пам'яті.
Оптимізація інструкцій, які не затримуються (лише для реєстрації, арифметики), не допоможуть у вирішенні питань щодо продуктивності, спричинених інструкціями, які дуже ймовірно зупиняються (доступ до пам'яті).
Це приклад неприйняття правила оптимізації 80-20: Оптимізація речей, які вже швидкі, не суттєво покращить загальну ефективність, якщо тільки не будуть оптимізовані повільніші речі.
У відповідь на відповідь Базиле Старинкевича
Це не "... (що завгодно) важко", це те, що EPIC є непридатним для будь-якої платформи, яка має затримуватися з високою динамічністю затримки.
Наприклад, якщо процесор має всі наступні дії:
- Немає прямого доступу до пам'яті;
- Будь-який доступ до пам'яті (читання або запис) повинен бути запланований за допомогою передачі DMA;
- Кожна інструкція має однакову затримку виконання;
- Виконання замовлення;
- Широкі / векторизовані одиниці виконання;
Тоді VLIW / EPIC буде добре підходити.
Де можна знайти такі процесори? DSP. І ось тут процвітав VLIW.
Зрештою, невдача Itanium (і продовження виливу науково-дослідних та дослідницьких робіт у невдачу, незважаючи на очевидні докази) є прикладом організаційного провалу і заслуговує на глибоке вивчення.
Звичайно, інші підприємства, такі як гіперточка, SIMD тощо, виявляються дуже успішними. Можливо, що інвестиції в Itanium, можливо, мали б збагачуючий вплив на майстерність його інженерів, що, можливо, дозволило їм створити наступне покоління успішної технології.