CUDA против FPGA?

Я разрабатываю продукт с тяжелыми 3D-графическими вычислениями,в значительной степени ближайший поиск точки и диапазона. Была бы полезна некоторая аппаратная оптимизация. Хотя я мало знаю об этом, мой босс (у которого нет опыта работы с программным обеспечением) защищает FPGA (потому что его можно адаптировать), в то время как наш младший разработчик защищает GPGPU с CUDA, потому что его дешевый, горячий и открытый. Хотя я чувствую, что мне не хватает суждения в этом вопросе, я считаю, что CUDA-это путь, потому что я беспокоюсь о гибкости, наш продукт все еще под сильным развитием.

Итак, перефразируя вопрос, есть ли какие-либо причины вообще идти на FPGA? Или есть третий вариант?

16 ответов


Я исследовал тот же вопрос некоторое время назад. После общения с людьми, которые работали на FPGAs, это то, что я получаю:

  • FPGAs отлично подходят для систем реального времени, где даже 1 мс задержки может быть слишком долго. Это не относится к вашему случаю;
  • FPGAs может быть очень быстрым, espeically для четко определенных цифровых применений обработки сигналов (например, радиолокационных данных), но хорошие из них намного дороже и специализированы, чем даже профессиональные GPGPUs;
  • FPGAs довольно громоздкая программа. Поскольку существует компонент конфигурации оборудования для компиляции, это может занять несколько часов. Кажется, он больше подходит для инженеров-электронщиков (которые, как правило, работают на FPGAs), чем для разработчиков программного обеспечения.

Если вы можете заставить CUDA работать на вас, это, вероятно, лучший вариант на данный момент. Он, безусловно, будет более гибким, чем FPGA.

другие варианты включают Брук от ATI, но пока что - то большое не произойдет, это просто не так хорошо, как CUDA. После этого все еще есть все традиционные параметры HPC (кластеры x86/PowerPC/Cell), но все они довольно дороги.

надеюсь, это поможет.


мы провели некоторое сравнение между FPGA и CUDA. Одна вещь, где CUDA сияет, если вы можете реально сформулировать свою проблему в SIMD-режиме и можете получить доступ к памяти. Если доступ к памяти не объединен(1) или если у вас другой поток управления в разных потоках, GPU может резко потерять свою производительность, и FPGA может превзойти его. Другое дело, когда ваша операция небольшая, но у вас ее огромное количество. Но вы не можете (например, из-за синхронизации) нет запустите его в цикле в одном ядре, тогда время вызова для ядра GPU превысит время вычисления.

также мощность FPGA может быть лучше (зависит от вашего сценария приложения, т. е. GPU только дешевле(с точки зрения Ватт / флоп), когда его вычисления все время).

Offcourse FPGA также имеет некоторые недостатки: IO может быть одним (у нас было здесь приложение, нам нужно было 70 Гбит / с, никаких проблем для GPU, но чтобы получить этот объем данных в FPGA, вам нужно для обычного дизайна больше штырей чем доступный). Еще один недостаток-время и деньги. FPGA намного дороже, чем лучший GPU, и время разработки очень велико.

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


Я бы пошел с CUDA.
Я работаю в области обработки изображений и уже много лет пробую аппаратные дополнения. Сначала у нас был i860, затем Транспьютер, затем DSP, затем FPGA и direct-compiliation-to-hardware.
Что неизбежно произошло, так это то, что к тому времени, когда аппаратные платы были действительно отлажены и надежны, и код был перенесен на них - обычные процессоры продвинулись, чтобы победить их, или архитектура хостинга изменилась, и мы не могли использовать старые платы, или создатели совет директоров обанкротился.

придерживаясь чего-то вроде CUDA, вы не привязаны к одному маленькому специалисту-изготовителю плат FPGA. Производительность графических процессоров улучшается быстрее, чем процессоры и финансируется геймерами. Это основная технология и поэтому, вероятно, объединится с многоядерными процессорами в будущем и поэтому защитит ваши инвестиции.


