Есть ли среди уважаемых форумчан люди, плотно знакомые с сабжем?
Я имею в виду именно «реконфигурируемый суперкомпьютер», разрабатываемый в Таганроге (под руководством Каляева И.А. и Левина И.И.), а не вообще тематику RC (Reconfigurable Computing) и HPRC (High Performance Reconfigurable Computing).

Команда из Таганрога вошла в ряд федеральных целевых программ по данной тематике, в частности:
Федеральная целевая программа "Исследования и разработки по приоритетным направлениям развития научно-технологического комплекса России на 2007-2012 годы". ГОСУДАРСТВЕННЫЙ КОНТРАКТ N 02.524.12.4002 от 20 апреля 2007 г. Лот 4 шифр "2007-4-2.4-20-01-007" по теме: "Создание семейства высокопроизводительных многопроцессорных вычислительных систем с динамически перестраиваемой архитектурой на основе реконфигурируемой элементной базы и их математического обеспечения для решения вычислительно трудоемких задач"

Стратегические задачи проекта
1.Разработка и создание отечественных конкурентоспособных реконфигурируемых многопроцессорных вычислительных систем, превосходящих по своим технико-экономическим характеристикам зарубежные образцы.
2.Серийный выпуск изделий для российского рынка.
3.Повышение престижа России на рынке высокопроизводительной вычислительной техники.
4.Продвижение перспективных российских разработок на мировой рынок.
(информация на сайте www.parallel.ru)

Более подробно с результатами работы команды Каляева и Левина можно ознакомиться по книге «Реконфигурируемые мультиконвейерные вычислительные структуры» (Каляев И.А., Левин И.И., Семерников Е.А., Шмойлов В.И., Ростов-на-Дону, 2008), а также по ряду статей, которые легко находятся в инете.
Я достаточно серьезно интересуюсь вопросами, связанными с RC, и в особенности HPRC. Провел обзор и анализ очень большого количества материалов по этой тематике и могу сказать следующее:
1. На Западе работы в этом направлении ведутся очень интенсивно и в диапазоне от «один человек по вечерам дома что-то сделал за 2 дня» до программ с большим финансированием и серьезными результатами (пара примеров из большого множества – HPRC системы у IBM в проекте суперкомпьютера Blue Gene и проект RAMP, инициированный Дэйвом Паттерсоном)
2. Есть успехи, есть и спекуляция на этом предмете, вообще серьезные конторы (ранга Cray, IBM и ведущих научных центров) заявляют примерно следующее: «направление очень перспективное, но работ непочатый край», то есть такого что «все сделано, все работает и все всем ясно» нет пока и в помине

Поэтому меня очень сильно заинтересовали и, вообще говоря, насторожили заявления команды из Таганрога. Насторожили по следующим причинам:

1. Ведущие западные конторы прямо и честно заявляют, что в общем пока «тут еще конь не валялся» и «работы море и хватит на всех», особенно это касается методологии разработки и проблемы «отображения» алгоритма на «железо» (HLL to HDL и т.п). В работах таганрогцев наоборот идет упор на то, что «мы впереди планеты всей», «мы уже много чего сделали» и «у нас (СССР/Россия) в этом направлении приоритет, т.к. данную тематику впервые "подняли" (в частности) академики (не уверен точно, что все они академики ) Каляев А.В., Евреинов Э.В., Прангишвили И.В.». Последнее заявление проверяется очень просто и обнаруживается, что в США подобные системы описали и даже сделали (!) раньше лет так на 5-7 (в частности, G. Estrin, “Organization of Computer Systems—The Fixed Plus Variable Structure Computer,” Proc.Western Joint Computer Conf., Western Joint Computer Conference, New York, 1960, pp. 33-40.). Сам по себе факт, кто там раньше написал/сделал (мы или амеры) не так важен – просто настораживает такой подход авторов: из разряда «Россия – родина слонов», ну и вообще это, если называть вещи своими именами, - прямая ложь.
(Любопытно, что в книгах Евреинова Э.В., на которые ссылаются Каляев И.А. и Левин И.И. есть ссылки на американские работы, в том числе и на приведенную мной в качестве примера, и нет заявлений, что "мы впереди планеты всей")

2. Из сделанного в железе у этой команды (то, что я нарыл в инете) – это платы типа «16 Virtex V/IV на борту», которые могут устанавливаться в модули. Все это названо «Семейство реконфигурируемых вычислительных систем». Я работал в достаточно серьезной западной конторе, которая занималась, в том числе разработкой достаточно серьезного хардвара, выпускаемого серийно, и хорошо понимаю, что просто «голая плата с 16 FPGA» сама по себе малоинтересна и назвать это «реконфигурируемой вычислительной системой» можно с большой натяжкой (также как кучу из 200 тонн кирпичей – красивым домом).

