caxapa.ru :: Похоже, есть одна тема, где бы это реально помогло. САПРы. Аппаратный матричный вчислитель. Чтобы с матрицами complex double можно было быстро работать. Думаю, тут все процы можно этой штукой натянуть. Но в качестве конкурента остаются GPU

Evgeny_CD, Архитектор (14.02.2010 14:36, просмотров: 273) ответил amusin на А задачу придумывать не надо - объявляете contest/challenge/etc и вуаля :-)

Похоже, есть одна тема, где бы это реально помогло. САПРы. Аппаратный матричный вчислитель. Чтобы с матрицами complex double можно было быстро работать. Думаю, тут все процы можно этой штукой натянуть. Но в качестве конкурента остаются GPU - там совсем скоро будет не просто умножителей, а ядер с плавучной 1к на кристалле.

Ответить

- эээ! какой там complex double!? FPU в плисинах получается мерзкий! как раз на GPU тучи FPU уже норма. а вот целочисленка да - тут FPGA вне конкуренции. - Mahagam(14.02.2010 15:38)
  - Хм! А вы подали мысль! Если сделать блок целочисленной арифметики 256 бит, то он по динамическому диапазону будет как float single precsigion, а то точности на голову выше! 256 бит на проце общего назначения можно утомиться считать. А тут, есди Evgeny_CD(50 знак., 14.02.2010 16:22)
    - эээ. лишняя трата ресурсов. 256 бит не нужно лишь потому, что полученные из реального мира данные редко бывают точнее 20 бит. получаем громадную избыточность по железу. проще для такой задачи виртуальную запятую двигать "в уме" но держать результать в Mahagam(262 знак., 14.02.2010 16:41)
      - 1) это для саентистов, а не для реального мира. 2) я говорю (теортеически) про некий загадочный класс алгоритмов, в которых нужно все 256 бит, и при этом они дают на порядок лучшие результаты, чем при дабле. В чем они могут состоять, эти алгоритмы - я не Evgeny_CD(6 знак., 14.02.2010 16:45)
        
        ну для таких извращенцев и double на компе сойдёт. комп-то уже на столе стоит, и в нём всякая порнуха крутится, почему бы одно из кучи ядер не нагрузить идиотскими расчётами :) все равно простаивает. Mahagam(208 знак., 14.02.2010 16:49)
        
        Да хрен с ним, девайсом этим. Пока хачу чиста тыоретыцски узреть, есть ли где алгоритмы, которым эти 256 бит в большом количестве нужны? - Evgeny_CD(14.02.2010 16:57)
        
        Итерационные решалки линейных систем с сильно разрешенными матрицами, которые еще в добавок плохо обусловленны, например, из вычислительной газодинамики. При числе неизвестных от 100 миллионов, двойной точности обычно не хватает, приходится переходить на МПП-ARM(210 знак., 18.02.2010 05:08)
        
        какой физический смысл такой точности - я не представляю. - Mahagam(18.02.2010 14:18)
        
        Скалярное произведение падает :) МПП-ARM(310 знак., 18.02.2010 14:42)
        
        шЫфравание! и коммутация сигналов. местами проще вести широкой шиной, но с низкой частотой. чем тракаццо со зверскими таймингами. - Mahagam(14.02.2010 16:59)
        
        Шифрование - понятно, откладываем. Коммутатор потоков E1 на умножителях - за это производители плисин поставят Вам памятник, остальные IP коммутацией как-то занимаются. Что еще? - Evgeny_CD(14.02.2010 17:05)
        
        не. я коммутацию упомянул в контексте 256 бит, а не в связи с умножителями. Mahagam(113 знак., 14.02.2010 17:14)
        
        Мысль глубокая, но не до конца верная. Да, основные физические констарты известны с точностью хуже 256 бит. Но! Evgeny_CD(387 знак., 14.02.2010 17:20)
        
        а теперь выведите наружу в оконечное устройство полученные 256 бит. и что? нет чем отобразить такой диапазон. Mahagam(466 знак., 14.02.2010 17:27)
  - Во! Я понял, что альтере надо делать по 28 нм! 1к DSP блоков с FPU!!! Double очень жалетельно :) - Evgeny_CD(14.02.2010 16:10)
    - а вот хрен! :))) Mahagam(798 знак., 14.02.2010 16:27)
      - Хм...В моем понимании все современные нормальные видеообработчики так и устроены. Тот же давинчи - там DSP на всякие "тайлы" и ARM на "С код". Железные кодеры типа аппаратных ускорителей i.MX* фрискаликовские тоже так устроены, токо там "тайлы" в Evgeny_CD(8 знак., 14.02.2010 16:35)
        
        угу. только что те блоки жёстко заточены под узкий ассортимент алгоритмов. типа h264 жмём, mpeg4 тоже жмём, а вот какой-нить vc-1 ой, не можем. - Mahagam(14.02.2010 16:44)
        
        Дык оптимальность связки CPU +FPGA предсказана лучшими умами конференции еще 2.5 года назад :) -> - Evgeny_CD(14.02.2010 16:48, ссылка)
        
        вместо FPGA в процах на самые популярные задачи втиснуты аппаратные блоки. и этим FPGA вытесняется из круга оптимальности, кроме того, пока что и ценник на ПЛИСины не такой уж и оптимальный. - Mahagam(14.02.2010 16:53)
        
        Оптимальная структура H.264 кодека пока в процессе споров. Ценники до $100 похоже, будут иметь чуть ли не все Spartan-6, а там есть нехилые камушки. - Evgeny_CD(14.02.2010 17:07)

Программируемая логика и ЦОС