Was bringt die Parallelisierung
-
Ich denke es ist prinzipiell nicht strittig, dass sich (rein) funktionaler Code besser parallelisieren lässt als imperativer. Das liegt vor allem daran, dass alle Funktionen schon per Definition seiteneffektfrei und somit thread-safe sind, ferner ist die Auswertungsreihenfolge egal und dank immutablen Variablen ist jegliche Art von Synchronisation, egal ob manuell oder automatisch, nicht notwendig. Auch bei dem tatsächlich effektvollem Code ist die Parallelisierung in Haskell dank höhere Threadabstraktion einfacher und im allgemeinen weniger fehleranfällig als in Sprachen wie C++.
Das heißt aber nicht, dass Haskell für parallele Programme generell besser geeignet ist als in C++. Gerade bei hochperformanten Anwendungen (wie z.B. Raytracer) ist C++ (noch) die bessere Wahl, zum einen dank bessere Compiler (Haskell ist generell etwas langsamer als C++), zum anderen, weil man besser optimieren kann. Auch ist die automatische Parallelisierung auch bei funktionalen Sprachen allenfalls noch in den Kinderschuhen. Dafür wird der Programmieraufwand in C++ in der Regel höher sein.
Nicht immer ist aber bei der Parallelisierung die Performance das Wichtigste bzw. das Ziel. Bei einem Server beispielsweise, der mehrere Clients gleichzeitig bedienen soll, kann Haskell mit höherer Abstraktion, einfacherem Threadmanagement, somit weniger fehleranfälligem Code und kürzerer Entwicklungszeit punkten. In C++ könnte man sicher auch dort ein paar Prozent rausholen, allerdings mit deutlich höherem Aufwand, der sich meistens nicht lohnt.
-
Auch ist die automatische Parallelisierung auch bei funktionalen Sprachen allenfalls noch in den Kinderschuhen.
Also ich fand die Paper bei Haskel schon beeindruckend. Und dann gibt es ja noch die anderen: Lisp und ML. Neu fuer die Java VM ist Clojure. Da steckt wenig in den Kinderschuhen.
Was man also eigentlich braucht (neben mathematischen Kniffen), sind drei "Register", zwei zum Hin - und Heraddieren, und einen Zähler. Und statt den Fibonaccizahlen, wird der Zähler rekursiv heruntergezählt. Und flupp...
Ja, nett. Aber es gibt eine allgemeine Strategie fuer rekursive Probleme durch Programmtransformation, nachzulesen in beispielsweise in "Algebra of Programming".
-
knivil schrieb:
Auch ist die automatische Parallelisierung auch bei funktionalen Sprachen allenfalls noch in den Kinderschuhen.
Also ich fand die Paper bei Haskel schon beeindruckend.
Interessant, hättest du ein paar Links für mich?
Ich bezog mich aber auch eher auf die praktische Umsetzung. Soviel ich weiß, wenden aktuelle Haskell-Compiler noch keine automatische Parallelisierung an. Wie ich es verstehe, ist das Hauptproblem nicht die Parallelisierung selbst, sondern das Erkennen der Stellen, wo sich Parallelisierung lohnt. Ich gebe aber zu, ich bin in dem Thema nur oberflächlich informiert, also bitte berichtige mich.
-
Einfach für alles Assembler nehmen und gut is, aber dafür sind ja die werten Damen/Herren der heutigen Zeit zu faul !
-
Welche relevante funktionale Sprache bietet überhaupt schon einen Compiler, der automatisch parallelisieren kann?
-
Der Computer Veteran schrieb:
Einfach für alles Assembler nehmen und gut is, aber dafür sind ja die werten Damen/Herren der heutigen Zeit zu faul !Assembler für hochmoderne, intern parallele RISC-Prozessoren, die neuerdings auch äußerlich parallel - mit sagen wir mal 4 * 12 = 48 Kernen oder mehr, sagen wir mal, 64, 128 oder 256 Kernen oder noch mehr, sagen wir tausenden Threads, die aufeinander abzustimmen und optimiert zu verschachtelen wären - wäre in der Tat eine eher fummelige, langwierig-mühselige und unproduktive Angelegenheit, die zusammen mit dem Geduld erfordernden Reversen undokumentierter Hardwarekomponenten im Rechner oder undokumentierter Softwarestrukturen im Betriebsystem, eine ziemliche Strafarbeit wäre, selbst für kleine, lernunwillige Computerveteranen.
-
maximAL schrieb:
Welche relevante funktionale Sprache bietet überhaupt schon einen Compiler, der automatisch parallelisieren kann?
Automatisch schon mal gar nicht. Was erwartest du: einen Kopf mit Aufschrift "mach meine Arbeit"? Halbautomatisch dann schon eher. Ich werde mal nach den Haskell Paper schauen.
-
knivil schrieb:
Automatisch schon mal gar nicht. Was erwartest du: einen Kopf mit Aufschrift "mach meine Arbeit"? Halbautomatisch dann schon eher.
Ich würde erwarten, dass das ähnlich funktioniert wie LTO: zuerst wird ein Programm mit profilinginformationen erzeugt, das Programm ausgeführt und dann mit den profiling daten prallelisiert.
ich melde auch interesse an dem Paper an.
-
Was ist jetzt mit dem Paper?
-
-
Tschuldigung vergessen, beispielsweise:
http://www.haskell.org/haskellwiki/Research_papers/Parallelism_and_concurrency
http://community.haskell.org/~simonmar/bib/bib.html
http://www.haskell.org/haskellwiki/ThreadScope