Zukunft von OpenCL?

Das OpenCL-Programmierparadigma verspricht, ein lizenzfreier Open-Standard für heterogenes Computing zu sein. Sollen wir unsere Zeit in die Entwicklung von OpenCL-basierter Software investieren? Für und Wider?

Die Frage ist zu weit gefasst und vage, um wirklich beantwortet zu werden. Allerdings sehe ich aus Sicht des wissenschaftlichen Rechnens einen bemerkenswerten Punkt gegen OpenCL, der selten betont wird. Bisher wurden keine Anstrengungen unternommen, Open Source-Infrastrukturbibliotheken für OpenCL zu erstellen, während CUDA über mehrere hervorragende Optionen verfügt:

• CUBLAS , CUFFT , CUSPARSE
• Thrust , Cusp , opencurrent
• PETSc-Unterstützung

Ich glaube, dass dies OpenCL wirklich schaden wird, da ein Hauptvermittler für die Einführung qualitativ hochwertiger, offener Bibliotheken ist.

OpenCL gegen was?

Wenn die Frage OpenCL vs CUDA ist, sehe ich viel Handarbeit über diese Frage, und es scheint mir verrückt. Es spielt keine Rolle. Ehrlich. Die Kerne, in denen alles harte Denken sein muss, sind zwischen den beiden Sprachen praktisch identisch. Sie könnten Makros für Ihren Lieblingseditor schreiben, um 99% der Arbeit zwischen OpenCL und CUDA zu erledigen. Es muss so sein; Sie steuern auf niedriger Ebene letztendlich ziemlich ähnliche Arten von Hardware. Sobald Sie herausgefunden haben, wie Sie Ihre wichtigen Kernel in {OpenCL, CUDA} schreiben, ist es einfach, sie nach {CUDA, OpenCL} zu portieren.

Der Hostcode, den Sie schreiben müssen, ist ebenfalls ähnlich, aber CUDA vereinfacht einfache Fälle. Deshalb unterrichten wir CUDA in unserem Zentrum. Sie können direkt mit dem Schreiben von Kernel-Code beginnen, während wir 1-2 Stunden unseres ganztägigen Kurses verbringen müssten, um nur die Kernel-Startfunktionen für OpenCL zu erläutern.

Aber auch dort ist der Unterschied nicht so wichtig. Sobald Sie anfangen, kompliziertere Dinge zu tun (asynchrone Kernel auf mehreren GPUS), sind beide gleich kompliziert und Sie können so ziemlich eine zeilenweise Übersetzung von einem zum anderen durchführen.

Wenn es sich um OpenCL im Vergleich zu den auf Direktiven basierenden Ansätzen handelt - OpenACC oder HMPP oder so -, sind dies wahrscheinlich (hoffentlich?) Gute Möglichkeiten, um diese Art von Architekturen in Zukunft zu programmieren, für die Sie 90% der Leistung erhalten können 10% der Arbeit. Aber welche Wahl "gewinnen" wird, bleibt abzuwarten, und ich würde nicht empfehlen, viel Zeit mit diesen zu verbringen.

Also würde ich sagen, wählen Sie zwischen CUDA oder OpenCL eine Sprache aus, die für Sie geeignet ist, und verwenden Sie sie. Machen Sie sich keine allzu großen Sorgen. Der wertvolle Teil - herauszufinden, wie Sie Ihr Problem in massiv parallelen SIMD-Code für kleine Kerne mit sehr wenig Speicher zerlegen können - wird zwischen Programmiermodellen ziemlich leicht übertragbar sein.

Wenn Sie NVIDIA-Hardware verwenden - und wahrscheinlich auch -, empfehle ich normalerweise CUDA. Matt Knepleys Argument zu den Bibliotheken ist nicht mehr aktuell. Wenn nicht, dann OpenCL.

Ob Sie Ihre Zeit in die Entwicklung von OpenCL- basierter Software investieren sollten, ist eine Frage, die nur Sie beantworten können. Wenn es so aussieht, als hätte es das Potenzial, die Probleme zu lösen, mit denen Sie gerade konfrontiert sind, und keine andere offene Lösung, besteht Ihre beste Vorgehensweise wahrscheinlich darin, das Risiko einzugehen, ein kleines Projekt damit umzusetzen.

