¿Por qué los programadores definen modelos de programación para reemplazar C / POSIX por paralelismo?

Los proveedores de nuevas arquitecturas informáticas regularmente intentan introducir nuevos modelos de programación, por ejemplo, recientemente CUDA / OpenCL para GPGPU, y desplazan a C / POSIX como interfaz de control para el paralelismo de plataformas. (Poss & Koening, AM3: Hacia un acelerador de hardware de Unix para muchos núcleos, 2015)

¿Por qué los diseñadores de arquitectura intentan diseñar nuevos modelos de programación para desplazar a C / POSIX para la computación paralela? ¿C / POSIX no es adecuado para multiprocesadores o los autores originales de C / POSIX no tenían en cuenta la necesidad de computación paralela en el momento del diseño de C / POSIX? ¿O es el caso de que los programadores necesitan más capacidades de las que C / POSIX puede ofrecer, recurriendo así a nuevos diseños, por ejemplo, CUDA / OpenCL, etc.?

Compare los hilos POSIX y Grand Central Dispatch, por ejemplo. Tengo un código que se envía a cuatro hilos en ocho líneas de código. Con POSIX, eso sería una pesadilla absoluta.

Por otro lado, CUDA / OpenCL no se trata de subprocesos múltiples en absoluto, sino de usar habilidades vectoriales masivas. (También pueden hacer subprocesos múltiples, pero la vectorización es lo importante).

Hay una distinción entre la programación paralela SIMD y el modelo de programación paralela más tradicional que utiliza POSIX.

SIMD es el modelo que utilizan CUDA, OpenCL, etc. Hay un único conjunto de instrucciones que se ejecutan simultáneamente por muchos subprocesos, cada uno operando en su propio grupo de datos. Esto es muy útil para cosas como gráficos 3-D, donde las mismas transformaciones se aplican a una gran cantidad de puntos.

El modelo POSIX supone que cada subproceso se ejecuta de forma asíncrona y que cada subproceso puede ejecutar código totalmente diferente.

Ambos modelos tienen sus fortalezas y debilidades, por eso son diferentes. POSIX es mucho más flexible, pero CUDA / OpenCL / etc. puede aprovechar el hardware especializado, ejecutando miles de subprocesos (generalmente más simples) a la vez.