AMD Bulldozer: чи чекати революції?

admin Статті про hardware

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

Анонс нових процесорів AMD Bulldozer ("Бульдозер") вийшов неоднозначним. У коментарях і оглядах панує повний скепсис. Тести показують відсутність значущого підвищення ефективності в порівнянні з попередньою архітектурою К10 в перерахунку на одиничне ядро. Довгоочікувана архітектура процесорів від AMD викликала загальне розчарування. А даремно. Непоміченим залишилося головне: в архітектурі процесорних систем AMD застосувала абсолютно новий спосіб підвищення продуктивності.

Щоб зрозуміти суть революційних змін в архітектурі нового процесора AMD, потрібно абстрагуватися від результатів конкретних тестів. Ніхто не сперечається - технологія сира. Але не будемо з водою викидати немовля: головне - концепція.

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

Процесор AMD Bulldozer

Раніше за продуктивність боролися трьома способами: нарощували кількість ядер в процесорі, підвищували число команд, що виконуються за одиничний такт, або збільшували тактову частоту, впираючись в тепловій пакет на рівні 130-150 Ватт.

Bulldozer рушив іншим шляхом. У боротьбу за підвищення продуктивності вступила багатопотокова обробка команд. Виникло нове поняття: "тісно пов'язані обчислювальні ядра", або, ще коротше, "процесорний модуль".

І ось з цього місця детальніше почну, хоч і популярно.

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

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

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

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

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

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

Як боротися з цією бідою? Та дуже просто: є пов'язані обчислювальні потоки, значить, за асоціацією, потрібно зробити тісно пов'язані обчислювальні ядра для їх ефективної обробки. Бульдозер вибрав цей шлях.

Нещодавно з'явилася ще одна область обчислювальних задач, на яких явно застосовуються тісно пов'язані обчислювальні потоки, - віртуалізація. У ній використовуються пов'язані обчислювальні потоки типу "хост-завдання".

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

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

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

Звичайно, сучасне програмне забезпечення неможливо реалізувати потенціал архітектури "Бульдозера". Використання залежних процесорних модулів у незалежних обчислювальних потоках буде тільки погіршувати результуючу продуктивність системи. Але вже анонсована підтримка даної архітектури в Windows 8, і це дає, за попередніми оцінками фахівців, близько п'ятнадцяти відсотків продуктивності. Навіть для такої елементарної оптимізації на рівні диспетчера потоків ОС. Якщо ж заточити під цю архітектуру віртуальні машини і компілятори, тоді до цих відсотках можна сміливо приписувати ще один нуль ...

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

До речі, на зорі архітектури К10 бродили чутки про те, що AMD збирається впровадити багатопоточність в це ядро, причому ця гіпотетична технологія красномовно називалася "антігіпертредінг" (Anti HyperThreading). Тепер зрозуміло, чому. Мабуть, на той момент концепція ще не дозріла, а тепер, схоже, настав її час.

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

Залишається загадкою: спочатку автори даної архітектури припускали подібне використання свого дітища, чи це вийшло у них випадково? Типу того, як Колумб плив до Індії, а відкрив Америку?