En informática , el lenguaje de programación Brook y su implementación BrookGPU fueron intentos tempranos e influyentes para permitir la computación de propósito general en unidades de procesamiento gráfico (GPGPU). [ 1 ] [ 2 ] Brook, desarrollado en el grupo de gráficos de la Universidad de Stanford , era un compilador y un sistema de tiempo de ejecución para un lenguaje de programación de flujo diseñado para aprovechar el paralelismo de las GPU como las de ATI o Nvidia .
BrookGPU compilaba programas escritos con el lenguaje de programación de flujos Brook, una variante de ANSI C. Podía usar OpenGL v1.3+, DirectX v9+ o AMD Close to Metal para el procesamiento posterior y se ejecutaba tanto en Microsoft Windows como en Linux . Para la depuración, BrookGPU también podía simular una tarjeta gráfica virtual en la CPU.
Estado
La última versión beta importante (v0.4) se lanzó en octubre de 2004, pero el desarrollo se reanudó y se detuvo nuevamente en noviembre de 2007 con el lanzamiento de la versión beta 1 v0.5.
Las nuevas características de la versión 0.5 incluyen un backend de OpenGL mucho más rápido y mejorado que utiliza objetos framebuffer en lugar de PBuffers y ha armonizado el código con las interfaces estándar de OpenGL en lugar de utilizar extensiones propietarias de los proveedores. Se añadió compatibilidad con GLSL , lo que incorpora a OpenGL toda la funcionalidad (ramificaciones y bucles complejos) que antes solo era compatible con DirectX 9. En concreto, esto significa que Brook ahora funciona igual de bien en Linux que en Windows .
Otras mejoras en la serie v0.5 incluyen el uso de múltiples backends, mediante el cual diferentes hilos pueden ejecutar diferentes programas Brook simultáneamente (maximizando así el uso de una configuración multi-GPU) y la compatibilidad con SSE y OpenMP para el backend de CPU (esto permite un uso casi máximo de las CPU modernas).
Comparación de rendimiento
Una comparación directa entre CPU de escritorio y GPGPU es problemática debido a las diferencias algorítmicas y estructurales. [ 3 ]
Por ejemplo, un Intel Core 2 Duo de 2,66 GHz puede realizar un máximo de 25 GFLOPs (25 mil millones de operaciones de punto flotante de precisión simple por segundo) si utiliza de forma óptima SSE y el acceso a memoria en flujo para que el prefetcher funcione perfectamente. Sin embargo, tradicionalmente (debido a los límites de longitud del programa de sombreado) la mayoría de los kernels GPGPU tienden a realizar cantidades relativamente pequeñas de trabajo en grandes cantidades de datos en paralelo, por lo que el gran problema de ejecutar directamente algoritmos GPGPU en CPU de escritorio es el ancho de banda de memoria mucho menor, ya que en términos generales la CPU pasa la mayor parte del tiempo esperando en la RAM . Como ejemplo, la RAM DDR2 PC2-6400 de doble canal puede transmitir alrededor de 11 Gbit/s, lo que es alrededor de 1,5 GFLOPs máximo dado que hay un ancho de banda total de 3 GFLOPs y se debe leer y escribir. Como resultado, si el ancho de banda de la memoria está restringido, el backend de CPU de Brook no superará los 2 GFLOPs. En la práctica, es incluso menor, sobre todo para cualquier tipo de dato que no sea float4, que es el único tipo de dato que puede acelerarse mediante SSE.
En una ATI HD 2900 XT ( núcleo de 740 MHz , memoria de 1000 MHz), Brook puede realizar un máximo de 410 GFLOPs a través de su backend DirectX 9. [ 4 ] OpenGL es actualmente (debido a las limitaciones del controlador y del compilador Cg ) mucho menos eficiente como backend GPGPU en esa GPU, por lo que Brook solo puede gestionar 210 GFLOPs cuando usa OpenGL en esa GPU. En teoría, esto parece unas veinte veces más rápido que la CPU, pero como se acaba de explicar, no es tan sencillo. Las GPU actualmente tienen importantes penalizaciones de acceso de lectura/escritura y de bifurcación, por lo que se espera un máximo razonable de un tercio del máximo pico en código del mundo real; esto todavía deja a esa tarjeta ATI en alrededor de 125 GFLOPs unas cinco veces más rápido que el Intel Core 2 Duo.
Sin embargo, esto no tiene en cuenta la parte crucial de la transferencia de datos hacia y desde la GPU. Con una interfaz PCI Express 1.0 x8, la memoria de una ATI HD 2900 XT puede escribirse a unos 730 Mbit/s y leerse a unos 311 Mbit/s, lo que resulta significativamente más lento que la memoria de un PC convencional. Para conjuntos de datos grandes, esto puede reducir considerablemente el aumento de velocidad que supone usar una GPU en comparación con una CPU bien optimizada. Por supuesto, a medida que las GPU se vuelven mucho más rápidas que las CPU y la interfaz PCI Express mejora, tendrá más sentido delegar el procesamiento de grandes volúmenes de datos a las GPU.
Aplicaciones y juegos que utilizan BrookGPU
Véase también
Referencias
- ↑ Tarditi, David; Puri, Sidd; Oglesby, Jose (2006). "Acelerador: uso del paralelismo de datos para programar GPU para usos de propósito general" (PDF) . ACM SIGARCH Computer Architecture News . 34 (5). doi : 10.1145/1168919.1168898 .
- ↑ Che, Shuai; Boyer, Michael; Meng, Jiayuan; Tarjan, D.; Sheaffer, Jeremy W.; Skadron, Kevin (2008). "Un estudio de rendimiento de aplicaciones de propósito general en procesadores gráficos usando CUDA". J. Parallel and Distributed Computing . 68 (10): 1370– 1380. doi : 10.1016/j.jpdc.2008.05.014 .
- ↑ Marziale, Lodovico; Richard, Golden (2007), "Massive threading: Using GPUs to increase the performance of digital forensics tools" , FSI Digital Investigation , 4 : 73–81 , doi : 10.1016/j.diin.2007.06.014
- ↑ Buck, Ian; Foley, Theresa; Horn, Daniel; Sugerman, Jeremy; Fatahalian, Kayvon; Houston, Mike; Hanrahan, Pat (agosto de 2004), "Brook para GPU: computación de flujo en hardware gráfico" , ACM Trans. Graph. , 23 (3): 777–786 , doi : 10.1145/1015706.1015800
{{citation}}: Mantenimiento CS1: fecha y año ( enlace )
Enlaces externos
- Sitio web oficial de la Universidad de Stanford.
- GPGPU
- Bibliotecas GPGPU