Pourquoi le parallélisme / concurrence implicite n'est-il pas plus répandu? [fermé]

Le parallélisme implicite ^ peut enlever un lourd fardeau à de nombreux programmeurs, en le plaçant sur l'ordinateur. Alors ... pourquoi n'est-il pas plus répandu actuellement?

Parce qu'à quelques exceptions près (Haskell), le compilateur ne peut en aucun cas dérouler une boucle. Le problème est que chaque itération dans la boucle peut modifier l'état global. Donc, le faire dans un ordre différent peut provoquer une rupture. Dans haskell, vous pouvez compter sur une fonction pure, c'est-à-dire qu'elle ne lit pas ou ne change pas l'état global, donc elles peuvent être exécutées dans n'importe quel ordre.

Le vrai problème est qu'à quelques exceptions près, comment bien gérer la concurrence est toujours un problème ouvert. Les communautés d'Erlang et de Haskell semblent se porter plutôt bien, mais c'est encore un long chemin à parcourir avant de vraiment comprendre comment programmer un système N-core pour les grands N.

La plupart des langages de programmation que nous utilisons maintenant sont arrivés au moment où la programmation à thread unique et l'interaction avec un seul utilisateur sont les plus utilisées pour de nombreuses applications (ex: applications de bureau autonomes). Avec l'augmentation des applications Web, du cloud computing et des applications multi-utilisateurs, nous avons désormais besoin de plus d'applications multi-thread.

Les langages de programmation hérités essaient de prendre en charge lentement les fonctionnalités multithread du langage lui-même (comme l'ajout de java java.util.concurrent).

Les nouvelles langues qui arriveront à l'avenir auront un meilleur support de threading et de concurrence.

Mis à part les points mentionnés dans les autres réponses (difficile de prouver que les opérations sont indépendantes et que les programmeurs pensent sérieusement), il y a un troisième facteur à prendre en compte: le coût de la parallélisation.

La vérité est que le parallélisme des fils a des coûts très importants qui lui sont associés:

• La création de threads est très coûteuse: pour le noyau, le démarrage d'un thread est à peu près la même chose que le démarrage d'un processus. Je ne suis pas sûr des coûts précis, mais je pense que c'est de l'ordre de dix microsecondes.

• La communication des threads via des mutex est coûteuse: généralement, cela nécessite un appel système de chaque côté, mettant éventuellement un thread en veille et le réactivant, ce qui produit une latence ainsi que des caches froides et des TLB vidés. En moyenne, prendre et libérer un mutex coûte environ une microseconde.

Jusqu'ici tout va bien. Pourquoi est-ce un problème pour le parallélisme implicite? Parce que le parallélisme implicite est plus facile à prouver à petite échelle. C'est une chose de prouver que deux itérations d'une boucle simple sont indépendantes l'une de l'autre, c'est une toute autre chose de prouver que l'impression de quelque chose stdoutet l'envoi d'une requête dans une base de données sont indépendants l'un de l'autre et peuvent être exécutés en parallèle ( le processus de base de données pourrait être de l'autre côté du tuyau!).

C'est-à-dire que le parallélisme implicite qu'un programme informatique peut prouver est probablement inexploitable car les coûts de la parallélisation sont supérieurs à l'avantage du traitement parallèle. D'un autre côté, le parallélisme à grande échelle qui peut vraiment accélérer une application n'est pas prouvable pour un compilateur. Pensez simplement à la quantité de travail qu'un processeur peut faire en une microseconde. Maintenant, si la parallélisation est supposée être plus rapide que le programme série, le programme parallèle doit être capable de garder tous les CPU occupés pendant plusieurs microsecondes entre deux appels mutex. Cela nécessite un parallélisme à gros grains, ce qui est presque impossible à prouver automatiquement.

Enfin, pas de règle sans exception: l'exploitation du parallélisme implicite fonctionne là où aucun thread n'est impliqué, ce qui est le cas de la vectorisation du code (en utilisant des jeux d'instructions SIMD comme AVX, Altivec, etc.). Cela fonctionne en effet mieux pour le parallélisme à petite échelle qui est relativement facile à prouver.

Les programmeurs pensent en série et les langages actuels sont conçus pour prendre en charge ce modèle. À l'exception des langages marginaux tels que Haskell Erlang, etc., les langages (je m'abstiens d'utiliser l'adjectif "moderne") sont essentiellement des assemblages de haut niveau où nous disons toujours à l'ordinateur quoi faire, quand le faire et comment le faire. Jusqu'à ce que nous ayons un système d'écho où nous disons à l'ordinateur quel résultat nous voulons est disponible, nous n'avons pas la capacité mentale, en tant que programmeurs, d'utiliser pleinement la capacité de multithreading.

c'est pas naturel ......

Les transactions doivent être ACID, donc le programmeur a tendance à penser à un seul thread.

Les langues et les plates-formes doivent protéger le programmeur de la concurrence autant que possible

Et la concurrence n'est pas aussi facile à tester que la fonctionnalité elle-même, donc les programmeurs ont tendance à laisser de côté ces problèmes et, même, ne pas penser à valider la gestion de la concurrence, ce qui est une erreur