Вибір між програмованим процесором та апаратною реалізацією
роз’яснює Марко Джакобс, спеціаліст фірми Videantis
http://www.videantis.com/can-programmable-processors-really-be-smaller-than-hardwired-logic.htmlФірма Videantis поширює свій процесор v-MP6000UDX для виконання таких програм, як згортувальна нейронна мережа (CNN), задачі комп’ютерного зору та відеокодеки. Часто такі алгоритми реалізуються в спецпроцесорах з апаратною реалізацією. Інтуїтивно зрозуміло, що підхід з апаратною реалізацією призводить до набагато менших апаратних витрат і менших енерговитрат. Але в Videantis вивчали багато проектів і виявили, що часто відбувається зворотне: використання процесора призводить до менших апаратних витрат та меншої споживаної потужності, ніж з використанням апаратної реалізації. Далі роз’яснюються причини такого феномену.
Високе завантаження апаратури
Перша причина, за допомогою якої програмований процесор може призвести до меншого за апаратурою рішення, полягає в тому, що виконувані у процесорі команди набагато більше використовують апаратуру повторно. Часто це називають повторним використанням кремнію, тобто, транзисторних схем, які реалізовані в поверхні кремнієвого кристалу.
При апаратній реалізації кожна функція в спецпроцесорі стає окремою індивідуальною схемою. При використанні програмованого процесора кожна функція просто стає деякою підпрограмою, яка знаходиться в пам’яті. Ця підпрограма потім може бути виконана на процесорі, надаючи процесору практично необмежену функціональність. Чим складніше алгоритм, який слід реалізувати, тим ефективнішим стає підхід на основі програмованого процесора, порівняно з його реалізацією в жорсткій логіці. Наприклад, просто неможливо апаратно впровадити всі засоби ОС Android.
Темний кремній на рівні завдання
Повторне використання кремнію відбувається на різних рівнях. Наприклад, багато процесорів, які вбудовані у мобільних телефонах, містять апаратні прискорювачі для кодування та декодування відеопотоків. Вони часто є окремими блоками, і в більшості випадків одночасно використовують лише один з кількох блоків. При цьому блок, який є незавантаженим, не споживає потужності. Про нього кажуть, що його кремній є темним, тобто, він не світиться у інфрачервоному діапазоні. Отже, наявність темного кремнію свідчить про неефективне використання апаратних ресурсів.
Крім того, вказані спецпроцесори повинні підтримувати багато стандартів кодування відео. Оскільки одночасно можна використовувати тільки один стандарт, схеми, які підтримують неактивні стандарти кодування, також мають темний кремній.
Темний кремній на рівні блоків
Також явище темного кремнію відбувається на нижчих рівнях реалізації алгоритмів. Візьмемо, наприклад, процесор обробки вхідного відеопотоку, який часто використовується в комп’ютерному зорі для відстеження руху камери і об’єктів, що знаходяться в полі зору. Обробка відеопотоку зазвичай є лише невеликою але важливою частиною алгоритму комп’ютерного зору. Алгоритм спочатку знаходить набір ознак, характерних точок на зображенні, які можна відстежувати. Потім він відстежує ці точки від кадру до кадру, намагаючись знайти відповідність між кадрами.
Цей алгоритм залежить від даних: деякі сцени матимуть тисячі характерних точок, а деякі — дуже мало. Сцена дерева з листям має дуже багато характерних точок. А якщо відеокамера дивиться на білу стіну або на блакитне небо, то таких точок буде мінімум. У цих випадках у спецпроцесорі з жорсткою логікою схеми узгодження характерних точок мають або відстежувати тисячі характерних точок, або, можливо, не виконують ніякої роботи, оскільки таких точок немає.
Цей дисбаланс призводить до темного кремнію. Іноді схеми максимально завантажені, іноді вони вимикаються. У випадку, якщо алгоритм реалізований програмно, при відсутності цих характерних точок процесор негайно звільняється для виконання наступного завдання, що навантажується на нього диспетчером.
Повторне використання пам’яті
Ще однією областю, де є багато можливостей для повторного використання апаратури, є пам’ять. Багато спецпроцесорів виконані з декількох модулів, кожен з яких має свій власний блок пам’яті. У процесорах обробки зображень та глибокого навчання це буфери FIFO, або буфери, які зберігають фрагменти зображень. Ці буфери розподілені по усьому процесору і не можуть бути використані повторно між різними модулями, оскільки кожен модуль має свої власні вимоги до розміру масиву, формату даних і пропускної здатності.
При використанні програмованого процесора існує природня ієрархія пам’яті з блоків пам’яті, які вбудовані в мікросхему, а також часто зовнішньої пам’яті. Виділення пам’яті, з’ясування, яким даним призначити певні адреси, робиться в програмному забезпеченні і часто виконується компілятором. При розробці спецпроцесора це завдання виконується один раз на папері на етапі проектування. А у випадку програмної реалізації це завдання виконується в програмному забезпеченні, частково автоматизованим компілятором, і може з часом регулюватися і оптимізуватися. Як наслідок, при процесорній реалізації існує набагато більше можливостей повторного використання пам’яті, що знову призводить до зниження потужності та менших апаратних витрат.
Колесо реінкарнації
Ідеї спеціалізованих процесорів розроблялись протягом останніх восьмидесяти років. Сатерленд і Меєр запропонували важливу ідею більше 50 років тому у своєму творі “Про розробку процесорів для дисплеїв” (http://cva.stanford.edu/classes/cs99s/papers/myer-sutherland-design-of-display-processors.pdf).
У ньому описано цікаве спостереження про природу розробки апаратури:
«Поступово процесор став більш складним. Ми не були стурбовані цим, тому що комп’ютерна графіка, зрештою, є складною. Нарешті, процесор дисплея нагадував повноцінний комп’ютер з деякими особливими графічними функціями. І тоді сталася дивна річ. Ми відчули, що треба додати до процесора другий, допоміжний процесор, який сам по собі став зростати за складністю. Саме тоді ми виявили тривожну істину. Розробка процесора для відображення графіки може стати нескінченним циклічним процесом. Насправді ми побачили, що цей процес настільки розчаровуючий, що ми вирішили назвати його “колесом реінкарнації”».
Тільки коли ці автори кілька разів крутонули це колесо, вони зрозуміли, що відбувається. Як тільки вони це зробили, вони спробували розглянути всю проблему з більш широкої перспективи. Це хороший приклад того, як вони робили компроміси між апаратними засобами та процесорами ще 50 років тому.
Оптимізація на різних рівнях абстракції
Оптимізація проекту відбувається на різних рівнях. На вищих рівнях вибирається архітектура програми, вибираються алгоритми і структури даних. На нижньому рівні оптимізація виконується при розробки схем, виборі системи команд і операцій. Така оптимізація залежить від процесорної платформи, тоді як зміни на більш високому архітектурному рівні та рівні алгоритмів є незалежними від платформи.
Оптимізація, що відбувається на вищих рівнях абстракції, зазвичай має більший вплив на продуктивність, ніж вибір реалізації на нижчому рівні. Наприклад, зміна алгоритму зі складністю O(n2) на алгоритм з O(n) може мати величезний вплив на продуктивність. Оскільки жорстке апаратне проектування відбувається на нижчому рівні абстракції, зазвичай на оптимізацію на рівні алгоритму витрачається мало зусиль.
Реалізація в програмному забезпеченні, що працює на процесорі, виконується на вищому рівні, надаючи гнучкість для реалізації більш широкого спектру способів оптимізації. Знову ж таки, ця зміна фокусу призводить до зниження сподиваної потужності та збільшення продуктивності реалізації на основі процесора.
Тривалість розробки
Іншим аспектом є тривалість розробки, якої завжди не вистачає. Більш трудомісткою є розробка схем апаратних засобів, ніж розробка програмного забезпечення. Тому розробники апаратних засобів почали використовувати нові засоби, такі як високогорівневий синтез, які генерують схеми з файлів на C / C++. Це дозволило розробникам отримати більші об’єми розробленої апаратури за рахунок менш ефективних реалізацій.
Завдяки підходу, що базується на процесорах, оптимізація виконується на двох рівнях: сам процесор з часом може бути оптимізований, зберігаючи незмінність архітектури системи команд. Це дає змогу тому самому програмному забезпеченню працювати на реалізаціях тої самої архітектури, які є вдосконаленими, більш швидкими або з меншими за апаратурою і з меншим енергоспоживанням. Крім того, для оптимізації програмного забезпечення доступно більше часу, оскільки для впровадження програмного забезпечення в порівнянні з розробкою апаратних схем потрібно менше часу.
Натомість, повністю апаратна реалізація візуальних обчислювальних алгоритмів і застосунків часто буває роздутою і має глибоку переробку протягом багатьох років.
Отже, спецпроцесор на жорстких логічних схемах може бути набагато меншим, ніж програмований процесор. У випадку, якщо потрібно, наприклад, просто помножити вхідний 16-бітний сигнал на постійний коефіцієнт, такий спецпроцесор буде набагато меншим, ніж при використанні підходу на основі програмованого процесора з його загальними блоком множення, пам’яттю команд, дешифратором команд, які можна вважати накладними витратами.
Але якщо застосунок є суттєво складнішим, наприклад, система, яка працює з різними мережами глибокого навчання, повноцінним кодуванням відео або стеками комп’ютерного зору, то ретельно продуманий програмований процесор, оптимізований для візуальних обчислень, може привести до проекту, який забезпечує більше відношення продуктивність на ватт і більше відношення продуктивності на долар вартості мікрсхеми.
15-річний досвід фірми Videantis показує, що застосунки на базі програмованих процесорів є дуже економічними як за вартістю так і енергоспоживанням і регулярно обходять апаратні прискорювачі за цими ключовими показниками, залишаючись при цьому програмованими, що є ключовим у сфері візуальних обчислень, де алгоритми та застосунки швидко змінюються.