Barrapunto

Sí, pero no es el lenguaje C el que limita, es la arquitectura. Imagina que tengas 100 mini CPUs en cada GPU, con sus respectivos buses a las memorias locales de esas mini-CPUs, al resto de mini-CPUs, a la memoria compartida de la GPU, al bus de E/S para llegar a la RAM del sistema, etc... sale muy caro tener tanto bus, por eso prefieren poner más unidades funcionales / mini-CPUs, con menos flexibilidad. En realidad, ese problema está solucionado, pero todavía no a esa escala (por poner un ejemplo en otro ámbito, un Cell con 7 SPEs no está limitado por el bus circular interno, pero si tuviese 14 SPEs, el chip tendría que ocupar no el doble, sino bastante más, pues tiene penalización extra por la nueva topología -no crece de manera exponencial, por ser un bus circular y no interconectado, pero es notable-).

Que yo sepa refiriendose al problema de acceso a los datos en la memoria global la GPU necesita entre 200 y 400 ciclos de reloj.

Pero esto ocurre tanto en la GPU como en la CPU, slo que la GPU va tan rápido que los tiempos de acceso se notan más y en vez de conseguir un speedup de x300 lo normal es conseguir solo un x30.

Pero si te las arreglas para que durante ese tiempo de acceso a la memoria global, el procesador esté haciendo otras operaciones aritméticas ese lag se nota cada vez menos. Y si te las arreglas para acceder a datos que estén secuenciales, en vez de hacer hacer accesos discreciones, los tiempos de acceso de optimizan mucho. Pero esto también funciona con las CPUs.

Por otra parte, si se hace uso de la memoria caché de la GPU (la que en el manual de CUDA llama shared) o se juega con texturas (la GPU tiene optimizados los accesos cuando trabaja con texturas) te aseguro que si se pueden conseguir esos x300 de aceleración.