Techniquement, pourquoi processus en Erlang sont-ils plus efficaces que les threads se ?

Question

Erlang Caractéristiques

De Erlang Programmation (2009):

Erlang la simultanéité est rapide et évolutive. Ses procédés sont plus léger que la machine virtuelle Erlang n'est pas de créer un OS thread pour chaque processus créé. Ils sont créés, planifiée et gérée dans la VM, indépendant du système d'exploitation. En conséquence, le processus de création, le temps est de l'ordre de quelques microsecondes et indépendante du nombre d'simultanément les processus existants. A comparer avec Java et C#, où, pour chaque processus de l'OS sous-jacent thread est créé: vous aurez une très concurrentiel des comparaisons, avec Erlang grandement surpassé les deux langues.

De la Simultanéité de la programmation orientée en Erlang (pdf) (slides) (2003):

Nous observons que le temps nécessaire pour créer un processus Erlang est constante 1µs jusqu'à 2 500 des processus; par la suite, il augmente à environ 3µs jusqu'à 30 000 processus. Les performances de Java et C# est indiqué en haut de la figure. Pour un petit nombre de processus, il faut environ 300µs de créer un processus. La création de plus de deux mille processus est impossible.

Nous voyons que jusqu'à 30 000 processus le temps d'envoyer un message entre deux processus Erlang est d'environ 0,8 µs. Pour C#, il faut environ 50µs par message, le nombre maximal de processus (qui était d'environ 1800 processus). Java a été encore pire, jusqu'à 100 processus a pris environ 50µs par message, par la suite, elle a augmenté rapidement à 10ms par message quand il y avait environ 1000 les processus Java.

Mes pensées

Je ne comprends pas tout, techniquement, pourquoi processus Erlang sont donc beaucoup plus efficace dans les nouvelles zones de frai des processus et ont beaucoup plus petite empreinte mémoire par processus. Le système d'exploitation et Erlang VM avez à faire de la planification, des changements de contexte, et de garder trace des valeurs dans les registres et ainsi de suite...

Tout simplement pourquoi ne sont pas les OS threads mise en œuvre de la même manière dans les processus d'Erlang? Ont-ils pour soutenir quelque chose de plus? Et pourquoi ont-ils besoin d'un plus grand espace de mémoire? Et pourquoi ont-ils ralentissement de la ponte et de la communication?

Techniquement, pourquoi sont des processus en Erlang plus efficace que les OS threads quand il s'agit de la ponte et de la communication? Et pourquoi pas des threads dans le système d'exploitation sera mis en œuvre et gérés de la même manière efficace? Et pourquoi ne OS threads ont plus de mémoire, plus de ralentissement de la ponte et de la communication?

Plus de lecture

• À l'intérieur de la Erlang VM avec un accent sur la SMP (2008)
• La simultanéité en Java et en Erlang (pdf) (2004)
• Les Mesures de Performance de Threads en Java et les Processus en Erlang (1998)

Answer 1

Il y a plusieurs facteurs:

1. Processus Erlang ne sont pas des OS de processus. Ils sont mis en œuvre par l'Erlang VM à l'aide d'un léger coopérative modèle de thread (préemptif à l'Erlang niveau, mais sous le contrôle d'un concert prévu à l'exécution). Cela signifie qu'il est beaucoup moins cher de changer de contexte, parce qu'ils ne interrupteur à, contrôlée de points et donc ne pas avoir à enregistrer la totalité de la CPU de l'état (normal, l'ESS et les registres FPU, espace d'adressage de la cartographie, etc.).
2. Processus Erlang utilisation allouée dynamiquement des piles, qui commencer très petit et de grandir en tant que de besoin. Ceci permet à la ponte de plusieurs milliers - voire des millions - de processus Erlang sans aspirer toute la mémoire disponible.
3. Erlang utilisé pour être mono-thread, ce qui signifie qu'il n'y a pas d'obligation de s'assurer fil de sécurité entre les processus. Il prend désormais en charge SMP, mais l'interaction entre les processus Erlang sur le même planificateur/core est encore très léger (il existe d'exécution séparé des files d'attente par cœur).

Answer 2

Après quelques recherches, j'ai trouvé une présentation par Joe Armstrong.

D' Erlang - logiciel pour un monde concurrentiel (présentation) (13 min):

