Проект "пульс": (описание идеи)
| Вид материала | Программа |
- Программа «Школа волонтеров Пульс», 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.
Архитектура кластерной системы, построенной на принципах схемной
эмуляции
В основе кластерной сети, построенной на принципах схемной эмуляции, лежит все та же идея масштабирования. Представляемая мною идея организации структуры кластерной сети отличается от выше рассмотренной мультиплатформенной вычислительной ПЛИС- системы лишь тем, что средой, в которой разворачивается рабочая область эмуляции, является PC платформа. А вместо модулей блоков исполнительных процессоров используется микропроцессор самой платформы.
В таком случае на каждой PC-платформе, кроме непосредственно фрагмента задачи, размещается и модуль схемной эмуляции. Совместная работа всех модулей эмуляции и выступает в роли звена, "собирающего" все фрагменты задачи в единую программную модель.
Существенным отличием представляемой структуры от известных архитектур кластерных систем состоит в том, что в ней все платформы абсолютно равноценны. Система абсолютно гомогенная и никто никем не управляет. То есть, в такой структуре нет места основному серверу (с установленным на него ПО – т.н. менеджера кластера) и узлам кластера (с клиентским ПО).
Полученную кластерную систему с полным правом можно использовать для решения любого класса задач, потому что по своей природе она является сильносвязанной системой. В то время как известные кластерные структуры могут быть использованы для решения слабосвязанных задач, не требующих интенсивного обмена данными между процессорными узлами.
Работа представляемой структуры до банальности проста: каждый модуль эмуляции разворачивает в пределах платформы программную модель соответствующего фрагмента задачи пользователя. Объединение фрагментов в единую модель осуществляется благодаря соединению всех платформ в единое сетевое подключение посредством сетевого концентратора
Можно сказать, что превратить одноплатформенную систему в мультиплатформенную – задача не менее сложная, чем организация самой мультипроцессорной платформы. Ведь в этом случае разработчик также сталкивается с информационным и алгоритмическим взаимодействием на уровне платформ. И здесь важнейшим аспектом, связанным с эффективностью работы вычислителя, начинает выступать организация межплатформенного обмена служебными потоками, а также проблемы распараллеливания и синхронизации информационных потоков самой задачи.
Вот почему менеджер кластера и клиентское части традиционных кластерных систем представляют собой чрезвычайно сложное и дорогостоящее программное обеспечение.
Представляемая мною кластерная структура свободна от всего этого, потому что все задачи организации межплатформенного взаимодействия берут на себя модули эмуляции, установленные на каждой платформе, причем сделают это они совершенно автоматически. Все что требуется от пользователя – это умение составить граф задачи, тупо разбить его на фрагменты и загрузить каждый фрагмент в отдельную платформу.
Понятно, что недостатком представляемой кластерной структуры является то, что, как это уже говорилось, в среде PC платформ всякая параллельность алгоритма работы авторского модуля эмуляции может только имитироваться, потому как любой микропроцессор в состоянии выполнять инструкции только последовательно. Единственным методом "борьбы" с таким системным недостатком, свойственным архитектуре фон Неймана, является как можно более глубокое распараллеливание задачи путем добавления в систему как можно большего числа PC платформ. Благо, для представляемой идеи это не представляет какой-либо проблемы, чего не скажешь о традиционных кластерных системах.
Однако, для тех приложений, где скорость выполнения задачи является принципиальным параметром, – использование рассмотренной в предыдущем разделе мультиплатформенной системы, построенной на микросхемах программируемой логики, представляется единственно реальной альтернативой.
Немного истории
История первая
Давным-давно, в детстве, родители подарили мне радио - конструктор, который позволял собирать некоторые простейшие устройства (радиоприемник, генератор сигналов и т.д.) путем складывания схем из пластмассовых кубиков. Сверху каждого кубика был изображен графический образ какой-либо радиодетали, а внутри – была распаяна сама деталь. По бокам имелись контактные ламели для обеспечения электрического контакта с другими кубиками.
Прошли годы, и уже работая в Научно-Исследовательском Отделении одного из военных ОКБ (специализирующемся на разработке и изготовлении опытных образцов цифровой техники военного применения), – я не раз с тоской вспоминал свой первый "конструктор". И думал – вот бы мне сейчас такой, только объемом побольше, да базой библиотечных компонент - "поширше"!
Прошли годы. Персональный компьютер, а вместе с ним и множество полезных прикладных программ, стали доступными для любого человека. Стало возможным просто нарисовать схему устройства на экране монитора и испытать ее. А по сформированным графикам временных диаграмм дойти до вывода о правильности ее функционирования.
Все казалось бы прекрасным, но чувство неудовлетворенности так и не прошло! Ведь нарисовать какую-либо схему для меня, как и для любого другого разработчика, и даже проверить на экране монитора правильность ее работы – оставалось явно недостаточно! Потому как этап рисования и проверки по-прежнему никак не отменяет последующих этапов – сборки и отладки опытного образца, а также организации технологического процесса изготовления серийных образцов.
Душа по-прежнему желала "кубиков", да еще и таких, чтобы "сложив" спроектированную систему, можно было просто вставить ее, к примеру, в объект автоматизации - и никаких проблем!
История вторая
Осенью 2000–го года я встретил человека, в последствии внесшего огромную роль в дело реализации моей идеи (представляемого здесь проекта), и поведавшего такую историю. Как оказалось, существует огромное количество малых фирм и частных предпринимателей, занимающихся разработкой и изготовлением различных мелкосерийных аппаратов – линий по производству макарон, сушки для семечек и фруктов, парогенераторы для домов быта и так далее.
Но, воплотив свои разработки в "железе", каждый из них начинал задумываться – а где взять "электронику", способную "оживить" построенную систему? Естественно, что, для начала, они обращаются за добрым словом в такие крупные компании как Инком или Квазар-микро.
Там говорят, парень! – никаких проблем! Пятнадцать тысяч долларов – и через три месяца ты будешь держать в руках то, что хочешь!
Тут "парень" как-бы начинает возражать: что мол он рассчитывал всего на пару, ну от силы – на три тысячи. Да и три месяца – срок многоватый. Ему коротко отвечают – не нравится? – "пройдись по базару"!
"И он приходит ко мне!" (то есть - человеку, поведавшего мне эту историю)
Вот почему уже тогда у моего собеседника созрело понимание, что для того, чтобы быстро и дешево обслужить клиента – он должен иметь возможность собирать системы из заранее заготовленных "кубиков". И чтобы никакого программиста! – постоянно тянущего жилы ценой своего труда, срывающего сроки внедрений да, к тому же, страдающего извечной способностью вносить трудно находимые ошибки в свои программы!
Вот тут-то, моя идея как изготовить такие "кубики" и его желание их иметь, стали отправной точкой совместной работы на целых девять месяцев, результатом которой стало "рождение" современного видения идеи и ее проверки на практических внедрениях.
Предлагаемая к рассмотрению в рамках данной статьи авторская идея эмуляции алгоритмов и систем позволяет разработку проекта любой сложности начать и закончить на бумаге! (Вернее сказать – на экране монитора). К тому же, она позволяет делать это непосредственно специалистам самым разных специальностей не прибегая к магическим услугам как электронщиков, так и программистов.
Реализовывается же любой проект просто сборкой из аппаратно-программных "кубиков" как в виде сосредоточенной системы (путем установки модулей в единое шасси), так и в виде распределенной системы, посредством сетевого интерфейса.
Вместо эпилога
Итак, в настоящее время все отчетливее зреет понимание того, что развитие архитектурных решений, основанных на принципах фон Неймана, близится к своему пределу.
Попытки найти достойный выход из ситуации в развитии альтернативных архитектур, таких как потоковые машины или реконфигурируемые структуры, тоже пока не увенчалась успехом в силу труднореализуемости, казалось бы, красивых на первый взгляд идей.
А как же Запад? Я понимаю, что Запад – не дурак, и что Он – не дремлет. Однако, похоже, что выход он находит традиционным для него способом – путем очередной технологической революции: оптическими, кубическими и прочими решениями.
Но если в основу новых компьютерных систем опять лягут идеи фон Неймана (а, похоже, что к тому и идет), то это приведет к очередному витку небывалого роста их сложности… и, в конечном итоге, к тому, что программированием таких систем смогут заниматься разве что сами их разработчики.
Может быть в этом и состоит их "хитрый" план реализации "мирового господства", только все равно здесь что-то не клеится. Ведь если на телегу поставить 600- сильный дизель, то от этого в мерседес она не превратиться!
Ведь сама по себе высокая мощность – это еще не панацея. Понятно, что в конечном итоге новые технологии принесут ее куда в больших значениях, чем это необходимо будет для расчета погоды, ядерного реактора или экономической модели государства. Но вот только чтобы добыть главное "черное золото XXI века" – знания – одной мощности недостаточно!
Потому как современные компьютерные системы позволяют общаться с ними только путем программирования, а интеллект, как известно – программированию не поддается. Главным звеном управления известных архитектур остается процессор или их множество. Но сам по себе процессор "мозгами" не обладает, он в состоянии только выполнять инструкции программиста.
Выход видится в одном – создании среды, способной к развитию и обучению. Сделать это аппаратным способом – проблема куда более сложная, чем потоковые машины и РВС вместе взятые, так с теми и по отдельности справиться не могут!
* при написании данного раздела использованы материалы идеологов идеи РВС, размещенные в сети интернет, такие как:
"Архитектура семейства реконфигурируемых вычислительных систем на основе ПЛИС"//
И.А. Каляев, И.И. Левин, Е.А. Семерников – ж-л "Искусственный интеллект", 3' 2008, г. Харьков
"Реконфигурируемые мультиконвейерные вычислительные структуры"//
И.А. Каляев, И.И. Левин, Е.А. Семерников, В.И. Шмойлов – издательство ЮНЦ РАН, г. Ростов-на-Дону, 2008 г.
"Реконфигурируемые вычислительные системы с открытой масштабируемой архитектурой"//
И.И. Левин, РАСО 2010 г.
"Вычислительные системы с реконфигурируемой (программируемой) архитектурой"//
А.В. Палагин, В.Н. Опанасенко, В.Г. Сахарин – ж-л Проблемы информатизации и управления",
10' 2004 г.
"Будущее высокопроизводительных систем"// Виктор Корнеев, "Открытые системы", #5 / 2003 г.
Материалы, освещающие авторскую идею схемной эмуляции алгоритмов и систем, опубликованы в журналах:
"Современная электроника", №1, 2004 / №5, 2010 г. Москва
"Компьютер-Информ", №19-20, 2005 / №3, 2006 / №1-2, 2011 / №15-16, 2011
г. Санкт-Петербург
"Промышленные контроллеры АСУ", №1, 2006 / №2, 2008 г. Москва
"π- КАД" №4, 2006/ №1, 2007 г. Киев, (КПИ)
"itech", №2, 2007 г. Москва
"Мир техники и технологий", №3, 2007/ №8, 2011 г. Харьков
или можно найти в сети интернет, набрав в строке поиска любого поискового сервера
фразу – "схемная эмуляция"