¿Qué futuro tiene la GPU en la informática?[cerrado]

Question

Puede que su CPU sea de cuatro núcleos, pero ¿sabía que algunas tarjetas gráficas actuales tienen más de 200 núcleos?Ya hemos visto lo que las GPU de las tarjetas gráficas actuales pueden hacer en lo que respecta a gráficos.Ahora también se pueden utilizar para tareas no gráficas y, en mi opinión, los resultados son sorprendentes.Un algoritmo que se presta bien al paralelismo tiene el potencial de ser mucho, mucho más rápido en una GPU que en una CPU.

Hay algunas tecnologías que hacen todo esto posible:

1.) CUDA por NVidia.Parece ser el más conocido y mejor documentado.Desafortunadamente, sólo funcionará en tarjetas de video NVidia.Descargué el SDK, probé algunas de las muestras y se están haciendo algunas cosas increíbles en CUDA.Pero el hecho de que esté limitado a tarjetas NVidia me hace cuestionar su futuro.

2.) Arroyo por ATI.El equivalente de ATI a CUDA.Como es de esperar, sólo funcionará en tarjetas ATI.

3.) OpenCL - El Grupo Khronos ha elaborado este estándar, pero aún está 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 facilite mucho el desarrollo de tarjetas de video cruzadas.

Pero, ¿qué otras tecnologías para la programación de GPU no gráficas están por llegar y cuál es más prometedora?¿Y ve o le gustaría ver que estas tecnologías se integren en algunos de los principales marcos de desarrollo como .NET para hacerlo mucho más fácil?

Answer 1

preveo que esta tecnología se convertirá en popular y corriente, pero tomará algún tiempo para hacerlo. Mi conjetura es de alrededor de 5 a 10 años.

Como se señaló correctamente, uno de los principales obstáculos para la adopción de la tecnología es la falta de una biblioteca común que se ejecuta en la mayoría de los adaptadores - tanto ATI y nVidia. Hasta que esto se resuelve en un grado aceptable, la tecnología no va a entrar en la corriente principal y permanecerá en el nicho de aplicaciones hechas a medida que se ejecutan en hardware específico.

En cuanto a su integración con C # y otros lenguajes administrados de alto nivel - esto va a tardar un poco más, pero ya XNA demuestra que los shaders personalizados y entorno administrado pueden mezclar juntos - hasta cierto punto. Por supuesto, el código de sombreado todavía no está en C #, y hay varios obstáculos principales para hacerlo.

Una de las principales razones para una rápida ejecución de código GPU es que tiene severas limitaciones en lo que el código puede o no puede hacer, y se utiliza en lugar de VRAM RAM habitual. Esto hace que sea difícil reunir código de la CPU y la GPU código. Mientras soluciones son posibles, que serían prácticamente anulan la ganancia de rendimiento.

Una posible solución que veo es hacer una sub-idioma para C # que tiene sus limitaciones, es compilado a código de la GPU, y tiene una forma estrictamente definida de comunicación con el código C # horneadas. Sin embargo, esto no sería muy diferente de lo que ya tenemos - simplemente más cómodo para escribir debido a un poco de azúcar sintáctica y funciones de la biblioteca estándar. Sin embargo, esto también es edades de distancia por ahora.

Answer 2

Creo que se puede contar el próximo DirectX como otra manera de utilizar la GPU.

A partir de mi experiencia, las GPU son extremadamente rápido para los algoritmos que son fáciles de poner en paralelo. recientemente optimicé una imagen especial el cambio de tamaño algoritmo en CUDA ser más de 100 veces más rápido en la GPU (ni siquiera un extremo alto uno) que un procesador de cuatro núcleos Intel. El problema estaba recibiendo los datos a la GPU y luego ir a buscar el resultado de nuevo a la memoria principal, ambas direcciones limitado por la velocidad memcpy () en esa máquina, que era menos de 2 GB / s. Como resultado, el algoritmo fue sólo ligeramente más rápido que la versión de la CPU ...

