Это не извращения. Вы все правильно сказали.
На CUDA реально удобно и быстро все это считать. Несколько мыслей по этому поводу:

1. CUDA - закрытая вещь. То есть чип от NVIDIA вы не купите и не поставите на свою плату. Даже документация дальше определенного уровня (детализации, специализации) недоступна. Эта проблема, возможно будет снята с "вводом в эксплуатацию" OpenCL. В общем, считаем, что этой проблемы нет

2. CUDA - это "жесткая" струкутра. Во-первых, и по своей сути - ну не измените вы DataFlow наиболее оптимально под задачу, и "в мелочах" (но важных) - то что ядра объединены в 8-ки (SIMD) не есть гуд для ряда задач. Просто, народ, запуская КУДу получает РЕАЛЬНОЕ ускорение в 10-100 раз и прыгает от радости. Немного кто задумывается, что это не предел

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

Теперь представьте, что мы сделали среднезернистую реконфигурируемую систему (чип), который содержит на борту 500 ядер с FPU, но с возможностью "программирования" DataPath между ними и, возможно, с какой-то элементарной программируемостью логики работы. Рабочая частота должна быть не хуже чем у КУДы, ну или не намного хуже - пусть спецы по разработке чипов скажут - так ли это? Я исхожу из того, что мы проигрываем в том, что в чипе есть доп-элементы необходимые на реконфигурацию (но средне/крупнозернистую, а не мелкозернистую как в фпга), но зато нет сложных процессорных ядер. Получается система с производительностью не хуже чем КУДА, но намного более гибкая для широкого класса задач (не для всех).

Реализуемость таких систем? А почему нет? Если КУДу сделали, то тут вроде почти тоже самое.
"Целочисленные" аналоги? Ну, например, MathStar (умер правда) и Ambric (умирает похоже). И еще вроде много таких.





Может просто не умеют



Уделывают. Поверьте. При желании Вы все это найдете. Именно на задачах типа этой,а на задачах где нужны какие-ниубдь трехбитные сумматоры с обратными связями (попадалось что-то подобное тоже откуда-то из генетики вроде) вообще рвут в клочья
ну вот еще - честно, говоря, не знаю насколько это круто с точки зрения генетики (спрошу специально у спецов), но не думаю что туфта http://private.ecit.qub.ac.uk/MSRC/Wednesd...li_OakRidge.pdf


Ключевое слово "сегодня". Давайте в будущее с оптимизмом смотреть

