Ich habe irgendwo gelesen, dass die funktionale Programmierung geeignet ist, um die Vorteile des Multi-Core-Trends in der Computertechnik zu nutzen. Ich habe die Idee nicht wirklich verstanden. Hängt das mit dem Lambda-Kalkül und der von-Neumann-Architektur zusammen?
Antworten
Zu viele Anzeigen?Alle obigen Antworten beziehen sich auf den Kerngedanken, dass "kein gemeinsam genutzter veränderbarer Speicher" eine wichtige Voraussetzung für die parallele Ausführung von Programmteilen ist. Das ebenso schwierige Problem, Dinge zu finden, die parallel ausgeführt werden können, wird dadurch nicht wirklich gelöst. Aber die typischen klareren Ausdrücke der Funktionalität in funktionalen Sprachen machen es theoretisch einfacher, Parallelität aus einem sequenziellen Ausdruck zu extrahieren.
In der Praxis denke ich, dass die Eigenschaft "kein gemeinsamer veränderbarer Speicher" von Sprachen, die auf Garbage Collection und Copy-on-Change-Semantik basieren, es einfacher machen, ihnen Threads hinzuzufügen. Das beste Beispiel ist wahrscheinlich Erlang, das eine nahezu funktionale Semantik mit expliziten Threads kombiniert.
Diese Frage ist ein wenig vage. Ein Vorteil von Multi-Core-CPUs besteht darin, dass man ein funktionales Programm laufen lassen kann, ohne sich Gedanken darüber zu machen, dass es andere Funktionen des Rechners beeinträchtigt.
Der Unterschied zwischen einem Multi-U-Server und einer Multi-Core-CPU in einem Server oder PC liegt in der Geschwindigkeitsersparnis, die sich dadurch ergibt, dass die Kerne auf demselben BUS liegen, was eine bessere und schnellere Kommunikation mit den Kernen ermöglicht.
bearbeiten: Ich sollte wahrscheinlich diesen Beitrag qualifizieren, indem ich sage, dass in den meisten der Skripte, die ich tue, mit oder ohne mehrere Kerne, ich selten ein Problem sehe, wenn ich meine Daten durch hackish Parallelisierung, wie mehrere kleine Skripte auf einmal in meinem Skript ausführen, so dass ich nicht durch Dinge wie das Warten auf URLs zu laden und was nicht verlangsamt werden.
double edit: Außerdem gibt es in vielen funktionalen Programmiersprachen seit Jahrzehnten parallele Varianten. Diese nutzen die parallele Berechnung besser aus, mit einigen Geschwindigkeitsverbesserungen, aber sie haben sich nie wirklich durchgesetzt.
Der Grund dafür ist, dass funktionale Programme keine Daten austauschen, ohne technische/wissenschaftliche Begriffe zu verwenden. Die Daten werden zwischen den Funktionen kopiert und übertragen, es gibt also keine gemeinsamen Daten in der Anwendung.
Und gemeinsam genutzte Daten sind es, die beim Multithreading die Hälfte der Kopfschmerzen verursachen.
Das Buch Erlang programmieren: Software für eine konkurrierende Welt von Joe Armstrong (dem Schöpfer von Erlang ) spricht ziemlich viel über die Verwendung von Erlang für Multicore(/Multiprozessor)-Systeme. Wie der Wikipedia-Artikel besagt:
Das Erstellen und Verwalten von Prozessen ist in Erlang trivial, während Threads in den meisten Sprachen als kompliziertes und fehleranfälliges Thema gelten. Obwohl alle Gleichzeitigkeit in Erlang explizit ist, kommunizieren Prozesse über die Weitergabe von Nachrichten anstelle von gemeinsam genutzten Variablen, wodurch die Notwendigkeit von Sperren entfällt.
- See previous answers
- Weitere Antworten anzeigen