ПЛИС для вычислений с длинной арифметикой Опции

[planetzeus]

Помогите пожалуйста с выбором.
Нужно делать вычисления с длинной арифметикой - до 8 тысяч бит. Т.е нужно простое АЛУ, но числа очень длинные.
Вычисления относительно простые - сложение, вычитание (сложение с отрицательным в обратном коде), сдвиг на бит и пара таких же длинных счетчиков.
Никаких умножений или делений. Т.е задаем начальные значения и и девайс должен складывать (вычитать) числа в зависимости от знакового бита, пока не дойдет до конечного или не найдет совпадения с заданным длинным числом.
На компьютере такие вычисления крайне медленные. На GPU тоже, так как в любом случае сложение вычисляется группами по 64 бита.
Поэтому подумал, что идеальный вариант - собственное АЛУ, которое делает одну операцию со всеми битами за такт. Насколько я понимаю, самый правильный вариант - ПЛИС.
Желательно делать перебор с максимальной скоростью - к примеру если есть возможность 1 или 2 Ггц, то именно это и нужно.
Почитал про ПЛИС и есть желание разобраться, но не понятно с какого девайса начинать искать. Не хотелось бы покупать плату, которая в итоге не подойдет для этой задачи.
Мне не нужны разные интерфейсы, USB и может быть микроконтроллер на плате пригодится, но остальное по большому счету не очень важно.
Посоветуйте пожалуйста с чего начинать и какую плату для разработки выбрать. Самый главный критерий - максимальная производительность и возможность "зашить" свою логическую схему.

[iiv]

Помогите пожалуйста с выбором.
Нужно делать вычисления с длинной арифметикой - до 8 тысяч бит. Т.е нужно простое АЛУ, но числа очень длинные.

Вы писали, что у вас есть 1080TI. Она в пике дает на сложениях или вычитаниях с 32 битными числами около 5е12 операций в секунду. Если у вас по сути вашей задачи есть возможность выполнять несколько операций над вашими длинными 8кбитными числами полностью не зависимо и параллельно, то как раз 16 тредов в параллель позволит вам выполнить 16 таких операций на регистрах, то есть у вас есть шанс приблизиться к пиковой производительности карты. То есть одно такое сложение у вас будет выполняться за время около 0.1нс.

Если взять стратикс по стоимости соизмеримый с 1080ti, то в него вы сможете положить около 100 таких сумматоров, если делать в лоб и работать они будут в лучшем случае с 100, а то и с 50МГц частотой. То есть в общем примерно те же яйца, только в профиль.

То есть пользовать или не пользовать GPU или ПЛИС будет зависеть только от того, как у вас идут сами эти вычисления. Если вы решите по USB в плиску или с PCIe на графическую карту скармливать эти операции, то скорость будет определяться не скоростью плиски или графической карты, а дыркой, через которую вы это все будете протаскивать и будет как минимум на пару порядков медленнее. Вероятность того, что ваш алгоритм со всеми промежуточными данными поместится в 11GB, которые есть на халяву на борту вашей графической карты и нескольких десятков мегабайт под код программы несравненно выше, чем если вы будете заморачиваться с плиской.

ЗЫ: плиску для быстрых вычислений имеет смысл использовать только если на борту графической карты нет аппаратно реализованных операций, а в вашем случае, 32 битные сложения в графических картах наличествуют, и заморачиваться с плиской ИМХО нет смысла.

[planetzeus]

То есть пользовать или не пользовать GPU или ПЛИС будет зависеть только от того, как у вас идут сами эти вычисления. Если вы решите по USB в плиску или с PCIe на графическую карту скармливать эти операции, то скорость будет определяться не скоростью плиски или графической карты, а дыркой, через которую вы это все будете протаскивать и будет как минимум на пару порядков медленнее. Вероятность того, что ваш алгоритм со всеми промежуточными данными поместится в 11GB, которые есть на халяву на борту вашей графической карты и нескольких десятков мегабайт под код программы несравненно выше, чем если вы будете заморачиваться с плиской.

Вот тут спорить даже не буду. Очень возможно что я не прав и на моей GPU будет та же скорость или даже больше. Попробую все-таки написать алгоритм на CUDA и проверить, но сравнить не с чем. С ПЛИС решил заморочиться из-за чисто интуитивного взгляда. Операция типа *2 (для 8 тыс. бит) на GPU нужно эмулировать. 8000 бит/32 ~ 250 операций. Все прочие операции такие же, почти везде нужен цикл и обход всех 250 32-битных чисел. Тогда как логикой это практически сразу.

Нет столько пинов - и не нужно, эти 8000 бит быстрее будут введены через какой-нибудь PCIe или Ethernet.

