¿Por qué el paralelismo / concurrencia implícitos no está más extendido? [cerrado]

13

Paralelismo implícito ^ puede quitarle una gran carga a muchos programadores, colocándolo en la computadora. Entonces ... ¿por qué no está más extendido en la actualidad?

^ El paralelismo implícito es hacer que una computadora pueda descubrir por sí misma cómo hacer más de una cosa a la vez, en lugar de que un programador tenga que hacer este trabajo utilizando subprocesos y similares.     
pregunta Abbafei 09.05.2011 - 07:46

5 respuestas

11

Porque con algunas excepciones (Haskell) no hay forma de que el compilador pueda desenvolver un bucle. El problema es que cada iteración a través del bucle puede modificar el estado global. Así que hacerlo en un orden diferente puede hacer que las cosas se rompan. En haskell puede contar con que una función sea pura, es decir, no lee ni cambia el estado global, por lo que pueden ejecutarse en cualquier orden.

El problema real es que, con algunas excepciones, cómo hacer bien la concurrencia sigue siendo un problema abierto. Parece que a las comunidades de Erlang y Haskell les está yendo bastante bien, pero aún falta mucho por recorrer antes de que realmente entendamos cómo programar un sistema N-core para una gran N.

    
respondido por el Zachary K 09.05.2011 - 10:08
5

La mayoría de los lenguajes de programación que estamos usando ahora vinieron en el momento en que la programación de un solo hilo y la interacción de un solo usuario es la más utilizada para muchas aplicaciones (por ejemplo, aplicaciones de escritorio independientes). Con el aumento de aplicaciones web, computación en la nube y aplicaciones multiusuario, ahora necesitamos más aplicaciones multihilo.

Los lenguajes de programación heredados intentan admitir lentamente las funciones de múltiples subprocesos del lenguaje en sí mismo (como java.util.concurrent agregado en java).

Los nuevos idiomas que vendrán en el futuro tendrán un mejor soporte de subprocesos y concurrencia.

    
respondido por el Dhanunjai 09.05.2011 - 08:08
4

Aparte de los puntos mencionados en las otras respuestas (es difícil demostrar que las operaciones son independientes y los programadores piensan en serie), hay un tercer factor que debe considerarse: el costo de la paralelización.

La verdad es que el paralelismo de hilos tiene costos muy significativos asociados:

  • La creación de subprocesos es muy cara: para el Kernel, comenzar un subproceso es casi lo mismo que iniciar un proceso. No estoy seguro de los costos precisos, pero creo que es del orden de diez microsegundos.

  • La comunicación de subprocesos a través de mutexes es costosa: por lo general, esto requiere una llamada del sistema en cada lado, posiblemente poner un subproceso en suspensión y reactivarlo, lo que produce latencia así como cachés fríos y TLB vaciados. En promedio, tomar y liberar un mutex cuesta alrededor de un microsegundo.

Hasta ahora, todo bien. ¿Por qué es esto un problema para el paralelismo implícito? Porque el paralelismo implícito es más fácil de probar en escalas pequeñas. Una cosa es probar que dos iteraciones de un bucle simple son independientes entre sí, es una cosa completamente diferente demostrar que la impresión de algo en stdout y el envío de una consulta a una base de datos son independientes entre sí y se pueden ejecutar en paralelo (¡el proceso de la base de datos podría estar al otro lado de la tubería!).

Es decir, es probable que el paralelismo implícito que un programa de computadora puede probar no se pueda explotar porque los costos de la paralelización son mayores que la ventaja del procesamiento paralelo. Por otro lado, el paralelismo a gran escala que realmente puede acelerar una aplicación no es demostrable para un compilador. Solo piense cuánto trabajo puede hacer una CPU en un microsegundo. Ahora, si se supone que la paralelización es más rápida que el programa en serie, el programa paralelo debe poder mantener todas las CPU ocupadas durante varios microsegundos entre dos llamadas mutex. Eso requiere un paralelismo de grano muy grueso, que es casi imposible de probar automáticamente.

Finalmente, no hay ninguna regla sin excepción: la explotación del paralelismo implícito funciona cuando no hay hilos involucrados, como ocurre con la vectorización del código (utilizando conjuntos de instrucciones SIMD como AVX, Altivec, etc.). De hecho, funciona mejor para el paralelismo a pequeña escala que es relativamente fácil de probar.

    
respondido por el cmaster 13.07.2015 - 22:25
0

Los programadores piensan en serie, y los lenguajes actuales están diseñados para soportar ese modelo. Con la excepción de los idiomas marginales, como Haskell Erlang, etc., los idiomas (me abstengo de usar el adjetivo "moderno") son esencialmente conjuntos de alto nivel donde aún le decimos a la computadora qué hacer, cuándo hacerlo y cómo hacerlo. Hasta que tengamos un sistema de eco donde le digamos a la computadora el resultado que deseamos está disponible, no tenemos la capacidad mental, como programadores, para hacer un uso completo de la capacidad de subprocesos múltiples.

es decir, no es natural ......

    
respondido por el mattnz 09.05.2011 - 09:46
0

Las transacciones deben ser ACID, por lo tanto, el programador tiende principalmente a pensar en un hilo.

Los lenguajes y las plataformas deben proteger al programador de la concurrencia tanto como pueden permitirse

Y la concurrencia no es tan fácil de probar como la funcionalidad en sí misma, por lo que los programadores tienden a dejar de lado estos problemas y, incluso, sin pensar en cometer el manejo de concurrencia, ¿qué es un error?

    
respondido por el Llistes Sugra 09.05.2011 - 10:10

Lea otras preguntas en las etiquetas