Así que realmente depende. Si usted tiene una aplicación científica donde se puede mantener la mayor parte de los datos sobre la GPU, y todos los algoritmos de asignar a una aplicación GPU, entonces está bien. Otra cosa me gustaría esperar hasta que haya una tubería más rápido entre la CPU y la GPU, o vamos a ver lo que ATI tiene bajo la manga con un chip combinado ...

Acerca de la tecnología a utilizar: Creo que una vez que tenga sus cosas funcionando en CUDA, el paso adicional para portarlo a OpenCL (u otro idioma) no es tan grande. Usted hizo todo el trabajo pesado por la paralelización de los algoritmos, y el resto es sólo un 'sabor' diferente

Answer 3

Monte Carlo es vergonzosamente paralelas, pero es una técnica fundamental en la computación científica y financiera.

Uno de los encuestados es ligeramente incorrecto decir que la mayoría de los desafíos del mundo real no son descomponibles fácilmente en este tipo de tareas.

Mucha investigación científica tractible se realiza mediante el aprovechamiento de lo que puede ser expresado de una manera embarazosa paralelo.

El hecho de que se llama "vergonzosamente" paralelo no quiere decir que no es un campo muy importante.

He trabajado en varias casas financieras, y preveo que podemos tirar granjas de más de 1000 motores de Montecarlo (muchas pilas de láminas alineadas entre sí) para varias grandes instalaciones NVidia CUDA - disminuir masivamente los costos de energía y calor en el centro de datos.

Uno de los beneficios de arquitectura significativa es que hay mucha menos carga de red también, ya que hay muchas menos máquinas que necesitan ser alimentados con datos e informar de sus resultados.

En el fondo, sin embargo estas 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 se ejecutan su propio código en sus propios procesadores.

Integración primero debe hacerse con Matlab, Mathematica que cabe esperar, junto con la API C de curso ...

Answer 4

Otra tecnología que se avecina para el procesamiento basada en la GPU es versiones de GPU de bibliotecas computacionales de alto nivel existentes. No es muy llamativo, lo sé, pero tiene ventajas significativas para el código portátil y facilidad de programación.

Por ejemplo, la corriente 2.0 SDK de AMD incluye una versión de su BLAS biblioteca (álgebra lineal) con algunos de los cálculos ejecutados sobre la GPU. El API es exactamente la misma que la CPU única versión de la biblioteca que han enviado durante años y años; todo lo que se necesita es volver a vincular la aplicación, y se utiliza la GPU y corre más rápido.

Del mismo modo, Dan Campbell en GTRI ha estado trabajando en una aplicación CUDA de la norma VSIPL para el procesamiento de señales. (En particular, el tipo de señal y procesamiento de imágenes que es común en los sistemas de radar y cosas relacionadas, como las imágenes médicas.) Una vez más, que es una interfaz estándar, y las aplicaciones que se han escrito para las implementaciones VSIPL en otros procesadores simplemente puede volver a compilar con éste y el uso de la capacidad de la GPU en su caso.

En la práctica, estos días ya un buen montón de programas numéricos de alto rendimiento no hacen su propia programación de bajo nivel, pero dependen de las bibliotecas. En el hardware de Intel, si está haciendo cálculos numéricos, por lo general es difícil de superar las librerías matemáticas (Intel MKL) para la mayoría de las cosas que aplique - y el uso de ellos significa que usted puede obtener las ventajas de todas las instrucciones vectoriales y trucos inteligentes en los procesadores x86 más nuevos, sin tener que especializarse su código para ellos. Con cosas como GPU, sospecho que esto será cada vez más frecuente.

Así que creo que la tecnología para tener en cuenta es el desarrollo de bibliotecas de uso general que forman los bloques básicos de construcción para aplicaciones en dominios específicos, de manera que las partes de captura de los algoritmos que se pueden enviar de manera eficiente fuera de la GPU y reducir al mínimo la cantidad de inteligencia-GPU específica no portátil requerida desde el programador.

