la programmation Simultanée ce qui concerne les opérations qui semblent se chevaucher, et est principalement lié à la complexité qui se pose en raison de la non-déterministe de flux de contrôle. Les coûts quantitatifs associés aux programmes concurrents sont généralement à la fois le débit et la latence. Les programmes concurrents sont souvent liés aux IO, mais pas toujours, par exemple les collecteurs de déchets concurrents sont entièrement sur-CPU. L'exemple pédagogique d'un programme concurrent est un web crawler. Ce programme initie des demandes de pages et accepte les réponses en même temps les résultats des téléchargements deviennent disponibles, l'accumulation d'un ensemble de pages qui ont déjà été visités. Le flux de contrôle est non déterministe parce que les réponses ne sont pas nécessairement reçues dans le même ordre chaque fois que le programme est exécuté. Cette caractéristique peut rendre très difficile le débogage de programmes concurrents. Certaines applications sont essentiellement concurrentes, par exemple, les serveurs web doivent traiter les connexions des clients simultanément. Erlang est peut-être le plus langage prometteur pour une programmation très concurrente.

programmation Parallèle concerne les opérations qui sont superposées pour l'objectif spécifique d'améliorer le débit. Les difficultés de la programmation simultanée sont éludées en rendant le flux de contrôle déterministe. En général, les programmes génèrent des ensembles de tâches enfants qui s'exécutent en parallèle et la tâche parent ne se poursuit qu'une fois que chaque sous-tâche est terminée. Cela rend les programmes parallèles beaucoup plus facile à déboguer. La partie la plus difficile de la programmation parallèle est l'optimisation des performances en ce qui concerne des questions telles que la granularité et la communication. Ce dernier problème se pose encore dans le contexte des multicores, car il y a un coût considérable associé au transfert de données d'un cache à un autre. Denses matrix-matrix multiplie est un exemple pédagogique de programmation parallèle et il peut être résolu efficacement en utilisant l'algorithme divide-and-conquer de Straasen et en attaquant les sous-problèmes en parallèle. Cilk est peut-être le plus langage prometteur pour la programmation parallèle haute performance sur des ordinateurs à mémoire partagée (y compris multicores).

https://joearms.github.io/published/2013-04-05-concurrent-and-parallel-programming.html

Concurrent = deux files d'attente et une machine à café.

parallèle = deux files d'attente et deux machines à café.

interprétant la question originale comme parallèle / concurrent calcul au lieu de programmation .

In calcul simultané deux calculs progressent indépendamment l'un de l'autre. Le second calcul n'a pas à attendre jusqu'à ce que le premier soit terminé pour qu'il avance. Il n'indique pas, cependant, le mécanisme comment cela est réalisé. Dans la configuration à noyau unique, la suspension et alterner entre les fils est nécessaire (également appelé préemptive multithreading).

In calcul parallèle deux calculs avancent simultanément - c'est littéralement en même temps. Cela n'est pas possible avec un seul CPU et nécessite une configuration multi-core à la place.

versus

Selon: " parallèle vs Concurrent dans le noeud.js " .

je crois que la programmation concurrente se réfère à la programmation multithread qui consiste à laisser votre programme exécuter plusieurs threads, abstenu de détails matériels.

programmation parallèle se réfère à la conception spécifique de vos algorithmes de programme pour tirer profit de l'exécution parallèle disponible. Par exemple, vous pouvez exécuter en parallèle deux branches de certains algorithmes dans l'attente qu'il atteindra le résultat plus tôt (en moyenne) qu'il ne le ferait si vous vérifié la première puis de la deuxième branche.

la vue d'un processeur, Il peut être décrit par ce pic

dans la vue à partir d'un processeur, il peut être décrit par ce pic

j'ai trouvé ce contenu dans un blog. La pensée, il est utile et pertinent.

la concurrence et le parallélisme ne sont pas la même chose. Deux tâches T1 et T2 sont concourantes si l'ordre dans lequel les deux tâches sont exécutées dans le temps n'est pas prédéterminé,

T1 peut être exécuté et terminé avant T2, T2 peut être exécuté et terminé avant T1, T1 et T2 peuvent être exécutés simultanément à la même période de temps (parallélisme), T1 et T2 peuvent être exécuté alternativement, ... Si deux threads concurrents sont programmés par L'OS pour fonctionner sur un seul processeur Non-SMT non-CMP, vous pouvez obtenir la simultanéité mais pas le parallélisme. Le parallélisme est possible sur des systèmes multi-core, multi-processeurs ou distribués.

la simultanéité est souvent décrite comme une propriété d'un programme, et est un concept plus général que le parallélisme.