FPGAs

  • то, что вам нужно:
    • узнайте VHDL / Verilog (и поверьте мне, вы не будете)
    • купить hw для тестирования, лицензии на инструменты синтеза
    • Если вы выбираете некоторые хорошие рамки (например. : RSoC)
      • разработка дизайна (и это может занять годы )
    • Если вы не:
      • DMA, водитель hw, ультра дорогие инструменты синтеза
      • тонны знаний о автобусах, памяти сопоставление, синтез гв
      • построить hw, купить IP-ядра
      • разработка дизайна
  • например средняя FPGA pcie карта с чипом Xilinx virtex-6 стоит более 3000$
  • результат:
    • Если вам не платит правительство, у вас недостаточно средств.

GPGPU (CUDA/OpenCL)

  • У вас уже есть hw для тестирования.
  • сравнить с Материал FPGA:
    • все хорошо документированы .
    • все дешево
    • все работает
    • все хорошо интегрировано в языки программирования
  • есть облако GPU, а также.
  • результат:
    • вам нужно просто загрузить sdk, и вы можете начать.

решение на основе FPGA, вероятно, будет намного дороже, чем CUDA.


CUDA имеет довольно существенную кодовую базу примеров и SDK, включая BLAS back-end. Попробуйте найти примеры, похожие на то, что вы делаете, возможно, также глядя на GPU Gems серия книг, чтобы оценить, насколько хорошо CUDA будет соответствовать вашим приложениям. Я бы сказал, с логистической точки зрения, CUDA легче работать и намного, намного дешевле, чем любой профессиональный инструментарий разработки FPGA.

в какой-то момент я заглянул в CUDA для имитационного моделирования запасов претензии. Есть очень хороший цикл лекций, связанных с веб-сайта для обучения. В Windows вам нужно убедиться, что CUDA работает на карте без дисплеев, поскольку графическая подсистема имеет таймер сторожевого пса, который будет уничтожать любой процесс, работающий более 5 секунд. Этого не происходит в Linux.

любой mahcine с двумя слотами PCI-e x16 должен поддерживать это. Я использовал HP XW9300, который вы можете забрать с ebay довольно дешево. Если у вас, убедитесь, что он имеет два процессора (а не один двухъядерный процессор), поскольку слоты PCI-e живут на отдельных шинах Гипертранспорта, и вам нужно два процессора в машине, чтобы обе шины были активны.


очевидно, что это сложный вопрос. Вопрос может также включать процессор ячейки. И, вероятно, нет ни одного правильного ответа на другие связанные с этим вопросы.

по моему опыту, любая реализация, выполненная абстрактно, т. е. скомпилированная реализация языка высокого уровня против реализации уровня машины, неизбежно будет иметь стоимость производительности, esp в реализации сложного алгоритма. Это относится как к FPGA, так и к процессорам любого типа. Разработанный FPGA в частности, для реализации сложного алгоритма будет работать лучше, чем FPGA, элементы обработки которых являются общими, что позволяет ему степень программируемости от входных регистров управления, ввода-вывода данных и т. д.

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

то же самое можно сказать о GPU и CPU. Алгоритмы, реализованные в C, выполняющиеся на CPU, разработанном без учета присущих характеристик производительности кэш-памяти или системы основной памяти, не будут выполняться так же, как и реализованные, которые это делают. Конечно, не учитывая эти характеристики производительности упрощает реализацию. Но на спектакле стоимость.

Не имея прямого опыта работы с GPU, но зная его присущие проблемы с производительностью системы памяти, он также будет подвержен проблемам производительности.


Я разработчик CUDA с очень небольшим опытом работы с FPGA: s, однако я пытался найти сравнение между ними.

Что я заключил:

GPU имеет гораздо более высокую (доступную ) пиковую производительность Он имеет более благоприятное соотношение флоп / ватт. Это дешевле Он развивается быстрее (довольно скоро у вас будет буквально "настоящий" 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+) интерфейсов к внешнему миру. Масштабирование геометрии чипа больше невозможно, а также извлечение большего количества тепла из одного чипового пакета без его плавления, поэтому это похоже на конец пути на один пакет чипсов. Мой тезис здесь заключается в том, что будущее принадлежит параллельному программированию многокристальных систем, и FPGAs имеют большие шансы опередить игру. Проверьтеhttp://isfpga.org/ Если у вас есть проблемы с производительностью и т. д.


