3. Was bringt die Parallelisierung

Was bringt die Parallelisierung

  • N
    Mod

    Gregor schrieb:

    Ich bin selbst sehr gespannt, was hier an Beispielen herumkommt, bei denen funktionale Sprachen eingesetzt werden. Ich habe eine Vermutung, was da ungefähr an Beispielen kommen wird, aber ich überlasse das mal den Leuten, die tatsächlich funktionale Sprachen nutzen. 😋

    vermutlich Programme, die auf "Algorithmen" wie diesem hier aufbauen:

    fib 0 = 0
fib 1 = 1
fib n = fib (n-1) + fib (n-2)

    😃
    ...
    zum Thema Raytracer gibt es eine bekanntere Seite http://www.ffconsultancy.com/languages/ray_tracer/index.html , auf der Haskell aber nicht so gut bei wegkommt. Man findet aber auf anderen Bloggerseiten und Co, dass Haskeller sich darüber ein wenig darüber wundern und wie sich zeigt, nicht ganz unbegründet. Aber bei allen Vergleichen bleibt Summasummarum C++ schneller.
    Nichtsdestotrotz zeigt die Entwicklung auch, dass Haskell noch relativ starken Optimierungsbedarf hat, bzw. Headroom in dieser Hinsicht (und nicht nur Compiler-und Programmiertechnisch, oder GUI betreffend), und ... - aber auch, dass eben, je mehr Kerne und Threads im Spiel sind, desto besser für Haskell und die einzelnen "Funktionen".
    Und das ist, so meine ich, auch die Zukunft: Selbstlaufende, selbstentscheidende Computer mit großer paralleler Datenauswertung, möglichst tight und fehlerfrei im Code.
    Und: Haskells Typenvielfalt kann einen in die Verzweiflung oder in den Wahnsinn treiben...aber Wahnsinn und Genie, so sagt man, liegen nah beieinander...;)
    (Man fragt sich ein bißchen, was wohl der Herr Cantor von haskelltypisch düsteren, multiparametrisch-rekursiven Datentypen gehalten hätte...aber auf jeden Fall war der Cantor nicht nur ein hervorragender Mathematiker, sondern auch ein sehr guter Didakt)
    (Die Freiheit und die mögliche Kreativität und Virtuosität, die hinter dem Wahnsinn warten, würde vielleicht aber auch die Weiterentwicklung eines Raytracers, oder der zukünftigen Hardware selber mitbestimmen.)
    So gesehen, mache ich mir keine großen Gedanken um die Performance. Erstens gibt es Profiler, und man kann (fast) immer Hardwareoptimierung machen, wenn es sein muß (oder lowerlevel C, wenn C=Kerncompiler; aber neuere GHC Compiler werden besser http://www.haskell.org/ghc/docs/latest/html/users_guide/code-generators.html), und zweitens, haben funktionale Sprachen eher ein Communityproblem als Performanceprobleme. Haskell ist eine große Chance der funktionalen Community.

    Und..oh Wunder...Assemblerprogrammierkenntnisse helfen bei Haskell. Erstmal, um den Code aufzupimpen, klar, aber auch, um bestimmte Funktionen zu finden.
    Wenn man auf der Haskell-Wikiseite nach Fibonaccis guckt http://www.haskell.org/haskellwiki/The_Fibonacci_sequence
    Dann kann man zwar viel über die Haskellprogrammierung lernen, über Tricksereien, aber über klare, einfache Performance? Wo ist mein beliebter

    add rax,rbx
add rbx,rax

    Ping-Pong-Algo?
    (oder mal eine nähere Erklärung des Codes, andere sehen vielleicht nicht alles auf einen Blick?)
    (pythonhacker können asm, sieht man gleich)

    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...

    Diese Haskell-Wikiseite zeigt, dass viele Haskeller gar kein Assembler können oder performanten Code vernünftig dokumentieren können.
    Und genau das ist in C-Kreisen ganz anders. Viele Profis, schon von Kindheit an dabei, hochoptimierte Bibliotheken, aber auch Geschäftsmodelle als Motor, gute C oder Fortrancompiler http://www.pgroup.com/resources/cudafortran.htm waren oder sind nicht unbedingt billig.

    0
  • I

    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.

    0
  • K

    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".

    0
  • I

    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.

    0
  • ?

    ⚠
    Einfach für alles Assembler nehmen und gut is, aber dafür sind ja die werten Damen/Herren der heutigen Zeit zu faul ! 👎

    0
  • M

    Welche relevante funktionale Sprache bietet überhaupt schon einen Compiler, der automatisch parallelisieren kann?

    0
  • N
    Mod

    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.
    😉

    0
  • K

    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.

    0
  • O

    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.

    0
  • ?

    Was ist jetzt mit dem Paper?

    0
  • Z

    http://stackoverflow.com/questions/4701207/current-status-of-automatic-parallelism-in-haskell

    0
  • K

    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

    http://www.youtube.com/watch?v=NWSZ4c9yqW8

    0
Anmelden zum Antworten