Wenn das gut geht, können Sie es mit größeren Projekten und so weiter versuchen, bis Sie entweder genug Vertrauen aufbauen, um es zu standardisieren, oder es zugunsten einer anderen Lösung verwerfen (bei der es sich möglicherweise um Ihre eigene proprietäre Lösung, eine andere offene Lösung oder sogar handelt) eine andere proprietäre Lösung).

Das Wunderbare an der Open-Source-Bewegung ist, dass Sie , weil Sie die Quelle haben, alles haben, was Sie brauchen, um das Projekt bei Bedarf aufzuteilen. Auch wenn Ihnen die Community selbst nicht die Einrichtungen bietet, die Sie benötigen, hindert nichts Sie daran, diese Einrichtungen selbst zu implementieren. Wenn Sie diese Funktionen haben möchten, besteht eine eindeutige Möglichkeit, dass andere Benutzer sie möchten. Wir würden uns daher freuen, wenn Sie diese Änderungen wieder in das Kernprojekt einbringen würden.

Nicht nur das, wenn Sie es aus Ihrer Sicht verbessern, kann es auch für andere besser sein, sie dazu ermutigen, ihre eigenen Verbesserungen einzureichen und letztendlich die Software für alle zu verbessern.

Letztendlich ist dies eine eher generische Antwort auf eine eher generische Frage. Um vollständiger antworten zu können, müssen wir Ihre Bedenken in Bezug auf OpenCL kennen. Ist es Reife? Gemeinschaftliche Unterstützung? Benutzerfreundlichkeit? Zeit zum Lernen benötigt? Zeit sich zu entwickeln? Ändern Sie Ihre Abläufe? Mit welchen anderen Produkten möchten Sie OpenCL vergleichen, wenn Sie nach den Vor- und Nachteilen fragen ? Welche Recherchen haben Sie bereits durchgeführt? Welche Funktionen benötigen Sie, um Ihre heterogene Computerumgebung zu unterstützen?

Ein großer Vorteil ist die Anzahl der Anbieter, die hinter OpenCL stehen. Ich habe einige anekdotische Erfahrungen damit gemacht, als ich eine Forschungsgruppe getroffen habe, die viel Zeit und Mühe aufgewendet hat, um einen ziemlich komplizierten CUDA-Code für ein NVIDIA-System zu entwickeln. Ein Jahr später, nachdem der Code entwickelt worden war, erhielt die Forschungsgruppe Zugang zu einem größeren und schnelleren AMD-basierten System, das sie jedoch nicht verwenden konnten, da sie nicht über die (personellen) Ressourcen verfügten, um den Code zu portieren.

Auch wenn die Kernfunktionen von CUDA und OpenCL fast identisch sind (wie @JonathanDursi ausführlich dargelegt hat), kann das gesamte Portierungsprojekt recht zeitaufwändig sein, wenn nicht der ursprüngliche Entwickler mit der Konvertierung des Codes beauftragt ist.

Es gibt jedoch einige offizielle Inkompatibilitäten zwischen CUDA und OpenCL. Bemerkenswerterweise unterstützt CUDA c ++ - Vorlagen, während OpenCL sie noch nicht offiziell unterstützt. AMD ist jedoch bemüht, eine Erweiterung für OpenCL mit Unterstützung für Vorlagen und andere C ++ - Funktionen zu entwickeln. Weitere Informationen finden Sie in diesem Beitrag von AMD dev central . Ich hoffe, dass eine zukünftige Überarbeitung von OpenCL diese Arbeit ergänzen wird.

Zu diesem Zeitpunkt (Anfang 2012) handelt es sich bei den fantastischen Bibliotheken, mit denen @MattKnepley verknüpft ist, um Closed-Source-Bibliotheken oder Vorlagen, sodass sie zumindest in der Zwischenzeit nicht für andere Hardware als NVIDIA verfügbar sind.

