¿Por qué los lenguajes funcionales son una bendición para los entornos de múltiples hilos?

Question

Duplicar posible:
Functional programming and multicore architecture

escucho mucho acerca de los lenguajes funcionales, y cómo se adapta bien porque no hay un estado en torno a una función; y, por lo tanto, esa función puede ser masivamente paralelizada.

Sin embargo, esto tiene poco sentido para mí porque casi todos los programas prácticos del mundo real necesitan/tienen que ocuparse del estado. También me parece interesante que la mayoría de las principales bibliotecas de escalamiento, es decir, MapReduce, están escritas típicamente en lenguajes imperativos como C o C++.

me gustaría escuchar desde el campo funcional en este bombo que estoy oyendo está viniendo ....

Answer 1

Es importante agregar una palabra: "no hay estado compartido".

Cualquier programa significativo (en cualquier idioma) cambia el estado del mundo. Pero (algunos) los lenguajes funcionales hacen que sea imposible acceder al mismo recurso desde múltiples hilos simultáneamente. La ausencia de estado compartido hace que el multihilo sea seguro.

Answer 2

Los lenguajes funcionales como Haskell, Scheme y otros tienen lo que se denomina "funciones puras". Una función pura es una función sin efectos secundarios. No modifica ningún otro estado en el programa. Esto es por definición threadsafe.

Por supuesto, puede escribir funciones puras en idiomas imperativos. También encontrará lenguajes multi-paradigma como Python, Ruby e incluso C# donde puede hacer una programación imperativa, programación funcional o ambas cosas.

Pero el punto de Haskell (etc.) es que no se puede escribir una función no pura. Bueno, eso no es estrictamente cierto, pero es mayormente cierto.

De manera similar, muchos idiomas imperativos tienen objetos inmutables por la misma razón. Un objeto inmutable es aquel cuyo estado no cambia una vez creado. De nuevo, por definición, un objeto inmutable es threadsafe.

Answer 3

Estás hablando de dos cosas diferentes y no te das cuenta.

Sí, la mayoría de los programas del mundo real han estado en algún lugar , pero si usted quiere hacer multihilo, ese estado no debería ser todas partes, y de hecho, el menor número de lugares que se encuentra, el mejor. En los programas funcionales, el valor predeterminado es no tener estado, y puede introducir el estado exactamente donde lo necesita y en ningún otro lugar. Esas partes que están tratando con el estado no serán tan fácilmente multiproceso, pero como todo el resto de su programa está libre de efectos secundarios y por lo tanto no importa en qué orden se ejecuten esas partes, elimina una gran barrera para la paralelización. .

Answer 4

Funciones de orden superior. Considere una operación de reducción simple, sumando los elementos de una matriz. En un lenguaje imperativo, los programadores suelen escribirse a sí mismos un ciclo y realizar reducciones de un elemento a la vez.

Pero ese código no es fácil de hacer multi-threaded. Cuando escribes un ciclo, estás asumiendo un orden de operaciones y tienes que deletrear cómo pasar de un elemento al siguiente. Te gustaría decir "suma la matriz" y hacer que el compilador, el tiempo de ejecución o lo que sea, tome la decisión sobre cómo trabajar a través de la matriz, dividir la tarea según sea necesario entre múltiples núcleos y combinar esos resultados . Entonces, en lugar de escribir un bucle, con algún código de adición incrustado dentro de él, una alternativa es pasar algo que representa "adición" en una función que puede hacer la división. Tan pronto como hagas eso, estarás escribiendo funcionalmente. Está pasando una función (adición) a otra función (el reductor).Si escribe de esta manera, no solo obtiene un código más legible, sino que cuando cambia la arquitectura o desea escribir para una arquitectura heterogénea, no tiene que cambiar el verano, solo el reductor. En la práctica, es posible que tenga muchos algoritmos diferentes que todos comparten un reductor, por lo que este es un gran beneficio.

Esto es solo un ejemplo simple. Es posible que desee construir sobre esto. Funciones para aplicar otras funciones en matrices 2D, funciones para aplicar funciones a estructuras de árbol, funciones para combinar funciones para aplicar funciones (por ejemplo, si tiene una estructura jerárquica con árboles arriba y matrices a continuación) y así sucesivamente.

Answer 5

Sin embargo, esto tiene poco sentido para mí porque casi todos los programas prácticos del mundo real necesitan/tienen que encargarse del estado.

¡Estaría sorprendido! Sí, todos los programas necesitan algún estado (E/S en particular) pero a menudo no necesitas mucho más. El hecho de que la mayoría de los programas tengan montones de estados no significa que necesite.

La programación en un lenguaje funcional lo alienta a usar menos estado, y por lo tanto, sus programas se vuelven más fáciles de paralelizar.

Muchos lenguajes funcionales son "impuros", lo que significa que permiten estado. Haskell no, pero Haskell tiene mónadas que básicamente te permiten obtener algo de la nada: obtienes estado usando construcciones sin estado. Las mónadas son un poco complicadas de trabajar, por lo que Haskell te da un fuerte incentivo para restringir el estado a una parte tan pequeña de tu programa como sea posible.

también me parece interesante que la mayoría de las bibliotecas de escala importantes, es decir, MapReduce, son típicamente escritos en lenguajes imperativos como C o C++.

La programación de aplicaciones simultáneas es "difícil" en C/C++. Es por eso que es mejor hacer todas las cosas peligrosas en una biblioteca que está fuertemente probada e inspeccionada. Pero todavía obtienes la flexibilidad y el rendimiento de C/C++.