Source: https://blogs.oracle.com/yuanlin/entry/concurrency_vs_parallelism_concurrent_programming

dans la programmation, la simultanéité est la composition de indépendamment l'exécution de processus, tandis que le parallélisme est l'exécution simultanée des calculs (éventuellement liés).

- Andrew Gerrand -

et

simultanéité est la composition de l'exécution indépendante calcul. La concurrence est un moyen de structurer le logiciel, particulièrement comme une manière d'écrire propre code qui interagit bien avec le monde réel. Il n'est pas de parallélisme.

la simultanéité n'est pas du parallélisme, bien qu'elle permette le parallélisme. Si vous n'avez qu'un seul processeur, votre programme peut toujours être simultanées, mais il ne peut pas être parallèles. D'autre part, un bien écrit simultanées le programme peut fonctionner efficacement en parallèle sur un ordinateur multiprocesseur. Que la propriété pourrait être importante...

- Rob Pike -

Pour comprendre la différence, je recommande vivement de voir cette Rob Pike(un des créateurs de Golang) de l'Vidéo. "La Simultanéité N'Est Pas Un Parallélisme "

programmation parallèle se produit lorsque le code est exécuté en même temps et chaque exécution est indépendante de l'autre. Par conséquent, il n'y a généralement pas de préocupation sur les variables partagées et autres parce que cela ne se produira pas.

cependant la programmation concurrente consiste en code exécuté par des processus/threads diférents qui partagent des variables et tels, donc sur la programmation concurrente nous devons établir une sorte de règle pour décider qui processus / thread exécute d'abord, nous voulons cela afin que nous puissions être sûrs qu'il y aura cohérence et que nous pouvons savoir avec certitude ce qui se passera. S'il n'y a pas de contrôle et que tous les threads calculent en même temps et stockent les choses sur les mêmes variables, comment saurions-nous à quoi nous attendre à la fin? Peut-être qu'un thread est plus rapide que l'autre, peut-être qu'un des threads s'est même arrêté au milieu de son exécution et un autre a continué un calcul différent avec un corrompu(pas encore entièrement calculé) variable, les possibilités sont infinies. C'est dans ces situations que nous utilisons habituellement la programmation concurrente au lieu de la programmation parallèle.

ce sont deux phrases qui décrivent la même chose à partir de (très légèrement) points de vue différents. La programmation parallèle décrit la situation du point de vue du matériel-il y a au moins deux processeurs (éventuellement dans un seul paquet physique) qui travaillent sur un problème en parallèle. La programmation simultanée décrit les choses davantage du point de vue du Logiciel -- deux ou plusieurs actions peuvent se produire exactement au même moment (simultanément).

le le problème ici est que les gens essaient d'utiliser les deux phrases de faire clairement la distinction, lorsqu'il n'existe vraiment. La réalité est que la ligne de démarcation qu'ils essaient de Tracer est floue et indistincte depuis des décennies, et est devenue de plus en plus indistincte avec le temps.

ce qu'ils essaient de discuter est le fait qu'une fois, la plupart des ordinateurs n'avaient qu'un seul CPU. Quand vous avez exécuté plusieurs processus (ou threads) sur ce CPU simple, le CPU était seulement vraiment exécuter une instruction à partir de l'un de ces fils à la fois. L'apparence de la simultanéité était une illusion--le CPU passant entre exécuter des instructions à partir de différents fils assez rapidement qu'à la perception humaine (à laquelle quelque chose moins de 100 ms semble instantanée) il semblait faire beaucoup de choses à la fois.

le contraste évident à ceci est un ordinateur avec plusieurs CPU, ou un CPU avec plusieurs noyaux, donc la machine exécute des instructions depuis plusieurs threads et/ou processus exactement en même temps; l'exécution de code l'un ne peut pas/n'a pas d'effet sur l'exécution de code dans l'autre.

maintenant le problème: une telle distinction nette a presque jamais existé. Les concepteurs d'ordinateurs sont en fait assez intelligents, de sorte qu'ils ont remarqué Il ya longtemps que (par exemple) lorsque vous aviez besoin de lire certaines données d'un appareil D'E / S Tel qu'un disque, il a fallu un long temps (en termes des cycles CPU) pour finir. Au lieu de laisser le CPU inactif pendant que cela se produisait, ils ont trouvé différentes façons de laisser un processus/thread faire une requête d'E/S, et de laisser le code d'un autre processus/thread exécuter sur le CPU pendant que la requête d'e/s est terminée.

ainsi, bien avant que les processeurs multicouches ne deviennent la norme, nous avons eu des opérations à partir de fils multiples se produisant en parallèle.

