Архитектура потоковой супер ЭВМ, построенной на принципах схемной эмуляции
Статья - Компьютеры, программирование
Другие статьи по предмету Компьютеры, программирование
µния задачи и требует, чтобы проект пользователя загружался в систему целиком до начала исполнения (эмуляции).
Поэтому выглядит естественным, что при решении больших практических задач может возникнуть ситуация, которую и придется "исправлять" путем добавления в систему некоторого числа точно таких же кристаллов ПЛИС. Тем не менее, пользователю совершенно даже не придется браться за паяльник.
Как уже говорилось, широкие возможности к развитию системы эмуляции и регулярность ее структуры служит надежной базой для реализации различных структурных вариаций. Все это открывает перед разработчиками широчайшие возможности по разработке оптимальной конфигурации базовых конструктивных модулей. Я лично больше склоняюсь к мнению, что применение принципов схемной эмуляции к вопросу проектирования суперЭВМ приведет к разработке двух основных типов модулей (платформ): модуля рабочей области эмуляции и модуля исполнительных процессоров, в каждом из которых количество микросхем программируемой логики будет подобрано оптимальным образом.
Таким образом, пользователю предоставляется возможность простым добавлением базовых платформ на общее шасси наращивать вычислительную мощность всей системы до любого практически необходимого уровня и, что не менее важно, мощность такой системы будет расти практически линейно числу добавляемых платформ. Притом, что использование такой системы обеспечит наивысшую производительность при решении действительно любых классов задач.
В заключении хотелось бы отметить, что представляемая в данной статье система эмуляции прошла успешную апробацию на практических внедрениях в области разработки систем автоматизации на PC- платформах и самым полным образом подтвердила свою работоспособность.
Архитектура кластерной системы, построенной на принципах схемной эмуляции
В основе кластерной сети, построенной на принципах схемной эмуляции, лежит все та же идея масштабирования. Представляемая мною идея организации структуры кластерной сети отличается от выше рассмотренной мультиплатформенной вычислительной ПЛИС- системы тем, что средой, в которой разворачивается рабочая область эмуляции, является PC платформа. А вместо модулей блоков исполнительных процессоров используется микропроцессор самой платформы.
В таком случае на каждой PC-платформе, кроме непосредственно фрагмента задачи, размещается и модуль схемной эмуляции. Совместная работа всех модулей эмуляции и выступает в роли звена, "собирающего" все фрагменты задачи в единую программную модель.
Существенным отличием представляемой структуры от известных архитектур кластерных систем состоит в том, что в ней все платформы абсолютно равноценны. Система абсолютно гомогенная и никто - никем не управляет. То есть, в такой структуре нет места основному серверу (с установленным на него ПО - т.н. менеджера кластера) и узлам кластера (с клиентским ПО).
Полученную кластерную систему с полным правом можно использовать для решения любого класса задач, потому что по своей природе она является сильносвязанной системой. В то время как известные кластерные структуры могут быть использованы для решения слабосвязанных задач, не требующих интенсивного обмена данными между процессорными узлами.
Работа представляемой структуры до банальности проста: каждый модуль эмуляции разворачивает в пределах платформы программную модель соответствующего фрагмента задачи пользователя. Объединение фрагментов в единую модель осуществляется благодаря соединению всех платформ в единое сетевое подключение посредством сетевого концентратора.
Можно сказать, что превратить одноплатформенную систему в мультиплатформенную - задача не менее сложная, чем организация самой мультипроцессорной платформы. Ведь в этом случае разработчик также сталкивается с информационным и алгоритмическим взаимодействием на уровне платформ. И здесь важнейшим аспектом, связанным с эффективностью работы вычислителя, начинает выступать организация межплатформенного обмена служебными потоками, а также проблемы распараллеливания и синхронизации информационных потоков самой задачи.
Вот почему менеджер кластера и клиентское части традиционных кластерных систем представляют собой чрезвычайно сложное и дорогостоящее программное обеспечение.
Представляемая мною кластерная структура свободна от всего этого, потому что все задачи организации межплатформенного взаимодействия берут на себя модули эмуляции, установленные на каждой платформе, причем сделают это они совершенно автоматически. Все что требуется от пользователя - это умение составить граф задачи, тупо разбить его на фрагменты и загрузить каждый фрагмент в отдельную платформу.
Понятно, что недостатком представляемой кластерной структуры является то, что, как это уже говорилось, в среде PC платформ всякая параллельность алгоритма работы авторского модуля эмуляции может только имитироваться, потому как любой микропроцессор в состоянии выполнять инструкции только последовательно. Единственным методом "борьбы" с таким системным недостатком, свойственным архитектуре фон Неймана, является как можно более глубокое распараллеливание задачи путем добавления в систему как можно большего числа PC платформ. Благо, для представляемой идеи это не представляет какой-либо проблемы, чего не скажешь о традиционных кластерных системах.
Однако, для тех приложений, где скорость ?/p>