CUDA vs FPGA?

Question

Estoy desarrollando un producto con pesados ​​cálculos de gráficos en 3D, en gran medida las búsquedas de punto y rango más cercanas. Algo de optimización de hardware sería útil. Aunque sé muy poco de esto, mi jefe (que no tiene experiencia en software) aboga por FPGA (porque se puede adaptar), mientras que nuestro desarrollador junior defiende GPGPU con CUDA, porque es barato, atractivo y abierto. Si bien siento que no tengo buen juicio en esta cuestión, creo que CUDA es el camino a seguir, también porque estoy preocupado por la flexibilidad, nuestro producto aún se encuentra en fuerte desarrollo.

Así, reformulando la pregunta, ¿hay razones para ir de FPGA en absoluto? ¿O hay una tercera opción?

Answer 1

Investigué la misma pregunta hace un tiempo. Después de charlar con personas que han trabajado en FPGAs, esto es lo que me sale:

• FPGAs son ideales para sistemas de tiempo real, donde hasta 1 ms de retardo puede ser demasiado largo. Esto no aplica en tu caso;
• FPGAs pueden ser muy rápido, espeically para usos bien definidos de procesamiento de señales digitales (por ejemplo, datos de radar), pero los buenos son mucho más caros y especializados que GPGPUs incluso profesional;
• FPGA son bastante engorrosos para programar. Dado que hay un componente de configuración de hardware para compilar, podría tomar horas. Parece ser más adecuado para los ingenieros electrónicos (que generalmente son los que trabajan en FPGA) que los desarrolladores de software.

Si puede hacer que CUDA trabaje para usted, es probablemente la mejor opción en este momento. Sin duda será más flexible que un FPGA.

Otras opciones incluyen Brook de ATI, pero hasta que suceda algo grande, simplemente no es así adoptados como CUDA. Después de eso, todavía hay todas las opciones tradicionales de HPC (clusters de x86/PowerPC/Cell), pero todas son bastante caras.

Espero que ayude.

Answer 2

CUDA tiene una base de código bastante considerable de ejemplos y un SDK, que incluye a BLAS back-end. Trate de encontrar algunos ejemplos similares a lo que está haciendo, tal vez también mirando la serie de libros GPU Gems, para medir qué tan bien se adaptará CUDA a sus aplicaciones. Diría que desde el punto de vista logístico, CUDA es más fácil de trabajar y mucho, mucho más barato que cualquier kit de herramientas de desarrollo FPGA profesional.

En un momento analicé CUDA para modelar la simulación de reserva de reclamos. Hay una buena serie de conferencias vinculadas desde el sitio web para el aprendizaje. En Windows, debe asegurarse de que CUDA se ejecute en una tarjeta sin pantallas, ya que el subsistema de gráficos tiene un temporizador de vigilancia que activará cualquier proceso que se ejecute durante más de 5 segundos. Esto no ocurre en Linux.

Cualquier mahcine con dos ranuras PCI-e x16 debería soportar esto. Usé un HP XW9300, que puedes comprar en eBay bastante barato. Si lo hace, asegúrese de que tenga dos CPU (no una CPU de doble núcleo) ya que las ranuras PCI-e viven en buses de Hypertransport separados y necesita dos CPU en la máquina para tener ambos buses activos.

Answer 3

Me gustaría ir con CUDA.
Trabajo en el procesamiento de imágenes y he estado probando complementos de hardware durante años. Primero tuvimos i860, luego Transputer, luego DSP, luego FPGA y compilación directa a hardware.
Lo que inevitablemente sucedió fue que cuando las placas de hardware realmente se depuraron y eran confiables y el código se les había transferido, las CPU regulares habían avanzado para superarlas, o la arquitectura de la máquina de alojamiento cambió y no pudimos usar las viejas placas , o los creadores de la junta fracasaron.

Al adherirse a algo como CUDA no está vinculado a un pequeño fabricante especialista de placas FPGA. El rendimiento de las GPU está mejorando más rápido que las CPU y está financiado por los jugadores. Es una tecnología convencional y, por lo tanto, probablemente se fusione con CPU multinúcleo en el futuro y, por lo tanto, proteja su inversión.

Answer 4

Hicimos algunas comparaciones entre FPGA y CUDA. Una cosa es que CUDA brilla si realmente puede formular su problema de una manera SIMD Y puede acceder a la memoria fusionada. Si los accesos a la memoria no están fusionados (1) o si tiene un flujo de control diferente en diferentes subprocesos, la GPU puede perder drásticamente su rendimiento y el FPGA puede superarlo. Otra cosa es cuando su operación es realmente pequeña, pero tiene una gran cantidad de ella. Pero no puede (por ejemplo, debido a la sincronización) no iniciarlo en un bucle en un kernel, entonces sus tiempos de invocación para el kernel GPU excede el tiempo de cálculo.

