2008-11-25 7 views
51

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

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

+2

Хотелось бы узнать, что люди думают о том, как Cell стекается против двух. – 0fnt 2012-06-11 13:21:07

ответ

41

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

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

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

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

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

+32

«CUDA будет, безусловно, более гибким, чем FPGA», является ложным. Для CUDA вам нужно крутить и превращать свой алгоритм в очень специфические способы, чтобы наслаждаться ускорением. С FPGA вы можете делать все, что хотите - т. Е.реализуйте специализированные процедуры вычислений, специально разработанные для вашего алгоритма. Конечно, для этого требуется компиляция программирования HDL, поэтому CUDA действительно более доступно для программистов. – 2009-04-30 05:51:52

+3

Теперь FPGA можно запрограммировать с помощью OpenCL - https://www.altera.com/products/design-software/embedded-software-developers/opencl/overview.html Это должно сделать FPGA более привлекательными для программистов. – ProfNimrod 2016-01-28 14:56:31

+1

Вот большой [статья] (http://mil-embedded.com/articles/fpga-gpu-evolution-continues/), где обсуждается, почему военные США уходят от ПЛИС в пользу GPU. В нем обсуждается точность с плавающей запятой, латентность, прямой доступ к памяти и различия в потреблении энергии между ними. – Stan 2017-03-01 15:46:13

3

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

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

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

14

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

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

+0

Процессоры больше не продвигаются. Однако теперь у нас есть Xeon Phi (512-бит SIMD), которые похожи. – 2014-03-07 13:29:05

+0

Я слышал, что вы @MartinBeckett о том, чтобы быть независимым от FPGA. Но имейте в виду, что UnifiedDeviceArch от nvidia светит только на чипах nVIDIA ;-) Таким образом, вы все равно получаете зависимость. Вот почему OpenCL 2.0 с SPIR, основанный на сильной кодовой базе LLVM, похоже на способ (февраль 2016) – 2016-02-02 11:13:45

+0

@NikYotis, это было написано в 08, и я сказал «что-то вроде CUDA». Сегодня я бы посмотрел OpenCL на общую проблему, но у CUDA, вероятно, есть преимущество, если вам нужна максимальная производительность сейчас – 2016-02-02 13:54:38

46

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

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

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

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

4

Решение на основе ПЛИС, вероятно, будет дороже, чем CUDA.

3

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

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

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

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

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

2

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

3

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

То, что я пришел к выводу, до сих пор:

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

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

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

мои 2 цента

1

ПВМ упал в немилость в ГПЦ секторе, поскольку они horrorterror программировать. CUDA работает, потому что гораздо лучше работать и все равно даст вам хорошую производительность. Я бы пошел с тем, что сообщество HPC прошло, и сделайте это в CUDA. Это проще, это дешевле, это более удобно.

1

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

8

ПВМ

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

GPGPU (CUDA/OpenCL)

  • У вас уже есть HW, чтобы проверить на.
  • Сравнение с продукцией ПЛИС:
    • Все хорошо документировано.
    • Все дешево
    • Все работает
    • Все хорошо интегрированы языки программирования
  • Существует облако GPU, а также.
  • Результат:
    • Вам нужно просто скачать SDK и вы можете начать.
2

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

2

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

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

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

OpenCL предназначен для работы на обоих графических процессорах FPGA &, даже CUDA можно портировать на FPGA.

FPGA & ускорители GPU могут быть использованы вместе

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

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

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

3

Это старая тема, начатая в 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/, если у вас есть сомнения по поводу производительности и т.д.

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