Les langages fonctionnels sont-ils intrinsèquement plus parallélisables que leurs OO ou leurs cousins ​​impératifs?

Question

J'ai lu et réfléchi un peu à ce sujet. Le buzz semble être que dans l'avenir multi-core, les langues fonctionnelles deviendront plus populaires. Je suis un parent par rapport à la programmation fonctionnelle. Ma seule exposition était académique, et rien de suffisamment compliqué pour vraiment mettre cette classe de langue à l'épreuve. Donc, si je comprends bien, les fonctions pures peuvent être parallélisées facilement et de façon transparente. C'est une fonctionnalité géniale, car cela ne signifie aucun problème avec l'écriture du code de thread. Cependant, il ne semble pas donner beaucoup d'aide avec le code série.

Example: 

fooN(... (foo3(foo2(foo1(0))))) 

Les appels de série comme ceci semblent être un problème commun et parfois inévitable. Pour moi, ils sont à la base de la raison pour laquelle la parallélisation est si difficile. Certaines tâches sont simplement (ou semblent être) hautement sérielles. Avoir un «état d'esprit fonctionnel» vous permet-il de mieux décomposer certaines tâches apparemment sérielles? Des langages fonctionnels existants offrent-ils des mécanismes transparents pour mieux paralléliser le code hautement série? Enfin, les langages fonctionnels sont-ils intrinsèquement plus parallélisables que les langages OO ou impératifs, et pourquoi?

Answer 1

Les langages fonctionnels sont plus parallélisables que les langages OO et impératifs en raison des fonctions pures. Cependant, vous avez absolument raison, si vous avez ce type de dépendance de données, vous ne pouvez pas le paralléliser. La principale valeur de la programmation fonctionnelle est de faciliter le repérage et le raisonnement du parallélisme présent dans votre code, car seules les dépendances de données, et non l'état mutable partagé, peuvent gêner. En fait, parce que la plupart des simples programmeurs mortels ont du mal à travailler dans des langages purement fonctionnels, et parce que la politique draconienne d'invalidation complète de l'état mutable peut être inefficace, l'idée de permettre l'écriture impérative des corps de fonctions , mais interdisant les effets secondaires entre les fonctions. En d'autres termes, toutes les fonctions qui doivent être parallélisées doivent être pures. Ensuite, vous pouvez avoir un état mutable pour les variables locales afin de rendre le code plus facile à écrire et plus efficace, tout en permettant une parallélisation automatique sûre et facile des appels vers ces fonctions pures. Ceci est en train d'être exploré, par exemple, dans la branche 2.0 du langage D.

Answer 2

Il s'agit principalement d'effets secondaires. Si le compilateur sait que certaines parties du code n'ont pas d'effets secondaires, il peut optimiser en fonction de la structure du code pour en exécuter certaines en parallèle.

Tenir compte LINQ sur C#/qui est semi-fonctionnel:

var someValues = from c in someArray 
       where // some comparisson with no side effects 
       select c; 

Vous indiquez l'intention de ce que vous voulez faire, si le compilateur connaissait chaque morceau de l'expression n'a pas d'effets secondaires, il pourrait affecter en toute sécurité différentes parties du tableau à traiter sur différents cœurs. En fait, il y a un .AsParalell qui arrivera sur linq parallèle (plinq), cela permettra juste cela. Le problème vient de ce qu'il ne sera pas en mesure de faire respecter le bit d'effets secondaires (étant sur un langage/framework qui ne le supporte pas), ce qui peut devenir vraiment moche si les développeurs ne sont pas au courant. À cause de cela, ils l'ont rendu explicite, mais vous pouvez voir que cela cause des problèmes en cours de route.