También la potencia del FPGA podría ser mejor (depende del escenario de su aplicación, es decir, la GPU es solo más económica (en términos de Watts/Flop) cuando está computando todo el tiempo).

La FPGA también tiene algunos inconvenientes: IO puede ser uno (teníamos aquí una aplicación donde necesitábamos 70 GB/s, no hay problema para la GPU, pero para obtener esta cantidad de datos en un FPGA necesita un diseño convencional más pines que disponibles). Otro inconveniente es el tiempo y el dinero. Un FPGA es mucho más costoso que el mejor GPU y los tiempos de desarrollo son muy altos.

(1) El acceso simultáneo desde diferentes hilos a la memoria tiene que ser en direcciones secuenciales. Esto a veces es realmente difícil de lograr.

Answer 5

Solución basada en FPGA es probable que sea mucho más costosa que CUDA.

Answer 6

Obviamente, esta es una pregunta compleja. La pregunta también podría incluir el procesador celular. Y probablemente no haya una sola respuesta que sea correcta para otras preguntas relacionadas.

En mi experiencia, cualquier implementación realizada en forma abstracta, es decir, compilación de alto nivel de lenguaje frente a la implementación a nivel de máquina, inevitablemente tendrá un costo de rendimiento, especialmente en una compleja implementación de algoritmo. Esto es cierto tanto para FPGA como para procesadores de cualquier tipo. Un FPGA diseñado específicamente para implementar un algoritmo complejo funcionará mejor que un FPGA cuyos elementos de procesamiento son genéricos, permitiendo un grado de programabilidad desde registros de control de entrada, datos de E/S, etc.

Otro ejemplo general donde un FPGA puede ser un rendimiento mucho más alto se da en los procesos en cascada donde las salidas del proceso se convierten en las entradas de otro y no se pueden hacer al mismo tiempo. Los procesos en cascada en un FPGA son simples y pueden reducir drásticamente los requisitos de E/S de memoria, mientras que la memoria del procesador se utilizará para conectar en cascada de manera efectiva dos o más procesos donde existen dependencias de datos.

Lo mismo se puede decir de una GPU y una CPU. Los algoritmos implementados en C que se ejecutan en una CPU desarrollada sin tener en cuenta las características de rendimiento inherentes de la memoria caché o el sistema de memoria principal no funcionarán tan bien como uno implementado que sí lo haga. De acuerdo, no considerar estas características de desempeño simplifica la implementación. Pero a un costo de rendimiento.

Al no tener experiencia directa con una GPU, pero conociendo sus problemas de rendimiento del sistema de memoria inherente, también estará sujeto a problemas de rendimiento.

Answer 7

¿En qué está desplegando? ¿Quién es tu cliente? Sin siquiera saber las respuestas a estas preguntas, no usaría un FPGA a menos que esté construyendo un sistema en tiempo real y tenga ingenieros eléctricos/informáticos en su equipo que tengan conocimientos de lenguajes de descripción de hardware como VHDL y Verilog. Hay mucho que hacer y requiere una mentalidad diferente a la programación convencional.

Answer 8

Soy un desarrollador CUDA con muy poca experiencia con FPGA: s, sin embargo, he estado tratando de encontrar comparaciones entre los dos.

Lo que he llegado a la conclusión hasta ahora:

La GPU tiene, con mucho, mayor rendimiento (accesible) pico Tiene una relación de FLOP/vatio más favorable. Es más económico Se está desarrollando más rápido (muy pronto literalmente tendrá un TFLOP "real" disponible). Es más fácil de programar (lea el artículo sobre esta opinión no personal)

Tenga en cuenta que estoy diciendo que es real/accesible para distinguir de los números que verá en un comercial de GPGPU.

PERO la gpu no es más favorable cuando necesita hacer accesos aleatorios a los datos. Es de esperar que esto cambie con la nueva arquitectura Nvidia Fermi que tiene un caché l1/l2 opcional.

mis 2 centavos

Answer 9

FPGAs han caído en desuso en el sector HPC porque son un horrorterror programar. CUDA participa porque es mucho más agradable programar y aún así le dará un buen rendimiento. Me gustaría ir con lo que la comunidad HPC ha ido y hacerlo en CUDA. Es más fácil, es más económico, es más fácil de mantener.

Answer 10

en la última GTC'13 muchas personas de HPC estuvieron de acuerdo en que CUDA llegó para quedarse. de FPGA son engorrosos, CUDA es cada vez bastante más madura apoyo Python/C/C++/ARM .. De cualquier manera, que era una cuestión de fecha

Answer 11

FPGAs

• lo que necesita:
  • Learn VHDL/Verilog (y créeme que no lo hará)
  • Comprar HW para la prueba, licencias de herramientas de síntesis
  • Si elige un buen marco (por ej.: RSoC)
    • Desarrollar el diseño (y puede tomar años)
  • Si no lo hace:
    • DMA, conductor HW, ultra costosas herramientas de síntesis
    • toneladas de conocimiento acerca autobuses, mapeo de memoria, hw synthesis
    • construir el hw, comprar los núcleos ip
    • Desarrollar el diseño
