Ієрархія в багатопроцесорних системах
Азин С.М.
Розглядається
апаратний механізм управління процесорної матрицею і створення логічних
внутрішніх і зовнішніх потоків даних у багатопроцесорної структурі.
Описується
обчислювальна система (НД) з розподіленою пам'яттю, яка складається з
довільної кількості абсолютно ідентичних, примітивних фон Неймановскіх
процесорів (далі елемент) з простим набором команд і повної сторінкою
пам'яті (наприклад, 64кб для 16-розрядного процесора). Система має структуру
ієрархічної піраміди. Один з елементів є основним або провідним
( "імператор"), він має канали програмного, прямого доступу до пам'яті
(ПДП) всіх елементів нижнього ярусу, вони, в свою чергу, маючи аналогічні
канали, розподіляють між собою управління наступним ярусом і т.д. до самого
низу піраміди, по цих каналах відбувається завантаження програм і даних. Маючи
доступ до регістрів управління підлеглого елемента, командир може звертатися
до пам'яті всіх нижніх елементів до підніжжя піраміди, минаючи безпосередніх
командирів. Наявність ПДП дає командиру повну владу над підлеглим, наприклад,
щоб зупинити виконання програми досить встановити пастку у вектор
переривання і викликати його і, замінивши пастку новим покажчиком, запустити іншу
програму. Командний елемент може спостерігати за роботою програми підлеглого
елемента, наприклад, зчитуючи значення покажчиків буферів або стека і навіть
допомагати йому, взявши частину навантаження на себе. Система має вихід назовні каналу
ПДП на згадку "імператора" для первинного завантаження системи,
характерна відсутність якої б то не було незалежній пам'яті, не потрібен
навіть початковий завантажувач, достатньо щоб всі елементи стартували з команди WAIT.
Механізм ПДП повинен мати апаратну систему змінних пріоритетів, щоб
ізолювати програмне ядро від несанкціонованих дій зовнішньої програми.
Більше того, максимальний пріоритет зовсім забороняє ПДП (наприклад, у
"імператора") при цьому система стає недоступною для
стороннього втручання - вірусів, несанкціонованого клонування і т.п.,
в цьому випадку відкрити систему можна тільки "вбивши" її вимиканням
харчування.
Вийшов
простий і зручний механізм управління будь-якою кількістю елементів, але на самому
справі це нічого не означає тому, щоб система запрацювала, потрібно написати
для неї програму і завантажити (вважати) дані. Тут постає філософське питання,
чому паралельні обчислення практично обмежуються конвеєрами і
матрицями з жорстким алгоритмом (мережеві обчислювачі в розрахунок не беремо тому
ефективність їх близька до нуля)? Причина, по всій видимості, в тому, що людина
не здатний створювати паралельні програми, синхронізувати 3-4 процесу --
це межа його можливостей. Ідея полягає в тому, що програміст повинен
працювати не з послідовністю операцій, а оперувати взаємозв'язками
потоків, тоді він може писати хоч на Бейсіку або Фортране, маючи на увазі під
змінними - потоки даних. Потоки даних можуть бути зовнішніми, наприклад,
оцифрований сигнал з мікрофона, відео сигнал або магістральний канал
оптичного волокна, і внутрішніми, наприклад, мантиса числа з плаваючою
комою. При описі потоку досить визначити два його параметри, тип числа
(наприклад, int або float) і його інтенсивність (кількість байт в одному значенні
поділене на періодичність у тактах системи). Якщо, наприклад, задані два потоки
А-int і В-long, то при зв'язку B = sinA, інтенсивність потоку В в два рази більше
А. Тут потрібна обчислювальна система, здатна легко створювати достатню
кількість таких потоків, встановлювати зв'язки між ними і самостійно
погоджувати їх інтенсивності. Для отримання безлічі потоків Кращий час
використовувати стробоскопічний загальний канал (ОК). За допомогою установки регістрів
управління, програмується його циклічність і кожному потоку (й елементу)
призначаються тайм-слоти з цього циклу для читання або запису, як це робиться в
телекомунікаційних каналах зв'язку. Через один промінь каналу можна пропускати
скільки завгодно потоків, все визначається розмірами циклу. Ясно, що ОК не може
бути нескінченно довгим через обмежену навантажувальної здатності. Назвемо
сегментом елементарний фрагмент піраміди, що складається з декількох елементів з
одним командиром і об'єднаних одним ОК, кількість елементів у сегменті одно
навантажувальної здатності ОК. В ідеалі сегмент розташований на одному чіпі. Для
зв'язки з іншими сегментами не обов'язково виводити ОК назовні сегмента, просто
одного або кількох елементів призначаються функції вузлів зв'язку. Вузол зв'язку
відрізняється від інших елементів тільки тим, що його інтерфейсні регістри
підключені не до каналів ПДП нижнього ярусу і не до множинного потоку даних,
а до аналогічних регістрів сусідніх сегментів. Як з'єднувати, це окремий
питання, я думаю найкраще зверху в низ по піраміді паралельно ПДП, щоб
диспетчеризацією потоків займалися сегменти верхнього рівня. Тоді
просторове підключення ОК сегментів можна реалізувати у вигляді: паралельних
каналів, грати, зірки, дерева і т.д., в залежності від вимог алгоритму.
Завданням вузлів зв'язку є сортування та переадресація потоків. Якщо застосувати
класифікацію Фліна, то ОК виконує функції одиночного потоку даних, а
елементи - множинного потоку команд. Всі елементи нижнього ярусу піраміди,
крім вузлів зв'язку, мають вільними виходи своїх інтерфейсних регістрів, до
яких підключається множинний двонаправлений потік даних, це будь-які
зовнішні пристрої, архівна пам'ять, диски, термінали, канали зв'язку і т.д. Є
ще один момент, припустимо, навантажувальна здатність ОК дорівнює 10, значить у
сегменті 10 елементів. Нехай для простоти, за один такт ОК елемент виконує
одну команду і кожному елементу призначено по одному тайм-слоту, значить цикл
дорівнює 10 тактів. Виходить, що кожен елемент може виконати цикл тільки з
10 команд, цього явно недостатньо для більшості завдань. Тому не має
сенсу гнатися за швидкістю каналу, до речі, при зменшенні швидкості ОК
збільшується його навантажувальна здатність, тут є оптимум.
Узгодити
швидкості програмних процедур і потоків, завдання не реальна, тому між ними
в кожному елементі повинні бути еластичні кільцеві буфера типу
"черга". Досить двох таких буферів, один для всіх вхідних
потоків і один для вихідних, вони займають всю вільну пам'ять елементу. Дані
в буфері однозначно прив'язані до даних каналу, тому немає необхідності
вживати якісь дії для їх ідентифікації, але при переході до іншого
сегмент, це не очевидно. Ця проблема лежить на совісті програмістів, які
будуть реалізовувати ядро системи. Можна в лоб перерахувати індекси при переході,
можна забезпечити потоки синхронізуючими мітками, а можна індекси передавати в
потоці разом з даними.
Принциповою
і специфічною особливістю даної системи реального часу є те, що
вона повинна працювати швидше надходження даних, інакше відбудеться переповнення
буферів і збій. Цю ситуацію можна виявити заздалегідь, якщо командир виявить
накопичення даних в буфері одного з елементів (це може бути переривання по
переходу червоної зони), у нього є якийсь час, щоб уникнути збоїв. У
цьому випадку необхідно або зупиняти завдання і перекомпоновивать систему,
або вирішувати проблему під час виконання, наприклад шляхом підключення резервних
елементів.
Швидкості
потоків даних, у принципі, обмежені тільки фізичними можливостями каналу,
оскільки завжди можна організувати стробоскоп з кількох елементів, які
будуть по черзі брати (виставляти) дані з каналу. Збільшуючи кількість
елементів у стробоскопи легко досягти граничних швидкостей. Більш того, якщо
канал не задовольняє вимогам по швидкості, достатньо зробити
стробоскопічний комутатор і розподілити потік між паралельними
структурами. Цей спосіб застосовується також для оптимізації обробки потоків,
тобто, щоб не простоювали короткі процедури, довгі запускаються через
стробоскоп, стробоскоп може бути тимчасовим, тобто маючи кілька резервних
елементів, можна підключати їх до відстаючим процедур під час виконання.
Є декілька варіантів організації конвеєрів типу конвеєра арифметики
плаваючою.
Піраміда
НД не обов'язково повинна бути правильної форми, і може мати відгалуження
довільної висоти і ширини (навіть віддалені, наприклад, з оптичного волокна)
і взагалі може бути спроектована з урахуванням виконуваного завдання, тут
відкривається великий простір для фантазії, наприклад, N 1 мірна піраміда з N
ортогональними ОК. Рівень інтелектуальних можливостей системи залежить від
висоти піраміди, а продуктивність від ширини, тому що ядро працює у верхніх
шарах, а основне завдання в основі. Ядро займається завантаженням, плануванням,
розбором конфліктів підлеглих і статистикою їх завантаженості. У завдання ядра
входить також тестування нд - визначення конфігурації конкретної системи і
виявлення та ізоляція дефектних елементів. Ядро НД, на відміну від UNIX,
працює у фоновому режимі, окрім чисто командних елементів, в яких основна
завдання взагалі не виконується.
Очевидно,
що робота в реальному часі сильно економить оперативну пам'ять. Коли обробляється
початок великого сегменту даних, кінець може взагалі не знадобитися і вантажити
його в свопінг або пам'ять, по крайней мере, не економно. Аналогічно з
додатками, якщо додаток виконав левову частку своєї роботи і крутитися в
малому циклі упорядкування даних, більша частина програмного коду вже (або
ще) не потрібна і, як результат, нікому не потрібні сторінки гуляють по системі
між кешем, пам'яттю, свопінг і файловою системою. Одноуровневая пам'ять
AS/400 намагається півзаходами частково вирішити ці проблеми, але навіщо для цього
городити город з 64-х розрядної адреси. У нашому випадку ця ситуація
відстежується повністю, оскільки всі процедури активні, перебувають під
спостереженням ядра і завжди можуть відрапортувати - "Завдання виконано, чекаю
вказівок або перезавантаження ". У певному сенсі, розбивка додатків на
процедури аналогічно розбиття сегмента на сторінки або файлу на кластери.
Крім того, потрібно зауважити, що багатозадачні операційні системи типу UNIX,
які непогано справляються з проблемами баз даних і секретарів, є
гальмом для цілого ряду вельми актуальних завдань - завдання управління в реальному
масштабі часу, завдання штучного інтелекту, машинного зору і т.д.
В
заключении хочу підкреслити, що система команд елемента повинна бути
максимально простий, фактично це інтелектуальна сторінка пам'яті. Ніяких
команд множення і ділення, тим більше плаваючої арифметики не вимагається,
оскільки нічого не варто досягти будь-якій швидкості обчислень простий
перекомпонування елементів, до того ж вигідно комбінувати відразу весь комплекс
обчислень, а не окремі арифметичні дії. При цьому виходить велика
економія в операціях, наприклад, досить однієї операції нормування на весь
комплекс, при цьому усувається накопичена помилка. До того ж ви можете працювати
з будь-яким числом плаваючою комою, а не з числом процесора плаваючою
арифметики. Орієнтація на режим реального часу накладає специфічні
вимоги на конструкцію процесорного елемента, наприклад, марність стека
і вкладених переривань, замість стека доцільно мати апаратні еластичні
буфера. Є деякі міркувань з приводу системи команд і реєстрового
архітектури елемента з двома стробоскопічним ОК, селектірованим каналом ПДП
із захистом за пріоритетами і двома еластичними, кільцевими буферами замість
апаратного стека, але це тема окремої розмови.
Список літератури
Для
підготовки даної роботи були використані матеріали з сайту http://www.sciteclibrary.ru
