El paralelismo implícito ^ puede quitarle una gran carga a muchos programadores y colocarlo en la computadora. Entonces ... ¿por qué no está más extendido en la actualidad?
^ El paralelismo implícito es hacer que una computadora sea capaz de descubrir por sí misma cómo hacer más de una cosa a la vez, en lugar de que un programador necesite hacer este trabajo usando hilos y similares
concurrency
parallelism
Abbafei
fuente
fuente
Respuestas:
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 ciclo puede modificar el estado global. Por lo tanto, 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, que no lee ni cambia el estado global, por lo que puede ejecutarse en cualquier orden.
El verdadero problema 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 queda un largo camino por recorrer antes de que realmente comprendamos cómo programar un sistema N-core para el gran N.
fuente
La mayoría de los lenguajes de programación que estamos utilizando ahora llegaron en el momento en que la programación de un solo hilo y la interacción de un solo usuario son las más utilizadas para muchas aplicaciones (por ejemplo, aplicaciones de escritorio independientes). Con el aumento de las aplicaciones web, la computación en la nube y las aplicaciones multiusuario, ahora necesitamos más aplicaciones multiproceso.
Los lenguajes de programación heredados están tratando de admitir lentamente funciones de subprocesos múltiples desde el propio lenguaje (al igual que Java agregó java.util.concurrent).
Los nuevos idiomas que vendrán en el futuro tendrán un mejor soporte de subprocesos y concurrencia.
fuente
Además de los puntos mencionados en las otras respuestas (difícil de 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 ese paralelismo de hilos tiene costos muy importantes asociados con él:
La creación de subprocesos es muy costosa: para el núcleo, iniciar 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 al sistema en cada lado, posiblemente poniendo un subproceso en suspensión y volviéndolo a activar, lo que produce latencia, así como cachés fríos y TLB vacíos. En promedio, tomar y liberar un mutex cuesta alrededor de un microsegundo.
Hasta aquí 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 a pequeña escala. Una cosa es demostrar que dos iteraciones de un bucle simple son independientes entre sí, es completamente diferente probar que imprimir algo
stdouty enviar una consulta a una base de datos son independientes entre sí y pueden ejecutarse en paralelo ( ¡el proceso de la base de datos podría estar al otro lado de la tubería!).Es decir, el paralelismo implícito que un programa de computadora puede probar es probablemente inexplorable 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 en 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 ser capaz de mantener ocupadas todas las CPU durante varios microsegundos entre dos llamadas mutex. Eso requiere un paralelismo de grano muy grueso, que es casi imposible de probar automáticamente.
Finalmente, ninguna regla sin una excepción: la explotación del paralelismo implícito funciona donde no hay hilos involucrados, como es el caso de la vectorización del código (usando conjuntos de instrucciones SIMD como AVX, Altivec, etc.). De hecho, eso funciona mejor para el paralelismo a pequeña escala que es relativamente fácil de probar.
fuente
Los programadores piensan en serie, y los lenguajes actuales están diseñados para admitir ese modelo. Con la excepción de los lenguajes marginales como Haskell Erlang, etc., los idiomas (me abstengo de usar el adjetivo "moderno") son esencialmente ensambles de alto nivel donde todavía 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 qué resultado queremos que esté disponible, no tenemos la capacidad mental, como programadores, para hacer un uso completo de la capacidad de subprocesamiento múltiple.
es decir, no es natural ......
fuente
don't have the patiencees una evaluación más precisa quedon't have the mental capacitysin embargo. A lo largo de mi carrera, he visto muchos más programadores perezosos que estúpidos . Sin embargo, tuve suerte, me enseñaron programación funcional y programación paralela detallada junto con procedimientos y OO, en mi primer año en la universidad. Sospecho que muchos programadores no tuvieron tanta suerte y, como resultado, sus procesos de pensamiento se han visto directamente forzados.Las transacciones deben ser ACID, por lo que el programador tiende principalmente a pensar en un hilo.
Los lenguajes y las plataformas deben proteger al programador de la concurrencia tanto como puedan 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 e, incluso, sin pensar en el manejo de la concurrencia de compromiso, lo que es un error
fuente