[Erlang] est en même temps une langue – j'entends par là que les threads sont une partie de la programmation de la langue, ils n'appartiennent pas au système d'exploitation. C'est vraiment quel est le problème avec les langages de programmation comme Java et C++. C'est threads ne sont pas dans le langage de programmation, les threads sont quelque chose dans le système d'exploitation et qu'ils héritent de tous les problèmes qu'ils ont dans le système d'exploitation. L'un des problèmes est la granularité de la gestion de la mémoire système. La gestion de la mémoire dans le système d'exploitation protège ensemble des pages de la mémoire, de sorte que la plus petite taille qu'un thread peut être est la plus petite taille d'une page. C'est en fait trop grande.

Si vous ajoutez de la mémoire de votre machine, – vous avez le même nombre de bits, qui protège la mémoire de sorte que la granularité de la page tables remonte – vous de dire à 64 ko pour un processus que vous connaissez cours d'exécution dans quelques centaines d'octets.

Je pense qu'il répond, si pas tous, au moins quelques-unes de mes questions

Answer 3

J'ai implémenté les coroutines en assembleur, et de mesurer la performance.

La commutation entre les coroutines, une.k.un. Processus Erlang, prend environ 16 instructions et 20 nanosecondes sur un processeur moderne. Aussi, souvent, vous connaissez le processus, vous êtes de commutation (exemple: un processus de réception d'un message dans la file d'attente peut être mise en œuvre directement de la main du processus appelant le processus de réception) de sorte que le planificateur ne vient pas en jeu, il est un O(1).

Pour changer d'OS de threads, il faut environ 500-1000 nanosecondes, parce que vous êtes d'appel vers le noyau. Le système d'exploitation planificateur de threads peuvent s'exécuter en O(log(n)) O(log(log(n)), le temps, qui va commencer à être visible si vous avez des dizaines de milliers, voire de millions de threads.

Par conséquent, le processus Erlang sont plus rapides et une meilleure évolutivité, car les fondamentaux de l'opération de commutation est plus rapide, et l'ordonnanceur fonctionne de moins en moins souvent.

Answer 4

Processus Erlang correspondent (environ) de fils verts dans d'autres langues; il n'y a pas d'OS-une séparation forcée entre les processus. (Il y a peut-être bien la langue-une séparation forcée, mais c'est un moindre protection en dépit d'Erlang fait un meilleur travail que la plupart.) Parce qu'ils sont tellement légers, ils peuvent être utilisé beaucoup plus largement.

OS threads d'autre part, sont en mesure de simplement être prévue sur les différents cœurs du PROCESSEUR, et sont la plupart du temps en mesure de soutenir indépendant lié au PROCESSEUR de traitement. OS les processus sont comme des OS threads, mais avec beaucoup plus d'OS-une séparation forcée. Le prix de ces capacités est que l'OS threads et (encore plus) les processus sont plus chers.

---

Une autre façon de comprendre la différence est cette. En supposant que vous alliez écrire une implémentation de Erlang sur le dessus de la JVM (pas particulièrement fou suggestion) alors tu ferais chaque processus Erlang être un objet à un état. Vous pouvez disposer d'un pool de Thread instances (généralement de taille moyenne en fonction du nombre de cœurs dans votre système hôte; c'est un réglage de paramètre dans la vraie Erlang runtimes BTW) qui exécutent le processus Erlang. À son tour, qui va distribuer le travail qui sera fait dans le réel les ressources système disponibles. C'est une très belle façon de faire les choses, mais s'appuie totalement sur le fait que chaque individu Erlang processus ne font pas grand-chose. C'est OK bien sûr; Erlang est structuré de manière à ne pas exiger de ces processus individuels à être lourd puisque c'est l'ensemble de ceux qui exécuter le programme.

Dans beaucoup de façons, le vrai problème est celui de la terminologie. Les choses que Erlang appels processus (et qui correspondent fortement à la notion même de CSP, CCS, et en particulier le π-calcul) sont tout simplement pas les mêmes que les choses que les langues avec un C de patrimoine (y compris C++, Java, C#, et beaucoup d'autres) appellent à un processus ou un thread. Il y a certaines similitudes (tous impliquent une certaine idée de l'exécution en simultané), mais il n'y a absolument aucune équivalence. Attention donc quand quelqu'un dit "processus"; il se peut comprendre que cela signifie quelque chose de complètement différent...

Answer 5

Erlang interprète ayant seulement à se soucier de lui-même, le système d’exploitation dispose bien d’autres choses à se soucier.