• Por ejemplo la tarjeta PCIe con media FPGA Xilinx chip Virtex-6 cuesta más de $ 3000
• Resultado:
  • Si no le pagan por el gobierno que no tiene suficientes fondos .

GPGPU (CUDA/OpenCL)

• Ya tiene hw a prueba en ella.
• Comparar con FPGA cosas:
  • Todo está bien documentado.
  • Todo es barato
  • Todo funciona
  • Todo está bien integrado a los lenguajes de programación
• Hay GPU nube también.
• Resultado:
  • Es necesario sólo tiene que descargar el SDK y ya puede comenzar.

Answer 12

Otros han dado buenas respuestas, sólo quería añadir una perspectiva diferente. Aquí está mi encuesta paper publicada en ACM Computing Surveys 2015 (su enlace permanente es here), que compara GPU con FPGA y CPU en métricas de eficiencia energética. La mayoría de los artículos informan que FPGA es más eficiente en energía que la GPU, que a su vez es más eficiente en energía que la CPU. Como los presupuestos de energía son fijos (dependiendo de la capacidad de refrigeración), la eficiencia energética de FPGA significa que se pueden hacer más cálculos dentro del mismo presupuesto de energía con FPGA, y así obtener un mejor rendimiento con FPGA que con GPU. Por supuesto, también son responsables de las limitaciones de FPGA, como lo mencionaron otros.

Answer 13

FPGA no será favorecido por aquellos con un sesgo de software ya que necesitan aprender un HDL o al menos entender systemC.

Para aquellos con un sesgo de hardware FPGA será la primera opción considerada.

En realidad, se requiere una comprensión firme de ambos &, entonces se puede tomar una decisión objetiva.

OpenCL está diseñado para ejecutarse en FPGA & GPU, incluso CUDA se puede portar a FPGA.

FPGA & aceleradores GPU se pueden utilizar juntos

así que no es un caso de lo que es mejor uno u otro. También está el debate sobre CUDA vs OpenCL

De nuevo, a menos que haya optimizado & como punto de referencia para su aplicación específica, no puede saber con certeza 100%.

Muchos simplemente irán con CUDA debido a su naturaleza comercial & recursos. Otros irán con openCL por su versatilidad.

Answer 14

Este es un hilo viejo que comenzó en 2008, pero sería bueno contar lo que pasó con la programación de FPGA desde entonces: 1. C a puertas en FPGA es el desarrollo principal para muchas compañías con gran ahorro de tiempo vs. Verilog/SystemVerilog HDL. En C a las puertas El diseño del nivel del sistema es la parte difícil. 2. OpenCL en FPGA existe durante más de 4 años, incluido el despliegue en coma flotante y en "nube" de Microsoft (Asure) y Amazon F1 (API de Ryft). Con OpenCL, el diseño del sistema es relativamente fácil debido al modelo de memoria muy definido y la API entre el host y los dispositivos de cómputo.

La gente de software solo necesita aprender un poco sobre la arquitectura FPGA para poder hacer cosas que NO SON POSIBLES con GPUs y CPU por razones de ser fijo de silicio y no tener interfaces de banda ancha (100Gb +) . Escalar la geometría de los chips ya no es posible, ni extraer más calor del paquete de un solo chip sin fundirlo, por lo que parece el final del camino para los chips de un solo paquete. Mi tesis aquí es que el futuro pertenece a la programación paralela de sistemas multi-chip, y los FPGA tienen una gran oportunidad de estar por delante del juego. Salida http://isfpga.org/ si tiene dudas acerca del rendimiento, etc.

Answer 15

• FPGAs son más paralelos de las GPU, en tres órdenes de magnitud. Mientras que una buena GPU presenta miles de núcleos, la FPGA puede tener millones de puertas programables.
• Mientras que los núcleos CUDA deben hacer cálculos muy similares para ser productivos, las células FPGA son verdaderamente independientes entre sí.
• FPGA puede ser muy rápido con algunos grupos de tareas y se utiliza a menudo donde ya se ve un milisegundo como de larga duración.
• GPU core es mucho más potente que la célula FPGA, y mucho más fácil de programar. Es un núcleo, puede dividirse y multiplicar sin problemas cuando la célula FPGA solo es capaz de una lógica booleana bastante simple.
• Como GPU core es core, es eficiente programarlo en C++. Incluso si también es posible programar FPGA en C++, es ineficiente (solo "productivo"). Se deben usar lenguajes especializados como VDHL o Verilog; son difíciles y difíciles de dominar.
• La mayoría de los instintos verdaderos y probados de un ingeniero de software son inútiles con FPGA. ¿Desea un para el bucle con estas puertas? ¿De qué galaxia eres? Necesita entender la mentalidad de un ingeniero en electrónica para comprender este mundo.