Pourquoi devrais-je connaître la programmation simultanée?

La programmation simultanée est assez difficile pour moi: même regarder une diapositive de base me semble difficile. Cela semble tellement abstrait.

Quels sont les avantages de bien connaître les concepts de programmation simultanée? Cela m'aidera-t-il dans une programmation régulière et séquentielle? Je sais qu'il y a une satisfaction à comprendre comment nos programmes fonctionnent, mais quoi d'autre?

Voici une motivation rapide et facile: Si vous voulez coder quoi que ce soit , mais les plus petits, les plus faibles systèmes, vous serez écrirez du code concurrent.

Vous voulez écrire pour le cloud? Les instances de calcul dans le cloud sont petites. Vous n'en avez pas de gros, vous en avez plein de petits. Soudain, votre petite application Web est une application simultanée. Si vous l'avez bien conçu, vous pouvez simplement ajouter plus de serveurs à mesure que vous gagnez des clients. Sinon, vous devez apprendre comment pendant que votre instance a sa moyenne de charge indexée.

OK, vous voulez écrire des applications de bureau? Tout a un processeur dual-ou-plus-core. Sauf les machines les moins chères. Et les gens avec les machines les moins chères ne vont probablement pas débourser pour votre logiciel cher, n'est-ce pas?

Vous souhaitez peut-être faire du développement mobile? Hé, l'iPhone 4S a un processeur dual-core. Le reste ne sera pas loin derrière.

Jeux vidéo? La Xbox 360 est un système multi-CPU et la PS3 de Sony est essentiellement un système multi-core.

Vous ne pouvez tout simplement pas vous éloigner de la programmation simultanée, sauf si vous travaillez sur de petits problèmes simples.

Mise à jour 2016 : L'itération actuelle du Raspberry Pi à 35 $ est construite autour d'un système quadricœur sur une puce destinée aux téléphones portables. Des progrès spectaculaires dans l'IA ont été réalisés en partie en raison de la disponibilité de cartes graphiques haut de gamme en tant que moteurs de calcul parallèles.

De 1970 à environ 2002, les processeurs ont doublé de vitesse tous les 18 mois environ. En tant que programmeur, tout ce que vous aviez à faire était d'attendre et votre programme irait plus vite. Le problème est que vers 2002 les règles ont changé. Maintenant, ils ne font pas de plus gros processeurs rapides, ils font de plus petits processeurs plus lents, mais les mettent en groupes. L'ordinateur sur lequel je travaille a maintenant 4 cœurs et des puces avec jusqu'à 8 cœurs (et 4 threads par cœur) existent. Bientôt, nous aurons des puces avec beaucoup plus de cœurs.

Donc, si vous écrivez un programme qui n'est pas du tout simultané, vous constaterez que vous utilisez 1 cœur ou thread, mais le reste du CPU est assis là à ne rien faire. Donc, si vous avez 16 cœurs, 1 exécutera votre programme et les 15 autres seront assis là!

Le problème avec la concurrence est qu'elle n'est pas déterministe. Cela signifie que vous ne savez pas exactement dans quel ordre les différents threads feront les choses. Traditionnellement, les programmeurs ont essayé de résoudre ce problème en utilisant des verrous et autres. Cela a conduit à BEAUCOUP de douleur. Avoir une forme d'état mutable auquel plus d'un thread peut accéder librement est souvent une formule pour la douleur et les insectes!

Ces derniers temps, la tendance a été de passer à des langages fonctionnels qui contrôlent étroitement l'état mutable. Il existe deux méthodes de base permettant aux langages fonctionnels de gérer la concurrence. La première consiste à utiliser la transmission de messages. Ceci est mieux illustré par Erlang. Dans Erlang, il n'y a en général pas d'état partagé entre les processus. Ils communiquent non pas en partageant la mémoire, mais en passant mes messages. Cela devrait vous sembler logique, car nous le faisons actuellement. Je vous envoie ces informations en vous envoyant un message, pas en vous en souvenant de mon cerveau! En passant au message passant la plupart des bugs de verrouillage disparaissent tout simplement. De plus, les messages peuvent être transmis sur le réseau ainsi que dans un nœud.

L'autre méthode est STM, qui signifie Software Transcriptional Memory, Ceci est présent dans clojure et Haskell (et autres). Dans la mémoire STM est partagée mais les modifications ne peuvent être effectuées que via une transaction. Comme les gens de la base de données ont compris tout cela dans les années 1970, il est assez facile de s'assurer que tout est bien fait.

En fait, j'ai un peu simplifié un peu, Clojure et Haskell peuvent tous deux faire passer des messages, et Erlang peut faire STM.

Clause de non-responsabilité Je suis l'auteur de la programmation des services Web avec Erlang , qui sera disponible en version anticipée dans les prochaines semaines.

