http://omega.sp.susu.ac.ru/books/conference/PaVT2015/full/011.pdf Тут посвежее. НИИ МВС вообще очень солидно смотрится по мировым меркам. Один их заметных мировых потребителей больших FPGA.

ну.....в общем-то само-собой напрашивающийся подход

Какой именно? Тут два момента. Во-первых, сама аппаратная платформа. Это более чем серьезно. Платы такого уровня можно увидеть у Synopsys (HAPS) и DiniGroup. Однако у НИИ МВС они мощнее, к тому же кроме самих модулей есть еще и сборка в шкафы. Причем некоторые платы (даже не шкафы) у НИИ МВС потребляют до 200 А, и это при скоростях передачи 1,2 Гбит/с (т.е.). Они делали специальный НИР по разработке системы питания, которая могла бы такое вытянуть.
Во-вторых, это COLAMO, который имеет альтернативы. Если аппаратная часть безусловно является продуктом высокого класса, который проще купить, чем сделать, то COLAMO - разработка Таганрога, которая раскладывает граф задачи в "поле ПЛИС". Системы такого типа - например, Vivado HLS, с одним тонким моментом. HLS не умеет раскладывать проект по нескольким ПЛИС! Поэтому такие вещи, как РВС-5 (5 шкафов по 256 ПЛИС) нормально загружаются только с помощью COLAMO. "Нормально" в данном случае означает "с помощью серьезной рабочей станции, потому что надо сделать 1000+ отдельных проектов для большой FPGA". Альтернатива, правда, это "ручное" проектирование, когда для каждой ПЛИС проект создается индивидуально, что уже некоторым образом за гранью разумного. Впрочем, еще одна альтернатива - это загрузка во все ПЛИС софт-процессоров и программирование уже их

я про саму идею - специализированного супервычислителя под определенный круг задач (ну или отдельную задачу)

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

Ну, тут у Каляева и Левина можно почитать ОЧЕНЬ много. Мне у них нравится один график (своей своевременностью). Они рассматривали ускорение некоторых алгоритмов при увеличении числа ядер, и обнаружили уменьшение производительности при превышении определенного порога. Не просто снижение темпов роста, а уменьшение абсолютного значения производительности! Объясняется довольно просто - чем больше ядер, тем больше времени они тратят на взаимодействие. Исключение составляют только полностью независимые задачи, которым нечем обмениваться. А если каждое ядро должно сообщать всем соседям о каждом своем действии, то чем больше таких соседей, тем хуже. Поэтому просто так взять и поставить побольше процессоров может оказаться не только невыгодно, а еще и просто вредно.

Даже и не в разы Вот сейчас Kintex-325 пересобирается пару часов (и загружен не весь). Сколько будет собираться проект для одного кристалла Virtex-585? А для Virtex-2000? А если таких кристаллов от десятков до сотен? Так ведь еще и сам процесс проектирования неоднозначен. Можно при очередной правке алгоритма поставить САПР в такие условия, что она вот эту лишнюю операцию вытянет с большим трудом, или вообще не вытянет. Допустим, COLAMO сможет разрешить вопрос алгоритмически (как это делает HLS). Например, конвейеризовав критическую цепь. Но это потащит за собой латентность, перестройку управляющих автоматов, поплывут характеристики производительности и т.п. Вобщем, если разработчик еще не полностью понял, что же он хочет от алгоритма, то отлаживать его непосредственно на шкафу ПЛИС - то еще приключение. В этой связи матрица процессоров, которые пусть и не очень близки к оптимальной архитектуре, зато программируются за десяток секунд, и при этом обеспечивают гарантированную тактовую частоту, очень даже поможет.

А если ограничивать число связей? По идее позволит преодолеть этот порог.

Если создавать специализированную систему. А если в компьютере просто N ядер с общей памятью, как тут можно аппаратно ограничить число связей? Это уже Non-Unified Memory Access, и нужно при создании системы решать другую задачу - сколько памяти дать какому ядру. А потом придет программист, который скажет "ну вот, вы мне сделали 4 процессора по 8 Гб, а мне надо 2 по 16".

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

По большому счету - где-то придется искать компромисс - до какого момента ломать задачу аналитически, а с какого и как уходить на численный счет, и как потом счет разносить по пространству и времени (то бишь по процам и памяти и как где делать конвейеры и потоки и пр...)

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


Да, разумеется Это уже не COLAMO, потому что там описываются операции по сути в терминах RTL. А вот как сделать различные процессоры, это уже очень интересное отдельное направление.

А то!

Не думать же, что типовая однородная система будет подходить для всех задач....

из ForthHub
ForthFreak ссылки на информацию связанную Forth]

В ответ на пост KPG в теме Начальный курс программирования на языке Форт Создал русский раздел в "Немецкой много языковой Wiki". Перевел заглавную страницу. Написал несколько своих. Для оформления статей используется DokuWiki -- упрощенная вики с простым синтаксисом. Присоединяйтесь.

Ссылки:
- Стартовая страница русского раздела: http://www.forth-ev.de/wiki/doku.php/ru:start
- Синтаксис Forth-ev Wiki описан здесь: http://www.forth-ev.de/wiki/doku.php/ru:wiki:syntax
- Все страницы Forth-ev Wiki (смотрим раздел "ru"): http://www.forth-ev.de/wiki/doku.php/ru:start?do=index
- Где и как в структуре Forth-ev Wiki оформлять свой проект: http://www.forth-ev.de/wiki/doku.php/ru ... s:treeinfo


Считаю что ссылки на литературу лучше выкладывать в этом форуме. P.S.: Зачем разбазаривать информацию по нескольким ресурсам. Хотя Вики для систематизации более удобна. Предлагаю использовать Вики так же для оформления набросков идей, статей и стандартов, которые потом дойдя до нужной кондиции будут вставлены на http://fforum.winglion.ru

Ресурс и так один (мой). Здесь - только самореклама микрофортеров.