3. Основная сложность (по оценкам многих умных людей) это вовсе не «сделать плату с 16 Virtex V на борту», а разработать методологию разработки и сами средства разработки для таких систем. Существует, наверное, несколько десятков проектов, в которых делаются попытки эту проблему решить , но пока «чаша Грааля» не найдена, насколько я знаю. Команда Каляева и Левина пишет (в книге и в статьях), что ими разработан язык высокого уровня Colamo (Коламо ?), который эти проблемы решает. Опять же, на западе ничего про этот чудо-язык никто не знает.

4. В книге встречаются такого рода высказывания (это точные цитаты из книги, без комментариев):

а)HDL-языки являются очень удобным средством описания различного рода интерфейсов, однако при реализации сложных вычислений разработчик не имеет возможности влиять на процедуру отображения написанного на HDL кода на физические ресурсы кристалла… …поэтому при реализации сложного вычислительного алгоритма представляется предпочтительным использование графического редактора.
б)…стандартные средства САПР ПЛИС позволяют программировать схемотехнику только одиночных ПЛИС
в)Процесс же реконфигурирования ПЛИС – очень длительный процесс, занимающий десятки секунд [50]. ([50] Каляев А.В., Левин И.И. Модульно-наращиваемые многопроцессорные системы со структурно-процедурной организацией вычислений. –М. Янус-К, 2003, 380)

5. Ни в книге, ни в одной другой работе указанных авторов практически нет ссылок на хоть какие-либо современные работы западных авторов. Есть либо общие слова, типа «на Западе работы ведутся», либо ссылки на какие-то третьестепенные малозначащие работы, либо на «старую классику». На западе сотни и тысячи работ по этой тематике. В книге из 146 ссылок только 5-6 на западные работы, хотя реально, в данном направлении число публикаций из СССР/России в процентном отношении составляет не более 1% (я имею в виду период реального развития тематики RC/HPRC, то есть с конца 90-х годов XX века, а не составление списка из сотен «работ» про «сферических коней в вакууме», датированных 60-80 годами).

6. Западные товарищи, в свою очередь, «в упор не видят» команду Каляева и Левина в своих работах.

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

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


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


На всех задачах "процессор шустрее фпга в разы"? "западные" люди приводят примеры, где наоборот FPGA шустрее в разы (с подробным описанием что и как делали и на чем). По ссылкам HPRC если поискать - много РЕАЛЬНЫХ примеров, как раз, и они "типичны" для супер-компьютинга задач.
Вы считаете, что это все "обман трудящихся"?


Согласен, что фпга - самое то для "обкатки" сложных систем и отладки алгоритмов. Именно в этом основная идея проекта RAMP - обкатать очень сложные вычислительные системы на HPRC-системе.

Но посмотрите по ссылкам, котрые я приводил, реальные примеры - тот же Cray - неужели это контора с ничего не понимающими инженерами, которые ради прикола FPGA поставили в суперкомп? Именно как вычислительный блок. Ну и не один Cray, далекон не один.

Полагаю, что производство ASICов экономически целесообразно только в немалых количествах. Да и технологически, наверное, не имеет смысла готовить производство ради нескольких штук.
Решения на FPGA гибче и какие-то незначительные "фичи" можно затачивать под каждого конкретного заказчика и даже под конкретное единичное устройство. Это проще, быстрее и дешевле, нежели лепить новый силикон.

Так было. Но, с каждым годом грань "большого количества" уменьшается стремительно. В конце концов, это вопрос экономический и политический. Я вот, к примеру, сейчас "клепаю" ASIC, который будет выпускаться только сотнями в год, скорее всего. Но, он нужен и его хотят.

Также, где кончается фпга и начинается проц - тоже постепенно размываемая граница. Например, реконфигурируемый проц "Cell" можно рассматривать и как шаг в сторону фпга.

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

Скорее всего, это не от хорошей жизни - просто не успели испечь чипы, и, как обычно, выпустили, по сути, прототип.
Так что, это не приколы, а "подпорки".

Грань "большого количества" с каждым годом только увеличивается, так как стоимость масок только растет и на сегодня уже измеряется миллионами долларов за комплект. ASIC сотнями в год - это политика чистой воды, 100% экономически неоправдано, даже если по MPW гнать.

Есть несколько российский фирм, которые разрабатывают аналогичные ускорители вычислений на ПЛИС.
Бюджет малость подпиливается, но железо и софт все же есть и они работают. Железо современное, Плисы свежие. Stratix 4 и Virtex 6 на очереди, кстати.
ASICи делаются.
Плохие результаты в вычислениях, как отметил Штирлиц, объясняются плохим качеством программ и незнанием целевой архитектуры, например, x86.

