CUDA oder OpenCL?

Nabend, ich bin sehr am Programmieren von Simulationen interessiert, habe auch schon zwei, drei Stück geschrieben und das Hauptproblem bestand am Ende meist darin, dass eine simple Berechnung für abertausende Punkte einer Matrix wiederum tausende Male durchgeführt werden muss, bis eine Änderung sichtbar ist (dt->0 => iterationen->unendlich) und somit die Geschwindigkeit durch die Taktfrequenz der CPU sehr gering bleibt. Durch Parallelisierung über die GPU wären extreme Leistungssteigerungen möglich, weshalb ich mich in OpenCL oder CUDA einarbeiten möchte. Das Hauptprogramm samt Visualisierung würde über Java laufen (einfache GUI-Programmierung, Koordinierung, CUDA/OpenCL durch JOCL oder JCUDA Libs), hab Demos schon kompilieren können. Nun zur eigentlichen Frage: Was ist besser für wissenschaftliches Programmieren mit GPUs oder GPGPU-Systemen geeignet? CUDA oder OpenCL? Welche Language kommt beim Cern oder Unis eher zum Einsatz bzw. ist absehbar, welcher Language im wissenschaftlichen Bereich die Zukunft gehört? Ich stehe zwar noch am Anfang meines Lebens, würde mir einen späteren Umstieg aber gerne ersparen^^ Vielen Dank fürs Lesen, hoffe ihr wisst Rat!
mfg die Wurzel

Welcher Sprache in der Wissenschaft die Zukunft gehört ist extrem unsicher. Aktuell wird viel mit CUDA gearbeitet. Das ist allerdings proprietär und läuft nur auf NVIDIA-Karten, was eigentlich der wissenschaftlichen Idee der freien Zugänglichkeit entgegen steht. Ich bin mir nicht sicher, ob sich das auf Dauer durchsetzen wird. Aber auch OpenCL ist nicht gerade das Gelbe vom Ei was Usability angeht.

Was für Berechnungen willst du eigentlich machen? Es ist nicht überall gleich nötig auf GPU zu gehen. Für Berechnungen mit Matrizen gibt es diverse hochoptimierte Libraries für die CPU, z.B. die Math Kernel Library von Intel.

Java ist für solche mathematischen Operationen gänzlich ungeeignet!

Hab zuletzt eine Wellensimulation geschrieben die nur bis 200x200 Partikel flüssig genug läuft, würde das Ganze gerne auch mit höheren Auflösungen probieren. Eigentlich war ich vorher nie ein richtiger Freund von Java, hab hier auch nen 1250 Seiten-Klopper über C++ liegen, allerdings habe ich mich schnell mit der doch vergleichsweise einfachen Syntax und den ganzen mitgelieferten Standardbiblioteheken von Java anfreunden können, gerade was GUIs und ein RGB-Panel angeht. Der CUDA/OpenCL-Kernel ist zwar in C/C++ geschrieben, aber die Berechnungen in C++ für die GPU umzuschreiben scheint mir leichter als die GUI etc noch dazu in C++ umzuschreiben. Werde mich wohl dennoch mit OpenGL und C++ eingehender beschäftigen müssen, was die Demos der GPU aber so an Leistung gerade bei großen Matrizen gezeigt ha, fand ich ziemlich erstaunlich. Da OpenGL sich ja als Alternative zu DirectX behaupten konnte, könnte ich mir sehr gut vorstellen, dass OpenCL nachzieht. Vielleicht sollte ich wohl erst C++ und OpenGL fressen und gucken, wies sich entwickelt. Dann ist OpenCL auch endlich über Version 1.1 hinaus^^
edit: und danke für den Post natürlich!

Derzeit ist eindeutig CUDA die bevorzugte Architektur im Bereich von wissenschaftlichen Berechnungen. Hat unter anderem damit zu tun, dass CUDA die erste Plattform zu diesem Zweck war…

