Bei Verwendung des traditionellen sequenziellen Reduktionsverfahrens wird der folgende Graph verkleinert:
%Vor%Graph Reductions sind jedoch von Natur aus parallel. Man könnte es stattdessen reduzieren als:
%Vor%Soweit ich weiß, verwendet jede funktionale Programmiersprache den ersten Ansatz. Ich glaube, dass dies hauptsächlich darauf zurückzuführen ist, dass bei der CPU-Planung Threads die Vorteile von parallelen Reduzierungen überkompensieren. Vor kurzem haben wir begonnen, die GPU mehr als die CPU für parallele Anwendungen zu verwenden. Wenn eine Sprache vollständig auf der GPU läuft , würden diese Kommunikationskosten verschwinden.
Gibt es funktionale Sprachen, die diese Idee nutzen?
Was bringt Sie dazu, bei der GPU-Planung zu denken, würde dies die Vorteile nicht überkompensieren?
Tatsächlich ist die Art der Parallelität, die in GPUs verwendet wird, viel schwieriger zu planen: es ist SIMD Parallelität, dh ein Ganzes Batch von stream processors machen alle im Wesentlichen die gleiche Sache zu einem Zeitpunkt, außer dass jeder einen anderen Haufen von Zahlen zertrümmert. Sie müssen also nicht nur die Teilaufgaben planen, Sie müssen sie auch synchron halten . Dies ist für allgemeine Berechnungen automatisch möglich.
Das Ausführen für bestimmte Aufgaben funktioniert sehr gut und wurde in funktionale Sprachen eingebettet. Schauen Sie sich das Projekt beschleunigen an.
auf der CPU, das Planen von Threads überkompensiert die Vorteile der parallelen Reduktion
Die Thread-Planung ist in modernen Betriebssystemen sehr effektiv. Threadinitialisierung und -beendigung können ein Grund zur Sorge sein, aber es gibt viele Techniken, um diese Kosten zu eliminieren.
Graph Reductions sind jedoch inhärent parallel
Wie bereits erwähnt, sind GPUs sehr spezielle Geräte. Man kann nicht einfach willkürlichen Algorithmus nehmen und 100 mal schneller machen, indem man einfach auf CUDA umschreibt. Apropos CUDA, es ist nicht genau eine SIMD (Single Instruction on Multiple Data), sondern SIMT (Single Instruction on Multiple Thread). Das ist etwas viel Komplexeres, aber stellen wir uns eine reine Vektorverarbeitungssprache vor. Wie der Name andeutet, sind Vektor -Prozessoren dafür ausgelegt, mit dichten Vektoren und Matrizen, d. H. Einfachen linearen Datenstrukturen, umzugehen. Jede Verzweigung innerhalb von Warp reduziert die Effizienz von Parallelität und Performance auf null. Moderne Architekturen (Fermi +) sind in der Lage, sogar einige Bäume zu verarbeiten, aber das ist ziemlich schwierig und die Leistung ist nicht so glänzend. Sie können also keine willkürliche Graphenreduktion beschleunigen.
Was ist mit funktionalen Sprachen für GPGPU? Ich glaube, es kann nicht ernst sein. Der meiste wertvolle CUDA-Code existiert in kaum optimierten Bibliotheken, die von PhDs erstellt wurden, und zielt direkt auf die Performance ab. Lesbarkeit, Deklarativität, Klarheit und sogar Sicherheit von funktionalen Sprachen spielen dabei keine Rolle.
Die Sprache Obsidian ist eine domänenspezifische Sprache, die in Haskell eingebettet ist und auf GPGPU-Berechnungen abzielt. Es ist eher niedriger als das, wonach du fragst, aber ich dachte, ich würde es trotzdem erwähnen.
Tags und Links haskell functional-programming parallel-processing ocaml gpu