Так в чем, собственно, дело, товарищи? В чем вопрос?
Что делать?
Нужно разработать всеобъемлющий язык с ООП с расширениями для ускорителей на ПЛИС?
ПЛИС-сопроцессор пустить в массы, выпустив к нему нехитрый SDK?

ИМХО Это авантюра чистой воды (денег все хотят) В конце скорее всего будет некий теоретический труд... Попробую навести конкретные справки

Подумайте - что такое миллион бяксов, при бюджете разработки в несколько сотен лимонов? Да 10 чипов будут печь, не проблема. Экономический эффект будет всё равно. Да и политика - тоже бизнес.
Хотя, всё это офф, пожалуй.

ПС. И потом, кто заставляет лезть в супер-новые техпроцессы? Еще и относительно старые не распаханы. И по ним, в шаттлах, реально делать чудеса за сущие копейки.

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

Не могли бы Вы их назвать, если не секрет? Если навскидку помните, конечно.



Да. Основная проблема - именно разработать МЕТОДОЛОГИЮ проектирования и средства разработки (а перед этим методологию разработки таких средств разработки). Грубо говоря, что-то типа такого - "ученый" пишет свою программу на Фортране для моделирования Навье-Стокса, а некий чудо-софтвар волшебным образом генерит Configware (выч-блоки) и Flowware (потоки данных). На конкретной задаче все ресурсы кристалла (грубо говоря, в пределе - куча из N миллиардов транзисторов) кидается на то, чтобы поставить 2000 умножителей и 15 сумматоров + завести между ними специфичные для данной задачи пути прокачки данных. Именно для этой конкретной задачи ничего кроме этих 2000 умножителей и 15 сумматоров не надо, поэтому вся "масса" (ресурсы) брошены на это. Нет необходимости во всем остальном.

Это, конечно, пока фантастика - я имею в виду решение в общем виде, а не примеры с C2H и т.п.
Если посмотреть что пишут про эту проблему люди из не самых маленьких контор и не самых отсталых научных центров, то пока, говоря по правде, нет такого решения.
Вот почему я и поднял такую тему - в Таганроге, по их словам, разработан язык Коламо, который эту проблему снимает

P.S.
Если кому интересно - некоторый обзор проблем и "головняков" дан в статье "Is high-performance reconfigurable computing the next supercomputing paradigm?" - находится по гуглю легко. Там разные люди свое видение проблемы и перспектив накидали. Спектр ораторов весьма широкий - от человека из Xilinx (босс какой-то вроде, ну понятно - ксайлинкс тут заинтересовнное лицо ) до представителей из "Сандии" (http://www.sandia.gov/).

Не могу, т.к. нельзя.

Все структуры делаются вручную в САПР ПЛИС. Чудо-софтвара нет.

Если Таганрог продвинулся в этом вопросе - можно у них что-нибудь прикупить, если продадут.

Судя по этому форуму, не только буржуйские мужики не знают.
На сайтах я вижу peaple, publications, sponsors.
Не вижу download development tools.
Вижу, что люди собрались и трындят, хотя, денег вот на это добыли, уважаю.
Может, плохо искал, тогда извиняюсь, покажите, где у них результаты, где показатели лучше, чем на процессорах общего назначения?


Продолжу рассматривать свой случай, так как это характерный пример.

Итак, что происходило:

1) прикладной специалист пишет программу на Си, допускает ошибочку в комплексном умножении, не лучшим способом выбирает метод, не учитывает ошибок округления.
Запомним этого человека, закроем глаза не перечисленные ошибки.
Он взорвал себе мозг и понял, как нужно считать!

2) далее специалист по системе динамического распараллеливания не вдаваясь в подробности (важно!) подправил программу для кластера. Не получилось. Долго и дорого и по прежнему с ошибками.

3) программу дали специалисту по архитектурам, по x86 и fpga. Так вот пока я не разобрался что именно мы считаем, не исправил ошибку, не определил допустимые ошибки округления, не сменил метод вычислений - тоже получалось плохо, в fpga не лезло, на процессоре считалось долго. А когда я все это сделал, то и opteron вполне справился. Один. Без всяких ускорителей за тысячи долларов.

Конечно, комплекс из драйвера, прикладной задачи и ускорителя на stratix в итоге обогнал opteron раз в 30, но opteron считал в floating point, а stratix в числах с фиксированной точкой и мантиссой меньше 16 бит!
Я уверен, что если использовать процессор по назначению, то есть, применить вылизанную годами библиотеку fftw, а еще лучше, написать целочисленный вариант, полный аналог сделанного в stratix с использованием SIMD-команд. Вот тут и шина не помешает и память. Думаю, что все упрется в чтение файла с диска.

