hardware cuda fpga

hardware - CUDA vs FPGA?



(15)

CUDA tiene una base de código bastante importante de ejemplos y un SDK , que incluye un back-end BLAS . 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 investigué en 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.

Estoy desarrollando un producto con pesados ​​cálculos de gráficos 3D, en gran parte, 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.

Entonces, volviendo a formular la pregunta, ¿hay alguna razón para ir a FPGA? ¿O hay una tercera opción?

Investigué la misma pregunta hace un tiempo. Después de conversar con personas que han trabajado en FPGA, esto es lo que obtengo:

  • Los FPGA son ideales para sistemas en tiempo real, donde incluso 1ms de retraso puede ser demasiado largo. Esto no aplica en tu caso;
  • Los FPGA pueden ser muy rápidos, especialmente para usos de procesamiento de señal digital bien definidos (por ejemplo, datos de radar), pero los buenos son mucho más costosos y especializados que las GPGPU profesionales;
  • Los 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, probablemente sea 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 algo grande suceda, simplemente no es tan bien adoptado 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.

Yo iría 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 para cuando las tarjetas de hardware ya estaban depuradas y eran confiables y el código había sido portado a ellas: las CPU regulares habían avanzado para superarlas, o la arquitectura de la máquina de alojamiento había cambiado y no podíamos usar las viejas placas, o los fabricantes de la junta fracasaron.

Al apegarse a algo como CUDA, no estás vinculado a un pequeño especialista en 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.

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 la FPGA puede superarla. 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.

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

Por supuesto, el FPGA también tiene algunos inconvenientes: IO puede ser uno (teníamos aquí una aplicación en la que necesitábamos 70 GB / s, no había problema para GPU, pero para obtener esta cantidad de datos en un FPGA necesitas más pins convencionales de diseño 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 un hilo diferente a la memoria tiene que ser a direcciones secuenciales. Esto a veces es realmente difícil de lograr.

Es probable que la solución basada en FPGA sea mucho más cara que CUDA.

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, compilado 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, lo que le permite un grado de programabilidad desde registros de control de entrada, datos de E / S, etc.

Otro ejemplo general en el que un FPGA puede tener un rendimiento mucho más alto es en procesos en cascada en los que las salidas del proceso se convierten en las entradas de otro y no pueden hacerse 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 puede decirse 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 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 conocer sus problemas de rendimiento del sistema de memoria inherente, también estará sujeto a problemas de rendimiento.

¿En qué estás 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.

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

Lo que he concluido hasta ahora:

La GPU tiene un rendimiento pico mucho más alto (accesible) Tiene una relación FLOP / watt más favorable. Es más barato. Se está desarrollando más rápido (muy pronto tendrás literalmente un TFLOP "real" disponible). Es más fácil de programar (leer 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

Los FPGA han caído en desgracia en el sector de HPC porque son un horror extremo para 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.

al último GTC''13 muchas personas de HPC estuvieron de acuerdo en que CUDA llegó para quedarse. Los FGPA son engorrosos, CUDA se está haciendo bastante más maduro y admite Python / C / C ++ / ARM ... de cualquier forma, esa fue una pregunta anticuada

Otros han dado buenas respuestas, solo querían agregar una perspectiva diferente. Aquí está mi encuesta publicada en ACM Computing Surveys 2015 (su enlace permanente está aquí ), 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.

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 y luego se puede tomar una decisión objetiva.

OpenCL está diseñado para ejecutarse en FPGA y GPU, incluso CUDA puede ser portado a FPGA.

Los aceleradores FPGA y GPU se pueden usar juntos

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

Nuevamente, a menos que haya optimizado y evaluado su aplicación específica, no puede saber con certeza al 100%.

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

Este es un hilo viejo que comenzó en 2008, pero sería bueno contar lo que le sucedió a la programación de FPGA desde entonces: 1. C a las puertas en FPGA es el desarrollo principal para muchas compañías con GRAN ahorro de tiempo frente a 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.

Los usuarios de software solo necesitan aprender un poco acerca de la arquitectura FPGA para poder hacer cosas que NO SON POSIBLES con las GPU y las CPU por el hecho de que ambos son de silicio fijo y no tienen interfaces de banda ancha (100Gb +) para el mundo exterior. 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. Visite http://isfpga.org/ si tiene dudas sobre el rendimiento, etc.

FPGA

  • Que necesitas:
    • Aprende VHDL / Verilog (y créeme que no)
    • Compre hw para probar, licencias en herramientas de síntesis
    • Si elige un buen marco (por ejemplo: RSoC )
      • Desarrollar diseño (y puede llevar años)
    • Si no lo haces:
      • DMA, controlador de hw, herramientas de síntesis ultra caras
      • toneladas de conocimiento sobre los autobuses, mapeo de memoria, síntesis hw
      • construye el hw, compra los núcleos ip
      • Desarrollar diseño
  • Por ejemplo, la tarjeta pcie FPGA promedio con chip Xilinx virtex-6 cuesta más de 3000 $
  • Resultado:
    • Si el gobierno no te paga, no tienes fondos suficientes.

GPGPU (CUDA / OpenCL)

  • Ya tienes hw para probar.
  • Compare con cosas de FPGA:
    • Todo está bien documentado.
    • Todo es barato
    • Todo funciona
    • Todo está bien integrado a los lenguajes de programación
  • También hay una nube GPU.
  • Resultado:
    • Solo necesita descargar SDK y puede comenzar.
  • Los FPGA son más paralelos que 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 usa a menudo donde ya se ve un milisegundo como de larga duración.
  • El núcleo GPU es mucho más poderoso 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 un núcleo , 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. ¿Quieres un bucle for con estas puertas? ¿De qué galaxia eres? Necesita entender la mentalidad de un ingeniero en electrónica para comprender este mundo.