ce n'est que la partie visible de l'iceberg. Il y a des décennies, les ordinateurs ont commencé fournissant un niveau de parallélisme. Encore une fois, étant des personnes assez intelligentes, les concepteurs d'ordinateurs ont remarqué que dans de nombreux cas, ils avaient des instructions qui n'affectaient pas les uns les autres, de sorte qu'il était possible d'exécuter plus d'une instruction à partir du même flux en même temps. Un des premiers exemples qui est devenu assez bien connu a été les données de contrôle 6600. C'était (de loin) l'ordinateur le plus rapide au monde lorsqu'il a été introduit en 1964--et une grande partie de la même architecture de base reste en usage aujourd'hui. Il suivait les ressources utilisées par chaque instruction et disposait d'un ensemble d'unités d'exécution qui exécutaient les instructions dès que les ressources dont elles dépendaient devenaient disponibles, très semblables à la conception des processeurs Intel/AMD les plus récents.

mais (comme disent les pubs) attendez--ce n'est pas tout. Il y a encore un autre élément de design pour ajouter encore plus de confusion. Il a été donné un certain nombre de noms différents (par exemple," Hyperthreading", " SMT", "CMP"), mais ils font tous référence à la même idée de base: un CPU qui peut exécuter plusieurs threads simultanément, en utilisant une combinaison de certaines ressources qui sont indépendantes pour chaque thread, et certaines ressources qui sont partagées entre les threads. Dans un cas typique, cela est combiné avec le parallélisme d'instruction décrit ci-dessus. Pour ce faire, nous avons deux (ou plus) séries de registres d'architecture. Ensuite, nous avons un ensemble d'unités d'exécution qui permet d'exécuter des instructions dès que les ressources nécessaires devenir disponibles. Celles-ci se combinent souvent bien parce que les instructions des différents flux ne dépendent pratiquement jamais des mêmes ressources.

Alors, bien sûr, nous arrivons à des systèmes modernes avec plusieurs cœurs. Ici, les choses sont évidentes, droit? Nous avons N (quelque part entre 2 et 256 en ce moment) des noyaux séparés, qui peuvent tous exécuter des instructions en même temps, donc nous avons un cas clair de vrai parallélisme--exécuter des instructions dans un processus/thread n'affecte pas exécuter des instructions dans un autre.

en quelque sorte. Même ici, nous avons quelques ressources indépendantes (registres, unités d'exécution, au moins un niveau de cache) et quelques ressources partagées (généralement au moins le niveau le plus bas de cache, et certainement les contrôleurs de mémoire et la bande passante vers la mémoire).

pour résumer: les scénarios simples que les gens aiment comparer entre les ressources partagées et les ressources indépendantes ne se produisent pratiquement jamais dans la vie réelle. Avec toutes les ressources partagées, nous finissons avec quelque chose comme MS-DOS, où nous ne pouvons exécuter qu'un programme à la fois, et nous devons arrêter d'en exécuter un avant de pouvoir exécuter l'autre. Avec des ressources complètement indépendantes, Nous avons N ordinateurs fonctionnant sous MS-DOS (sans même un réseau pour les connecter) sans possibilité de partager quoi que ce soit entre eux (parce que si nous pouvons même partager un fichier, Eh bien, c'est une ressource partagée, une violation de la prémisse de base de rien étant partagé).

Chaque cas intéressant implique une combinaison de ressources propres et de ressources partagées. Chaque ordinateur raisonnablement moderne (et beaucoup qui ne sont pas du tout modernes) a au moins une certaine capacité à effectuer au moins quelques opérations indépendantes simultanément, et à peu près tout ce qui est plus sophistiqué que MS-DOS a tiré avantage de cela au moins dans une certaine mesure.

la belle et nette division entre "concurrent" et" parallèle " que les gens aiment dessiner ne existent, et presque jamais. Ce que les gens aiment classer comme "concurrent" implique généralement encore au moins un et souvent plus différents types d'exécution parallèle. Ce qu'ils aiment classer comme "parallèle" implique souvent le partage des ressources et (par exemple) un processus bloque l'exécution d'un autre tout en utilisant une ressource qui est partagée entre les deux.

les gens qui essaient de faire une nette distinction entre "parallèle" et "concurrent" vivent dans une fantaisie d'ordinateurs qui n'a en fait jamais existé.

j'ai compris que la différence était:

1) Concurrent-exécution en tandem utilisant des ressources partagées 2) Parallèles côte à côte à l'aide de différentes ressources