О чем тут речь?
О том, что избежать погружения в прикладную область очень трудно.
А погрузившись нужно не утратить информацию о платформе.
Только имея информацию о задаче и о платформе можно сделать что-то быстрое.

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

Однако, средств, позволяющих взять программу на C или FORTRAN и превратить ее в bitstream для FPGA+драйвер+прикладная задача - я не знаю. Ну, есть математические пакеты, которые для некоторых задач могут сделать прошивку для FPGA, не изучал и сомневаюсь в возможности применения. Возможно, напрасно.

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

Возможно, подобные ситуации с халявным программистским ресурсом создают иллюзию, что на FPGA можно что-то там ускорять, просто запаять микросхему и оно сразу ускориться. Это иллюзия. Сначала придется повозиться запаять, а потом кому-то придется потрудиться и запрограммировать.

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

Да, а еще ведь тайминги могут не получиться нужные! Это же как у пожарных, работа отличная, но как place & route, так хоть увольняйся. Ну и как быстро объяснить математику про setup-time и hold-time и про почему оно не может быть размещено рядом из-за разных clock_enable сигналов? А быстро объяснить нельзя, а если не понимать, то получится плохо. Халявных студентов тоже касается.

Еще раз, чуть более внятно:
Для успеха нужно 2 части знаний, 1) о задаче 2) о платформе.
Так вот, 2 часть в FPGA большая. Её нужно исхитриться куда-то засунуть, в голову разработчику или в средство разработки. А голова у разработчика хоть и выглядит резиновой, краник туда небольшой ведет. Все учесть не получается и в результате ускорения может не получиться.
У процессора 2-я часть меньше, во всяком случае, голов и средств разработки с загруженным знанием о процессоре больше на рынке.
В результате, за одинаковые деньги и время на CPU задача начнет считаться существенно раньше и будет считаться быстрее, чем на FPGA.

К экономической целесообразности все это не имеет никакого отношения.

PS: но если хочется ускоритель, да на FPGA, да сложная задача и время не ограничено и есть евросумма с шестью нулями - добро пожаловать!

На уже упоминавшимся http://www.parallel.ru/ смотрим подразделы http://www.parallel.ru/russia/organizations.html и http://www.parallel.ru/computers/rus_vendors.html. Конторы наподобие Цифроника, Коррунда-М или Спирита подойдут вряд ли, но их существенно больше.

Если правильно понял, это язык с однократным присваиванием, те одного уровня с *HDL, и с теми-же проблемами.

Давайте я один пример кину, ладно? но при желании Вы сами их найдете очень много.

http://www.hindawi.com/GetArticle.aspx?doi.../ASP/2006/97950

"RigidMolecule Docking: FPGA Reconfiguration for Alternative Force Laws".
Это конкретное приложение (хотя сам метод, как говорят спецы, с которыми я общался - устаревший). Ускорение по сравнению с 3 ГГц процессором "общего назначения" в 130-1100(!) раз.
на одном XC2VP70-5.

Если уже зашла речь о "дешевых" вычислениях, стоит вспомнить про вычислительные возможности видеокарт, например использование технологии CUDA, к тому же есть реализация БПФ на CUDA, которая позволяет вычислять несколько одномерных БПФ одновременно.
К тому же ядра видеороцессоров оптимизированы для вычислений с плавающей запятой, шина между графическим чипом широка (256 или 512 бит), работает на высокой частоте.
Может быть, это и извращения, но затраты на оборудование и на работу будут куда меньше, чем при использовании FPGA.

Пара мыслей:
- PC correlation performance на уровне 0.2E9 8-битных MAC для 3 ГГц Xeon низковат, пару порядков за счет ядер, конвейера и MMX можно изыскать.
- частота 60-90 МГц для 2-7 битных вычислений представляется маловатой.

Уверен, никто здесь не будет утверждать, что ускорение на ПЛИС вещь по определению ненужная.
Но заметно, как прямо хочется им в 100000 раз уделать компьютер, до конца с ним не поборовшись.
Да, уделали, но не в 1000 раз, а в 10, что само по себе неплохо, хотя и на 90 МГц в Virtex 2.
Остается уделать их на Virtex 5 или на 10 компьютерах.


---

Где-то мне попадалась реклама про нечто от Intel вроде КУДЫ, только с x86 инструкциями. Если вдруг такая штука выйдет, тогда будет интересно.

Из-за всевозможных проблем инструментов для сборки проектов ПЛИС любая высокоуровневая оболочка обречена сегодня.