Проект "пульс": (описание идеи)
| Вид материала | Программа |
- Программа «Школа волонтеров Пульс», 453.36kb.
- Проект посвящен вопросам эксплуатации кц-1 кс «Игринская», 23.57kb.
- Как начинается проект?, 59.12kb.
- Настоящий Проект перспективного развития школы на 2011-2015 годы продолжает основные, 711.77kb.
- Тематическое планирование уроков в 7 классе, 894.98kb.
- Описание современной модели доступного и качественного образования в Хабаровском крае, 55.82kb.
- Конкурс инновационных проектов «Новый Алтай», 29.46kb.
- Анализ требований к проекту сайта (см табл. 9) 18 Согласование выработанной идеи проекта, 590.25kb.
- В. А. Заботина Утверждаю Начальник своуо в. Г. Кобозева Положение конкурс, 38.14kb.
- Программа производства и сбыта Формирование каналов сбыта продукции. Разработка мероприятий, 1030.06kb.
Рис. 10 Отображение графа G(Q,X) в матричную мультимикроконвейерную структуру
Поэтому более перспективным направлением считается проектирование РВС на основе архитектуры мультимакроконвейерных структур с программируемой логикой (рис. 11). Суть которого состоит в том, чтобы создать архитектуру вычислительной системы, способную реконфигурировать свою структуру к графу алгоритма. При этом, функции коммутации перекладываются с процессоров, как в выше рассмотренном случае, на отдельную коммутационную структуру. В отличие от однородных вычислительных сред, авторы данной концепции предложили строить процессорный узел в виде некоторого множества элементарных многоразрядных процессоров, объединенных полнодоступной коммутационной шиной. При этом, как и в предыдущем случае, процесс решения задачи сводится к организации мультиконвейерных цепочек, отображающих информационный граф решаемой задачи.
Основными вычислительными блоками в мультимакроконвейерной РВС являются макропроцессоры, представляющие собой набор некоторого числа элементарных процессоров, объединенных в единый вычислительный ресурс с помощью локального коммутатора. Элементарные процессоры, в отличие от стандартного микропроцессора, не управляют процессом обработки информации, а лишь реализуют операции над поступающими на их входы операндами. В свою очередь, макропроцессоры реализуют крупные операции, предписанные вершинам информационного графа. В каждый момент времени макропроцессор может реализовать одну макрооперацию. Незадействованные в макрооперации элементарные процессоры будут простаивать. Для реализации всего информационного графа макропроцессоры объединяются с помощью системного коммутатора (коммутатора второго уровня) в единую параллельно-конвейерную структуру.
Таким образом, совокупность вычислительных структур, созданных в рамках базовой архитектуры РВС, образуют виртуальный проблемно-ориентированный вычислитель, структура которого адекватна информационному графу решаемой задачи. При этом считается, что именно при таком подходе будет достигнута реально высокая производительность вычислительной системы на широком классе задач, а также почти линейный рост производительности при увеличении числа процессоров. Правда, говоря о широком классе задач, как на мое мнение, разработчики РВС немного льстят себе. Потому что изначально такие системы позиционировались для решения исключительно параллельных задач, да и то - потоковых. При том, что подавляющее число практических приложений представляют собой сложную иерархию параллельно-последовательных меняющихся во времени процессов.
Реализация идеи реконфигурируемых МВС долгое время сдерживалось отсутствием подходящих компонент. Появления в конце 90-х годов XX века программируемых логических интегральных схем сверхвысокой степенью интеграции вдохнуло в идею второе дыхание. Микросхемы ПЛИС представляет собой матрицу логических ячеек (FPGA – Field Programmable Gates Array), путем программирования и коммутации которых можно создавать аппаратные реализации различных структур, причем перепрограммирование допускается многократно.
Вот, пожалуй, и вся идея организации архитектуры программируемых реконфигурируемых вычислительных структур. Она является основополагающей и лежит в основе всех РВС различных типов. Отличие подходов заключается лишь в той или иной степени детализации конвейерной ступени, а также в том или ином способе реконфигурирования связей между ними. Поэтому для дальнейших рассуждений понимания рассмотренной сути представляемой идеи вполне достаточно.
Рис. 11 Архитектура мультимакроконвейерной РВС с программируемой логикой.
Тем не менее, изначально красивая идея оказалась труднореализуемой. И главным источником преткновения стал факт того, что число операционных вершин в графе алгоритма практически любой реальной задачи пользователя оказывается значительно больше числа макропроцессоров в мультиконвейере. Поэтому информационные графы больших задач не могут быть целиком отображены в имеющемся аппаратном ресурсе РВС.
Именно на разрешение этой проблемы и была направлена львиная доля усилий исследователей и разработчиков. Для этого информационный граф всей задачи предлагается сегментировать на фрагменты – непересекающиеся базовые подграфы, физически реализуемые в аппаратуре РВС. Размер подграфа выбирается таким образом, чтобы ресурсов системы было достаточно для его структурной реализации. В таком случае решение большой задачи выполняется структурно-процедурным способом, при котором на аппаратный ресурс поочередно отображаются базовые подграфы всего информационного графа. Весь процесс назван "структурно-процедурным" оттого, что вычисления в соответствии с отображенным подграфом выполняются структурно, а смена подграфов выполняется процедурно.
И опять-таки, за внешне привлекательной идеей организации структурно-процедурного способа обнаружилось множество подводных камней. Так, многокритериальное разрезание графа G(Q,X) на подграфы оказалось достаточно непростым процессом. В свою очередь, и процесс отображения каждого подграфа Gi(Qi,Xi) в мультиконвейер также оказался нетривиальной задачей. Требующей, к тому же, организации механизма сохранения результатов обработки каждого подграфа в некоторой промежуточной памяти. Соответствующих аппаратных ресурсов требует и механизм формирования очереди подграфов.
К тому же, не вызывает сомнения, что применение структурно-процедурного метода замедляет скорость обработки данных, поступающих на вход мультиконвейера. Ведь регулярной перезагрузки кадров в кристалл ПЛИС просто не избежать. Как выход из создавшейся ситуации разработчиками РВС предложен механизм накопления векторов входных данных в пакеты, которые затем уже поступают на вход структуры. Но и в таком случае вполне реальной может сложиться ситуация, когда время подготовки вычислений станет соизмеримым и даже заметно превышающим время самих вычислений! До боли знакомая картина, уже наблюдаемая в архитектурах универсальных ЭВМ с жесткими межпроцессорными связями.
Как метод уменьшения зависимости от частой перезагрузки кадров было предложено организовывать отдельные микросхемы программируемой логики в большие решающие поля. В этом случае все вычислительные и коммутационные структуры задачи разворачиваются не в отдельной микросхеме ПЛИС, а во всем решающем поле. Однако реализация такой идеи также потребовала немалых аппаратных ресурсов.
В то же время, построение больших решающих полей на ПЛИС требует преодоления ряда проблем. Одна из которых – это негативный эффект границ, возникающих на стыках отдельных ПЛИС при их объединении в решающее поле.
Еще одной, не менее важной проблемой, выступает конструкторско-технологическое ограничение на размещение ограниченного числа ПЛИС на печатной плате приемлемого размера. Что решается путем модульного построения аппаратуры. В свою очередь, введение модульного принципа построения аппаратуры порождает проблему нового типа границ – межмодульного. И т.д., и т.п.
III. Архитектура традиционной машины потоков
Рассмотрение архитектуры потоковой машины является не менее прекрасным материалом, позволяющим, в конечном итоге, показать всю красоту идеи схемной эмуляции применительно к теме создания мультипроцессорных суперЭВМ.
Но прежде, неплохо было бы понять – а зачем вообще нужны машины потоков? И зачем мировое сообщество так много сил и средств тратит на исследовательские работы в этом направлении?
А причина – известна практически каждому. Это все более растущее понимание того, что так называемая архитектура фон Неймана, которая до сих пор лежит в основе всех компьютеров, становится все большим тормозом на пути роста их функциональных возможностей и дальнейшего увеличения вычислительной мощности. Можно сказать, что суть назревшего кризиса кроется в несоответствии архитектуры современных компьютеров и идеологией современного программирования.
Одним из альтернативных направлений по созданию высокопроизводительных вычислительных систем стала разработка машин потоков данных.
Особенностью таких систем является возможность выполнения операций по мере готовности операндов. В вычислительных системах потоков данных выглядит естественным использование большого числа процессоров, что дает возможность параллельно выполнять множество готовых к выполнению операций.
Модель потока данных отменяет главные атрибуты модели фон Неймана: счетчик команд, глобальную обновляемую память и единый тракт, соединяющий процессор с памятью - которые сужают использование параллелизма. А поскольку я уже декларировал, что Система Эмуляции по своей сути есть потоковая машина, то прекрасной возможностью еще раз показать преимущества новой идеологии - это провести сравнительный анализ архитектуры, основанной на принципах схемной эмуляции с архитектурой традиционной потоковых машины.
Функциональная схема традиционной машины потоков данных приведена на рис. 12
Рис. 12 Функциональная схема машины потоков данных (чистого потока).
Если кратко, то можно сказать, что в архитектуре машин потоков данных отсутствует понятие "пассивная память", а в языке потоков данных нет понятия "переменная": данные перемещаются из команды в команду по мере выполнения программы. Кроме того, не используются понятия "передача управления", "счетчик команд" и "ветвление вычислительного процесса". Вместо этого команды (операторы) управляются данными.
Считается, что команда готова к выполнению, если данные присутствуют в каждом из ее входных портов и отсутствуют в выходном. Выполнение команды приводит к исчезновению данных в ее входных портах и появлению результата в выходном порте. Благодаря такому правилу срабатывания модель потока данных является асинхронной. Кроме того, она является самопланируемой, так как установление последовательности выполнения команд зависит только от готовности данных. Таким образом, поток управления аналогичен потоку данных между различными командами.
В результате программа потока данных может быть представлена в виде направленного графа, состоящего из именованных узлов, которые обозначают команды, и дуг, которые обозначают зависимости по данным между этими командами.
Подходящим математическим описанием для такого графа является аппарат сетей Петри.
Выходной порт одной команды соединен с входным портом другой команды. Таким образом, порядок выполнения команды определяется не счетчиком команд, а движением потока данных в командах.
Можно сказать, что приказ выполнить следующую команду в архитектуре фон Неймана здесь заменен на разрешение ее выполнить. Таким образом, в потоковой машине реализуется идея перехода от повелительного наклонения к изъявительному.
Значения данных распространяемых по дугам графа в форме пакетов данных, называются токенами. Считается, что узел активируется, как только токены появляются на его входных дугах и нет ни одного токена на его выходных дугах.
Машина потоков данных работает следующим образом. Если ячейка команды располагает всеми необходимыми входными токенами, она посылает командный пакет в селекторную сеть. Последняя направляет пакет к свободным блокам выполнения операции или принятия решения. Разница между этими блоками заключается в том, что результатом работы блока выполнения операции являются данные (полученные, например, при реализации операции сложения или умножения), а результатом работы блока принятия решений - управляющая информация (логическая величина).
В ходе выполнения командного пакета создаются один или несколько пакетов результата (по одному для каждого адресата), которые пересылаются в распределительную или управляющую сеть.
Налицо два уровня параллелизма вычислений. Один уровень определяется наличием множества команд, одновременно готовых к выполнению и доступных для параллельной обработки многими процессорами. Другой уровень определяется прохождением этих команд и их результатов через сети, которые сами в большой степени обладают свойством параллелизма функционирования.
Еще одним свойством машины потоков данных является высокая степень однородности логической структуры машины. Уже ячейка команды содержит значительную часть различных элементов, определяющих структуру машины в целом. Каждая ячейка включает запоминающее устройство и логические схемы проверки состояния готовности команды к выполнению.
Схема машины потоков данных, конечно, производит впечатление своей регулярностью и красотой идеи, если бы только не ряд принципиальных недостатков, низводящих первоначальную "красоту" практически на нет. А именно:
1) Как оказалось, непосредственная реализация компьютеров в соответствии с моделью чистого потока данных оказалась трудно реализуемой задачей. Потому простая и красивая с виду идея реально не заработала. И все дальнейшее ее развитие проводилось и проводится в направлении все большего усложнения исходной модели, что довело ситуацию до того, что в реально работающих прототипах не осталось и намека на красоту идеи, представленной на рис. 12.
Кроме того, все это если и может быть сегодня реализовано в оборудовании, то крайне ущербным и частным способом. В частности, самый ключевой элемент такой машины – память – должна иметь встроенный механизм инициализации выборки первых команд, чтобы машина начала работу, а также сложные схемы записи и считывания. Каждая ячейка должна включать схемы проверки состояния готовности команд к выполнению, А поскольку такую проверку должны выполнять все ячейки одновременно, то память должна быть ассоциативной.
2) Не смотря на всю критику "узкого горлышка" в машине команд (канал "память – микропроцессор"), машина потоков также не смогла избавиться от него. Более того, достаточно глянуть на схему рис. 12, чтобы увидеть, что количество портов к памяти даже увеличилось.
И это все притом, что с возложением на память активного принципа работы ее устройство значительно усложнилось, а значит, время обработки одного операнда – увеличилось.
3) В традиционной машине потоков данных перевод команд в состояние готовности к выполнению производится независимо от того, доступны или нет их адресаты. Таким образом, команда может быть выполнена и пакет ее результата послан в распределительную сеть до того, как команды-получатели будут способны принять его.
Поэтому, с целью синхронизации пакетов, во все сети машины (селекторную, управляющую и распределительную) пришлось вставить буферы, обеспечивающие временное хранение пакетов. А поскольку количество токенов, ожидающих выборку, может быть очень большим, то может требоваться память большого объема. Из-за отсутствия локальности трудно оценить вероятность появления требуемого для выборки токена, поэтому в системах потока данных создание кэша токенов, которые будут выбраны в ближайшее время, является весьма проблематичной задачей.
Для того, чтобы двухместная команда могла быть запущена на исполнение, необходимо иметь два токена – результата предшествующих команд. Первый токен хранится в памяти ожидания и совпадения, тем самым, представляя «пузырь» (bubble) в исполнительном конвейере машины потока данных. Команда запускается только тогда, когда прибывает второй токен. Исследования показали, что пузыри в конвейере составляли 28,75% времени исполнения программы коммивояжера.
Пакеты, "висящие" в буфере сети будут препятствовать продвижению других пакетов. Большое число пакетов, пребывающих в таком состоянии, и может привести к блокировке сети.
4) Машина потоков данных подвержена также эффекту "взрывного параллелизма". Взрывной параллелизм - это чрезмерно высокий параллелизм, возникающий в системах потока данных, для использования которого ресурсов машины недостаточно. Причиной этому является параллельное выполнение программы, которое требует гораздо больше ресурсов, чем последовательное выполнение.
Для устранения подобного явления в функциональную схему машины потоков вводят дополнительные узлы, обеспечивающие принудительную синхронизацию токенов, в соответствии с определенным принципом. Для чего разработан большой теоретический аппарат и множество схем его реализации.
Вы будете смеяться, но тема взрывного параллелизма и разработки аппаратно-программных средств его регулирующих является в настоящее время одной из сложнейших задач теории и практики потоковых машин, над разрешением которой работают светлейшие умы США и Великобритании, не забывая тратить, при этом, миллионы долларов ежегодно на зарплату, проекты и содержание своих лабораторий.
Классно устроились "ребята"! В особенности если вспомнить, что, взяв на вооружение идею схемной эмуляции, они давно бы построили самую лучшую потоковую машину. Вы спрашиваете, почему тогда этого не сделал я? … так мне на мои проекты никто и рубля не дал! А своих средств хватило пока только на "освоение" темы АСУ ТП.
5) Не меньшей проблемой остался и вопрос программирования машины потоков данных. Языки графического описания программ, вроде языка Денниса, являющимися производными от сетей Петри – подходят разве что для демонстрации их работы. Поэтому естественным выглядит употребление языков, предполагающих представление программ потоков данных, в более привычном для программиста виде – в форме последовательности операторов, подчиняющихся определенному синтаксису такого языка.
Но каждый раз узким местом для машин потока данных оказывалось несоответствие стиля программ, требуемого для них, тем стилям, к которым привыкли программисты.
6) Главный принцип организации сетей потоков данных гласит, что каждый узел графа (команды) может иметь не более двух входных дуг (токенов).
Причина такого изначального ограничения ясна – ведь любой граф потом надо иметь возможность "всунуть" в структуру существующих ЭВМ путем перевода его в последовательность машинных команд. А, как известно, основополагающий принцип программирования предполагает наличие в структуре команды не более двух полей операндов, поскольку регистровые структуры любого процессора не рассчитаны для работы с большим их числом.
Все это априори уменьшает функциональную мощность графических языков программирования для машин потоков.
7) Используемые для обработки машинные команды являются низкоуровневыми.
Поэтому, вполне естественным выглядит использование в архитектуре машины потоков данных упрощенных процессорных элементов. Это – так называемые RISC процессоры с сокращенным набором команд.
Однако, в таком случае, без особо глубоких подсчетов становится очевидным, что на выборку каждой команды, ее "блуждание" по сети и обратную запись в память, понадобиться время даже значительно большее, чем непосредственно время исполнение в каком – либо из процессоров!
8) Окончательно "добило" идею чистого потока явное несоответствие парадигмы современных языков программирования и структуры машины потоков, в которой органически не оказалось места для оперирования совокупностью такими данными, как массивы и структуры.
Пришлось разработчикам в исходную модель вставлять новые модули - устройства хранения и обработки структур со сложной (и до сих пор не завершенной идеей) архитектурой, включающего в себя память, распределительную и селекторную сеть и т.д.
Заканчивая рассмотрение традиционной архитектуры машины потоков можно сказать, что не смотря на большое число исследований, которые были направлены на развитие идеи в течение длительного времени, эти машины до сих пор так и не нашли коммерческого применения. Более того, лично у меня сложилось впечатление, что интерес исследователей к этой архитектуре уже иссяк.
А все оттого, что имелась тенденция не создавать что-либо оригинальное "с нуля", а довольствоваться совершенствованием имеющегося: разработка архитектура машины потоков отталкивалась от совершенствования архитектуры фон Неймана.
IV. Архитектура машины потоков, построенной на принципах схемной эмуляции
Итак, выше были рассмотрены недостатки традиционных архитектур мультипроцессорных машин и показано, что ограничения их идеологии носят системный характер. Отчего развитие архитектурных решений основанных на принципах фон Неймана близится к пределу. Показано, что регулярность вычислительной структуры еще не является залогом ее высокой производительности на широком классе задач. Необходимым условием увеличения производительности для широкого класса задач следует считать также возможность реконфигурации вычислительной системы, чтобы граф G* вычислительного процесса как можно ближе совпадал с графом G решаемой задачи.
Тем не менее, разработка альтернативных архитектур, к которым можно отнести потоковые машины и реконфигурируемые вычислительные структуры, пока не дала должного результата. Что, главным образом, находит пояснение в труднореализуемости проектов и даже высокой степенью сложности программирования таких систем.
Представляемая на суд читателя статья является, по сути, первой попыткой заявить вслуг, что нет смысла и дальше бороться с "ветряными мельницами". Потому что на самом деле есть другой путь – более дешевый, эффективный, надежный и доступный каждому! И, к тому же, свободный от каких-либо системных "болезней". Путь, который почему-то совершенно выпал из поля зрения идеологов и разработчиков вычислительных систем, имя которому – моделирование.
Я преднамеренно выше, при рассмотрении идеи несовпадения графов задачи и исполняющей системы, в разделе посвященным описанию архитектуры реконфигурируемых вычислительных структур, выделил жирным курсивом слово "моделирует", потому что все идеологи архитектур его видят (и пишут про него), но при этом всеми силами с ним борются, выбрав за основу развития – реконфигурацию. Притом, как оказалось, путь тернистый, усеянный множеством трудноразрешимых преград.
Целью данной статьи есть стремление показать, что именно идея моделирования, предварительно развитая автором до понятия эмуляции алгоритмов и систем, обладает поразительной возможностью к развитию. Она открывает альтернативный подход к проектированию вычислительных систем, основанный на том, что заниматься реконфигурированием их среды каждый раз заново от задачи к задаче – как раз и не нужно! Достаточно только один раз "заточить" ее под структуру авторского модуля схемной эмуляции, а потом просто эмулировать задачи пользователей, элементарно загружая их в уже подготовленную среду. В этом случае отпадает всякая необходимость ценой неимоверных аппаратно-программных усилий стремиться подогнать структуру вычислительной системы (S*) к структуре пользовательской задачи (S), потому что в среде эмуляции мы уже непосредственно работаем с исходным информационным графом задачи пользователя (G). Предлагаемый подход прост в реализации и совершенно свободен от недостатков, которыми в избытке наделены абсолютно все известные архитектуры, включая и реконфигурируемые вычислительные структуры.
Именно соединение этих двух компонент – авторского модуля схемной эмуляции (реализованного на принципах многопоточности), и матрицы вентильных массивов (как устройства параллельного действия), открывает широчайшие возможности для создания действительно принципиально новой вычислительной среды – системы эмуляции задач пользователей, представленных в графическом виде.
В соответствии с идеологией системы эмуляции, модуль схемной эмуляции, по сути, выполняет функцию системы исполнения задач пользователей, представленных в графическом виде.
Уровень представления задач здесь допускается самый разный: от графов, сетей, алгоритмов и специальных языков графического программирования - до функциональных и структурных схем. В конце концов – это может быть принципиальная схема электронного устройства, реализующего некий алгоритм. Поскольку в теории реконфигурируемых систем отталкиваются от такого уровня как графы алгоритмов, то и я в рамках данной статьи привяжусь именно к этому уровню. Да и пронаблюдать сравнительный анализ двух архитектур в этом случае будет значительно проще.
Исполнить задачу в системе эмуляции – означает эмулировать (имитировать поведение в режиме реального времени и реальной среды окружения) графический рисунок пользователя, в соответствии с тем, как сам пользователь мог бы представить его работу в своем воображении. Только модуль эмуляции сделает это точно и без ошибок. Красота идеи состоит в том, что при этом пользователю не нужно браться за паяльник, чтобы реализовать свою задачу аппаратно, или пытаться реализовать ее программным способом.
Вообще говоря, возможность реализовать алгоритмы аппаратными или программными способами издавна называется дуализмом (Э.Э. Клингман). До сегодняшнего дня развитие технических систем проходило именно в соответствии с этим принципом. Идея схемной эмуляции впервые открывает пользователю новый (третий) путь реализации его проектов – просто имитацией их поведения в принципиально новой среде – среде графического исполнения, основанной на принципах схемной эмуляции.
Могу с уверенностью сказать, что разработанный и программно реализованный мною алгоритм, по сути, открывает новый класс программных продуктов – программ схемной эмуляции.
Странно, но даже сама идея "не браться за паяльник, а эмулировать разработанные системы (в том числе алгоритмы) почему-то до сих пор обходит умы исследователей и разработчиков.
Особенностью архитектуры системы эмуляции, построенной на основе кристалла ПЛИС, есть то, что в распоряжение пользователя предоставляется не "голый" кристалл, который ему еще каким-то образом необходимо запрограммировать. А такой, в котором рабочая область уже предварительно "отформатирована" структурой модуля эмуляции, и в которую пользователю достаточно только загрузить описание графической схемы своей задачи.
Поскольку целью данной статьи есть стремление донести идею применения принципов схемной эмуляции к вопросу создания альтернативной вычислительной среды, то на рис.13 такая среда представлена на уровне функциональной схемы без привязки к структурам конкретных комплектующих каких-либо производителей.
Рис. 13 Функциональная схема машины потоков, построенной на принципах схемной эмуляции.
Тем не менее, за основу принимается, что базовым элементом такой архитектуры является микросхема программируемой логики. Потому что именно соединение принципа многопоточности авторского модуля схемной эмуляции с принципом параллельного действия ПЛИС позволяет создать принципиально новую вычислительную среду параллельного действия.
В то же время, высокая степень регулярности представляемой структуры, позволяет использовать различные варианты ее реализации, предоставляя тем самым разработчикам широкое поле деятельности при поиске наиболее оптимальной конфигурации на этапе опытно-конструкторских работ. На рис. 13 показаны три варианта реализации авторской идеи, которые, тем не менее, органично дополняют друг друга даже в пределах одной структуры.
Работа в новой системе представляется следующим образом.
Изначально, пользователь, находясь в среде графического редактора (установленного на ПК), рисует граф алгоритма своей вычислительной задачи. После окончания этапа рисования, специальный программный модуль "сворачивает" рисунок проекта в так называемый файл описания схемы (ФОС), который и загружается в рабочую область эмуляции кристалла ПЛИС, уже предварительно "отформатированного" структурой модуля эмуляции. Модуль эмуляции разворачивает в рабочей области эмуляции программную модель схемы проекта.
Именно на уровне программной модели происходит эмуляция (имитация) работы схемы задачи пользователя.
Модуль эмуляции, с учетом динамики протекающих в программной модели процессов, порождает в матрице FPGA множество потоков. Под процессами здесь подразумется волны изменения значений идентификаторов в ветвях программной модели рисунка задачи пользователя. Потоки – это реальные сигналы в матрице FPGA. В соответствии с идеологией системы эмуляции одному процессу может соответствовать некоторое множество потоков.
Одна часть потоков "существует" исключительно в рабочей области эмуляции и не выходит за ее пределы, назовем их внутренними. Предназначены они для обеспечения функционирования самой модели. Другая часть потоков, для которой необходимо выполнение каких-либо арифметических или логических операций, предписанных вершинами графа задачи, посредством концентратора SW перенаправляются в свободные исполнительные процессоры (Исполнительный процессор 1 – Исполнительный процессор N). Назовем такие потоки внешними. Каждый внешний процесс несет на себе необходимые операнды и номер (код) операции, и возвращает результат операции в рабочее поле эмуляции. Исполнительные процессоры, как и макропроцессоры для случая РВС, не управляют процессом обработки информации, а лишь реализуют операции над поступающими на их входы операндами.
Существенным отличием представляемой архитектуры от идеологии реконфигурируемых вычислительных структур является то, что здесь исполнительные процессоры ни коим образом не привязаны к вершинам графа задачи пользователя.
В соответствии с идеологией системы эмуляции, в каждый момент времени каждый из исполнительных процессоров может быть занят обработкой данных, поступивших на его входы вместе с любым внешним потоком. Поэтому в функциональном плане они должны быть абсолютно идентичными, то есть, каждый должен быть способным выполнить операцию, предписанную любой вершине графа задачи. Правило выбора процессора потоком простое: поток, посредством сетевого концентратора, выбирает первый же исполнительный процессор, который не занят обработкой данных какого-либо другого протока.
Со времен появления первых компьютеров стало очевидным, что для каждого уровня технологического развития практически единственным путем увеличения мощности вычислительной системы является соединение энного числа процессоров в единую "упряжку", то есть создание мультипроцессорной системы. Казалось бы, что может быть проще: превратить однопроцессорную машину в многопроцессорную путем добавления на платформу некоторого числа точно таких же процессоров. Однако на практике все оказалось гораздо сложнее и добавление в систему даже одного процессора может уменьшить производительность системы. Ведь в этом случае разработчик сталкивается с принципиально новым явлением – информационным и алгоритмическим взаимодействием процессоров. И здесь важнейшим аспектом, связанным с эффективностью работы вычислителя, начинает выступать организация межпроцессорного обмена служебными потоками, а также проблемы распараллеливания и синхронизации информационных потоков самой задачи. В свою очередь, поддержание всего этого требует немалых аппаратных усилий. Все это привело к тому, что современные процессора превратились в сложнейшие устройства, в которых вспомогательные узлы - т.н. опережающей выборки команд, условных ветвлений, блоков синхронизации и т.д. – занимают на кристалле значительно больше места, чем непосредственно само арифметико-логическое устройство.
Идея реконфигурируемых вычислительных структур, казалось бы, могла стать достойным ответом на проблему. Но, как выяснилось, она оказалась не только сложнореализуемой, но даже использование такой системы превратилась в достаточно нетривиальную задачу. К тому же, такой ответ оказался не вполне достаточным и потому, что наилучшим образом подходит только для решения потоковых задач. Поэтому говорить о широком классе задач при работе с такой структурой не приходится.
В противоположность выше сказанному я с уверенностью могу утверждать, что идея использования системы эмуляции в основе вычислительной структуры, впервые открывает простейший путь соединения любого числа процессоров (платформ) в единую "упряжку", потому что никакого взаимодействия процессоров здесь просто нет. Вся работа по организации этих процессов переносится на уровень программной модели задачи пользователя, что, в свою очередь, позволяет использовать в системе процессора с элементарной внутренней архитектурой.
Все что требуется в такой структуре от процессора для организации мультипроцессорности – это подать в сетевой концентратор сигнал готовности, после того как операнды, попавшие на его входы вместе с потоком, обсчитаны и результат возвращен в рабочее поле эмуляции.
Такая система самым оптимальным образом подходит для решения как параллельных, так и параллельно-последовательных задач. При том, что генерация всех процессов в программной модели, их взаимная синхронизация, а также, разделение ресурсов программной модели между любым числом процессоров происходит автоматически.
Представляемая вычислительная структура, основанная на принципах схемной эмуляции, по сути, есть ни что иное, как машина потоков. Однако главное отличие ее от архитектур традиционных потоковых машин состоит в том, что в ней порядок операций, предписанный вершинами графа задачи, определяется не готовностью данных, а информационными потоками в программной модели задачи пользователя. К слову будет сказать, что именно это отличие, главным образом, и освобождает представляемую мною архитектуру от массы проблем, сопутствующим традиционным потоковым архитектурам. И от неразрешимости которых, те до сих пор так и не получили развития дальше экспериментальных образцов.
Архитектура машины потоков, построенная на принципе схемной эмуляции, позволяет эффективно разрешить проблему "узкого горлышка" (канал "память – микропроцессор"), которая до конца не решена даже для потоковых машин с традиционной архитектурой. Напомню, что там каждый пакет в момент записи результата по ячейкам команд-адресатов захватывает всю память. В то время как другие пакеты находятся в состоянии ожидания. Ассоциативный принцип действия памяти (вот для чего нужна ассоциативность!), конечно, существенно ускоряет данную процедуру, но не отменяет ее. Мультипроцессорная система, построенная на принципах схемной эмуляции, свободна от этого недостатка, потому что, как об этом уже не раз говорилось, центральным местом архитектуры системы эмуляции является программная модель пользовательского проекта, основанная на принципах многопоточности. В среде аппаратной реализации авторского модуля эмуляции – микросхемы программируемой логики – такая многопоточность трансформируется в потоки непересекающихся сигналов, каждый из которых посредством сетевого концентратора (являющегося по своей природе также устройством параллельного действия) "находит" свободный процессорный элемент.
Главный дирижер всех процессов в представляемой архитектуре – программная модель, в которой непосредственно все потоки и порождаются, и уничтожаются. Поэтому в представляемой архитектуре отсутствуют такие узлы, присущие традиционным архитектурам потоковых машин, как память ожиданий и совпадений, буферов хранения пакетов, блоков выполнения операций или блоков принятия решений и т.д. и т.п. Машина потоков, основанная на принципах схемной эмуляции, свободна от таких недостатков, упомянутых выше, как блокировка сети или взрывной параллелизм.
Фундаментальным отличием представляемой идеологии от идеологии РВС состоит в том, что от понятий "структура" и "реконфигурация" мы переходим к оперированию понятиями – "эмуляция" и "рисунок задачи". В соответствии с идеологией системы эмуляции, модуль схемной эмуляции, по сути, выполняет функцию системы исполнения задач пользователей, представленных в графическом виде.
Этапы "программирования" и исполнения в представляемой архитектуре полностью согласованы. "Общим знаменателем" такой согласованности выступает работа с графическим образом проекта, как на этапе проектирования, так и на этапе исполнения. Для машины потоков, построенной на принципах схемной эмуляции, представление проектов в графическом виде является единственно допустимым и естественным способом. Поэтому процесс ее "программирования" до безобразия прост: начинается он с прорисовки графа задачи в среде графического редактора, а заканчивается загрузкой файла описания схемы задачи в саму платформу одним кликом мышки.
Традиционные архитектуры потоковых машин (как и машин фон Неймана) не приспособлены для исполнения графических образов проектов и поэтому требуют возврата к программным кодам, что и является источником семантического разрыва между аппаратной частью традиционных вычислительных систем и парадигмой современного программирования.
Вычислительная структура, основанная на принципах схемной эмуляции, является более однородной, чем структуры РВС. Как видно на рис. 13, в ней можно четко выделить три области: рабочую область эмуляции, сетевой концентратор и блоки исполнительных процессоров. Увеличение степени однородности открывает широкие возможности по увеличению функциональной мощности базовой структуры.
Описание работы представляемой вычислительной системы, приведенное выше, касалось только части всей функциональной схемы – базовой структуры. В нем были задействованы следующие узлы: рабочая область эмуляции, концентратор SW и модуль исполнительных процессоров ИП 1-ИП N. Если принять, что все они находятся в пределах одного кристалла микросхемы программируемой логики, то такую архитектуру смело можно назвать закрытой.
Современный уровень интеграции ПЛИС позволяет при реализации структуры РВС размещать на кристалле порядка 100 макропроцессоров. В системе эмуляции большую часть ресурсов кристалла займет рабочее поле эмуляции. Поэтому обобщенная оценка показывает, что оставшихся его ресурсов окажется достаточным для реализации всего лишь с десяток исполнительных процессоров. Естественно, что такого их количества явно недостаточно для полноценного обслуживания всех порожденных программной моделью внешних потоков. В этом случае, потоки, которым не хватит свободных ИП, будут переходить в состояние ожидания. Благо, произойдет это на уровне программной модели и поэтому никаких аппаратных затрат в виде разного рода буферов памяти здесь не потребуется.
Не вызывает сомнений, что имеющегося числа ИП в такой структуре можно считать более чем достаточным при реализации какой-нибудь системы управления (например, бортового компьютера), но никак не суперЭВМ. Очевидно, что уменьшить влияние притормаживания потоков на скорость решения задач пользователей можно только увеличением числа ИП в системе. Разрешить проблему нехватки ресурсов одного кристалла ПЛИС поможет все та же однородность структуры системы эмуляции. Для этого, внешние потоки с выхода сетевого концентратора SW вместо внутреннего блока исполнительных процессоров следует перенаправить в Блок Портов низкоскоростного последовательного ввода-вывода. При этом сам модуль исполнительных процессоров необходимо будет переместить в отдельные корпуса ПЛИС. При таком варианте реализации структуры, каждый из внешних потоков будет использовать соответствующий порт как транзитный узел.
На реализацию рассмотренного варианта может накладываться ограничение только одним фактором – ограничением по числу внешних контактов микросхемы ПЛИС, которые могут быть задействованы под реализацию данной конфигурации.
Разрешить проблему нехватки контактов можно достаточно простым способом, использовав вместо блока низкоскоростных портов один порт высокоскоростного обмена (Порт 2). Такой порт должен иметь в своем составе буфера памяти, принимающие в себя информацию от каждого потока, и непосредственно узел высокоскоростного обмена. Понятно, что в этом случае и сам модуль исполнительных процессоров должен иметь в своем составе аналогичный порт.
Рассмотренные варианты структуры системы эмуляции, в которых использован внешний модуль исполнительных процессоров назовем открытой.
Здесь к слову будет сказать, что вычислительная система, построенная на принципах открытой структуры обладает широкими возможностями к развитию. Например, она позволяет в качестве исполнительных процессоров использовать обычные (к примеру - RISC) коммерчески доступные микропроцессорные кристаллы.
В рассмотренной выше функциональной схеме использование такого узла как сетевой концентратор (SW) также несет высокую идейную нагрузку. Дело в том, что в современных архитектурах вычислительных структур (не исключением которых стали как потоковые машины, так и реконфигурируемые вычислительные структуры) широкое применение находят сетевые коммутаторы (Hab). Конечно, реализация такого устройства требует меньших аппаратных ресурсов, однако его принципиальным недостатком является жесткий принцип действия. Это значит, что в момент программирования в его структуре может быть реализована только одна схема коммутации. И замена старой схемы на новую потребует очередного перепрограммирования. Принципиальным отличием концентратора есть то, что по своей сути он является устройством параллельного действия. Это значит, что в каждый момент времени такое устройство в состоянии обеспечить гибкую коммутацию любого числа непересекающихся (не имеющих коллизий) активных каналов.
Таким образом, соединение во едино двух упомянутых компонент – авторского модуля схемной эмуляции (построенного на принципах многопоточности) и сетевого концентратора (как устройства параллельного действия) придает вычислительной структуре абсолютную степень параллельности, а также высокую степень гибкости, которая, в свою очередь, служит источником различных структурных вариаций.
Тем не менее, принцип многопоточности модуля эмуляции – это, на самом деле, только первое важное его свойство. Другим, не менее важным свойством, следует считать высокую степень поддержки идеологии т.н. распределенного управления систем (Distributed Control System). Что, в свою очередь, позволяет на самом высоком уровне обеспечить высокую степень масштабируемости структуры.
Это означает, что если ресурсов одной микросхемы программируемой логики окажется недостаточным для загрузки в нее всего файла описания схемы, то достаточно будет всего лишь разбить последний на нужное число фрагментов (частей). Притом, сделать это автоматически, находясь в среде графического редактора схем. А после этого каждый фрагмент загрузить в отдельный кристалл. Понятно, что размер фрагмента выбирается из такого расчета, чтобы ресурсов одного кристалла ПЛИС стало достаточно для загрузки одного фрагмента ФОС.
Положительный эффект здесь достигается тем, что объединение фрагментов задачи пользователя осуществляется не на физическом уровне кристаллов программируемой логики (как в случае РВС), а на уровне программной модели всей задачи. Именно модули схемной эмуляции, прошитые в структурах матриц программируемой логики, выступают теми цементирующими кирпичиками, которые связывают всю систему воедино. Поэтому таким "хроническим" проблемам, присущих РВС, как "негативный эффект границ" и др. в представляемой архитектуре просто нет места.
Для целей аппаратной поддержки принципа масштабируемости в структуру системы эмуляции (рис. 13) служит порт (Порт 1) низкоскоростного обмена потоками. В соответствии с идеологией системы эмуляции считается, что в этот порт направляются потоки (Q), образованные как раз на местах "разрезания" файла описания схемы. Чтобы организовать обмен такими потоками между всеми кристаллами ПЛИС, необходимо все выводы микросхем, соответствующих упомянутым портам, соединить между собой посредством внешнего сетевого концентратора (концентратора II уровня).
Здесь резонно может возникнуть вопрос – а причем тут масштабируемость и зачем ее поддерживать? А все дело в том, что идеология системы эмуляции свободна от такого понятия как структурно-процедурный метод решения задачи и требует, чтобы проект пользователя загружался в систему целиком до начала исполнения (эмуляции).
Поэтому выглядит естественным, что при решении больших практических задач может возникнуть ситуация, которую и придется "исправлять" путем добавления в систему некоторого числа точно таких же кристаллов ПЛИС. Тем не менее, пользователю совершенно даже не придется браться за паяльник.
Как уже говорилось, широкие возможности к развитию системы эмуляции и регулярность ее структуры служит надежной базой для реализации различных структурных вариаций. Все это открывает перед разработчиками широчайшие возможности по разработке оптимальной конфигурации базовых конструктивных модулей. Я лично больше склоняюсь к мнению, что применение принципов схемной эмуляции к вопросу проектирования суперЭВМ приведет к разработке двух основных типов модулей (платформ): модуля рабочей области эмуляции и модуля исполнительных процессоров, в каждом из которых количество микросхем программируемой логики будет подобрано оптимальным образом.
Таким образом, пользователю предоставляется возможность простым добавлением базовых платформ на общее шасси наращивать вычислительную мощность всей системы до любого практически необходимого уровня и, что не менее важно, мощность такой системы будет расти практически линейно числу добавляемых платформ. Притом, что использование такой системы обеспечит наивысшую производительность при решении действительно любых классов задач.
Осталось только ответить на последний чисто практический вопрос – каким образом "программировать" реальные системы, содержащие в себе сотни, тысячи или даже миллионы вершин в графе проекта? Ведь никакой такой граф не вместится не только в формат монитора (графического редактора), но даже в воображении разработчика. Для этого случая само-собой напрашивается по крайней мере три способа:
Первый способ - использовать методы схемотехнического проектирования электронных устройств. В этом случае графический проект задачи пользователя сначала прорисовывается на укрупненном уровне функциональной схемы, а затем каждый "кубик" детализируется до уровня структурных схем. При этом, вложенность детализации может достигать многих уровней.
Второй способ – использовать методы разработки больших и сверхбольших интегральных микросхем. В этом случае пользователь описывает проект на уровне поведения – с помощью специального языка программирования. Затем специальный графический компилятор по текстам такого описания автоматически генерирует рисунок проекта.
С понятием графической компиляции мы уже сталкивались в самом начале статьи, когда говорилось, что в средах современных SCADA- систем происходит переход от графического представления проекта пользователя к программным операторам. Правда, там имела место быть операция обратная той, о которой мы говорим сейчас.
Третий способ - спроектировать специальный графический компилятор, который, просматривая программу пользователя (представленную в виде обычных программных текстов, написанных с использованием какого-либо известного языка программирования), – "на выходе" будет генерировать графический образ проекта.
В заключении хотелось бы отметить, что представляемая в данной статье система эмуляции прошла успешную апробацию на практических внедрениях в области разработки систем автоматизации на PC- платформах и самым полным образом подтвердила свою работоспособность.