(Bias exención de responsabilidad: Mi compañía también ha estado trabajando en un puerto CUDA de nuestra biblioteca VSIPL ++, por lo que me inclino a pensar que esto es una buena idea)

Además, en una dirección completamente diferente, es posible que desee echa un vistazo a algunas de las cosas que está haciendo RapidMind. Su plataforma fue pensado inicialmente para sistemas multi-núcleo de tipo CPU, pero que han estado haciendo una buena cantidad de trabajo que se extiende a los cálculos de GPU también.

Answer 5

Casi cualquier cosa que puede ser paralelo puede ser capaz de beneficiarse. Los ejemplos más específicos serían SETI @ home, Folding @ home, y otros proyectos distribuidos, así como la computación científica.

Especialmente cosas que dependen en gran medida aritmética de punto flotante. Esto se debe a que las GPU han especializado circuito que es muy rápido en operaciones de coma flotante. Esto significa que no es tan versátil, pero es muy bueno en lo que hace.

Si desea buscar en el procesamiento de la GPU más dedicado, echa un vistazo a de Nvidia Tesla GPU . Es una GPU, pero en realidad no tienen una salida de monitor!

Dudo que ver demasiado procesamiento de la GPU en el escritorio común, o al menos por un tiempo, porque no todo el mundo tiene una CUDA o tarjeta gráfica capaz similares, si es que tienen una tarjeta gráfica en absoluto. También es muy difícil hacer más programas paralelos. Juegos posiblemente podría utilizar esta energía adicional, pero será muy difícil y probablemente no será muy útil, ya que todos los cálculos gráficos son en su mayoría ya están en la GPU y la otra es el trabajo de la CPU y tiene para estar en la CPU debido a los conjuntos de instrucciones.

procesamiento de la GPU, al menos por un tiempo, será para mercados muy específicos del lugar que necesitan una gran cantidad de cálculos de punto flotante.

Answer 6

Es importante tener en cuenta que incluso las tareas que son inherentemente serie se pueden beneficiar de paralelización si se deben llevar a cabo muchas veces de forma independiente.

Además, tenga en cuenta que cada vez que alguien reporta el aumento de velocidad de una implementación GPU para una implementación de la CPU, casi nunca es una comparación justa. Para que sea realmente justo, los ejecutores deben primero pasar el tiempo para crear una implementación paralela CPU realmente optimizada. Un único procesador Intel Core i7 965 XE CPU puede alcanzar alrededor de 70 gigaflops en doble precisión en la actualidad. Las GPU de gama alta actuales pueden hacer gigaflops 70-80 en doble precisión y alrededor de 1000 en precisión simple. Así, un aumento de velocidad de más de 15 puede implicar una implementación CPU ineficiente.

Una advertencia importante con la computación de la GPU es que es actualmente "pequeña escala". Con un centro de supercomputación, puede ejecutar un algoritmo parallelized en cientos o incluso miles de núcleos de CPU. En contraste, la GPU "clusters" se limitan actualmente a alrededor de 8 GPU conectados a una máquina. Por supuesto, varias de estas máquinas se pueden combinar entre sí, pero esto añade complejidad adicional ya que los datos no sólo deben circular entre los ordenadores, sino también entre las GPU. Además, todavía no existe un equivalente MPI que permite a los procesos de forma transparente escalan a varias GPU a través de múltiples máquinas; se debe implementar manualmente (posiblemente en combinación con MPI).

Además de este problema de escala, la otra importante limitación de las GPU de computación paralela es la severa restricción en los patrones de acceso a memoria. el acceso aleatorio a la memoria es posible, pero el acceso de memoria cuidadosamente planificada dará lugar a muchas veces mejor rendimiento.

Tal vez el próximo candidato más prometedor es Larrabee de Intel. Tiene un acceso mucho mayor a la CPU, la memoria del sistema, y, quizás lo más importante, el almacenamiento en caché. Esto debería darle ventajas considerables con muchos algoritmos. Si no puede coincidir con el ancho de banda de memoria masiva en las GPU actuales, sin embargo, puede ser la zaga de la competencia por los algoritmos que utilizan de forma óptima este ancho de banda.