Was die Zukunft bringt? Gute Frage! Einerseits könnte man davon ausgehen, dass der Wechsel zu OpenCL erfolgt, da das auch auf anderen GPUs funktioniert. Nächstes Jahr kommt allerdings auch Intel MIC und würde es erlauben bestehenden Anwendungen/Werkzeuge - und man fängt ja bekannterweise niemals bei 0 an - weiterverwendet werden können.

IMHO sind weder CUDA noch OpenCL in Sachen Usability der Weisheit letzter Schluss - als C++-Programmierer gefallen mir da Ansätze wie C++AMP oder eben auch Intel MIC + OpenMP um einiges mehr…

Wegen dem Umstieg: In Bezug auf Kernel-Programmierung nehmen sich OpenCL-C und CUDA-C jetzt nicht unbedingt viel - CUDA bietet da noch den Vorteil andere Sprachen zu unterstützen (C++, Fortran,…). Der Boilercode auf der Host-Seite in OpenCL ist aber extrem nervig (und überraschend Fehleranfällig^^) - Aber mit Boilercode kennst du dich ja vermutlich aus (machst ja Java )

r00t~ schrieb:

Da OpenGL sich ja als Alternative zu DirectX behaupten konnte, könnte ich mir sehr gut vorstellen, dass OpenCL nachzieht. Vielleicht sollte ich wohl erst C++ und OpenGL fressen und gucken, wies sich entwickelt. Dann ist OpenCL auch endlich über Version 1.1 hinaus^^

Zum Vergrößern anklicken....

Nur zur Info: OpenGL brauchst du nicht um OpenCL zu verstehen, die beiden haben nix miteinander zu tun - außer dass beide heute von Khronos verwaltet werden und "Open" im Namen haben
BTW: OpenGL ist älter als DX… von behaupten würde ich daher nicht sprechen. Faktisch ist es eher so, dass Direct3D OpenGL nicht verdrängen konnte und es auch nie wird, da OpenGL ein viel größeres Umfeld bedient…

wissenschaftliche simulation? CUDA Fortran ^^

ne im ernst, die konzepte von cuda und opencl sind die gleichen. also wenn du das eine kannst, kannst du auch das andere. ich mein der syntax ist zwar unterschiedlich, aber der ist ja normalerweise nicht das problem, oder?

also bei opencl musst du damit leben, dass du immermal über etwas stolperst, was (noch) nicht implementiert ist. das passiert dir bei cuda nicht. außerdem brauchst du mit cuda 4.0 für mehrere rechner kein mpi.

ich glaub nicht dass opencl sich durchsetzt, der vorsprung von cuda ist zu groß... grade für wissenschaftliches zeug.
vorallem ist das platformkomzept von opencl einfach nur schwach umgesetzt (die dlls von verschiedenen herstellern schließen sich aus... )
c++ amp von m$ traue ich da mehr zu...
beim cern haben sie wohl eher den begriff grid als gpgpu im kopf...

bei dem von dir beschriebenen problemen kannst du zwar mit gpgpu was rausholen, aber ich weiß noch aus unserem computational physics kurs: du kannst den ganzen hardwareschnickschnack vergessen, wenn der algorithmus nicht schon bis zum geht nicht mehr optimiert ist.
der schritt auf die hardware ist der letzte. und da haben wir dann dann feststellen müssen, dass sich gpgpu eigentlich nicht lohnt. fpgas sind für fast alle simulationen viel besser geeignet... nur vhdl ist scheußlich (allerdings waren unsere Probleme viel rechenaufwendiger als deines..)

Sheeep schrieb:

bei dem von dir beschriebenen problemen kannst du zwar mit gpgpu was rausholen, aber ich weiß noch aus unserem computational physics kurs: du kannst den ganzen hardwareschnickschnack vergessen, wenn der algorithmus nicht schon bis zum geht nicht mehr optimiert ist.
der schritt auf die hardware ist der letzte. und da haben wir dann dann feststellen müssen, dass sich gpgpu eigentlich nicht lohnt. fpgas sind für fast alle simulationen viel besser geeignet... nur vhdl ist scheußlich (allerdings waren unsere Probleme viel rechenaufwendiger als deines..)

