parallel processing - tipos - ¿Qué futuro tiene la GPU en informática?
gpu vs cpu (16)
Casi cualquier cosa que pueda ser paralela puede beneficiarse. Ejemplos más específicos serían SETI @ home, fold @ home, y otros proyectos distribuidos, así como la computación científica.
Especialmente las cosas que dependen en gran medida de la aritmética de punto flotante. Esto se debe a que las GPU tienen circuitos especializados que son MUY rápidos en operaciones de punto flotante. Esto significa que no es tan versátil, pero es MUY bueno en lo que hace.
Si desea ver un procesamiento de GPU más dedicado, consulte la GPU Tesla de Nvidia . Es una GPU, ¡pero en realidad no tiene salida de monitor!
Dudo que veamos demasiado procesamiento de GPU en el escritorio común, o al menos por un tiempo, porque no todos tienen una tarjeta gráfica compatible con CUDA o similar, si es que tienen una tarjeta gráfica. También es muy difícil hacer programas más paralelos. Es posible que los juegos utilicen esta potencia adicional, pero será muy difícil y probablemente no sea muy útil, ya que la mayoría de los cálculos gráficos ya están en la GPU y el otro trabajo está en la CPU y tiene que estar en la CPU debido a los conjuntos de instrucciones.
El procesamiento de GPU, al menos por un tiempo, será para nichos de mercado muy específicos que necesitan muchos cálculos de punto flotante.
Su CPU puede ser de cuatro núcleos, pero ¿sabía que algunas tarjetas gráficas tienen más de 200 núcleos? Ya hemos visto lo que las GPU en las tarjetas gráficas de hoy pueden hacer cuando se trata de gráficos. Ahora también se pueden usar para tareas no gráficas, y en mi opinión, los resultados son increíbles. Un algoritmo que se presta bien al paralelismo tiene el potencial de ser mucho, mucho más rápido en una GPU de lo que podría estar en una CPU.
Hay algunas tecnologías que hacen todo esto posible:
1.) CUDA por NVidia. Parece ser el más conocido y documentado. Desafortunadamente, solo funcionará en tarjetas de video NVidia. Descargué el SDK, probé algunas de las muestras y hay algunas cosas increíbles que se están haciendo en CUDA. Pero el hecho de que esté limitado a las tarjetas NVidia me hace cuestionar su futuro.
2.) Stream por ATI. El equivalente de ATI a CUDA. Como es de esperar, solo funcionará en tarjetas ATI.
3.) OpenCL - El Grupo Khronos ha elaborado este estándar, pero aún se encuentra en sus etapas iniciales. Aunque me gusta la idea de OpenCL. La esperanza es que sea compatible con la mayoría de los fabricantes de tarjetas de video y que el desarrollo de tarjetas de video cruzado sea mucho más fácil.
Pero, ¿qué otras tecnologías para la programación no gráfica de GPU están llegando y cuáles son las más prometedoras? ¿Y ve o le gustaría ver estas tecnologías incorporadas en algunos de los marcos de desarrollo principales como .NET para que sea mucho más fácil?
Creo que puedes contar el próximo DirectX como otra forma de usar la GPU.
Desde mi experiencia, las GPU son extremadamente rápidas para algoritmos que son fáciles de paralelizar. Recientemente optimicé un algoritmo especial de cambio de tamaño de imagen en CUDA para que fuera más de 100 veces más rápido en la GPU (ni siquiera en uno de gama alta) que un procesador Intel de cuatro núcleos. El problema fue llevar los datos a la GPU y luego recuperar el resultado en la memoria principal, ambas direcciones limitadas por la velocidad de memcpy () en esa máquina, que era inferior a 2 GB / s. Como resultado, el algoritmo fue solo un poco más rápido que la versión de la CPU ...
Así que realmente depende. Si tiene una aplicación científica donde puede mantener la mayoría de los datos en la GPU, y todos los algoritmos se asignan a una implementación de la GPU, entonces está bien. De lo contrario, esperaría hasta que haya una tubería más rápida entre la CPU y la GPU, o veamos qué ATI tiene en sus mangas con un chip combinado ...
Acerca de qué tecnología usar: Creo que una vez que tenga sus cosas funcionando en CUDA, el paso adicional para llevarlo a OpenCL (u otro idioma) no es tan grande. Hiciste todo el trabajo pesado paralelizando tus algoritmos, y el resto es solo un ''sabor'' diferente
Es cierto que las GPU pueden alcanzar números de rendimiento muy altos en situaciones de paralelismo de nivel de datos, como se menciona aquí. Pero como lo veo, ahora no hay mucho uso en el espacio de usuario. No puedo evitar sentir que toda esta propaganda de GPGPU proviene de los fabricantes de GPU, que solo quieren encontrar nuevos mercados y usos para sus productos. Y eso es absolutamente bien. ¿Alguna vez se ha preguntado por qué Intel / amd no incluye algunos núcleos mini-x86 además de los estándar (digamos, modelo con cuatro núcleos x86 y 64 núcleos mini-x86), solo para aumentar las capacidades de paralelismo a nivel de datos? Definitivamente podrían hacer eso, si quisieran. Supongo que la industria no necesita ese tipo de poder de procesamiento en las máquinas de escritorio / servidor normales.
Es importante tener en cuenta que incluso las tareas que son inherentemente en serie pueden beneficiarse de la paralelización si deben realizarse muchas veces de forma independiente.
Además, tenga en cuenta que cuando alguien informa la aceleración de una implementación de GPU a una implementación de CPU, casi nunca es una comparación justa. Para ser realmente justos, los implementadores primero deben dedicar tiempo a crear una implementación de CPU paralela verdaderamente optimizada. Una sola CPU Intel Core i7 965 XE puede alcanzar alrededor de 70 gigaflops en doble precisión hoy. Las GPU actuales de gama alta pueden hacer 70-80 gigaflops en precisión doble y alrededor de 1000 en precisión simple. Por lo tanto, una aceleración de más de 15 puede implicar una implementación ineficiente de la CPU.
Una advertencia importante con la computación de GPU es que actualmente es de "pequeña escala". Con una instalación de supercomputación, puede ejecutar un algoritmo paralelizado en cientos o incluso miles de núcleos de CPU. En contraste, los "grupos" de GPU actualmente están limitados a aproximadamente 8 GPU conectadas a una máquina. Por supuesto, varias de estas máquinas se pueden combinar juntas, pero esto agrega complejidad adicional, ya que los datos no solo deben pasar entre las computadoras sino también entre las GPU. Además, aún no hay un equivalente de MPI que permita que los procesos se amplíen de manera transparente a múltiples GPU en múltiples máquinas; debe implementarse manualmente (posiblemente en combinación con MPI).
Aparte de este problema de escala, la otra limitación importante de las GPU para la computación en paralelo es la severa restricción en los patrones de acceso a la memoria. El acceso aleatorio a la memoria es posible, pero el acceso a la memoria cuidadosamente planificado resultará en un rendimiento mucho mejor.
Quizás el próximo contendiente más prometedor sea el Larrabee de Intel. Tiene un acceso considerablemente mejor a la CPU, a la memoria del sistema y, quizás lo más importante, al almacenamiento en caché. Esto debería darle considerables ventajas con muchos algoritmos. Sin embargo, si no puede coincidir con el ancho de banda de memoria masiva en las GPU actuales, puede estar rezagado con respecto a la competencia para los algoritmos que utilizan de manera óptima este ancho de banda.
La generación actual de hardware y software requiere un gran esfuerzo por parte del desarrollador para obtener un rendimiento óptimo. Esto a menudo incluye algoritmos de reestructuración para hacer un uso eficiente de la memoria de la GPU. También a menudo implica experimentar con diferentes enfoques para encontrar el mejor.
Tenga en cuenta también que el esfuerzo requerido para obtener un rendimiento óptimo es necesario para justificar el uso del hardware de GPU. La diferencia entre una implementación ingenua y una implementación optimizada puede ser de un orden de magnitud o más. Esto significa que una impulsión de CPU optimizada probablemente será tan buena o incluso mejor que una implementación de GPU ingenua.
La gente ya está trabajando en los enlaces .NET para CUDA. Ver here Sin embargo, debido a la necesidad de trabajar a bajo nivel, no creo que la computación de GPU esté lista para las masas todavía.
Espero las mismas cosas que las CPUs se utilizan para?
Solo quiero decir que esto me parece un truco. Dudo en decir "eso no va a ninguna parte" cuando se trata de tecnología, pero la función principal de las GPU es la representación de gráficos y la función principal de las CPU es todo el procesamiento. Hacer que la GPU haga cualquier otra cosa parece una locura.
Estoy muy entusiasmado con esta tecnología. Sin embargo, creo que esto solo exacerbará el desafío real de las grandes tareas paralelas, una de ancho de banda. Agregar más núcleos solo aumentará la contención de la memoria. OpenCL y otras bibliotecas de abstracción de GPGPU no ofrecen ninguna herramienta para mejorar eso.
Cualquier plataforma de hardware de computación de alto rendimiento generalmente se diseñará con el problema del ancho de banda cuidadosamente planificado en el hardware, equilibrando el rendimiento, la latencia, el almacenamiento en caché y el costo. Siempre que el hardware básico, las CPU y las GPU estén diseñados de forma aislada, con un ancho de banda optimizado solo para su memoria local, será muy difícil mejorar esto para los algoritmos que lo necesitan.
He escuchado mucho hablar de convertir lo que hoy son GPU en "unidades de procesadores de arrays" de uso más general, para usar con cualquier problema matemático de matriz, en lugar de solo procesamiento de gráficos. Aunque no he visto mucho venir de eso todavía.
La teoría era que los procesadores de matrices podrían seguir aproximadamente la misma trayectoria que siguieron los procesadores de punto flotante un par de décadas antes. Originalmente, los procesadores de punto flotante eran opciones adicionales caras para PC que no muchas personas se molestaban en comprar. Con el tiempo, se volvieron tan vitales que se colocaron en la propia CPU.
Las GPU funcionan bien en problemas donde hay un alto nivel de paralelismo de nivel de datos , lo que esencialmente significa que hay una forma de particionar los datos para ser procesados de manera que todos puedan procesarse.
Las GPU no son inherentemente tan rápidas a un nivel de velocidad de reloj. De hecho, estoy relativamente seguro de que la velocidad del reloj en los sombreadores (¿o tal vez tienen un término más GPGPU para ellos en estos días?) Es bastante lenta en comparación con las ALU en un procesador de escritorio moderno. La cosa es que una GPU tiene una cantidad absolutamente enorme de estos sombreadores, convirtiendo la GPU en un procesador SIMD muy grande. Con la cantidad de shaders en un Geforce moderno, por ejemplo, es posible que una GPU esté trabajando en varios cientos (¿mil?) Números de punto flotante a la vez.
Tan breve, una GPU puede ser increíblemente rápida para problemas donde puede particionar los datos correctamente y procesar las particiones de forma independiente. No es tan poderoso en el paralelismo de nivel de tarea (hilo) .
Las GPU pueden o no seguir siendo tan populares como lo son ahora, pero la idea básica se está convirtiendo en un enfoque bastante popular para el procesamiento de alta potencia. Una tendencia que viene ahora es el "acelerador" externo para ayudar a la CPU con grandes trabajos de punto flotante. Una GPU es solo un tipo de acelerador.
Intel está lanzando un nuevo acelerador llamado Xeon Phi , que esperan poder desafiar a la GPU como un acelerador HPC. El procesador Cell adoptó un enfoque similar, al tener una CPU principal para realizar tareas generales y descargar tareas intensivas de cómputo a otros elementos de procesamiento, logrando algunas velocidades impresionantes.
Los aceleradores en general parecen ser de interés en este momento, por lo que deberían estar alrededor por lo menos durante un tiempo. Ya sea que la GPU permanezca o no como el acelerador de facto queda por verse.
Los investigadores de GHC (Haskell) (que trabajan para Microsoft Research) están agregando soporte para el paralelismo de datos anidados directamente a un lenguaje de programación de propósito general. La idea es utilizar múltiples núcleos y / o GPU en el back-end, pero exponer las matrices paralelas de datos como un tipo nativo en el idioma, independientemente del tiempo de ejecución que ejecute el código en paralelo (o en serie para el respaldo de una sola CPU).
http://www.haskell.org/haskellwiki/GHC/Data_Parallel_Haskell
Dependiendo del éxito de esto en los próximos años, esperaría ver que otros idiomas (específicamente C #) retomaran la idea, lo que podría llevar este tipo de capacidades a una audiencia más general. Quizás para ese momento se resolverán los problemas de ancho de banda y controlador de CPU-GPU.
Monte Carlo es vergonzosamente paralelo, pero es una técnica central en computación financiera y científica.
Uno de los encuestados es ligeramente incorrecto al decir que la mayoría de los desafíos del mundo real no se pueden descomponer fácilmente en este tipo de tareas.
Gran parte de la investigación científica se realiza aprovechando lo que puede expresarse de una manera vergonzosamente paralela.
El hecho de que se llame paralelo "vergonzosamente" no significa que no sea un campo extremadamente importante.
He trabajado en varias casas financieras, y prevemos que podemos desechar granjas de más de 1000 motores montecarlo (muchas pilas de hojas alineadas) para varias instalaciones grandes de NVidia CUDA: disminuyendo enormemente los costos de energía y calor en el centro de datos.
Un beneficio arquitectónico importante es que también hay mucha menos carga de red, ya que hay muchas menos máquinas que necesitan ser alimentadas de datos e informar de sus resultados.
Fundamentalmente, sin embargo, tales tecnologías están en un nivel de abstracción más bajo que un lenguaje de tiempo de ejecución administrado como C #, estamos hablando de dispositivos de hardware que ejecutan su propio código en sus propios procesadores.
La integración primero debe hacerse con Matlab, Mathematica que espero, junto con las API de C, por supuesto ...
Otra tecnología que viene para el procesamiento basado en GPU son las versiones de GPU de bibliotecas computacionales de alto nivel existentes. No muy llamativo, lo sé, pero tiene ventajas significativas para el código portátil y la facilidad de programación.
Por ejemplo, Stream 2.0 SDK de AMD incluye una versión de su biblioteca BLAS (álgebra lineal) con algunos de los cálculos implementados en la GPU. La API es exactamente la misma que la versión de la biblioteca solo para CPU que han enviado durante años y años; todo lo que se necesita es volver a vincular la aplicación, usa la GPU y se ejecuta más rápido.
De manera similar, Dan Campbell en GTRI ha estado trabajando en una implementación CUDA del estándar VSIPL para el procesamiento de señales. (En particular, el tipo de señal y procesamiento de imagen que es común en los sistemas de radar y cosas relacionadas como imágenes médicas). Una vez más, esa es una interfaz estándar, y las aplicaciones que se han escrito para implementaciones de VSIPL en otros procesadores pueden simplemente compilarse con este y usar la capacidad de la GPU cuando sea apropiado.
En la práctica, en estos días ya muchos programas numéricos de alto rendimiento no hacen su propia programación de bajo nivel, sino que dependen de las bibliotecas. En el hardware de Intel, si está haciendo cálculos numéricos, generalmente es difícil superar las bibliotecas matemáticas de Intel (MKL) para la mayoría de las cosas que implementa, y usarlas significa que puede obtener las ventajas de todas las instrucciones vectoriales y Trucos inteligentes en los nuevos procesadores x86, sin tener que especializar su código para ellos. Con cosas como las GPU, sospecho que esto será aún más frecuente.
Así que creo que una tecnología para vigilar es el desarrollo de bibliotecas de propósito general que forman bloques de construcción centrales para aplicaciones en dominios específicos, de manera que capturen partes de esos algoritmos que pueden enviarse de manera eficiente a la GPU a la vez que minimizan la cantidad de GPU no portátil. -especialidad específica requerida por el programador.
(Descargo de responsabilidad parcial: mi compañía también ha estado trabajando en un puerto CUDA de nuestra biblioteca VSIPL ++, por lo que me inclino a pensar que es una buena idea).
Además, en una dirección completamente diferente, es posible que desee ver algunas de las cosas que está haciendo RapidMind. Su plataforma inicialmente estaba diseñada para sistemas de CPU de varios núcleos, pero también han estado haciendo un poco de trabajo para extenderla a los cálculos de GPU.
Preveo que esta tecnología se volverá popular y general, pero tomará algún tiempo para hacerlo. Mi conjetura es de unos 5 a 10 años.
Como señaló correctamente, un obstáculo importante para la adopción de la tecnología es la falta de una biblioteca común que se ejecute en la mayoría de los adaptadores, tanto ATI como nVidia. Hasta que esto se resuelva en un grado aceptable, la tecnología no entrará en la corriente principal y se mantendrá en el nicho de las aplicaciones personalizadas que se ejecutan en hardware específico.
En cuanto a su integración con C # y otros lenguajes administrados de alto nivel, esto llevará un poco más de tiempo, pero XNA ya demuestra que los sombreadores personalizados y el entorno administrado pueden mezclarse entre sí, hasta cierto punto. Por supuesto, el código de sombreado aún no está en C #, y existen varios obstáculos importantes para hacerlo.
Una de las razones principales para la ejecución rápida del código GPU es que tiene limitaciones severas en lo que el código puede y no puede hacer, y utiliza VRAM en lugar de la RAM habitual. Esto hace que sea difícil reunir el código de la CPU y el código de la GPU. Si bien las soluciones son posibles, prácticamente anularían la ganancia de rendimiento.
Una posible solución que veo es crear un sublenguaje para C # que tenga sus limitaciones, se compile en un código de GPU y tenga una forma estrictamente definida de comunicarse con el código de C #. Sin embargo, esto no sería muy diferente de lo que ya tenemos, simplemente más cómodo de escribir debido a algunas funciones de biblioteca sintácticas y de azúcar. Sin embargo, esto también es mucho más lejos por ahora.
Repetiré la respuesta que di here.
A largo plazo, creo que la GPU dejará de existir, a medida que los procesadores de propósito general evolucionen para asumir esas funciones. Larrabee de Intel es el primer paso. La historia ha demostrado que apostar contra x86 es una mala idea.
Su percepción de que las GPU son más rápidas que las CPU se basa en el concepto erróneo creado por algunas aplicaciones paralelas embarazosas aplicadas a dispositivos como el de PS3, NVIDIA y ATI.
http://en.wikipedia.org/wiki/Embarrassingly_parallel
La mayoría de los desafíos del mundo real no se pueden descomponer fácilmente en este tipo de tareas. La CPU de escritorio es mucho más adecuada para este tipo de desafío, tanto desde un conjunto de características como desde el punto de vista del rendimiento.
Un gran problema con la tecnología GPU es que, si bien tiene una gran cantidad de capacidad de cómputo, ingresar datos (y sacarlos) es terrible (en cuanto al rendimiento). Y observe detenidamente cualquier comparación comparativa ... a menudo comparan gcc (con mínima optimización, sin vectorización) en un solo sistema de procesador con la GPU.
Otro gran problema con las GPU es que si no piensa CUIDADOSAMENTE en cómo se organizan sus datos, sufrirá un impacto real en el rendimiento interno (en la GPU). Esto a menudo implica reescribir el código muy simple en una pila de basura enrevesada.