La actual generación de hardware y software requiere mucho esfuerzo desarrollador para obtener un rendimiento óptimo. A menudo, esto 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 la mejor.

Tenga en cuenta también que el esfuerzo que se requiere para obtener un rendimiento óptimo es necesario para justificar el uso de hardware GPU. La diferencia entre una aplicación ingenua y una implementación optimizada puede ser un orden de magnitud o más. Esto significa que un impelemntation CPU optimizado probable que sea tan bueno o incluso mejor que una aplicación ingenua de la GPU.

Las personas que ya están trabajando en los enlaces de .NET para CUDA. Ver aquí . Sin embargo, con la necesidad de trabajar en un nivel bajo, no creo cómputo GPU está listo para las masas todavía.

Answer 7

He oído hablar mucho de hablar de convertir lo que hoy en día son de la GPU en más de propósito general "unidades de gama proceesor", para su uso con cualquier problema de la matriz matemática, en lugar de procesamiento de gráficos. No he visto mucho salir de ahí con todo sin embargo.

La teoría era que los conjuntos de procesadores podrían seguir más o menos la misma trayectoria que flotan puntos procesadores siguieron un par de décadas antes. Originalmente procesadores de coma flotante eran caros opciones adicionales para PC de que no mucha gente se molestó en comprar. Con el tiempo se convirtieron en tan vitales que se pusieron en la propia CPU.

Answer 8

Voy a repetir la respuesta que he dado aquí.

A largo plazo creo que la GPU dejará de existir, como los procesadores de propósito general evolucionan para hacerse cargo de esas funciones. Larrabee de Intel es el primer paso. La historia ha demostrado que las apuestas en contra x86 es una mala idea.

Answer 9

GHC (Haskell) investigadores (que trabajan para Microsoft Research) están añadiendo soporte para anidada datos Paralelismo directamente a un lenguaje de programación de propósito general. La idea es utilizar múltiples núcleos y / o las GPU en el extremo posterior todavía exponer datos arrays paralelos como un tipo nativo en el idioma, independientemente del tiempo de ejecución de ejecutar el código en paralelo (o en serie para el repliegue de un solo CPU).

http://www.haskell.org/haskellwiki/GHC/Data_Parallel_Haskell

En función del éxito de este en los próximos años, que se puede esperar para ver otros idiomas (C # específicamente) recoger en la idea, lo que podría traer este tipo de capacidades a un público más convencional. Tal vez en ese momento se resolverán los problemas de ancho de banda y el conductor de la CPU-GPU.

Answer 10

Las GPU funcionan bien en problemas donde hay un alto nivel de Paralelismo a nivel de datos, lo que básicamente significa que hay una manera de particionar los datos que se van a procesar de modo que todos puedan procesarse.

Las GPU no son inherentemente tan rápidas a 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 hoy en día?) es bastante lenta en comparación con las ALU en un procesador de escritorio moderno.La cuestión es que una GPU tiene una cantidad absolutamente enorme de estos sombreadores, lo que convierte a la GPU en una computadora muy grande. SIMD procesador.Con la cantidad de sombreadores en una Geforce moderna, por ejemplo, es posible que una GPU trabaje con varios cientos (¿miles?) de números de punto flotante a la vez.

En resumen, una GPU puede ser increíblemente rápida para problemas en los que se pueden particionar los datos correctamente y procesar las particiones de forma independiente.No es tan poderoso en Paralelismo a nivel de tarea (hilo).

Answer 11

Un gran problema con la tecnología GPU es que mientras que usted tiene una gran cantidad de capacidad de cómputo de allí, la obtención de datos en (y fuera de ella) es terrible (en cuanto al rendimiento). Y observar cuidadosamente en busca de puntos de referencia de comparación ... que a menudo comparan gcc (con la optimización de mínimos, sin vectorización) en un sistema de procesador único de la GPU.