Что ты на развертывание? Кто ваш клиент? Даже не зная ответов на эти вопросы, я бы не стал использовать FPGA, если вы не создаете систему в реальном времени и не имеете инженеров-электриков/инженеров-компьютерщиков в своей команде, которые знают языки описания оборудования, такие как VHDL и Verilog. Это очень много, и для этого требуется другое мышление, чем обычное программирование.


Плис впали в немилость в сфере высокопроизводительных вычислений, потому что они horrorterror к программе. CUDA находится, потому что это намного приятнее программировать и все равно даст вам хорошую производительность. Я бы пошел с тем, что сообщество HPC пошло С и сделать это в CUDA. Так проще, дешевле,удобнее.


другие дали хорошие ответы, просто хотели добавить другую перспективу. Вот мой обзор статьи опубликовано в ACM Computing Surveys 2015 (его постоянная ссылка здесь), который сравнивает GPU с FPGA и CPU по метрике энергоэффективности. Большинство статей сообщают: FPGA более энергоэффективна, чем GPU, который, в свою очередь, более энергоэффективен, чем 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.. в любом случае, это был устаревший вопрос


  • FPGAs более параллельны, чем графические процессоры, на три порядка величины. В то время как хороший GPU имеет тысячи ядер, FPGA может иметь миллионы программируемых ворот.
  • в то время как ядра CUDA должны делать очень похожие вычисления, чтобы быть продуктивными, ячейки FPGA действительно независимы друг от друга.
  • FPGA может быть очень быстрым с некоторыми группами задач и часто используется там, где миллисекунда уже рассматривается как большая продолжительность.
  • ядро GPU является более мощным чем клетка FPGA, и очень легкий для того чтобы запрограммировать. Это ядро, может делить и умножать без проблем, когда ячейка FPGA способна только на довольно простую логику.
  • как ядро GPU является базовый, эффективно программировать его на C++. Даже это также можно запрограммировать FPGA на C++, это неэффективно (просто "продуктивно"). Необходимо использовать специализированные языки, такие как VDHL или Verilog - их трудно и сложно освоить.
  • большинство истинных и попытался инстинкты инженера-программиста бесполезны с FPGA. Вы хотите цикл С этими воротами? Из какой вы галактики? Вам нужно изменить мышление инженера-электронщика, чтобы понять этот мир.

Программирование GPU в CUDA определенно проще. Если у вас нет опыта программирования FPGAs в HDL, это почти наверняка будет слишком сложной задачей для вас, но вы все равно можете запрограммировать их с помощью OpenCL, который похож на CUDA. Однако это сложнее реализовать и, вероятно, намного дороже, чем программирование графических процессоров.

какой из них быстрее?

GPU работает быстрее, но FPGA может быть более эффективным.

GPU имеет потенциал работы на скорости выше, чем FPGA может когда-либо достичь. Но только для алгоритмов, которые специально для этого подходят. Если алгоритм не является оптимальным, GPU потеряет большую производительность.

FPGA, с другой стороны, работает намного медленнее, но вы можете реализовать проблемное оборудование, которое будет очень эффективным и сделает все за меньшее время.

Это как есть суп вилкой очень быстро, и едят его с ложкой больше медленно.

оба устройства основывают свою производительность на распараллеливании, но каждый немного по-разному. Если алгоритм можно гранулировать на множество частей, которые выполняют одни и те же операции (ключевое слово: SIMD), GPU будет быстрее. Если алгоритм может быть реализован как длинный конвейер, FPGA будет быстрее. Кроме того, если вы хотите использовать плавающую точку, FPGA не будет очень доволен этим :)

Я посвятил этой теме всю свою магистерскую диссертацию. ускорение алгоритма на FPGA с OpenCL