Archiv verlassen und diese Seite im Standarddesign anzeigen : Paralleles Programmieren: OpenCL, Cuda oder was anderes?
Weyoun
2009-02-11, 10:40:58
Hi,
möchte gerne eine Programmiersprache lernen, mit denen ich mit den meisten x86er Parallelcomputern umgehen kann. D.h. ich will Multicore CPUs UND GPUs (z. B. von Nvidia) programmieren können.
Eine Programmiersprache, die die meisten Leute / Firmen auch benutzen werden und die auch Zukunft hat. Ich möchte nichts lernen, nach ein paar Jahren wieder in der Versenkung verschwindet, aufgrund von mangelnder Aktzeptanz. Dann hätte ich mir die Mühe umsonst gemacht.
Die Grundsprache sollte möglichst C++ sein, lege mich da aber nicht fest. Meine Fähigkeiten reichen mittlerweile von (gutem) C++ über Java bis hin zu 8051er Mikrocontrollerprogrammierung, mit x86er Assembler habe ich nur mal ein bischen was probiert, das zu lernen sollte aber kein Problem sein. Ich mache alles gerne.
Ins Auge gefasst habe ich z. B. OpenCL und Cuda. Gibts da noch ein paar andere Sachen, die ich eurer Meinung nach unbedingt näher anschauen sollte? Mein Interessenfokus liegt auf der Programmierung von Multicore CPUs und GPUs. Multithreading für CPUs geht ohnehin mit C++, aber wie krieg ich das mit GPUs hin?
Hat jemand ein paar Tipps oder ähnliches für mich, bevor ich mich da verrenne?
Ich kann auch warten, bis die ersten OpenCL fähigen Programme oder eine bessere Sprache rauskommt, für mich ist das mehr Fortbildung interessenhalber. Dieser Thread soll für mich eine kleine Stoffsammlung werden, damit ich auf dieser Grundlage entscheiden kann, was ich nehme.
MfG,
Weyoun
Meines Wissens gibt es keine gemeinsame Sprache für Multicore CPU und GPU. Das sind einfach zu unterschiedliche Szenarien, bei Multicore CPU hast du sagen wir mal im Bereich 1-15 Threads, bei GPUs aber gleichmal ein paar tausend.
Für Nvidia Grakas bietet sich natürlich CUDA an, auch wenn das wohl auf Nvidia beschränkt bleiben wird. CUDA ist im Prinzip C/C++ mit Erweiterungen für parallele Programmierung auf der GPU. Grafikmäßig angebunden werden kann das sowohl über D3D als auch OpenGL.
Wie das mit der Akzeptanz in ein paar Jahren aussieht kann ich nicht sagen, aber CUDA ist IMO in der Community gut akzeptiert und auch weiter verbreitet als OpenCL. Die Spezifikationen von OpenCL kamen ja erst kürzlich raus, während CUDA mittlerweile bei glaub ich Version 2.1 ist. So einen Vorsprung merkt man natürlich und es ist fraglich ob OpenCL das ohne weiteres aufholen. Alles IMO.
lg
Gibt es überhaupt schon verfügbare OpenCL-Treiber? Du kannst schlecht in die Luft programmieren ;)
Meines Wissens gibt es keine gemeinsame Sprache für Multicore CPU und GPU.g
Man kann sowohl CUDA- als auch OpenCL-Kernel auf CPUs ausführen und zwar mit praktisch linearer Skalierung. Man hat dann allerdings eben die gleichen Beschränkungen wie wenn man es für eine GPU programmieren würde. Herkömmliches Multithreading auf CPUs ist deutlich flexibler.
Ich würde für neue Projekte aber auch lieber auf OpenCL setzen, da CUDA eben nicht auf ATI-Karten läuft.
Man kann sowohl CUDA- als auch OpenCL-Kernel auf CPUs ausführen und zwar mit praktisch linearer Skalierung. Man hat dann allerdings eben die gleichen Beschränkungen wie wenn man es für eine GPU programmieren würde. Herkömmliches Multithreading auf CPUs ist deutlich flexibler.
Das ist eine bessere Lösung als sich auf die Schnittmenge der Programmiersprachen zu beschränken und das nötige Framework drumrumzukopieren ;)
Die andere Alternative wäre beliebigen CPU-Code auf die GPU umzusetzen, egal wie langsam das dann wird.
Das gleiche Problem hat man übrigens auch was FPGAs angeht, da wäre eine Softwarelösung um Algorithmen wahlweise auf CPU oder FPGA auszuführen auch gut. Am besten freie Auswahl zwischen CPU, GPU und FPGA ;)
Eine Sprache ist grundsaetzlich nicht auf einen Prozessortyp beschraenkt. Es ist eher die Frage fuer welche Betriebsysteme die Sprache verfuegbar ist.
Senior Sanchez
2009-02-11, 18:06:22
Eine Sprache ist grundsaetzlich nicht auf einen Prozessortyp beschraenkt. Es ist eher die Frage fuer welche Betriebsysteme die Sprache verfuegbar ist.
Im sehr hardwarenahen Bereich sehe ich das anders, da braucht man sich bloß Assembler anschauen. Die ganzen verschiedenen Adressierungsarten die es zum Teil gibt oder auch anders strukturierte Anweisungen machen diese Assemblersprache spezifisch für einen bestimmten Prozessortypen.
Gibt es überhaupt schon verfügbare OpenCL-Treiber? Du kannst schlecht in die Luft programmieren ;)
Es gibt noch nichteinmal passende OpenCL Compiler!
Apple wirbt damit: http://www.apple.com/macosx/snowleopard/
Was es allerdings bedeutet, ob also ein Compiler mitgeliefert wird (unwahrscheinlich), ist mir nicht ganz klar.
Leider nur auf CPU basierend, scheint mir Open MP eine gute API für C++ zu sein, was prallele Programmierung angeht. Habe es leider selbst nie benutzt und kann deswegen auch nichts sicheres sagen. Jedenfalls ist es Plattformunabhängig (im Gegensatz zu pthreads z.B.) und Compiler sind in guter Vielfalt verfügbar (VS 08 bringt z.B. schon einen mit).
Senior Sanchez
2009-02-11, 21:09:35
Naja, Apple integriert es via Grand Central und für Objective-C haben sie ne Anbindung versprochen, was ja auch nur Sinn macht, denn es wird vielleicht das herausstechenste Merkmal von Snow Leopard sein. Ich weiß gar nicht, wie das in den aktuellen Dev-Seeds aussieht, ob es da schon eine Xcode Umgebung gibt, die Unterstützung für Grand Central bietet. Aber zur Finalversion wirds das garantiert geben.
Intern wird das wohl über LLVM abgebildet.
Man kann sowohl CUDA- als auch OpenCL-Kernel auf CPUs ausführen und zwar mit praktisch linearer Skalierung. Man hat dann allerdings eben die gleichen Beschränkungen wie wenn man es für eine GPU programmieren würde.
Was das ganze wiederum ziemlich sinnlos macht. Wozu einen Kernel auf der CPU laufen lassen wenn er auf der GPU 1000mal schneller ist? Andersrum kann man das was man mit Multithreading machen möchte nicht mal eben in einen Kernel umschreiben.
Herkömmliches Multithreading auf CPUs ist deutlich flexibler.
Ganz genau. Parallele Programmierung auf der GPU ist eben ganz was anderes als parallele Programmierung auf einer Multiprozessormaschine.
Ich würde für neue Projekte aber auch lieber auf OpenCL setzen, da CUDA eben nicht auf ATI-Karten läuft.
Naja, wie gesagt, die ein zwei Jahre Rückstand sind nicht so ganz ohne. Bei CUDA gibt es mittlerweile ausgereifte Tools, gute Doku, eine große Community... ein nicht zu unterschätzender Vorteil.
ATI hat den GPGPU Zug IMO sowieso verpasst... Wer in dem Bereich tätig ist hat zu (deutlich) mehrheitlich eine Nvidia und kann zwischen CUDA und OpenCL wählen - was wird man da wohl eher nehmen?
Was das ganze wiederum ziemlich sinnlos macht. Wozu einen Kernel auf der CPU laufen lassen wenn er auf der GPU 1000mal schneller ist?
Muss nichtmal unbedingt der Fall sein. Bestimmte Speicherzugriffsmuster mögen die GPUs z.B. nicht.
Aber du hast schon recht. Es ist oft nicht sinnvoll.
Ganz genau. Parallele Programmierung auf der GPU ist eben ganz was anderes als parallele Programmierung auf einer Multiprozessormaschine.
Etwas ganz anderes ist es nun auch wieder nicht.
Intern wird das wohl über LLVM abgebildet.
Gibt es dafür eigentlich schon eine Bestätigung?
Da sie die IR für OpenCL nicht festgelegt haben, ist es natürlich möglich. Allerdings hab ich bisher auch nichts auf der LLVM Dev-Mailingliste gesehen, was etwas in der Richtung andeuten würde.
Senior Sanchez
2009-02-11, 22:55:14
Gibt es dafür eigentlich schon eine Bestätigung?
Da sie die IR für OpenCL nicht festgelegt haben, ist es natürlich möglich. Allerdings hab ich bisher auch nichts auf der LLVM Dev-Mailingliste gesehen, was etwas in der Richtung andeuten würde.
Nope, ich habe bisher auch nur die Vermutung gelesen, weswegen ich auch das Wörtchen "wohl" eingefügt habe. :)
Aquaschaf
2009-02-11, 23:09:06
Eine Programmiersprache, die die meisten Leute / Firmen auch benutzen werden und die auch Zukunft hat. Ich möchte nichts lernen, nach ein paar Jahren wieder in der Versenkung verschwindet, aufgrund von mangelnder Aktzeptanz. Dann hätte ich mir die Mühe umsonst gemacht.
Mit der Vorbedingung wird es nicht einfach. Es stecken gerade mehrere Programmierkonzepte in den Kinderschuhen, die alle zum Ziel haben parallele Programmierung einfacher zu machen. Was es am Ende wird ist nicht vorhersehbar. Aber: man lernt ja nicht eine bestimmte Sprache, sondern die Konzepte dahinter. Durchaus nicht schlimm, wenn man eine Sprache lernt die sich als nicht relevant herausstellt. Erkentnisse lassen sich auf andere Sprachen übertragen.
Weyoun
2009-02-12, 01:17:47
Mit der Vorbedingung wird es nicht einfach. Es stecken gerade mehrere Programmierkonzepte in den Kinderschuhen, die alle zum Ziel haben parallele Programmierung einfacher zu machen. Was es am Ende wird ist nicht vorhersehbar. Aber: man lernt ja nicht eine bestimmte Sprache, sondern die Konzepte dahinter. Durchaus nicht schlimm, wenn man eine Sprache lernt die sich als nicht relevant herausstellt. Erkentnisse lassen sich auf andere Sprachen übertragen.
Nicht aber die Projekte, die aufwändig umgeschrieben werden müssen. Für die zur Programmierzeit aktuelle Hardware mag das ja gelten. Aber wer gerantiert mir das, wenn ich diesselben Sachen 5 Jahre später auf nem weitaus schnelleren Rechner laufen lassen will?
Ich programmiere für gewöhnlich gleich vom Start weg nur höchstens ein oder zweimal HelloWorld Programme um mal die Funktionalität und Implementierungsmethodik dahinter zu verstehen. Das weitere Lernen geschieht dann gleich mit handfesten Programmen, die ich auch weiterverwenden will. Learning by doing in gewisser Weise.
@Coda, du hast Recht, dass es für OpenCL noch nichts wirklich brauchbares gibt. Aber ich kann warten, ich bin jung und habe Zeit. :) In der Zeit mach ich halt noch was anderes, und wenns soweit ist beschäftige ich mich umfassender damit.
Gibts neben Cuda und OpenCL noch was ähnliches, das in diesselbe Richtung geht und eine breite Aktzeptanz hat oder haben wird?
Ja, Direct3D 11 Compute Shader
Aquaschaf
2009-02-12, 13:16:44
Nicht aber die Projekte, die aufwändig umgeschrieben werden müssen. Für die zur Programmierzeit aktuelle Hardware mag das ja gelten. Aber wer gerantiert mir das, wenn ich diesselben Sachen 5 Jahre später auf nem weitaus schnelleren Rechner laufen lassen will?
Mit dem Risiko musst du leben. In die Zukunft sehen kann niemand. Erst recht nicht in einer Übergangsphase wie wir sie gerade erleben.
Übrigens: OpenCL (AMD Demo) auf der Siggraph vergangenen Jahres: http://www.youtube.com/watch?v=mcU89Td53Gg&fmt=18
Die Frage, die du dir als erster stellen musst ist, welche Programme du wirklich auf der GPU laufen lassen willst. Bisher gibt es außer ein paar Spielereien noch keine einzige Anwendung, die wirklich davon profitiert. Eine GPU ist auch bei weitem keine 1K mal schneller. Wenn man ein High End Modell her nimmt mit idealem Code, dann ist des ca. Faktor 20, in der Realität wird es vielleicht um den Faktor 3-5 schneller sein und das auch nur bei Code, der sich gut optimieren lässt.
Die Programmierung einer GPU gestaltet sich nicht so, dass man einfach ein paar Bibliotheken benutzt oder eine andere Programmiersprache benutzt. Hier ist das Programmierkonzept an sich schon ein komplett anderes. Die meisten Programme haben viel zu viele IO Zugriffe, als dass sie überhaupt von einer GPU profitieren würden und die Arbeit ist auch sehr selten so gut parallelisierbar. Speicherzugriffe sind sowieso der Tod jeder GPU.
Für den 0815 User fällti mir momentan überhaupt keine Anwendung für eine GPU ein, außer Spiele an sich und vielleicht in diesen noch ein bisschen Physik.
Speicherzugriffe sind sowieso der Tod jeder GPU.
Das ist so nicht richtig. Die Latenzen kann man sehr gut durch die große Anzahl an Threads verstecken.
Bandbreite ist eh mehr als genügend vorhanden.
Aquaschaf
2009-02-13, 22:56:10
Für den 0815 User fällti mir momentan überhaupt keine Anwendung für eine GPU ein, außer Spiele an sich und vielleicht in diesen noch ein bisschen Physik.
Naja, die meisten rechenintensiven Aufgaben könnte man relativ effizient parallelisieren für so eine Architektur. Außer Spielen und der Codierung von Videodaten fällt mir konkret aber auch kaum was ein. Ich vermute es wird eher umgekehrt laufen; irgendwem werden sinnvolle Anwendungen einfallen, die erst durch (breite) Parallelrechnern realisierbar sind.
Die Frage, die du dir als erster stellen musst ist, welche Programme du wirklich auf der GPU laufen lassen willst. Bisher gibt es außer ein paar Spielereien noch keine einzige Anwendung, die wirklich davon profitiert. Eine GPU ist auch bei weitem keine 1K mal schneller. Wenn man ein High End Modell her nimmt mit idealem Code, dann ist des ca. Faktor 20, in der Realität wird es vielleicht um den Faktor 3-5 schneller sein und das auch nur bei Code, der sich gut optimieren lässt.
Naja, mit einfachen Filtern hast du bald einmal einen Speedup von um die 1000. Ist natürlich ein bisschen theoretisch, aber bei "richtigen Anwendungen" hab ich sogar auf meiner 8600M GT (mobil!) einen Speedup von 30.
Die Programmierung einer GPU gestaltet sich nicht so, dass man einfach ein paar Bibliotheken benutzt oder eine andere Programmiersprache benutzt. Hier ist das Programmierkonzept an sich schon ein komplett anderes. Die meisten Programme haben viel zu viele IO Zugriffe, als dass sie überhaupt von einer GPU profitieren würden und die Arbeit ist auch sehr selten so gut parallelisierbar.
Ja das Problem sollte natürlich schon parallelisierbar sein, das ist ja quasi Grundvoraussetzung. Niemand würde auf die Idee kommen einen Texteditor auf der GPU zu implementieren. Ich denke der Threadstarter hat auch entsprechend parallelisierbare Probleme vorliegen und will nicht einfach "aus Spaß" mal eben auf der GPU rumprogrammieren.
Speicherzugriffe sind sowieso der Tod jeder GPU.
Wie meinen? Die Daten musst erstmal in den Speicher der GPU schieben, das kann dauern. Aber dann? So schnell wie du auf den Speicher der GPU zugegriffen hast (vielleicht auch noch schön sequentiell, s. oben parallelisierbar) kannst gar net schauen.
CUDA z.b. stellt dir auch Funktionalität bereit dass du den Speicher auf der GPU schon entsprechend gepadded = optimiert für den schnellen Zugriff bekommst.
Für den 0815 User fällti mir momentan überhaupt keine Anwendung für eine GPU ein, außer Spiele an sich und vielleicht in diesen noch ein bisschen Physik.
Oh ich glaub die Masse der 0815 Photoshop Nutzer ist da anderer Meinung. Kein fitzeliges Ausschneiden mehr, mit GrabCut geht das alles vollautomatisch. Vielleicht ein zwei Klicks mit der Maus um nachzubessern und das wars. :)
So schnell wie du auf den Speicher der GPU zugegriffen hast (vielleicht auch noch schön sequentiell, s. oben parallelisierbar) kannst gar net schauen.
Aber auch nur wenn genügend Threads laufen. Sonst ist die Zugriffslatenz schon einige hundert Takte.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.