Zum Vergrößern anklicken....

Was ich noch ergänzen würde: Ein optimaler CPU-Algorithmus funktioniert auf einer GPU nicht effizient! Optimale CPU-Algorithmen haben eigentlich immer das Ziel die Anzahl der Berechnungen auf ein Minimum zu senken -> Verzweigungen. Auf der GPU drosselt ein solcher Code allerdings stark den Durchsatz wegen Serialisierung…

An dieser Stelle erstaml vielen Dank für eure zahlreichen Antworten! Wenn ich das richtig verstanden habe, ist es ratsamer, erst den Algorithmus in C++ mit effizienten Maths-Libs auf Herz und Nieren zu optimieren bevor man auf andere Hardware ausweicht. In den letzten Ferien hatte ich eine in Python 3 entwickelte Simulation aus Performancegründen in Java umgeschrieben, jetzt werd ich wohl die neue von Java in C++ umschreiben. Mal gucken was bei raus kommt^^

Fang nur bloß nicht an Matrixmultiplikationen etc. selbst zu implementieren. Die verfügbaren hochoptimierten Libraries sind in Assembly entwickelt und nutzen alle nur denkbaren Tricks um das Maximum an Performance raus zu holen. Da kommst du mit einer eigenen Implementierung nicht einmal in die Nähe von.. die sind üblicherweise über 10x schneller als naive Implementierungen.

Das gilt übrigens sowohl für C++, als auch für CUDA oder OpenCL.

Kugg dir einfach mal die Benchmarks der verfügbaren Libraries an, die sprechen Bände

Wenn dir das mit dem Optimieren Ernst ist, empfehle ich dir auch jeden fall einen Blick auf den Intel Compiler zu werfen, da dieser in den meisten Fälle den performantesten Code produziert. Für Linux stellt Intel das Parallel Studio XE übrigens kostenlos zu Verfügung, welches neben besagten Compilern auch noch diverse Tool zu Performanceoptimierung bietet. Wenn du nicht gerade auf Clustern mit MPI oder sonstigen NUMA Maschinen arbeitest und dich deswegen erstmal um die Kommunikation kümmern musst, ist es eine gute Idee die Cache Misses auf ein Minimum zu reduzieren (Stichwort Prefetching, raumfüllende Kurven).
Zum Thema GPU Computing hat NVidia da momentan noch die Nase vorne, das sie dieses als erste gepusht haben und da auch sponsoringtechnisch ziemlich viel Geld reinstecken. Die spannende Frage ist nämlich, womit NVidia in ein paar Jahren Geld verdienen will, wenn diskrete Grafikkarten bis auf den kleinen Kreis Enthusiaten durch APUs verdrängt wurden. Mit Tegra scheint man ja nicht allzuviel zu reißen, womit nur noch Tesla und Quadro blieben...
AMD dürfe Ende des Jahres mit GCN den GPGPU Markt ordenlich aufmischen und Intel hat Knights Corner für 2012 in 22nm mit DP Unterstützung und vermulich 64 Cores angekündigt. OpenCl Code ist zwar theoretisch plattformunabhängig, allerdings wird vor Allem im HPC Bereich speziell auf eine Architektur hin optimiert werden. Code der auf Grund von Vektorisierung gut auf AMD läuft, erzielt nur eine mäßige Performance auf NVidia und Code gut für NVidia optimiert wurde, bleibt auf einer AMD weit unter den Möglichkeiten der Karte. Es wird sogar so sein, dass Kepler Code nichts für Fermi ist und GCN Code kein VLIW4 oder VLIW5 mag.

Hat sich bis jetzt etwas geändert oder ist CUDA noch die erste Wahl? Worauf muss man beim Kauf einer Grafikkarte für CUDA achten? Könnt ihr eine effiziente empfehlen?