¿Por qué el código de paralelo de GPU es más complicado que el código de paralelo de CPU?

Hablando en términos generales, las CPU deciden qué hacer en función de la hora. Programarlos es un ejercicio para presentar su solución como una secuencia de operaciones muy programada. Puede relajar el orden de ejecución marcando puntos en su programa / programa donde las operaciones funcionan igual independientemente, para que puedan extenderse a través de CPU paralelas. Básicamente, todavía está organizando una cadena de eventos: algunas operaciones pueden ir primero, mientras que otras deben venir después.

El programa dice qué hacer cuando , y la CPU (principalmente) se encarga de dónde encontrar los números.

Por el contrario, las GPU deciden qué hacer en función de los elementos de datos que se les han asignado. Programarlos es un ejercicio para convertir su solución en un sistema de coordenadas que particiona la entrada. Esto deja la mayor parte de la programación a la GPU, por lo que no tiene que rastrear el tiempo con cuidado, pero se produce a expensas de prestar mayor atención a cómo están organizados sus elementos de datos.

El programa dice qué hacer dónde , y la GPU (en su mayoría) se encarga de cuándo encontrar los números.

No estoy seguro de que una u otra forma de representar un problema sea más fácil que la otra, pero las GPU que tenemos actualmente no pueden hacer muchas cosas por sí mismas: su carga de trabajo se transmite, inicia y detiene mediante un programa que las controla. desde la CPU del sistema host. Creo que la razón esencial por la cual el código de paralelización de GPU es más complicado que el código de paralelización de CPU es que la paralelización de GPU es realmente paralelización de CPU y GPU . Te obliga a pensar de dos maneras sobre un programa, porque tienes que decidir qué partes de la computación se manejan mejor con qué tipo de maquinaria, y administrar la interfaz entre ellas.

Los detalles de la pregunta mencionan las molestias de instalar controladores, acoplar lenguajes y demás, pero estos están quizás más relacionados con la madurez de los estándares tecnológicos. En última instancia, podrían resolverse pagándole a alguien para que resuelva los aspectos técnicos antes de que especifique lo que hará su programa.

En cuanto a la paralelización de las GPU es realmente más complicada, diría que es porque es más difícil programar una máquina híbrida que una homogénea. No creo que se pueda simplificar mucho acortando la notación del código fuente.

En mi experiencia de uso de CUDA, la arquitectura asume que la GPU solo podría ejecutar la misma línea de código en todos los núcleos. Nvidia incluso aconseja evitar sucursales con operaciones de aritmética como multiplicar por uno y más cero, etc.

Estas son las características de la arquitectura que funcionan bien en la operación vectorizada pero funcionan mal en una operación que consiste en muchas ramas if-else. Esto es similar a las instrucciones SSE de Intel para CPU.

La flexibilidad en la programación de subprocesos para ejecutar diferentes códigos en diferentes núcleos viene con problemas como que el código debe considerar la seguridad de los subprocesos / atomicidad / comparar e intercambiar y el rendimiento al compartir la línea de caché entre los núcleos.

La razón es doble:

1. El modelo de programación en GPU es diferente, por ejemplo, mencionaste CUDA. Esto no siempre es más difícil per se, pero definitivamente es diferente y no se enseña tanto en la universidad.
2. Probablemente, la “paralelización simple en 7 líneas de código de CPU” de la que habla es el compilador que autovectoriza sus bucles o algo por el estilo. Esto es mucho más fácil porque si tiene código pesado de ramificación después de este segmento paralelo de código, su CPU lo manejará bien, pero su GPU no lo hará y, por lo tanto, necesita un modelo de programación diferente (es decir, mencionó CUDA).

Debido a que GPU es una parte adicional, cuando agrega algo tiene que configurarlo. Cuando instalas algo tienes que configurarlo. Simple es eso.