algorithm - nvidialatam - Rendimiento de GPU vs CPU para algoritmos comunes
nvidia shop mexico (5)
Echa un vistazo al thrust :
Thrust es una biblioteca CUDA de algoritmos paralelos con una interfaz que se parece a la Biblioteca de plantillas estándar de C ++ (STL). Thrust proporciona una interfaz flexible de alto nivel para la programación de GPU que mejora en gran medida la productividad del desarrollador.
Me interesa saber si algunos algoritmos comunes (clasificación, búsqueda, gráficos, etc.) se han transferido a OpenCL (o cualquier lenguaje de GPU) y cómo se compara el rendimiento con el mismo algoritmo ejecutado por la CPU. Estoy específicamente interesado en los resultados (números).
¡Gracias!
El cambio de tamaño de la imagen debe ser común en muchos sitios web que aceptan cargas de imágenes.
Cambiar el tamaño de una imagen jpeg 2600ish x 2000ish 2MB (a 512x512) tomó 23.5 milisegundos en C # con las opciones de calidad más bajas y el muestreo del vecino más cercano. La función utilizada fue graphics.DrawImage() basada en una. El uso de la CPU también fue% 21.5.
Obtener la extracción "rgba byte array" en el lado C # y enviarla a la GPU y cambiar el tamaño en la GPU y obtener los resultados en una imagen tomó 6,3 milisegundos y el uso de la CPU fue de% 12.7. Esto se hizo con un% 55 gpu más barato con solo 320 núcleos.
Sólo 3.73X multiplicador de aceleración.
El factor limitante aquí fue enviar los datos de 20MB rgb extraídos (¡el jpeg solo es de 2MB!) A la GPU. Esa parte que consumió tiempo fue casi el 90% del tiempo total, ¡incluida la extracción de la matriz de bytes laterales C #! Así que supongo que habría una aceleración de aproximadamente 30X al menos si la parte de extracción también se pudiera realizar en GPU.
30X no es malo.
Luego, puede canalizar la capa de extracción con la capa de cambio de tamaño para ocultar la latencia de la copia de memoria para obtener aún más velocidad. Esto podría ser 40X-50X.
Luego, aumente la calidad del muestreo (como bicubic en lugar del vecino más cercano), tiene aún más ventaja en el lado de GPU. Al agregar un filtro gaussiano de 5x5 se agregaron solo 0.77 milisegundos. La CPU obtendría un tiempo mayor además de eso, especialmente si los parámetros gaussianos necesarios son diferentes a la implementación de C # .Net.
Incluso si no está satisfecho con el índice de aceleración, la descarga a la GPU y tener un "núcleo libre" en la CPU aún es ventajoso para impulsar más trabajo a ese servidor.
Ahora agregue el hecho de los niveles de consumo de energía de la GPU (30W vs 125W en este ejemplo), es mucho más ventajoso.
CPU difícilmente podría ganar en
C[i]=A[i]+B[i]
puntos de referencia cuando ambos lados se ejecutan con códigos optimizados y aún puede descargar la mitad de las matrices a la GPU y terminar más rápido usando CPU + GPU al mismo tiempo.
La GPU no está construida para trabajos no uniformes. Las GPU tienen tuberías profundas, por lo que levantarse después de una parada debido a la ramificación, toma demasiado tiempo. También el hardware de tipo SIMD lo obliga a hacer lo mismo en todos los elementos de trabajo en él. Cuando un elemento de trabajo hace una cosa diferente a la del grupo, pierde el rumbo y agrega burbujas en todo el proceso SIMD o simplemente otros esperan el punto de sincronización. Por lo tanto, la separación afecta tanto a las áreas de tubería amplias como a las profundas y lo hace incluso más lento que la CPU en condiciones perfectamente caóticas.
Hay bastantes muestras de este tipo de cosas en el sitio web de NVidia. Tenga en cuenta que algunas cosas, como la clasificación, requieren algoritmos especiales para un paralelismo eficiente y pueden no ser tan eficientes como un algoritmo sin hilos en un solo núcleo.
Las GPU son hardware altamente especializado diseñado para realizar un pequeño conjunto de tareas muy bien y altamente paralelizadas. Esto es básicamente aritmético (particularmente matemática de punto flotante de precisión simple, aunque las GPU más nuevas funcionan bastante bien con doble precisión). Como tales, solo son adecuados para algoritmos particulares. No estoy seguro de si la clasificación se ajusta a esa categoría (al menos en el caso general).
Los ejemplos más comunes son la fijación de precios de instrumentos financieros, grandes cantidades de matrices matemáticas e incluso la anulación de la encriptación (por fuerza bruta). Dicho esto, encontré la clasificación GPU paralela rápida utilizando un algoritmo híbrido .
Otro ejemplo comúnmente citado es ejecutar SETI @ HOME en una GPU Nvidia pero está comparando manzanas con naranjas. Las unidades de trabajo para las GPU son diferentes (y muy limitadas) en comparación con lo que normalmente hacen las CPU.
TENGA CUIDADO, MUY CUIDADO de los números de rendimiento citados para GPGPU. A mucha gente le gusta publicar números realmente impresionantes que no tienen en cuenta el tiempo de transferencia necesario para obtener los datos de entrada de la CPU a la GPU y los datos de salida, ambos superando un cuello de botella PCIe.