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


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


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

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