¿CUDA o FPGA para cálculos de gráficos 3D de propósito especial?
https://stackoverflow.com/questions/317731
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
Estoy desarrollando un producto con grandes cálculos de gráficos en 3D, en gran medida búsquedas de punto y rango más cercanas . Alguna optimización de hardware sería útil. Si bien sé poco sobre esto, mi jefe (que no tiene experiencia en software) aboga por FPGA (porque se puede adaptar), mientras que nuestro desarrollador junior aboga por GPGPU con CUDA, porque es barato, atractivo y abierto. Si bien siento que no tengo criterio en esta pregunta, creo que CUDA es el camino a seguir también porque estoy preocupado por la flexibilidad, nuestro producto aún está en desarrollo.
Entonces, reformulando la pregunta, ¿hay alguna razón para optar por FPGA? ¿O hay una tercera opción?
Solució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 excelentes para sistemas en tiempo real, donde incluso 1 ms de retraso puede ser demasiado largo. Esto no se aplica en su 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 caros y especializados que incluso GPGPU profesionales;
- Los FPGA son bastante engorrosos de programar. Dado que hay un componente de configuración de hardware para la compilación, puede llevar 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 funcione para usted, probablemente sea la mejor opción en este momento. Ciertamente será más flexible que un FPGA.
Otras opciones incluyen Brook de ATI, pero hasta que ocurra algo grande, simplemente no está tan bien adoptado como CUDA. Después de eso, todavía hay todas las opciones tradicionales de HPC (grupos de x86 / PowerPC / Cell), pero todas son bastante caras.
Espero que eso ayude.
Otros consejos
Hicimos alguna comparación entre FPGA y CUDA. Una cosa donde CUDA brilla si realmente puede formular su problema de manera SIMD Y puede acceder a la memoria fusionada. Si los accesos a la memoria no están unidos (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 núcleo, luego sus tiempos de invocación para el núcleo de la GPU exceden el tiempo de cálculo.
Además, la potencia del FPGA podría ser mejor (depende del escenario de su aplicación, es decir, la GPU solo es más barata (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 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 caro que la mejor GPU y los tiempos de desarrollo son muy altos.
(1) Los accesos simultáneos desde diferentes hilos a la memoria tienen que ser a direcciones secuenciales. Esto a veces es realmente difícil de lograr.
Yo iría con CUDA.
Trabajo en el procesamiento de imágenes y he estado probando complementos de hardware durante años. Primero teníamos i860, luego Transputer, luego DSP, luego FPGA y compilación directa al hardware.
Lo que sucedió inevitablemente fue que cuando las placas de hardware estaban realmente depuradas y confiables y el código había sido transferido a ellas: las CPU normales habían avanzado para vencerlas, o la arquitectura de la máquina de alojamiento cambió y no pudimos usar las placas viejas, o los creadores de la junta fueron a la quiebra.
Al apegarse a algo como CUDA, no está atado a un pequeño fabricante especializado 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 fusionará con CPU de varios núcleos en el futuro y protegerá su inversión.
FPGAs
- Lo que necesitas:
- Aprenda VHDL / Verilog (y confíe en mí, no lo hará)
- Compre hw para pruebas, 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 hw, herramientas de síntesis ultra costosas
- toneladas de conocimiento sobre buses, mapeo de memoria, síntesis de 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 le paga, no tiene fondos suficientes.
GPGPU (CUDA / OpenCL)
- Ya tienes hw para probar.
- Comparar 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 de GPU.
- Resultado:
- Solo necesita descargar sdk y puede comenzar.
Es probable que la solución basada en FPGA sea mucho más costosa 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 de manera abstracta, es decir, compilación de lenguaje de alto nivel versus implementación de nivel de máquina, inevitablemente tendrá un costo de rendimiento, especialmente en una implementación de algoritmo complejo. 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 entrada / salida, etc.
Otro ejemplo general en el que un FPGA puede tener un rendimiento mucho mayor es en procesos en cascada donde las salidas del proceso se convierten en entradas para otro y no se pueden hacer simultáneamente. 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 usará para conectar en cascada de manera efectiva dos o más procesos donde hay dependencias de datos.
Lo mismo puede decirse de una GPU y 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 hace. Por supuesto, no tener en cuenta estas características de rendimiento simplifica la implementación. Pero a un costo de rendimiento.
Al no tener experiencia directa con una GPU, pero conociendo los problemas de rendimiento del sistema de memoria inherente, también estará sujeta a problemas de rendimiento.
Este es un viejo hilo iniciado en 2008, pero sería bueno contar lo que sucedió con la programación FPGA desde entonces: 1. C to gates en FPGA es el desarrollo principal para muchas compañías con un enorme ahorro de tiempo frente a Verilog / SystemVerilog HDL. En C to gates, el diseño a nivel de sistema es la parte difícil. 2. OpenCL en FPGA está allí por más de 4 años, incluyendo coma flotante y "nube" implementación por Microsoft (Asure) y Amazon F1 (Ryft API). Con el diseño del sistema OpenCL es relativamente fácil debido al modelo de memoria y API muy bien definidos entre el host y los dispositivos informáticos.
La gente de software solo necesita aprender un poco sobre la arquitectura FPGA para poder hacer cosas que NO SON POSIBLES CON GPUs y CPUs por las razones de ser silicio fijo y no tener interfaces de banda ancha (100Gb +) para el mundo exterior. Reducir la geometría del chip ya no es posible, ni extraer más calor del paquete de un solo chip sin derretirlo, 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 de múltiples chips, y los FPGA tienen una gran oportunidad de adelantarse al juego. Visite http://isfpga.org/ si le preocupa el rendimiento, etc.
CUDA tiene una base de ejemplos de código bastante sustancial y un SDK , que incluye < a href = "http://www.nvidia.com/content/cudazone/cuda_sdk/Linear_Algebra.html" rel = "nofollow noreferrer"> un back-end BLAS . Intenta encontrar algunos ejemplos similares a lo que estás haciendo, quizás también mirando el serie de libros GPU Gems , para evaluar qué tan bien CUDA se ajustará a sus aplicaciones. Yo diría que desde un 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 profesional FPGA.
En un momento busqué en CUDA para el modelado de simulación de reserva de reclamo. Hay una buena serie de conferencias vinculadas fuera del sitio web para el aprendizaje. En Windows, debe asegurarse de que CUDA se esté ejecutando en una tarjeta sin pantallas, ya que el subsistema de gráficos tiene un temporizador de vigilancia que detendrá 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 admitir esto. Utilicé una HP XW9300, que puedes comprar en eBay de forma bastante económica. 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 Hypertransport separados y necesita dos CPU en la máquina para tener ambos buses activos.
Soy un desarrollador de CUDA con 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 máximo mucho más alto (accesible) Tiene una relación FLOP / vatio más favorable. Es más barato Se está desarrollando más rápido (muy pronto, literalmente, tendrá disponible un TFLOP real). Es más fácil de programar (lea el artículo sobre esta opinión no personal)
Tenga en cuenta que estoy diciendo real / accesible para distinguir de los números que verá en un comercial de GPGPU.
PERO el gpu no es más favorable cuando necesita hacer accesos aleatorios a los datos. Con suerte, esto cambiará con la nueva arquitectura Nvidia Fermi que tiene un caché opcional l1 / l2.
mis 2 centavos
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 & amp; entonces se puede tomar una decisión objetiva.
OpenCL está diseñado para ejecutarse tanto en FPGA como en amp; GPU, incluso CUDA se puede portar a FPGA.
FPGA & amp; Los aceleradores de GPU se pueden usar juntos
Entonces, no es un caso de lo que es mejor uno u otro. También existe el debate sobre CUDA vs OpenCL
Nuevamente, a menos que haya optimizado & amp; comparado con su aplicación específica que no puede conocer con 100% de certeza.
Muchos simplemente irán con CUDA debido a su naturaleza comercial & amp; recursos Otros irán con openCL debido a su versatilidad.
¿En qué estás desplegando? ¿Quien 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 y requiere un marco mental diferente al de la programación convencional.
Los FPGA han caído en desgracia en el sector de HPC porque son un horror horrort para programar. CUDA está en funcionamiento porque es mucho más agradable de programar y todavía 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 barato, es más fácil de mantener.
Otros han dado buenas respuestas, solo querían agregar una perspectiva diferente. Aquí está mi encuesta paper publicado en ACM Computing Surveys 2015 (su enlace permanente es
- Los FPGA son más paralelos que las GPU, en tres órdenes de magnitud. Si bien una buena GPU presenta miles de núcleos, FPGA puede tener millones de puertas programables.
- Si bien los núcleos CUDA deben realizar 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 a menudo se usa donde un milisegundo ya se ve como una larga duración. El núcleo
- GPU es mucho más poderoso que la celda FPGA y mucho más fácil de programar. Es un núcleo, puede dividirse y multiplicarse sin problemas cuando la celda FPGA solo es capaz de una lógica booleana bastante simple.
- Como el núcleo de la GPU es un núcleo , es eficiente programarlo en C ++. Incluso si también es posible programar FPGA en C ++, es ineficiente (solo "productivo"). Deben usarse 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 for loop con estas puertas? ¿De qué galaxia eres? Debe cambiar la mentalidad del ingeniero electrónico para comprender este mundo.
a más tardar GTC'13, muchas personas de HPC acordaron que CUDA llegó para quedarse. Los FGPA son engorrosos, CUDA se está volviendo bastante más maduro al admitir Python / C / C ++ / ARM ... de cualquier manera, esa era una pregunta anticuada
Programar una GPU en CUDA es definitivamente más fácil. Si no tiene experiencia con la programación de FPGAs en HDL, seguramente será un gran desafío para usted, pero aún puede programarlos con OpenCL, que es un poco similar a CUDA. Sin embargo, es más difícil de implementar y probablemente mucho más costoso que programar GPU.
¿Cuál es más rápido?
GPU funciona más rápido, pero FPGA puede ser más eficiente.
GPU tiene el potencial de funcionar a una velocidad superior a la que puede alcanzar FPGA. Pero solo para algoritmos especialmente adecuados para eso. Si el algoritmo no es óptimo, la GPU perderá mucho rendimiento.
FPGA, por otro lado, funciona mucho más lento, pero puede implementar hardware específico para problemas que será muy eficiente y hará las cosas en menos tiempo.
Es como comer su sopa con un tenedor muy rápido en lugar de comerla con una cuchara más lentamente.
Ambos dispositivos basan su rendimiento en la paralelización, pero cada uno de una manera ligeramente diferente. Si el algoritmo se puede granular en muchas piezas que ejecutan las mismas operaciones (palabra clave: SIMD), la GPU será más rápida. Si el algoritmo se puede implementar como una tubería larga, el FPGA será más rápido. Además, si desea utilizar coma flotante, FPGA no estará muy contento con él :)