ainsi, deux choses peuvent se produire en même temps indépendamment l'une de l'autre, même si elles se rejoignent aux points (2) ou deux choses en puisant sur les mêmes réserves tout au long des opérations en cours d'exécution (1).

1. Définitions:

Classique d'ordonnancement de tâches peuvent être SERIAL , PARALLEL ou CONCURRENT

SERIAL: L'analyse montre que les tâches doivent être exécutées l'une après l'autre dans une séquence connue trompée ordre ou il ne fonctionnera pas .

c'est-à-dire: Assez facile, nous pouvons vivre avec ce

PARALLEL: L'analyse montre que les tâches doivent être exécutées en même temps ou elle ne fonctionnera pas .

• toute toute défaillance de l'une des tâches -- fonctionnelle ou temporelle -- entraînera: panne totale du système.
• toutes les tâches doivent avoir un bon sens du temps.

c'est-à-dire: Essayez d'éviter cela ou nous aurons des larmes à l'heure du thé.

CONCURRENT. L'analyse montre que nous ne doit pas se soucier . Nous ne sommes pas négligents, nous avons analysé et il n'a pas d'importance; nous peut donc exécuter tout tâche à l'aide de tout facilité de crédit disponible au tout du temps.

c'est-à-dire: HAPPY DAYS

souvent la programmation disponible change à des événements connus que j'ai appelé un changement d'état.

2. Il ne s'agit pas d'un {Software | Programming } Feature mais d'un System Design approach:

les gens pensent souvent qu'il s'agit de logiciel mais il est en fait un conception de systèmes concept que pré-dates ordinateurs

systèmes logiciels ont été un peu lent dans l'absorption, très peu logiciel langues même essayer de résoudre le problème.

Vous pouvez essayez de regarder le TRANSPUTER langue occam si vous êtes intéressés à un bon essai.

( occam a un grand nombre principalement innovantes ( si ce n'est en second lieu à aucun ), incl. prise en charge explicite du langage pour PAR et SER les constructeurs d'exécution de pièces de code que d'autres langues souffrent principalement d'avoir dans l'ère forthcoming de réseaux de processeurs parallèles massifs disponibles dans les dernières années, réinventer la roue InMOS Transputers utilisés Il ya plus de 35 ans (!!!))

3. Ce qui fait un bon la Conception de Systèmes prend soin de couverture:

de façon succincte, "systems design s'adresse à ce qui suit:

LE VERBE - Ce que vous faites. ( opération ou algorithme )

LE NOM - Que faites-vous à . ( données ou interface )

quand - ouverture, horaire, changements d'état, SERIAL , PARALLEL , CONCURRENT

OÙ une Fois que vous savez quand les choses se passer ensuite, vous pouvez dire où ils peuvent se produire et pas avant.

POURQUOI Est-ce une façon de le faire? Est-il d'autres moyens? Est-il un meilleur moyen?

.. et le dernier mais pas des moindres .. CE QUI ARRIVE SI VOUS NE LE FAITES PAS ?

4. Exemples visuels de parallèle vs. en série approches:

Récente architectures Parallèles disponible en 2014 en action sur les matrices de 16-, 64 -, 1024-RISC parallèle uP-s

quart de siècle en arrière - une partie de la véritable histoire parallèle avec Inmos Transputer CPU démo vidéo du début des années 1990

bonne chance

• Concurrent programming est dans un sens général de se référer à des environnements dans lesquels les tâches que nous définissons peuvent se produire dans n'importe quel ordre. Un tâche peut se produire avant ou après une autre, et certaines ou toutes les tâches peuvent être réalisée dans le même temps.

• Parallel programming se réfère spécifiquement à l'exécution simultanée de tâches simultanées sur différents processeurs. Ainsi, tous les la programmation parallèle est simultanées, mais pas tous les programmes concurrents est parallèle.

Source: PThreads Programmation POSIX Standard pour une Meilleure Multitraitement, Buttlar, Farrell, Nichols

bien qu'il n'y ait pas complet d'accord sur la distinction entre les termes parallèle et concurrent , de nombreux auteurs font les distinctions suivantes:

• en informatique simultanée, un programme est un programme dans lequel plusieurs tâches peuvent être en cours à tout moment.
• en informatique parallèle, un programme est un programme dans lequel plusieurs tâches coopèrent étroitement pour résoudre un problème.

ainsi les programmes parallèles sont concurrents, mais un programme tel qu'un système d'exploitation multitâche est également concurrent, même lorsqu'il est exécuté sur une machine avec un seul noyau, car plusieurs tâches peuvent être en cours à tout moment.

Source : une introduction à la programmation parallèle, Peter Pacheco