Parce que la simultanéité peut exploser dans votre visage quand vous vous y attendez le moins ...

La première règle de programmation simultanée est "C'est difficile". La deuxième règle de la programmation simultanée est "C'est. Est. Difficile" .. !!

Plus sérieusement cependant, il existe deux approches communes pour la programmation simultanée, le multithread et le multitraitement. Le multi-traitement est le plus facile à comprendre car cela signifie simplement que plusieurs instances d'un processus s'exécutent pour accomplir une tâche. Le est assez facile à faire sur les systèmes basés sur Unix via des appels à fork / join, mais pas si facile sur les systèmes Windows.

Le multi-threading est probablement l'approche à laquelle la plupart des gens pensent lorsqu'ils parlent de simultanéité. Il n'est pas difficile de démarrer plusieurs threads dans une application, mais le diable est dans les détails. Vous devez coordonner le partage de données entre les threads (généralement à l'aide de verrous), ce qui peut entraîner un blocage ou des données dans un état non valide. Vous devez également comprendre comment communiquer entre les threads à l'aide de concepts tels que les sémaphores, les variables conditionnelles, etc., etc.

L'avantage de tout cela est qu'une fois que vous le comprenez, vous pouvez utiliser plus efficacement le matériel sous-jacent. De nos jours, c'est à peu près la norme pour un processeur d'avoir plusieurs cœurs. En utilisant la programmation simultanée, vous pouvez faire fonctionner ces cœurs pour vous, et votre application obtiendra une amélioration de la vitesse.

L'inconvénient est que vous devez commencer à réfléchir à la façon dont vous allez diviser votre application en petites parties qui peuvent être exécutées sur différents threads. C'est beaucoup plus difficile qu'il n'y paraît. De plus, les solutions hautement concurrentes peuvent être difficiles à tester unitaire car l'ordre d'exécution est moins déterministe.

De nos jours, la plupart des langues sont livrées avec une abstraction sur la plupart des primitives simultanées pour vous faciliter la vie. Par exemple, .NET 4 est livré avec la bibliothèque parallèle de tâches, ce qui facilite un peu la vie. En Java, ils ont le package Concurrency .

J'ai récemment eu une tâche très intéressante à accomplir dans laquelle le multitraitement m'a sauvé. J'ai essentiellement dû faire beaucoup de demandes à quelques serveurs distincts, traitant de très petites quantités de données, mais de nombreuses demandes.

En travaillant avec PHP, j'ai fait les choses à l'ancienne, et le meilleur temps que j'ai obtenu après quelques heures de travail a abouti à environ 120 secondes pour exécuter un certain test (beaucoup de demandes + délai réseau + pas d'async)

Mais ce n'était pas suffisant par rapport à ce dont j'avais besoin, et après avoir échoué lamentablement avec le multitraitement PHP, je suis passé à Python.

Après quelques heures, j'ai eu un script de multi-traitement Python en cours d'exécution qui a fonctionné en 20 secondes, et après un peu de bidouiller avec les délais d'attente et non. de threads à utiliser, je l'ai réduit à ~ 10 secondes .

Il s'agissait d'un site Web écrit à 100% en PHP, à l'exception d'un seul script Python de 100 lignes. Et le tout fonctionne parfaitement.

Ma conclusion serait que même si cela ne vous aide pas au jour le jour, vous pouvez rencontrer des situations où connaître au moins les bases de la programmation simultanée vous aidera grandement.

Bonne chance et bon codage!

PS: Je n'essaie pas de bash PHP, mais PHP n'était tout simplement pas le bon outil pour le travail à accomplir.

PS2: Connaître une nouvelle technologie ou une nouvelle façon de faire peut ouvrir la porte à un tout nouveau monde de possibilités.

Si vous effectuez n'importe quel type de développement Web, la concurrence entre en jeu, au moins avec la plupart des langues. Par exemple, j'utilise spring pour le développement web et chaque nouvelle requête arrive comme son propre thread. Par conséquent, si une requête finit par accéder à un objet partagé, où l'état peut être modifié d'une variable, la concurrence est un facteur très important et doit être prise en considération. Si ce n'est pas le cas, les données peuvent être modifiées de manière imprévisible et une corruption des données peut en résulter. Il n'est pas essentiel de connaître tous les détails de la concurrence, mais l'apprentissage des éléments à la fois est important pour mieux comprendre la programmation des applications Web.Si vous travaillez sur des applications de bureau, ce n'est peut-être pas si important, sauf si vous devez exécuter plusieurs threads.

Apprenez à mieux comprendre les systèmes d'exploitation. La lecture du code source des planificateurs et des pilotes de périphériques vous aidera; ils sont définitivement concurrents.