Подтвердить что ты не робот

CUDA против FPGA?

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

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

4b9b3361

Ответ 1

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

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

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

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

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

Ответ 2

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

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

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

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

Ответ 3

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

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

Ответ 4

ПВМ

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

GPGPU (CUDA/OpenCL)

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

Ответ 5

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

Ответ 6

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

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

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

Ответ 7

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

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

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

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

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

Ответ 8

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

То, что я сделал до сих пор:

Графический процессор имеет намного более высокую (доступную) пиковую производительность Он имеет более благоприятное соотношение FLOP/Watt. Это дешевле Он развивается быстрее (довольно скоро у вас будет буквально "реальный" TFLOP). Проще программировать (читайте статью об этом не личном мнении)

Обратите внимание, что я говорю "реальный/доступный", чтобы отличать цифры, которые вы увидите в рекламной ролике GPGPU.

НО gpu не является более благоприятным, когда вам нужно делать произвольный доступ к данным. Это, мы надеемся, изменится с новой архитектурой Nvidia Fermi, которая имеет дополнительный кеш l1/l2.

мои 2 цента

Ответ 9

Это старый поток, начатый в 2008 году, но было бы полезно узнать, что случилось с программированием FPGA с тех пор: 1. C для ворот в FPGA является основной разработкой для многих компаний с огромным экономией времени и Verilog/SystemVerilog HDL. В C к воротам. Системный уровень - сложная часть. 2. OpenCL на FPGA существует в течение 4 лет, включая развертывание с плавающей точкой и "облаком" Microsoft (Asure) и Amazon F1 (API-интерфейс API). С дизайном системы OpenCL относительно легко из-за очень хорошо определенной модели памяти и API между хостом и вычислительными устройствами.

Пользователям программного обеспечения просто нужно немного узнать о архитектуре FPGA, чтобы иметь возможность делать вещи, которые НЕ МОГУТ ВОЗМОЖНО с графическими процессорами и процессорами, поскольку они являются фиксированными кремниевыми и не имеют широкополосных (100 Гбит +) интерфейсов для внешнего мира. Масштабирование геометрии чипов становится невозможным, а также не выделяет больше тепла из одного чип-пакета без его таяния, так что это похоже на конец дороги для чипов с одним пакетом. Мой тезис здесь заключается в том, что будущее относится к параллельному программированию многочиповых систем, а FPGA имеют отличную возможность опередить игру. Проверьте http://isfpga.org/, если у вас есть проблемы с производительностью и т.д.

Ответ 10

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

Ответ 11

Другие дали хорошие ответы, просто хотели добавить другую точку зрения. Вот мой обзор документ, опубликованный в ACM Computing Surveys 2015 (его постоянная ссылка здесь), который сравнивает GPU с FPGA и CPU по метрике энергоэффективности. В большинстве отчетов говорится: FPGA более энергоэффективен, чем GPU, что, в свою очередь, более энергоэффективно, чем процессор. Так как энергетические бюджеты фиксированы (в зависимости от возможностей охлаждения), энергоэффективность FPGA означает, что можно делать больше вычислений в рамках одного энергопотребления с FPGA и, таким образом, получать более высокую производительность с FPGA, чем с GPU. Разумеется, также учитываются ограничения FPGA, как упоминалось другими.

Ответ 12

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

Ответ 13

последнее время GTC'13 многие люди HPC согласились, что CUDA здесь останется. FGPA громоздки, CUDA становится более зрелым, поддерживающим Python/C/С++/ARM.. в любом случае, это был датированный вопрос

Ответ 14

FPGA не будет одобряться теми, у кого есть предвзятость программного обеспечения, поскольку им необходимо изучить HDL или хотя бы понять systemC.

Для тех, у кого есть аппаратное отклонение FPGA, будет рассмотрен первый вариант.

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

OpenCL предназначен для работы как на FPGA, так и на GPU, даже CUDA можно портировать на FPGA.

Ускорители FPGA и GPU могут использоваться вместе

Так что это не случай того, что лучше того или другого. Существует также дискуссия о CUDA vs OpenCL

Опять же, если вы не оптимизировали и не сравнили результаты с вашим конкретным приложением, вы не можете знать со 100% уверенностью.

Многие просто пойдут с CUDA из-за своего коммерческого характера и ресурсов. Другие будут работать с openCL из-за своей универсальности.