Система графического программирования-исполнения, построенная на принципах схемной эмуляции

И опять-таки, за внешне привлекательной идеей организации структурно-процедурного способа обнаружилось множество подводных камней. Так, многокритериальное разрезание графа 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- платформах и самым полным образом подтвердила свою работоспособность.

V. Архитектура кластерной системы, построенной на принципах схемной эмуляции

В основе кластерной сети, построенной на принципах схемной эмуляции, лежит все та же идея масштабирования. Представляемая мною идея организации структуры кластерной сети отличается от выше рассмотренной мультиплатформенной вычислительной ПЛИС- системы лишь тем, что средой, в которой разворачивается рабочая область эмуляции, является PC платформа. А вместо модулей блоков исполнительных процессоров используется микропроцессор самой платформы.

В таком случае на каждой PC-платформе, кроме непосредственно фрагмента задачи, размещается и модуль схемной эмуляции. Совместная работа всех модулей эмуляции и выступает в роли звена, "собирающего" все фрагменты задачи в единую программную модель.

Существенным отличием представляемой структуры от известных архитектур кластерных систем состоит в том, что в ней все платформы абсолютно равноценны. Система абсолютно гомогенная и никто никем не управляет. То есть, в такой структуре нет места основному серверу (с установленным на него ПО - т.н. менеджера кластера) и узлам кластера (с клиентским ПО).

Полученную кластерную систему с полным правом можно использовать для решения любого класса задач, потому что по своей природе она является сильносвязанной системой. В то время как известные кластерные структуры могут быть использованы для решения слабосвязанных задач, не требующих интенсивного обмена данными между процессорными узлами.

Работа представляемой структуры до банальности проста: каждый модуль эмуляции разворачивает в пределах платформы программную модель соответствующего фрагмента задачи пользователя. Объединение фрагментов в единую модель осуществляется благодаря соединению всех платформ в единое сетевое подключение посредством сетевого концентратора

Можно сказать, что превратить одноплатформенную систему в мультиплатформенную - задача не менее сложная, чем организация самой мультипроцессорной платформы. Ведь в этом случае разработчик также сталкивается с информационным и алгоритмическим взаимодействием на уровне платформ. И здесь важнейшим аспектом, связанным с эффективностью работы вычислителя, начинает выступать организация межплатформенного обмена служебными потоками, а также проблемы распараллеливания и синхронизации информационных потоков самой задачи.

Вот почему менеджер кластера и клиентское части традиционных кластерных систем представляют собой чрезвычайно сложное и дорогостоящее программное обеспечение.

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

Понятно, что недостатком представляемой кластерной структуры является то, что, как это уже говорилось, в среде PC платформ всякая параллельность алгоритма работы авторского модуля эмуляции может только имитироваться, потому как любой микропроцессор в состоянии выполнять инструкции только последовательно. Единственным методом "борьбы" с таким системным недостатком, свойственным архитектуре фон Неймана, является как можно более глубокое распараллеливание задачи путем добавления в систему как можно большего числа PC платформ. Благо, для представляемой идеи это не представляет какой-либо проблемы, чего не скажешь о традиционных кластерных системах.

Однако, для тех приложений, где скорость выполнения задачи является принципиальным параметром, - использование рассмотренной в предыдущем разделе мультиплатформенной системы, построенной на микросхемах программируемой логики, представляется единственно реальной альтернативой.

Вместо пролога

Итак, в настоящее время все отчетливее зреет понимание того, что развитие архитектурных решений, основанных на принципах фон Неймана, близится к своему пределу.

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

А как же Запад? Я понимаю, что Запад - не дурак, и что Он - не дремлет. Однако, похоже, что выход он находит традиционным для него способом - путем очередной технологической революции: оптическими, кубическими, бионическими и прочими решениями.

Но если в основу новых компьютерных систем опять лягут идеи фон Неймана (а, похоже, что к тому и идет), то это приведет к очередному витку небывалого роста их сложности… и что программированием таких систем смогут заниматься разве что сами их разработчики.

Может быть в этом и состоит их "хитрый" план реализации "мирового господства", только все равно здесь что-то не клеится. Ведь если на телегу поставить 600- сильный дизель, то от этого в мерседес она не превратиться!

Ведь сама по себе высокая мощность - это еще не панацея. И новые технологии принесут ее куда в больших значениях, чем это необходимо будет для расчета погоды, ядерного реактора или экономической модели государства. А вот чтобы добыть главное "черное золото XXI века" - знания - одной мощности недостаточно!

Потому как современные компьютерные системы позволяют общаться с ними только путем программирования, а интеллект, как известно - программированию не поддается. Главным звеном управления известных архитектур является процессор или их совокупность. Но сам по себе процессор "мозгами" не обладает, он в состоянии только выполнять инструкции программиста.

Выход видится в одном - создании среды, способной к развитию и обучению. Сделать это аппаратным способом - проблема куда более сложная, чем потоковые машины и РВС вместе взятые, так с теми и по отдельности разобраться не могут!

Предлагаемая к рассмотрению в рамках данной статьи авторская идея эмуляции алгоритмов и систем позволяет разработку проекта любой сложности начать и закончить на бумаге! (Вернее сказать - на экране монитора). К тому же, она позволяет делать это непосредственно специалистам самым разных специальностей не прибегая к магическим услугам как электронщиков, так и программистов.

Реализовывается любой проект просто сборкой из аппаратно-программных "кубиков" как в виде сосредоточенной системы (путем установки модулей в единое шасси), так и в виде распределенной системы, посредством сетевого интерфейса.

Немного истории

История первая

Давным-давно, в детстве, мне подарили радио - конструктор, который позволял собирать некоторые схемы (радиоприемник, генератор сигналов и т.д.) путем складывания схем из пластмассовых кубиков. Сверху каждого кубика был изображен графический образ какой-либо радиодетали, а внутри - была распаяна сама деталь. По бокам имелись контактные ламели для обеспечения электрического контакта с другими кубиками.

Прошли годы, и уже работая в Научно-Исследовательском Отделении одного из военных ОКБ (специализирующемся на разработке и изготовлении опытных образцов цифровой техники военного применения), - я не раз с тоской вспоминал свой первый "конструктор". И думал - вот бы мне сейчас такой, только объемом побольше, да базой библиотечных компонент поширше!