В качестве аналогии приведу маленький пример: в книге "Dragon Book" (классика по разработке компиляторов - автор Ахо) в введении написано, что первый компилятор Фортрана потребовал 18 человеко-лет. С точки зрения сегодняшнего дня, это компилятор предельно простой. Ахо пишет, что сегодня компилятор С++ (может не самый крутой, но достаточно серьезный) может написать толковый студент за семестр (я точно не напишу ни за семестр, ни за два ).
Компилятор фортрана писали люди "класса" Джона Бэкуса (http://en.wikipedia.org/wiki/John_Backus). Вы верите в то, что студент умнее команды Бэкуса? Нет, конечно. Просто за 50 лет куча людей пропахала методологию разработки компиляторов и создала мощный фундамент, который РЕАЛЬНО работает!

Так почему нельзя тоже самое сделать для ПЛИС?!

P.S. Может Коламо и есть тот самый прорыв?

Может вы это имели ввиду Intel Integrated Performance Primitives IPP. Вещь достойная сам пользовался

Похоже имелся в виду LRB - графический чип (с массивом GPU). Общая инфа есть на сайте Intel'а. Собственно чип еще не вышел

Да, действительно, LRB, т.е. Larrabee.

У быстрых синтезированных FPU большая задержка в тактах, 8-12. Это накладывает искусственный отпечаток многопоточности на алгоритм свертки.

Кроме того, нельзя обделять целочисленные алгоритмы. Тут - да, на 1...6-битовых- операциях в плис - раздолье.

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

Будем надеяться на лучшее.

Время сборки будет обратно пропорционально времени, проведенному с проектом.
Сначала 3-е суток, под конец полчаса и меньше.
Модульная сборка rloc, logic lock, hard macro, или как оно будет у вас называться, сильно ускоряет работу, но требует загрузки в голову.

Вот вязаночка.
http://www.phys.uu.nl/~steen/web08/fpga-accel.html

И, подробнее, один из:
http://www.drccomputer.com/pdfs/DRC_Acceli...ce_Platform.pdf

Ну да, экстракт кошемира.
Там же и написано, что virtex-5, программируется на СИ-подобных языках. То есть, в общем случае вы не можете взять программу для PC и не модифицируя ее и не изучая эти самые Handel-C и Mitrion-C затащить в FPGA. Изучение потребует энергии и времени. Но если эту энергию потратить в мирных целях, то есть, на оптимизацию математических методов, алгоритма и кода для PC или, еще лучше, для CELL, то будет результат на порядки лучше, чем в FPGA.
Еще раз, FPGA побеждает процессор только низкой задержкой от ножек к ножкам. Ну и для прототипирования годится.

Скажем, Virtex 5-50t = 28800 LUT * пусть 400 МГц = 11,520,000,000,000 шестибитовых операций (чертова прорва операций, надо отметить).
Кому эти операции в таком чистом виде нужны - тому повезло

Речь, ваще-то идёт о СПЕЦИАЛИЗИРОВАННЫХ сопроцессорах. Что, вполне естественно, предполагает глубокое знание предмета и достаточно нишевое применение. Так что и учиться, и модифицировать придётся по-любому. В ПДФ-ке, кстати, описана байда, имеющая гипертранспортные линки, т.е. с точки зрения интерконнекта, она мало чем отличается от ЦПУ.

Клеточные автоматы?
На youtube ролики есть - студенты прикалываются - на FPGA что-то подобное сделано (Life Game типа).

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

На virtex-5 Hypertransport можно сделать только 500MHz, скорее всего, 2 байта. То есть, 2*10^9 Byte/sec в каждую сторону грязными. Реально около 1.7*10^9 Byte/sec если очень постараться.
Сейчас выгоднее FPGA цеплять через PCI-e версии 2, потому что из AMD-шных процессоров торчат линки шириной 2 байта, 4-х байтовых нет, но FPGA не умеет работать с source synchronous сигналами так быстро, как умеет процессор и микросхемы чипсета. Вот и получается, что interconnect имеет большую пропускную способность, чем ускоритель, и меньшая латентность hypertrasport играет меньшую роль. Подключение ускорителя к AMD-шному процессору после чипсета по PCI-e и вовсе лишает затею смысла.

Новые FPGA как-то не сильно позволяют разбежаться, скорости вроде бы растут, памяти clock manager-ов, а вот ввод-вывод по прежнему медленный и шумный.

Вот если бы была FPGA, способная подключиться напряму на полной скорости к HT или QuickPath, набитая сотнями мелких банков памяти по паре килобайт, сотнями 80-битных умножителей и сумматоров для чисел с плавающей точкой и остальной радостью, чтобы все это работало хотя бы на гигагерце и жило в небольшом корпусе в 1152 ноги. Вот это был бы ускоритель. Да.

Во-во! В точку (сама идея, детали можно обсуждать)!

P.S. Еще добавить возможность реконфигурации datapath между ядрами FP
Но FPGA крайне полезна, чтобы такую штуку (и тем более систему из "эн" таких штук) смоделировать в реале - посмотрите ради интереса инфу по проекту RAMP.
Только у них нацеленность на моделирование классических суперкомпов.

P.P.S. А сколько практически можно прокачать через самую-самую толстую из имеющихся FPGA при соединении chip-chip (типа все пины если задействовать)?

Самый жирный stratix-IV GT может прокачать 47 гигабайт в секунду.
К шинам столько по простому не подключить, так как для PCI-e или infiniband останется 12 гигабайт/сек полноценных трансиверов и PCI-e ядер или еще меньше. А чтобы увеличить трафик нужно так помучаться, что за это время выйдет еще пара поколений FPGA и процессоров.

Вот интерконнект сделать на этом можно, но кому ж оно надо?
(в смысле, кто деньги будет тратить, а не пилить).

PS: соединять через MultiGigabit-трансиверы выходит жирнее и проще, чем через LVDS-ные трансиверы.

Засланный казачок из счетной палаты? Никогда еще разработчики из Таганрога не были так близки к провалу...