Говорю ж, обмен данными совсем не главная операция. Загрузили числа, перебираем. Можно загрузить такой диапазон, что перебирать в поисках подходящих значений будет сутками. Поэтому главная цель - скорость перебора в поиске, а не обмен. Ради загрузки 4 значений по 8 тыс. бит раз в сутки - нет необходимости в высокоскоростных интерфейсах.

[AVR]

С ПЛИС решил заморочиться из-за чисто интуитивного взгляда. Операция типа *2 (для 8 тыс. бит) на GPU нужно эмулировать. 8000 бит/32 ~ 250 операций. Все прочие операции такие же, почти везде нужен цикл и обход всех 250 32-битных чисел. Тогда как логикой это практически сразу.

А GPU разве не "логика"? Такая же самая логика, только фиксированная, пользователь лишь задает программу этой фиксированной логике.
Только вот если в ПЛИС задействуются цепи переноса, то откуда же там возникнет "практически сразу"? Ну можно засунуть в рот 5 бутербродов. Только ПЛИС это когда сто ртов независимо едят сто бутеров.
Я вот кое что делал на Spartan-6, ресурсов куча, а ячеек с переносом не осталось. Переделал на встроенных умножителях - влезло. Может для суммирования и сдвига тоже можно нечто подобное провернуть, но не факт что оно таки не сожрет "все" с переносом. Я с ПЛИС давно работаю, но некоторые моменты у меня остаются откровенно слабыми, пробелы.

ЗЫ: плиску для быстрых вычислений имеет смысл использовать только если на борту графической карты нет аппаратно реализованных операций, а в вашем случае, 32 битные сложения в графических картах наличествуют, и заморачиваться с плиской ИМХО нет смысла

Вот тут согласен, если все равно большое число придется разлохматить на кусочки, то сомневаюсь что ПЛИС даст выигрыш. Если конвейеризовать это на те же 32/64-битные части, то даже если задержка не критична (а это вроде так), то будет ли выигрыш относительно GPU?

[planetzeus]

Только вот если в ПЛИС задействуются цепи переноса, то откуда же там возникнет "практически сразу"?

Для суммы - да есть переносы, но для 2x+1, к примеру, нет.
Повторюсь, я не утверждаю ничего, допускаю что Вы правы. Но даже если скорость будет сравнима с GPU, я бы предпочел находить нужный мне ряд чисел на FPGA.
Мне сложно сравнивать. Процессор, который интерпретирует команды и в цикле работает с массивом 32-битных чисел или логическая схема внутри FPGA, оптимизированная под конкретную задачу.
На GPU я могу распараллелить задачу на разные диапазоны, но вот как распараллелить суммирование или сдвиг нескольких тысяч бит на разные блоки/потоки не представляю.

Я вот кое что делал на Spartan-6, ресурсов куча, а ячеек с переносом не осталось. Переделал на встроенных умножителях - влезло.

Именно для этого я и создал эту тему. Чтобы хотя бы определиться в какую сторону копать. Поскольку опыта у меня 0, то оценить сколько нужно логических элементов чтобы сделать сумматор для двух 8000-битовых чиел - загадка.

В общем-то я уже сделал первые выводы. Попробую для начала написать на Verilog схему в эмуляторе. Ну и присмотрюсь к облакам вместо реальной железки.

[jojo]

Именно для этого я и создал эту тему. Чтобы хотя бы определиться в какую сторону копать. Поскольку опыта у меня 0, то оценить сколько нужно логических элементов чтобы сделать сумматор для двух 8000-битовых чиел - загадка.

На вдаваясь в зависимости данных вокруг обсуждаемого алгоритма,

На примере Xilinx 1 слайс вычисляет 4 бита суммы, всего битов 8000, значит, слайсов 2000 на ядро.
Например, в Kintex 325T 50950 слайсов, т.е. 25 ядер.
25*500МГц = 12500 млн оп/c.
25*2*8000 = 400000 триггеров, впритык, значит, ядер меньше
Конвейер 250 этапов.

Если в GPU 3000 ядер на 2000 МГц суммируют по 32 бита, то будет
3000*2000*32/8000 = 24000 млн операций /с, и это без учёта влияния архитектуры.

Таким образом, порядок величин один и тот же.

[blackfin]

25*2*8000 = 400000 триггеров, впритык, значит, ядер меньше
Конвейер 250 этапов.

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

Итого:

25*(3*8000+250) = 25*24250 = 606250 триггеров.

[jojo]

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

Итого:

25*(3*8000+250) = 25*24250 = 606250 триггеров.

Да, я даже не спорю. И подробностей этих миллион.
Ещё в моей схеме маячат затраты на сдвиговые регистры на SRL или BRAM. Тем не менее, дело интересное и оно вроде бы в общем может получиться.