CUDA против FPGA?
Я разрабатываю продукт с тяжелыми вычислениями 3D-графики,в значительной степени поиск ближайших точек и диапазонов. Некоторые аппаратные оптимизации были бы полезны. Хотя я мало знаю об этом, мой босс (у которого нет опыта работы с программным обеспечением) защищает FPGA (потому что он может быть адаптирован), а наш младший разработчик защищает GPGPU с CUDA, потому что он дешевый, горячий и открытый. Хотя я чувствую, что мне не хватает суждения в этом вопросе, я считаю, что CUDA-это путь, потому что я беспокоюсь о гибкости, наш продукт все еще под сильным развитием.
Итак, перефразируя вопрос, есть ли вообще причины идти на FPGA? Или есть третий вариант?
16 ответов:
Я исследовал тот же вопрос некоторое время назад. После общения с людьми, которые работали на ПЛИС, это то, что я получаю:
- FPGAs отлично подходят для систем реального времени, где даже 1 мс задержки может быть слишком долго. Это не относится к вашему случаю;
- FPGAs может быть очень быстрым, особенно для четко определенных цифровых методов обработки сигналов (например, радиолокационных данных), но хорошие из них намного дороже и специализированы, чем даже профессиональные GPGPUs;
- FPGAs довольно громоздки для программирования. Поскольку существует компонент конфигурации оборудования для компиляции, это может занять несколько часов. Кажется, он больше подходит для инженеров-электронщиков (которые, как правило, работают на ПЛИС), чем для разработчиков программного обеспечения.
Если вы можете заставить CUDA работать на вас, это, вероятно, лучший вариант на данный момент. Это, безусловно, будет более гибким, чем FPGA.
другие варианты включают ручей от ATI, но пока что-то большое не произойдет, это просто не так хорошо принят, как CUDA. После этого все еще есть все традиционные варианты HPC (кластеры x86/PowerPC/Cell), но все они довольно дороги.
надеюсь, что это поможет.
мы провели некоторое сравнение между FPGA и CUDA. Одна вещь, где CUDA сияет, если вы действительно можете сформулировать свою проблему в SIMD-моде и можете получить доступ к объединенной памяти. Если доступ к памяти не объединен(1) или если у вас есть другой поток управления в разных потоках, GPU может резко потерять свою производительность, и FPGA может превзойти ее. Другое дело, когда ваша операция реально мала, но у вас ее огромное количество. Но вы не можете (например, из-за синхронизации) нет запустите его в цикле в одном ядре, тогда время вызова для ядра GPU превышает время вычисления.
также мощность FPGA может быть лучше (зависит от вашего приложения scenarion, т. е. GPU только дешевле (с точки зрения Ватт/флоп), когда его вычисления все время).
Offcourse FPGA имеет также некоторые недостатки: IO может быть одним (у нас было здесь приложение, нам нужно было 70 Гбит / с, никаких проблем для GPU, но чтобы получить этот объем данных в FPGA вам нужно для обычного дизайна больше контактов, чем доступно). Еще один недостаток-это время и деньги. FPGA намного дороже, чем лучший графический процессор, и время разработки очень велико.
(1) одновременные обращения из разных потоков к памяти должны быть по последовательным адресам. Это иногда действительно трудно достичь.
Я бы пошел с CUDA.
Я работаю в области обработки изображений и пробовал аппаратные дополнения в течение многих лет. Сначала у нас был i860, затем Транспьютер, затем DSP, затем FPGA и прямая компиляция в аппаратное обеспечение.
Что неизбежно произошло, так это то, что к тому времени, когда аппаратные платы были действительно отлажены и надежны, и код был перенесен на них - обычные процессоры продвинулись, чтобы победить их, или архитектура хост-машины изменилась, и мы не могли использовать старые платы или создатели совет директоров обанкротился.придерживаясь чего-то вроде CUDA, вы не привязаны к одному маленькому специалисту-производителю плат FPGA. Производительность графических процессоров улучшается быстрее, чем процессоры, и финансируется геймерами. Это основная технология и поэтому, вероятно, в будущем объединится с многоядерными процессорами и таким образом защитит ваши инвестиции.
FPGAs
- то, что вам нужно:
- узнайте VHDL / Verilog (и поверьте мне, вы не будете)
- купить hw для тестирования, лицензии на инструменты синтеза
- Если вы выбираете некоторые хорошие рамки (например. :RSoC)
- разработка дизайна (и это может занять годы )
- Если вы не:
- DMA, драйвер hw, ультра дорогие инструменты синтеза
- тонны знаний о шинах, памяти сопоставление, синтез гв
- постройте hw, купите IP-ядра
- разработка дизайна
- например средняя FPGA pcie карта с чипом Xilinx virtex-6 стоит более 3000$
- результат:
- Если вам не платит правительство у вас нет достаточно средств.
GPGPU (CUDA/OpenCL)
- У вас уже есть hw для тестирования.
- сравнить с ПЛИС материал:
- все хорошо документированы .
- все дешево
- все работает
- все хорошо интегрировано в языки программирования
- есть облако GPU, а также.
- результат:
- вам нужно просто скачать sdk, и вы можете начать.
CUDA имеет довольно существенную кодовую базу примеров и SDK, включая бэк-энд BLAS. Попробуйте найти некоторые примеры, похожие на то, что вы делаете, возможно, также глядя на GPU Gems серия книг, чтобы оценить, насколько хорошо CUDA будет соответствовать вашим приложениям. Я бы сказал, что с логистической точки зрения CUDA легче работать и намного дешевле, чем любой профессиональный инструментарий разработки FPGA.
в какой-то момент я действительно заглянул CUDA для имитационного моделирования резерва претензий. Есть очень хороший цикл лекций, связанных с веб-сайта для обучения. В Windows вам нужно убедиться, что CUDA работает на карте без дисплеев, поскольку графическая подсистема имеет сторожевой таймер, который будет уничтожать любой процесс, работающий более 5 секунд. Этого не происходит в Linux.
любой mahcine с двумя слотами PCI-e x16 должен поддерживать это. Я использовал HP XW9300, который вы можете забрать с ebay довольно дешево. Если вы это сделаете, убедитесь, что он имеет два процессора (а не один двухъядерный процессор), поскольку слоты PCI-e живут на отдельных шинах Гипертранспорта, и вам нужно два процессора в машине, чтобы обе шины были активны.
очевидно, что это сложный вопрос. Вопрос может также включать в себя процессор ячейки. И, вероятно, нет ни одного ответа, который был бы правильным для других связанных с этим вопросов.
по моему опыту, любая реализация, выполненная абстрактным образом, т. е. скомпилированная реализация языка высокого уровня против реализации уровня машины, неизбежно будет иметь затраты на производительность, особенно в реализации сложного алгоритма. Это справедливо как для ПЛИС, так и для процессоров любого типа. ПЛИС предназначен в частности, для реализации сложного алгоритма будет работать лучше, чем ПЛИС, элементы обработки которых являются универсальными, что позволяет ему степень программируемости от входных регистров управления, ввода-вывода данных и т. д.
другой общий пример, где FPGA может быть гораздо более высокой производительностью, - это каскадные процессы, где выходы процесса становятся входами в другой, и они не могут выполняться одновременно. Каскадные процессы в ПЛИС просты и могут значительно снизить требования к вводу/выводу памяти в то время как память процессора будет использоваться для эффективного каскадирования двух или более процессов, где есть зависимости данных.
то же самое можно сказать о GPU и CPU. Алгоритмы, реализованные в C, выполняемые на CPU, разработанном без учета присущих характеристик производительности кэш-памяти или системы основной памяти, не будут выполняться так же, как и реализованный, который это делает. Конечно, не учитывая эти характеристики производительности упрощает реализацию. Но на спектакле стоимость.
Не имея прямого опыта работы с графическим процессором, но зная присущие ему проблемы с производительностью системы памяти, он тоже будет подвержен проблемам с производительностью.
Я разработчик CUDA с очень небольшим опытом работы с FPGA: s, однако я пытался найти сравнения между ними.
к чему я пришел до сих пор:
графический процессор имеет гораздо более высокую (доступную ) пиковую производительность Он имеет более благоприятное соотношение флоп / ватт. Это дешевле Он развивается быстрее (довольно скоро у вас будет буквально "настоящий" TFLOP). Проще запрограммировать (читайте статью по этому не личному мнению)
обратите внимание, что я говоря реальный / доступный, чтобы отличить от чисел, которые вы увидите в рекламе GPGPU.
но gpu не является более благоприятным, когда вам нужно сделать произвольный доступ к данным. Это, надеюсь, изменится с новой архитектурой Nvidia Fermi, которая имеет дополнительный кэш l1/l2.
мои 2 цента
Это старый поток, запущенный в 2008 году, но было бы неплохо рассказать, что произошло с программированием FPGA с тех пор: 1. C to gates в FPGA-это основная разработка для многих компаний с огромной экономией времени по сравнению с Verilog/SystemVerilog HDL. В C для разработки системного уровня ворота-это самое трудное. 2. OpenCL на FPGA существует в течение 4+ лет, включая развертывание с плавающей запятой и "облако" от Microsoft (Asure) и Amazon F1 (Ryft API). С дизайном системы OpenCL относительно легко из-за очень хорошо определенная модель памяти и API между хостом и вычислительными устройствами.
программистам просто нужно немного узнать об архитектуре FPGA, чтобы иметь возможность делать то, что даже невозможно с графическими процессорами и процессорами по причинам как фиксированного кремния, так и отсутствия широкополосных (100Gb+) интерфейсов к внешнему миру. Масштабирование геометрии чипа больше невозможно, ни извлечение большего количества тепла из одного пакета чипов без его плавления, поэтому это похоже на конец пути на один пакет чипсов. Мой тезис здесь заключается в том, что будущее принадлежит параллельному программированию многокристальных систем, и ПЛИС имеют большие шансы быть впереди игры. Проверьтеhttp://isfpga.org/ Если у вас есть опасения по поводу производительности и т. д.
Что вы развертываете? Кто ваш клиент? Даже не зная ответов на эти вопросы, я бы не использовал FPGA, если вы не строите систему в реальном времени и не имеете инженеров-электриков/компьютерных инженеров в своей команде, которые знают языки описания оборудования, такие как VHDL и Verilog. Там много к нему, и это занимает другое настроение, чем обычное программирование.
Плис впали в немилость в секторе HPC, потому что они ужасны для программирования. CUDA находится в том, что это намного лучше программировать и все равно даст вам хорошую производительность. Я бы пошел с тем, что сообщество HPC пошло С и сделать это в CUDA. Это проще, это дешевле, это более ремонтопригодно.
другие дали хорошие ответы, просто хотели добавить другую перспективу. Вот мой опрос статьи опубликовано в ACM Computing Surveys 2015 (его постоянная ссылка здесь), который сравнивает GPU с FPGA и CPU по метрике энергоэффективности. Большинство статей отчета: ПЛИС является более энергоэффективной, чем ГПУ, который, в свою очередь, является более энергоэффективной, чем процессор. Поскольку бюджеты мощности фиксированы (в зависимости от возможности охлаждения), энергоэффективность FPGA означает, что можно сделать больше вычисления в пределах того же бюджета мощности с FPGA, и, таким образом, получить лучшую производительность с FPGA, чем с GPU. Конечно, также учитываются ограничения FPGA, как упоминалось другими.
FPGA не будет благоволить к тем с предвзятостью програмного обеспечения по мере того как им нужно выучить HDL или хотя бы понять systemC.
для тех, кто с аппаратным смещением FPGA будет первым рассмотренным вариантом.
на самом деле требуется твердое понимание обоих, и тогда может быть принято объективное решение.
OpenCL предназначен для работы как на FPGA, так и на GPU, даже CUDA может быть портирован на FPGA.
FPGA и GPU ускорители могут использоваться вместе
Так это не тот случай, когда лучше то или другое. Существует также дискуссия о CUDA vs OpenCL
опять же, если вы не оптимизировали и бенчмаркинг как для вашего конкретного приложения вы не можете знать со 100% уверенностью.
многие просто пойдут с CUDA из-за его коммерческого характера и ресурсов. Другие пойдут с openCL из-за его универсальности.
по крайней мере GTC'13 Многие люди HPC согласились, что CUDA здесь, чтобы остаться. FGPA громоздки, CUDA становится довольно зрелой поддержкой Python/C/C++/ARM.. в любом случае, это был устаревший вопрос
- Плис более параллельны, чем графические процессоры, на три порядка величины. В то время как хороший GPU имеет тысячи ядер, FPGA может иметь миллионы программируемых ворот.
- в то время как ядра CUDA должны выполнять очень похожие вычисления, чтобы быть продуктивными, ячейки FPGA действительно независимы друг от друга.
- FPGA может быть очень быстрым с некоторыми группами задач и часто используется там, где миллисекунда уже рассматривается как большая продолжительность.
- ядро GPU намного мощнее чем клетка FPGA, и гораздо легче запрограммировать. Это ядро, может делить и умножать без проблем, когда ячейка FPGA способна только к довольно простой булевой логике.
- как ядро GPU является базовый, это эффективно, чтобы запрограммировать его в C++. Даже это также можно запрограммировать FPGA на C++, это неэффективно (просто "продуктивно"). Необходимо использовать специализированные языки, такие как VDHL или Verilog - их трудно и сложно освоить.
- большинство из истинных и пробовал инстинкты инженера-программиста бесполезны с FPGA. Вы хотите цикл С этими воротами? Из какой ты галактики? Вам нужно изменить мышление инженера-электронщика, чтобы понять этот мир.
Программирование GPU в CUDA, безусловно, проще. Если у вас нет опыта программирования Плис в HDL, это почти наверняка будет слишком сложной задачей для вас, но вы все равно можете запрограммировать их с помощью OpenCL, который похож на CUDA. Однако это сложнее реализовать и, вероятно, намного дороже, чем программирование графических процессоров.
какой из них быстрее?
GPU работает быстрее, но FPGA может быть более эффективным.
GPU имеет потенциал работы на скорости выше, чем FPGA может когда-либо достичь. Но только для алгоритмов, которые специально для этого подходят. Если алгоритм не является оптимальным, GPU потеряет много производительности.
FPGA, с другой стороны, работает намного медленнее, но вы можете реализовать проблемное оборудование, которое будет очень эффективным и выполнять работу за меньшее время.
Это вроде как есть суп с вилкой очень быстро против есть его с ложкой больше медленно.
оба устройства основывают свою производительность на распараллеливании, но каждый немного по-другому. Если алгоритм можно гранулировать на множество частей, которые выполняют одни и те же операции (ключевое слово: SIMD), GPU будет быстрее. Если алгоритм может быть реализован в виде длинного конвейера, ПЛИС будет быстрее. Кроме того, если вы хотите использовать плавающую точку, FPGA не будет очень доволен этим :)
этой теме я посвятил всю свою магистерскую диссертацию. ускорение алгоритма на ПЛИС с OpenCL