Otro gran problema con la GPU de es que si no pensar cuidadosamente acerca de cómo se organiza sus datos, que van a sufrir un verdadero impacto en el rendimiento interno (en la GPU). Esto a menudo implica reescribir el código muy simple en un montón de basura complicado.

Answer 12

Estoy muy entusiasmado con esta tecnología. Sin embargo, creo que esto sólo va a exacerbar el verdadero desafío de las grandes tareas en paralelo, uno de ancho de banda. La adición de más núcleos sólo aumentará la pelea por la memoria. OpenCL y otras bibliotecas de abstracción GPGPU no ofrecen ninguna herramienta para mejorar eso.

Cualquier plataforma de hardware de computación de alto rendimiento generalmente será diseñado con ancho de banda de la emisión planeada cuidadosamente en el hardware, el equilibrio de rendimiento, la latencia, el almacenamiento en caché y el costo. Mientras hardware básico, CPU y la GPU de, están diseñados en forma aislada unos de otros, con un ancho de banda optimizado sólo a su memoria local, que será muy difícil mejorar esto para los algoritmos que lo necesitan.

Answer 13

Es cierto que las GPU puede alcanzar cifras de rendimiento muy hi en situaciones de paralelismo a nivel de datos, como un montón aquí mencionados. Pero como yo lo veo, no hay mucho uso a que en el espacio de usuario ahora. No puedo evitar sentir que todo esto viene de la propaganda GPGPU fabricantes de GPU, que sólo quieren encontrar nuevos mercados y usos para sus productos. Y eso es absolutamente impresionante bien. ¿Se ha preguntado por qué Intel / AMD aún no ha incluyen algunos núcleos mini-x86, además de los estándar (digamos - modelo con cuatro núcleos x86 y 64 mini-x86-núcleos), sólo para aumentar los capacidad de paralelismo a nivel de datos? Ellos definitivamente podría hacer eso, si es necesario. Mi conjetura es que la industria simplemente no necesitas ese tipo de poder de procesamiento en las máquinas regulares de escritorio / servidor.

Answer 14

GPU puede o no puede seguir siendo tan popular como lo son ahora, pero la idea básica se está convirtiendo en un enfoque más popular para el procesamiento de alta potencia. Una tendencia que está surgiendo ahora es el "acelerador" externa para ayudar a la CPU con grandes trabajos de punto flotante. Una GPU es sólo un tipo de acelerador.

Intel va a lanzar un nuevo acelerador llamado el Intel MIC , que tienen la esperanza puede desafiar la GPU como un acelerador de HPC. El procesador Cell rel="nofollow"> tomó un enfoque similar, que tiene una CPU principal para hacer las tareas generales, y la descarga de computar las tareas intensivas con algunos otros elementos de procesamiento, el logro de algunas velocidades impresionantes.

Los aceleradores en general parecen ser de interés en este momento, por lo que deben estar allí por un tiempo al menos. Sea o no la GPU se mantiene como el acelerador de facto, queda por ver.

Answer 15

Su percepción de que las GPU son más rápidas que las CPU se basa en la idea errónea creado por unas pocas aplicaciones embarazosamente paralelos aplicados a los gustos de la PS3, NVIDIA y ATI hardware.

http://en.wikipedia.org/wiki/Embarrassingly_parallel

La mayoría de los desafíos del mundo real no son descomponibles fácilmente en este tipo de tareas. La CPU de escritorio está mejor manera adecuada para este tipo de retos, tanto desde el conjunto de características y rendimiento de punto de vista.

Answer 16

espero que las mismas cosas que las CPU se utilizan para?

Sólo quiero decir que esto parece un truco para mí. No me atrevo a decir "eso va a ninguna parte" cuando se trata de tecnología, sino GPU función principal es la de procesamiento de gráficos y CPU principal función es todos los demás procesos. Tener la GPU hacer cualquier otra cosa sólo parece loco.