J'ai des connaissances très limitées sur Erlang, mais aussi loin que je le comprends, elle peut reproduire des "processus" avec un coût très faible.
Alors je me demande, quels sont ces "processus" dans les coulisses?
Sont-ils des fibres? Fils? Continuations?
4 Réponses :
Ils sont Processus légers .
Voir aussi ma question techniquement pourquoi Processus d'Erlang plus efficace que les threads OS .
essentiellement, ils sont des threads;) un espace d'adressage pour eux.
Non, ils ne sont pas. Les fils sont beaucoup trop lourds pour mettre en œuvre des processus Erlang. (Je n'ai pas répondu, Btw.)
Donc, ils sont totalement émulés par un fil de temps d'horaire? Désolé, cela semble ridiculo9us inefficace dans les temps où les ordinateurs ont plus d'un noyau;)
Erlang SMP est un fil au noyau de la CPU. L'Erlang VM fournit chaque processus avec un espace d'adressage isolé, une IPC et un horaire.
Les fibres utilisent le multitâche coopératif: lorsqu'une fibre atteint un bon point d'arrêt, il donne explicitement le contrôle, permettant ainsi une autre fibre de fonctionner sur le même noyau. Les processus Erlang ressemblent davantage à des threads verts: en.wikipedia.org/wiki/green_threads
En outre, les threads sont assez inefficaces. Chacun nécessite une pile de taille fixe séparée, pour une chose, généralement quelques MB. Cela signifie seulement 1024 threads par peu de Go de RAM dans la machine ou vous obtenez un échange, ce qui obtient vraiment inefficace. Vous pouvez exécuter plusieurs milliers de processus erlang dans quelques Go.
@Warren: Vous pouvez courir des millions de gb.
Aussi, de l'Erlang Doc:
Les processus Erlang sont un poids léger (grandir et rétrécir dynamiquement) avec Petite empreinte mémoire, rapide à créer et terminer et la planification Les frais généraux sont bas.
Source: http://www.erlang.org/doc/reference_manual/processes .html
Vous voudrez peut-être aussi consulter ceci:
http://www.defmacro.org/ramblings/concurrency.html
Lorsque vous parlez de processus Erlang, il dit:
Les processus Erlang sont légers fils. Ils sont très bon marché pour commencer haut et détruire et sont très rapides à basculer entre parce que sous le capot ils sont simplement des fonctions. Un typique Système erlang fonctionnant sur un moderne ordinateur de bureau peut basculer entre beaucoup de dizaines de milliers de processus de ce type. Les processus sont commutés tous les deux couple de douzaine d'appels de fonction qui fait Commutateurs moins granulaires mais économise un quantité considérable de temps normalement gaspillé sur le changement de contexte.
Alors, comment cela diffère-t-il des fibres?
Par exemple, les fibres rubis ne peuvent pas courir simultanément sur différents cœurs / processeurs (autant que je sache, corrigez-moi si je me trompe), tandis que Erlang est très bon à cela.
N'est-ce pas plus de limitation de rubis? Vous pouvez créer des fibres de / dans des threads de Win32. Et ainsi, cela ne devrait pas être un problème de les faire courir sur plusieurs cœurs?
Je suppose que vous pouvez exécuter des fibres sur plusieurs noyaux, si les threads sont préventifs. Je lisais aussi la Follwing ( ULF. wiger.net/weblog/2008/02/06/... ). Semble intéressant.
Aussi bonne explication au sommet de erlang.org/doc/getting_started/conc_prog.htmlle_ a>
Je n'ai pas trouvé de source définitive, mais d'après ce que je comprends:
Il existe un planificateur (par exemple ou plusieurs planificateurs qui agissent coopérativement) qui détermine le processus Erlang à lancer sur lequel OS fil.
Ces processus ont une pile de culture (peut-être un préambule dans chaque fonction qui alloue la pile si nécessaire) afin qu'ils ne consomment pas Trop de mémoire à moins d'en avoir besoin.
Ils renoncent au planificateur selon qu'ils sont attendre des données ou avoir exécuté pendant une durée suffisante (Peut-être le code préambule dans certaines fonctions vérifie pour voir combien de temps écoulée). Contrairement aux threads, ils ne sont pas préemptés?
Chaque processus attribue la mémoire de différentes pages ou d'un Allocator différent, il n'est donc pas possible de partager la mémoire (dans manière similaire que les processus OS évitent la mémoire de partage).
présentaient probablement également des allocators ou des pages distincts par processus erlang aideraient également à la collecte des ordures, et dans le cas où le processus se termine, alors le Les pages peuvent être retournées sans avoir à faire une collecte des ordures: http://prog21.dadgum.com/16.html
Related: Stackoverflow.com/questions/1934707/...
Connexes: Stackoverflow.com/Questtions/1947180/...