Für jemanden, der GPU-Computing lernt, würde ich sagen, dass OpenCL C ziemlich schwierig sein kann, da es viele Details gibt, die den Lernenden von den Grundideen ablenken, während CUDA einfacher und unkomplizierter ist. Es gibt jedoch Tools, mit denen OpenCL viel einfacher zu erlernen und zu verwenden ist, wie PyOpenCL (der Python-Wrapper für opencl), der den gesamten Python-Zucker zu OpenCL bringt (beachten Sie, dass es auch ein PyCUDA gibt). Beispielsweise umfasst die PyOpenCL-Demo zum Hinzufügen von zwei Arrays knapp 25 Zeilen: Erstellen der Arrays auf Host und Gerät, Datenübertragung, Erstellen des Kontexts und der Warteschlange, Kernel, Erstellen und Ausführen des Kernels , erhalte die Ergebnisse von der GPU und vergleiche sie mit Numpy (siehe Links unten).

PyOpenCL - http://mathema.tician.de/software/pyopencl

PyCUDA - http://mathema.tician.de/software/pycuda

Für erfahrene gpu-Programmierer stimme ich hier mit @JonathanDursi überein, CUDA und OpenCL sind grundsätzlich gleich und es gibt wirklich keine Bürgermeisterunterschiede. Darüber hinaus ist die harte Arbeit bei der Entwicklung eines effizienten Algorithmus für GPUs sehr viel sprachunabhängiger, und die OpenCL-Unterstützung von Anbietern und der Dokumentation ist jetzt viel ausgereifter als noch vor 2 Jahren. Der einzige Punkt, der noch einen Unterschied macht, ist, dass NVIDIA mit ihrer Unterstützung für die CUDA-Community wirklich großartige Arbeit leistet.

OpenCL bietet den zusätzlichen Vorteil, dass es auf CPUs ausgeführt werden kann und bereits von Intel und AMD unterstützt wird. Sie müssen also Ihr algorithmisches Framework nicht ändern, wenn Sie alle verfügbaren CPU-Kerne nutzen möchten. Ich bin nicht der Meinung, dass OpenCL die beste Lösung für eine Single-CPU / Multicore-orientierte Anwendung ist, da ein CPU-optimierter Kernel erheblich anders aussehen kann als ein GPU-optimierter Kernel. Meiner Erfahrung nach profitiert die CODE-Entwicklung jedoch davon, dass sie auf der CPU ausgeführt werden kann.

Ich denke, OpenCL leidet derzeit unter dem Mangel an einem "Champion". Wenn Sie beispielsweise die NVIDIA-Website jetzt (16.12.2011) besuchen, werden auf der Begrüßungsseite mehrere Aufnahmen im Ken Burns-Effekt-Stil angezeigt, die sich auf die wissenschaftliche / industrielle Seite des GPU-Computing konzentrieren. Die vierte Ihrer Navigationsoptionen weist Sie auf Dinge hin, die wahrscheinlich bei CUDA landen werden. Hersteller von "GPU Computing" -Servern und -Workstations verkaufen NVIDIA-Lösungen.

Konkurrierende Angebote von ATI werden mit der allgemeinen AMD-Site gemischt, die schwerer zu finden ist und in Lösungen von Drittanbietern nicht so stark vertreten ist. Diese Lösungen und die Fähigkeit zur OpenCL-basierten Programmierung gibt es sicherlich, aber es bleibt eine Wahrnehmung - zumindest in meinem Kopf, aber in den Köpfen einiger anderer Leute, mit denen ich gesprochen habe -, die die großen Firmensponsoren der OpenCL-Plattform bereits haben. " das Feld verlassen ". Menschen, die beispielsweise OS X verwenden, sind wahrscheinlich allzu beschäftigt, darüber zu spekulieren, ob es in einem Jahr überhaupt noch eine Apple-Workstation geben wird, um daran zu glauben, dass sie OpenCL GPU-Computing vorantreiben.

Der wichtigste Faktor ist, dass CUDA nur von NVIDIA-Hardware unterstützt wird.

Wenn Sie also robuste und tragbare Software erstellen möchten, ist OpenCL die einzige Option. Sie können sich höchstens um einige derzeit von CUDA unterstützte Bibliotheken kümmern und hoffen, dass sie in Zukunft über OpenCL erweitert werden, indem Sie Ihren Code mit einbeziehen.