Was bringen funktionale Programmiersprachen bei der Parallelisierung?
-
backdoorman schrieb:
Also muss man sich genauso wie bei jeder anderen Sprache Algorithmen ausdenken die parallel ausgeführt werden können.
Was hast du denn gedacht? Dass du funktional alle Probleme der Welt automatisch geloest bekommst?
Die Arbeit ist immer beim Programmierer - Tools helfen dir dabei und machen die Arbeit leichter. Aber am Ende des Tages zaehlt der Programmierer, nicht die Sprache.
-
volkard schrieb:
Achtung, gleich sind wir wieder dabei, Ökosysteme zu vergleichen und zu schauen, ob die IDE "Refactoring" im Menu hat.
Das stimmt, da vieles als Bibliothek implementiert werden kann. Aber ich wehre mich gegen die Aussage, alles sei Einheitsbrei. Es gibt gravierende Unterschiede.
-
Shade Of Mine schrieb:
backdoorman schrieb:
Also muss man sich genauso wie bei jeder anderen Sprache Algorithmen ausdenken die parallel ausgeführt werden können.
Was hast du denn gedacht? Dass du funktional alle Probleme der Welt automatisch geloest bekommst?
Wenn man Leute wie knivil so hört, könnte man schon meinen, das man mit funktionalen Programmiersprachen alles ganz einfach parallelisieren kann, aber geglaubt hab ich es nicht.
-
Was meinst du denn mit einfach? Vergleicht man die parallele Implementation von Quicksort in Haskell mit der sequentiellen in Haskell, so fallen recht wenig Unterschiede auf. Unteranderem entfaellt der Code fuer Erzeugen von Threads, Verteilen der Daten, etc. Der Aufwand verringert sich, die Implementation ist einfach. Wenn du aber mit einfach meinst, dir keine Gedanken mehr machen zu muessen, dann muss ich dich enttaeuschen.
-
Es ging nie um Sprachfeatures die einem beim Erzeugen von Threads usw. helfen.
-
backdoorman schrieb:
Es ging nie um Sprachfeatures die einem beim Erzeugen von Threads usw. helfen.
Es wurden Links zu allen Aspekten der parallelen Programmierung gegeben. Und ja, es ist einfacher dank rein funktional.
Wenn man Leute wie knivil so hört .. alles ganz einfach .. geglaubt hab ich es nicht.
Wenn man keine Ahnung vom Problem hat, ist es egal, welches Werkzeug man benutzt. Und wenn man keine Ahnung vom Werkzeug hat, hilft es einem wohl auch nicht viel. Wieviel Erfahrung hast du denn mit paralleler Algorithmen oder funktionalen Sprachen?
-
knivil schrieb:
Was meinst du denn mit einfach? Vergleicht man die parallele Implementation von Quicksort in Haskell mit der sequentiellen in Haskell, so fallen recht wenig Unterschiede auf.
Woanders auch nicht. Ob man mitte=teile(begin,end);quicksort(begin,mitte);quicksort(mitte,end); schreibt oder mitte=teile(beginn,end);thread1=start(quicksort,begin,mitte);thread2=start(quicksort,mitte,end);join(thread1);join(thread2); schreibt, ist relativ egal.
Ich glaube nicht, mit der geeigneten Sprache würde das Parallelisieren quasi von allein gehen.
-
Die Sprache ersetzt nicht das Denken, was backdoorman anscheinend will (.. free lunch ..).
Ob man mitte=teile .. thread2=start(quicksort,mitte,end);join(thread1);join(thread2); schreibt, ist relativ egal.
Ja. Aber man moechte vielleicht nicht mehr Threads als Kerne erzeugen. Es waere schoen, wenn die darunterliegende Runtime das automatisch kontrolliert. Natuerlich kann ich das auch in anderen Sprachen realisieren. Man verwandelt Threads in Jobs und schickt sie an einen Jobmanager (Singleton ..), der die Abbildung auf echte Threads uebernimmt. Aber man muss es selbst implementieren.
-
knivil schrieb:
Es wurden Links zu allen Aspekten der parallelen Programmierung gegeben. Und ja, es ist einfacher dank rein funktional.
knivil schrieb:
Die Sprache ersetzt nicht das Denken, was backdoorman anscheinend will
Entscheide dich mal. Ist es jetzt einfacher weil funktional oder muss man genauso viel nachdenken und es parallel hin zu bekommen? Alles was du bringst sind technische Sachen wie Threads erzeugen und nichts wie ein Algorithmus einfacher zu parallelisieren wäre.
-
backdoorman schrieb:
Entscheide dich mal. Ist es jetzt einfacher weil funktional oder muss man genauso viel nachdenken und es parallel hin zu bekommen? Alles was du bringst sind technische Sachen wie Threads erzeugen und nichts wie ein Algorithmus einfacher zu parallelisieren wäre.
Wer einen Fibonacci-Generator mit zipWith implementiert, der ist so uber (und hat vermutlich einen Knall), daß Parallelisierung für ihn zu den unwichtigen Randproblemen gehört. Kein Mensch würde behaupten, daß ein Fahrrad beim Garten-Umgraben hilft. Und doch kann's der Radfahrer besser als die Sofakartoffel. Ein Wunder.
http://www.c-plusplus.net/forum/viewtopic-var-t-is-264982-and-start-is-0-and-postdays-is-0-and-postorder-is-asc-and-highlight-is-.html
-
Parallelisierung für ihn zu den unwichtigen Randproblemen
Das soll es werden.
muss man genauso viel nachdenken
Gegenfrage: Warum ist denn parallele Programmierung schwerer? Meist ist das Synchronisation. Da waere es toll, wenn die Sprache/Bibliothek einige high-level-Konstrukte anbietet, diese zu vereinfachen oder gar unnoetig zu machen. Vielleicht werden dann nicht alle Kerne zu 100% ausgenutzt, aber immer noch besser als bei der sequenziellen Variante. Auch wunsche ich mir Unterstuetzung fuer wiederkehrende Patterns fuer parallele Probleme. Wenn man diese nicht kennt und sein Algorithmus nicht dahingehend parallelisiert, dann hilft einem die Sprache/Bibliothek auch nicht.
-
knivil schrieb:
Gegenfrage: Warum ist denn parallele Programmierung schwerer?
Ist nicht schwer? Erst recht nicht, wenn man Algos vorführt, die sich eh schon brav parallelisieren lassen. Was ganz anderes ist es, wenn sie nicht brav sind. Und wenn man dann noch Locks vermeiden will (bzw. Parallelität haben will, die für andere (z.B. automatisierte Parallelitätsorakel) unvorstellbar ist), dann fallen so Sachen wie stratifizierte Bäume auf einen.
Das macht Aua.
-
Haha!
-
Shade Of Mine schrieb:
Soetwas wie automatische Parallelisierung gibt es nicht.
Klar gibt es das. Im Grunde ist ein Vectoriser ja schon automatische Parallelisierung. Aber einige Fortrancompiler können Autoparallelisierung mit Threads. Würde mich wundern, wenn es für funktionale Sprachen (zumindest Haskell) nicht zumindest irgend ein Forschungsprojekt gibt, dass so etwas auch macht.
-
rüdiger schrieb:
Shade Of Mine schrieb:
Soetwas wie automatische Parallelisierung gibt es nicht.
Klar gibt es das. Im Grunde ist ein Vectoriser ja schon automatische Parallelisierung. Aber einige Fortrancompiler können Autoparallelisierung mit Threads. Würde mich wundern, wenn es für funktionale Sprachen (zumindest Haskell) nicht zumindest irgend ein Forschungsprojekt gibt, dass so etwas auch macht.
Das kann nur im Spezialfall funktionieren. Automatische Parallelisierung für alles, was wohl gemeint war, wäre so wie die Programmiersprache der man sagen muss "ich will Programm XYZ" und die macht es.
-
ölfö schrieb:
Das kann nur im Spezialfall funktionieren. Automatische Parallelisierung für alles, was wohl gemeint war, wäre so wie die Programmiersprache der man sagen muss "ich will Programm XYZ" und die macht es.
Der Pure-Part einer programmiersprache sollte parallelisierbar sein. Und da mittels Monaden jeder Zustand markiert ist, kann der Compiler auch raus kriegen, welche Codeteile durch Locks geschützt werden müssen...den Rest macht dann die Laufzeitanalyse - ohne gehts natürlich nicht.
-
otze schrieb:
ölfö schrieb:
Das kann nur im Spezialfall funktionieren. Automatische Parallelisierung für alles, was wohl gemeint war, wäre so wie die Programmiersprache der man sagen muss "ich will Programm XYZ" und die macht es.
Der Pure-Part einer programmiersprache sollte parallelisierbar sein. Und da mittels Monaden jeder Zustand markiert ist, kann der Compiler auch raus kriegen, welche Codeteile durch Locks geschützt werden müssen...den Rest macht dann die Laufzeitanalyse - ohne gehts natürlich nicht.
otze schrieb:
Parser sind im Allgemeinen nicht parallelisierbar. Da können auch funktionale Sprachen nichts ändern.
Passt wohl nicht zusammen.
-
malsomalso schrieb:
otze schrieb:
Parser sind im Allgemeinen nicht parallelisierbar. Da können auch funktionale Sprachen nichts ändern.
Passt wohl nicht zusammen.
Klar. Das erste war eine spezielle Aussage für State-machines, die über Zustandsübergänge(=Seiteneffekte) definiert sind. Es ist schwer dort einen "Pure-Part" zu finden. Das zweite war eine allgemeine Aussage über Programme. Die spezielle Aussage überschreibt die allgemeine Aussage im richtigen Kontext.
Und nun?
-
otze schrieb:
ölfö schrieb:
Das kann nur im Spezialfall funktionieren. Automatische Parallelisierung für alles, was wohl gemeint war, wäre so wie die Programmiersprache der man sagen muss "ich will Programm XYZ" und die macht es.
Der Pure-Part einer programmiersprache sollte parallelisierbar sein. Und da mittels Monaden jeder Zustand markiert ist, kann der Compiler auch raus kriegen, welche Codeteile durch Locks geschützt werden müssen...den Rest macht dann die Laufzeitanalyse - ohne gehts natürlich nicht.
Das hat nichts mit dem zu tun was ich als automatische Parallelisierung bezeichnen würde. Du schreibst den Pure-Part ja schon so, dass er eben pure und parallelisierbar ist und es wird nicht einfach jeder Algorithmus automatisch pure und parallelisierbar.
-
ölfö schrieb:
Das hat nichts mit dem zu tun was ich als automatische Parallelisierung bezeichnen würde. Du schreibst den Pure-Part ja schon so, dass er eben pure und parallelisierbar ist und es wird nicht einfach jeder Algorithmus automatisch pure und parallelisierbar.
Nein, aber darum geht es nicht. Die Programmiersprache forciert Pure-Funktionen. Und ich halte es für einen massiven Vorteil, wenn man Parallelisierung dann Gratis dazu bekommt. Ist immerhin besser als wenn man sie nicht hätte, richtig? richtig!