Si por “más rápido” uno significa “menor tiempo de reloj de pared para el cálculo”, es decir, un intervalo de tiempo más pequeño desde la entrada hasta la salida, definitivamente es cuestión de cuánto se puede paralelizar un código de aplicación. Esto también significa que a veces uno puede necesitar reescribir el código desde cero para hacer su versión más paralela que podría ser utilizada por GPU o FPGA. Esencialmente, ambos dispositivos ofrecen cómputo más rápido porque admiten paralelismo. Si toma una implementación secuencial de un algoritmo, la GPU probablemente será más rápida en virtud de su frecuencia de reloj operativa más alta que supera fácilmente los 500 MHz. Es extremadamente difícil realizar el cierre temporal de los diseños en FPGA por encima de 300 MHz y cuanto más lógica digital (relacionada con la implementación de un algoritmo) sigas agregando, más difícil será lograr frecuencias de reloj operativas más altas en FPGA. Entonces, ¿cuándo pueden los FPGAs computar más rápido? La respuesta es cuando tienes más paralelismo en tu diseño. Pero eso también es cuando una GPU puede ser más rápida. Entonces esto plantea la pregunta: ¿cuándo debería uno elegir uno de estos sobre el otro? ¿Es necesario probar implementaciones tanto en una GPU como en una FPGA para determinar cuál calcularía más rápido o debería usar algunas reglas generales para decidir cuál elegir para un algoritmo específico o para una versión paralela específica de un algoritmo? Las reglas generales como un gran número de operaciones de multiplicación, multiplicación-suma, multiplicación-acumulación, requisitos de menos memoria, datos simplificados y dependencias de control, etc. pueden inclinar el favor hacia FPGA.
Por otro lado, los requisitos de menos memoria, datos simplificados y dependencias de control también podrían favorecer una implementación de GPU, aunque en este caso la GPU no se utilizará en todo su potencial, haciendo que un arquitecto de sistemas se pregunte por qué elegirla. Para extraer lo mejor de un FPGA, uno también debe ser un experto en hacer diseño digital a nivel RTL y tener una comprensión profunda de los recursos FPGA que incluyen recursos de cómputo, comunicación y reloj. Por otro lado, programar una GPU es relativamente más fácil y lleva menos tiempo iterar una implementación de GPU para cumplir con el tiempo requerido de entrada a salida. Esta es una tarea desalentadora con FPGA, especialmente cuando los algoritmos ricos en matemáticas tienden a ser muy complejos.
El otro problema aquí es si la visualización de resultados es importante. Por ejemplo, no es suficiente ejecutar un algoritmo de retroproyección en vóxeles creados por sensores en, por ejemplo, un escáner CT. Un usuario final quiere visualizar los resultados. Una implementación basada en CUDA ofrece ambos: visualización en la CPU del host y cálculo en la GPU. En este aspecto, los FPGA son un mal candidato porque el diseño RTL (en Verilog / VHDL) requerirá ser mezclado con la descripción basada en C de la visualización que se ejecuta en una CPU y el beneficio de un procesamiento más rápido en FPGA puede perderse en este caso si la comunicación entre CPU y FPGA no es rápido y los límites algorítmicos (visualización vs computación vs comunicación) no están claramente definidos.
- ¿Por qué el ordenamiento rápido se denomina 'rápido' incluso cuando tiene complejidad O (n2) en el peor de los casos?
- He estado tratando de aprender el análisis de algoritmos usando el libro CLRS, sin embargo, encuentro que ese libro es difícil de entender. ¿Soy el único?
- Cómo enviar una matriz unidimensional a una función y tener esa misma matriz (posición en la memoria) convertida en una matriz bidimensional en C ++
- Cómo aprender qué algoritmo usar en un conjunto de problemas en particular
- Cómo resolver este problema con un árbol de segmentos o BIT
