Wie / warum skaliert funktionale Sprachen (insbesondere Erlang) gut?

Question

Ich beobachte seit geraumer Zeit die wachsende Sichtbarkeit funktionaler Programmiersprachen und -funktionen. Ich habe sie mir angesehen und sehe den Grund für ihre Anziehungskraft nicht.

Vor Kurzem habe ich jedoch Kevin Smiths Präsentation "Grundlagen von Erlang" auf Codemash besucht.

Ich habe die Präsentation genossen und erfahren, dass viele der Eigenschaften funktionaler Programmierung es erleichtern, Thread-/Concurrency-Probleme zu vermeiden. Mir ist bekannt, dass das Fehlen von Zustand und Veränderbarkeit es unmöglich macht, dass mehrere Threads dieselben Daten ändern, aber Kevin sagte (wenn ich es richtig verstanden habe), dass alle Kommunikation über Nachrichten erfolgt und die Nachrichten synchron verarbeitet werden (auch hier werden Konflikte vermieden).

Aber ich habe gelesen, dass Erlang in hoch skalierbaren Anwendungen verwendet wird (der Hauptgrund, warum Ericsson es überhaupt erst erstellt hat). Wie kann es effizient sein, Tausende von Anfragen pro Sekunde zu verarbeiten, wenn alles als synchron verarbeitete Nachricht behandelt wird? Ist das nicht der Grund, warum wir begonnen haben, uns in Richtung asynchroner Verarbeitung zu bewegen - um den Vorteil zu nutzen, mehrere Threads gleichzeitig ausführen zu können und Skalierbarkeit zu erzielen? Es scheint, als ob diese Architektur, obwohl sicherer, einen Schritt rückwärts in Bezug auf Skalierbarkeit darstellt. Was übersehe ich?

Ich verstehe, dass die Schöpfer von Erlang bewusst vermieden haben, Multithreading zu unterstützen, um Konflikte zu vermeiden, aber ich dachte, dass Multithreading notwendig sei, um Skalierbarkeit zu erreichen.

Wie können funktionale Programmiersprachen von Natur aus threadsicher sein und dennoch skalieren?

Answer 1

Erlang-Nachrichten sind rein asynchron, wenn Sie eine synchrone Antwort auf Ihre Nachricht wünschen, müssen Sie explizit dafür programmieren. Möglicherweise wurde gesagt, dass Nachrichten in einer Prozessnachrichtenbox sequenziell verarbeitet werden. Jede an einen Prozess gesendete Nachricht sitzt in dieser Prozessnachrichtenbox, und der Prozess wählt eine Nachricht aus dieser Box aus, verarbeitet sie und geht dann zur nächsten über, in der Reihenfolge, die er für angemessen hält. Dies ist eine sehr sequenzielle Handlung, und der Empfangsblock tut genau das.

Sie haben wohl synchron und sequenziell verwechselt, wie Chris erwähnt hat.

Answer 2

Referentielle Transparenz: Siehe http://de.wikipedia.org/wiki/Referentielle_Transparenz_(Informatik)

Answer 3

In einer rein funktionalen Sprache spielt die Reihenfolge der Auswertung keine Rolle - bei einer Funktionsanwendung fn(arg1, .. argn) können die n Argumente parallel ausgewertet werden. Das garantiert ein hohes Maß an (automatischem) Parallelismus.

Erlang verwendet ein Prozessmodell, bei dem ein Prozess in derselben virtuellen Maschine oder auf einem anderen Prozessor ausgeführt werden kann - es gibt keine Möglichkeit, dies zu unterscheiden. Das ist nur möglich, weil Nachrichten zwischen Prozessen kopiert werden, es gibt keinen gemeinsamen (veränderbaren) Zustand. Multiprozessor-Parallelismus geht viel weiter als Multithreading, da Threads auf gemeinsamem Speicher basieren, so dass nur 8 Threads gleichzeitig auf einer 8-Kern-CPU laufen können, während Multiprozessoren auf Tausende parallele Prozesse skalieren können.