Welche Zukunft hat die GPU im Computing?[geschlossen]

https://stackoverflow.com/questions/1126989

13-09-2019
|

Frage

Ihre CPU mag ein Quad-Core-Prozessor sein, aber wussten Sie, dass einige Grafikkarten heutzutage über 200 Kerne haben?Wir haben bereits gesehen, was GPUs in heutigen Grafikkarten in Sachen Grafik leisten können.Jetzt können sie auch für nicht-grafische Aufgaben verwendet werden, und meiner Meinung nach sind die Ergebnisse geradezu erstaunlich.Ein Algorithmus, der sich gut für Parallelität eignet, kann auf einer GPU viel, viel schneller sein, als er es jemals auf einer CPU sein könnte.

Es gibt einige Technologien, die all dies ermöglichen:

1.) CUDA von NVidia.Es scheint das bekannteste und am besten dokumentierte zu sein.Leider funktioniert es nur auf NVidia-Grafikkarten.Ich habe das SDK heruntergeladen, einige Beispiele ausprobiert und festgestellt, dass in CUDA einige tolle Dinge gemacht werden.Aber die Tatsache, dass es auf NVidia-Karten beschränkt ist, lässt mich an seiner Zukunft zweifeln.

2.) Strom von ATI.ATI ist das Äquivalent zu CUDA.Wie zu erwarten ist, funktioniert es nur auf ATI-Karten.

3.) OpenCL – Die Khronos Group hat diesen Standard erstellt, aber er steckt noch in den Kinderschuhen.Ich mag jedoch die Idee von OpenCL.Die Hoffnung besteht darin, dass es von den meisten Grafikkartenherstellern unterstützt wird und die grafikübergreifende Entwicklung erheblich vereinfacht.

Aber welche anderen Technologien für die nicht-grafische GPU-Programmierung kommen und welche sind am vielversprechendsten?Und sehen Sie, oder möchten Sie, dass diese Technologien in einige der gängigen Entwicklungs-Frameworks wie .NET integriert werden, um es noch einfacher zu machen?

Lösung

Ich sehe voraus, dass diese Technologie populär und Mainstream werden wird, aber es wird einige Zeit, dies zu tun, nehmen. Meine Vermutung ist, von etwa 5 bis 10 Jahren.

Wie Sie richtig bemerkt, ein großes Hindernis für die Einführung der Technologie ist das Fehlen einer gemeinsamen Bibliothek, die auf den meisten Adapter läuft - sowohl ATI und nVidia. Solange dies nicht auf ein akzeptables Maß gelöst wird, wird die Technologie nicht Mainstream betritt und wird in der Nische von maßgeschneiderten Anwendungen bleiben, die auf spezifische Hardware ausgeführt werden.

Wie es mit C # und anderen High-Level-verwalteten Sprachen zu integrieren - das wird etwas länger dauern, aber XNA zeigt bereits, dass benutzerdefinierte Shadern und verwalteten Umgebung können zusammen mischen - bis zu einem gewissen Grad. Natürlich noch nicht in C # die Code-Shader ist, und es gibt einige große Hindernisse für dies zu tun.

Einer der Hauptgründe für die schnelle Ausführung von GPU-Code ist, dass es strenge Beschränkungen auf, was der Code hat, kann und nicht kann, und es verwendet VRAM anstelle der üblichen RAM. Dies macht es schwierig CPU-Code und GPU-Code zusammen zu bringen. Während Abhilfen möglich sind, würden sie praktisch den Leistungsgewinn zunichte machen.

Eine mögliche Lösung, die ich sehe, ist eine Unter Sprache für C # zu machen, die ihre Grenzen hat, ist GPU-Code kompiliert und hat eine genau definierte Art und Weise mit dem ususal C # -Code zu kommunizieren. Dies würde jedoch nicht viel anders sein als das, was wir bereits haben - nur bequemer, weil einiger syntaktischen Zucker und Standardbibliothek Funktionen zu schreiben. Dennoch ist auch dieses Alter ist weg für jetzt.

Andere Tipps

Ich glaube, Sie können die nächste DirectX als eine andere Art und Weise zählen die GPU zu nutzen.

Aus meiner Erfahrung GPUs sind extrem schnell für Algorithmen, die einfach zu parallelisieren sind. Ich optimierte vor kurzem ein spezielles Bild in CUDA Größenänderung Algorithmus mehr als 100-mal schneller auf der GPU (nicht einmal ein High-End-eins) als ein Quad-Core-Intel-Prozessor zu sein. Das Problem war, die Daten an die GPU bekommen und dann das Ergebnis in dem Hauptspeicher zurück zu holen, in beiden Richtungen durch die Memcpy () Geschwindigkeit auf dieser Maschine beschränkt, die weniger als 2 GB / s. Als Ergebnis war der Algorithmus nur etwas schneller als die CPU-Version ...

Es hängt also wirklich. Wenn Sie eine wissenschaftliche Anwendung, wo Sie die meisten Daten auf der GPU zu halten, und alle Algorithmen Karte auf eine GPU Implementierung, dann fein. Sonst würde ich warten, bis es eine schnellere Leitung zwischen CPU und GPU ist, oder mal sehen, was ATI die Ärmel mit einem kombinierten Chip verfügt über bis ...

über welche Technologie zu verwenden: Ich denke, wenn Sie Ihre Sachen in der CUDA ausgeführt haben, der zusätzlichen Schritt zu portieren zu OpenCL (oder eine andere Sprache) ist nicht so groß. Sie haben alle die schwere Arbeit durch Ihre Algorithmen parallelisieren, und der Rest ist nur ein anderer ‚Geschmack‘

Monte Carlo ist beschämend parallel, aber es ist eine Kerntechnik in finanziellen und wissenschaftlichen Rechnens.

Einer der Befragten ist etwas falsch zu sagen, dass die meisten realen Welt Herausforderungen leicht in diese Art von Aufgaben, die nicht abbaubar sind.

Viel tractible wissenschaftliche Untersuchung erfolgt durch den Einsatz, was in einer peinlichen parallel Weise ausgedrückt werden kann.

Nur weil es den Namen „beschämend“ parallel bedeutet nicht, es ist nicht ein äußerst wichtiges Feld.

Ich habe in mehreren Finanzhäuser gearbeitet, und wir forsee, dass wir Farmen von 1000 Monte Carlo Motoren (viele Stapel von Blättern aufgereiht zusammen) werfen kann für mehrere große NVidia CUDA Installationen - massiv abnehmenden Strom- und Wärmekosten in der Rechenzentrum.

Ein bedeutender architektonischer Vorteil ist, dass es auch viel weniger Netzlast ist, da es weit weniger Maschinen sind, die Daten gefüttert werden müssen und ihre Ergebnisse zu berichten.

Im Grunde jedoch solche Technologien auf einer Abstraktionsebene sind niedriger als eine Runtime-Sprache verwaltet wie C #, wir sprechen über Hardware-Geräte, die ihren eigenen Code ausführen auf eigenen Prozessoren.

Die Integration sollte zunächst mit Matlab, Mathematica erfolgt ich erwarten würde, zusammen mit dem C-APIs natürlich ...

Eine weitere Technologie, die für die GPU-basierte Verarbeitung auf dem Vormarsch ist, sind GPU-Versionen bestehender High-Level-Rechenbibliotheken.Ich weiß, nicht sehr auffällig, aber es bietet erhebliche Vorteile für portablen Code und eine einfache Programmierung.

Beispielsweise enthält das Stream 2.0 SDK von AMD eine Version seiner BLAS-Bibliothek (lineare Algebra), wobei einige der Berechnungen auf der GPU implementiert sind.Die API ist genau die gleiche wie die reine CPU-Version der Bibliothek, die sie seit Jahren ausliefern.Sie müssen lediglich die Anwendung neu verknüpfen, schon nutzt sie die GPU und läuft schneller.

In ähnlicher Weise hat Dan Campbell von GTRI an einer CUDA-Implementierung des VSIPL-Standards für die Signalverarbeitung gearbeitet.(Insbesondere die Art der Signal- und Bildverarbeitung, die in Radarsystemen und verwandten Bereichen wie der medizinischen Bildgebung üblich ist.) Auch hier handelt es sich um eine Standardschnittstelle, und Anwendungen, die für VSIPL-Implementierungen auf anderen Prozessoren geschrieben wurden, können mit dieser einfach neu kompiliert werden und nutzen Sie gegebenenfalls die Fähigkeiten der GPU.

In der Praxis führen heutzutage bereits viele leistungsstarke numerische Programme keine eigene Low-Level-Programmierung durch, sondern greifen auf Bibliotheken zurück.Wenn Sie auf Intel-Hardware mit Zahlen rechnen, ist es im Allgemeinen schwer, die Intel-Mathematikbibliotheken (MKL) für die meisten Dinge, die sie implementiert, zu schlagen – und ihre Verwendung bedeutet, dass Sie die Vorteile aller Vektoranweisungen nutzen können clevere Tricks in neueren x86-Prozessoren, ohne dass Sie Ihren Code dafür spezialisieren müssen.Ich vermute, dass dies bei Dingen wie GPUs noch häufiger vorkommen wird.

Daher denke ich, dass eine Technologie, die man im Auge behalten sollte, die Entwicklung von Allzweckbibliotheken ist, die Kernbausteine für Anwendungen in bestimmten Domänen bilden, und zwar auf eine Art und Weise, die Teile dieser Algorithmen erfasst, die effizient an die GPU gesendet werden können, während gleichzeitig die Menge an nicht tragbaren GPUs minimiert wird -Spezifische Klugheit, die vom Programmierer gefordert wird.

(Befangenheitsausschluss:Mein Unternehmen hat auch an einer CUDA-Portierung unserer VSIPL++-Bibliothek gearbeitet, daher bin ich geneigt, dies für eine gute Idee zu halten!)

In einer ganz anderen Richtung möchten Sie vielleicht auch einige der Dinge ausprobieren, die RapidMind tut.Ihre Plattform war ursprünglich für Multicore-CPU-Systeme gedacht, aber sie haben viel Arbeit geleistet und sie auch auf GPU-Berechnungen ausgeweitet.

So ziemlich alles, was parallel geschaltet werden kann, kann in der Lage zu profitieren. Speziellere Beispiele SETI @ home, Folding @ home und andere verteilen Projekte sowie die wissenschaftliche Rechnen sein würden.

Vor allem Dinge, die auf Gleitkomma-Arithmetik stark angewiesen. Dies liegt daran, GPUs spezialisiert hat Schaltung, die bei Gleitkommaoperationen sehr schnell ist. Das bedeutet, es ist nicht so vielseitig, aber es ist sehr gut, was es tut.

Wenn Sie auf mehreren dedizierten GPU Verarbeitung aussehen Besuche Nvidias Tesla GPU . Es ist eine GPU, aber es nicht wirklich einen Monitorausgang hat!

Ich bezweifle, dass wir zu viel GPU-Verarbeitung auf dem gemeinsamen Desktop, oder zumindest für eine Weile sehen werden, weil nicht jeder eine CUDA oder ähnliche fähige Grafikkarte hat, wenn sie überhaupt eine Grafikkarte hat. Es ist auch sehr schwierig, Programme mehr parallel zu machen. Spiele könnten möglicherweise diese zusätzliche Leistung nutzen, aber es wird sehr schwierig sein und werden wahrscheinlich nicht allzu nützlich sein, da alle Grafiken Berechnungen meist schon auf der GPU sind und die andere Arbeit ist auf der CPU und hat auf der CPU sein aufgrund der Befehlssätze.

GPU-Verarbeitung, zumindest für eine Weile, für ganz bestimmte Nischenmärkte, die eine Menge von Gleitkomma-Berechnung benötigen.

Es ist wichtig, im Auge zu behalten, dass auch Aufgaben, die von Natur aus Serien sind, können von Parallelisierung profitieren, wenn sie unabhängig mehrmals durchgeführt werden muß.

Auch zu beachten, dass, wenn jemand die Beschleunigung einer GPU-Implementierung einer CPU Implementierung berichtet, ist es so gut wie nie ein fairer Vergleich. Um wirklich fair, müssen die Implementierer verbringen zuerst die Zeit, um eine wirklich optimierte, parallel CPU Implementierung zu erstellen. Ein einzelne Intel Core i7 965 XE CPU kann heute rund 70 Gigaflops in doppelter Genauigkeit erzielen. Aktuelles High-End-GPUs kann 70-80 Gigaflops in doppelter Genauigkeit tun und um das Jahr 1000 in einfacher Genauigkeit. So wird eine Beschleunigung von mehr als 15 eine ineffiziente CPU Implementierung bedeuten.

Eine wichtige Einschränkung mit GPU-Computing ist, dass es zur Zeit „in kleinem Maßstab“. Mit einer Supercomputer-Anlage können Sie einen parallelisierten Algorithmus auf Hunderte oder sogar Tausende von CPU-Kernen laufen. Im Gegensatz dazu GPU „Cluster“ sind derzeit auf etwa 8 GPUs beschränkt auf eine Maschine angeschlossen ist. Natürlich können mehrere dieser Maschinen miteinander kombiniert werden, aber dies bringt zusätzliche Komplexität, da die Daten nicht nur zwischen Computern, sondern auch zwischen GPUs passieren muss. Außerdem gibt es noch nicht ein MPI-Äquivalent, die Prozesse transparent skaliert auf mehrere GPUs auf mehreren Rechnern können; es muss (möglicherweise in Verbindung mit MPI) manuell durchgeführt werden.

Abgesehen von diesem Problem der Skala, ist die andere große Einschränkung von GPUs für Parallel Computing die strenge Beschränkung auf Speicherzugriffsmuster. Zufällige Speicherzugriff ist möglich, aber sorgfältig geplant Speicherzugriff wird in vielen fach bessere Performance zur Folge hat.

Vielleicht ist die vielversprechendste kommenden Anwärter ist Intels Larrabee. Es hat einen deutlich besseren Zugang zu der CPU, Systemspeicher und, was vielleicht am wichtigsten ist, Caching. Dies sollte es erhebliche Vorteile mit vielen Algorithmen geben. Wenn es nicht die massive Speicherbandbreite zu aktuellen GPUs bieten kann, obwohl, kann es liegt hinter der Konkurrenz für Algorithmen, die optimal diese Bandbreite nutzen.

Die aktuelle Generation von Hard- und Software erfordert viel Entwickler Aufwand eine optimale Leistung zu erhalten. Dazu gehören oft Umstrukturierung Algorithmen zur effizienten Nutzung der GPU-Speicher zu machen. Es ist auch oft mit mit unterschiedlichen Ansätzen experimentieren die besten zu finden.

Beachten Sie auch, dass der Aufwand für eine optimale Leistung zu erhalten, ist notwendig, um die Verwendung von GPU-Hardware zu rechtfertigen. Der Unterschied zwischen einer naiven Implementierung und eine optimierte Implementierung kann eine Größenordnung oder mehr sein. Dies bedeutet, dass eine optimierte CPU impelemntation wahrscheinlich als gut oder sogar besser als eine naive GPU-Implementierung.

Die Menschen arbeiten bereits an .NET-Bindings für CUDA. Siehe hier . Doch mit der Notwendigkeit auf einem niedrigen Niveau zu arbeiten, ich glaube nicht, GPU-Computing für die Massen bereit ist, vor.

Ich habe viel darüber reden drehen, was heute gehört sind GPUs in mehr Allzweck- „Array proceesor Einheiten“ zur Verwendung mit jeder Matrix mathematischen Problems ist, und nicht nur Grafikverarbeitung. Ich habe nicht viel draus noch obwohl gesehen.

Die Theorie war, dass Array-Prozessoren in etwa die gleiche Flugbahn folgen könnten, die Prozessoren-Punkt schwebt vor ein paar Jahrzehnten gefolgt. Ursprünglich waren Fließkommaprozessoren teuer Zusatzoptionen für PCs, dass nicht viele Leute zu kaufen belästigt. Schließlich wurde sie so wichtig, dass sie in die CPU gesetzt wurden selbst.

Ich werde die Antwort wiederholen Ich gab hier.

Langzeit denke ich, dass die GPU zu existieren aufhören zu, als Allzweck-Prozessoren entwickeln, diese Funktionen zu übernehmen. Intels Larrabee der erste Schritt ist. Die Geschichte hat gezeigt, dass gegen x86 Wetten ist eine schlechte Idee.

GHC (Haskell) Forscher (Arbeits für Microsoft Research) werden mit Unterstützung für verschachtelte Datenparallelität direkt zu einer Allzweck-Programmiersprache. Die Idee ist, mehrere Prozessorkerne und / oder GPUs auf dem hinteren Ende noch belichten Daten parallel Arrays als natives Typ in der Sprache zu verwenden, unabhängig von der Laufzeit des Codes parallel (oder seriell für das Single-CPU Ausweich) ausgeführt wird.

http://www.haskell.org/haskellwiki/GHC/Data_Parallel_Haskell

Je nach Erfolg dieses in den nächsten Jahren, würde ich erwarten, dass andere Sprachen (C # speziell) zu sehen, auf der Idee, abholen, die diese Art von Fähigkeiten zu einem Mainstream-Publikum bringen könnten. Vielleicht bis zu diesem Zeitpunkt werden die CPU-GPU-Bandbreite und Treiberprobleme gelöst werden.

GPUs funktionieren gut in Probleme, wo es ein hohes Maß an Daten-Level-Parallelismus , die im wesentlichen bedeutet, dass es eine Möglichkeit, die Daten zu partitionieren ist so verarbeitet werden, dass sie alle bearbeitet werden können.

GPUs ist nicht von Natur aus so schnell mit einer Taktgeschwindigkeit Niveau. In der Tat bin ich relativ sicher, dass die Taktfrequenz auf den Shadern (oder vielleicht haben sie einen GPGPU Begriff für sie in diesen Tage?) Ziemlich langsam im Vergleich zu dem ALUs auf einem modernen Desktop-Prozessor. Die Sache ist, eine GPU eine absolut enorme Menge dieser Shadern hat, drehte die GPU in ein sehr großen SIMD Prozessor. Mit der Menge von Shadern auf einem modernes Geforce zum Beispiel ist es möglich, dass eine GPU auf mehr hundert (tausend?) Arbeiten zu Gleitkommazahlen auf einmal.

So kurz kann eine GPU erstaunlich schnell sein für Probleme, bei denen Sie die Daten richtig partitionieren und die Partitionen unabhängig verarbeiten. Es ist nicht so mächtig unter Aufgabe (Thread) Level-Parallelismus .

Ein großes Problem mit der GPU-Technologie ist, dass, während Sie viel Rechenkapazität in dort zu tun haben, Daten in (und aus ihm heraus) immer schrecklich (Performance-weise). Und achten sorgfältig auf Vergleich Benchmarks ... sie oft gcc vergleichen (mit minimaler Optimierung, keine Vektorisierung) auf einem einzelnen Prozessor-System auf die GPU.

Ein weiteres großes Problem mit der GPU ist, dass, wenn Sie nicht vorsichtig darüber nachdenken, wie Sie Ihre Daten organisiert ist, werden Sie eine echte Leistung intern getroffen leiden (in der GPU). Dabei geht es oft sehr einfachen Code in einen gewundenen Müllhaufen neu zu schreiben.

Ich bin sehr aufgeregt über diese Technologie. Ich denke jedoch, dass dies nur die eigentliche Herausforderung der großen paralleler Aufgaben verschärfen, eine Bandbreite. mehr Kerne Hinzufügen nur Rennen um Speicher zu erhöhen. OpenCL und andere GPGPU Abstraktion Bibliotheken bieten keine Werkzeuge, die zu verbessern.

Jeder wird High Performance Computing-Hardware-Plattform in der Regel mit der Bandbreite Ausgabe sorgfältig geplant in die Hardware entworfen werden, Balancing Durchsatz, Latenz, Caching und Kosten. Solange handelsüblicher Hardware, CPU und GPU sind isoliert voneinander entwickelt, mit optimierter Bandbreite nur auf dem lokalen Speicher, wird es sehr schwierig sein, dies für die Algorithmen zu verbessern, die sie benötigen.

Es ist wahr, dass GPUs sehr hallo Performance-Zahlen in Datenebene Parallelität Situationen erzielen kann, wie viele hier erwähnt. Aber wie ich es sehe, gibt es keine viel verwenden, um es in jetzt Benutzerraum. Ich kann nicht helfen Gefühl, dass all diese GPGPU Propaganda von GPU-Hersteller kommt, die nur neue Märkte finden wollen und verwendet für ihre Produkte. Und das ist absolutelly ok. Haben Sie sich jemals gefragt, warum Intel / AMD nur knapp sein Ziel, einige Mini-x86-Kerne zusätzlich zu den Standard diejenigen umfassen (sagen wir - Modell mit vier x86-Kernen und 64 Mini-x86-Kerne), nur Datenebene paralelism capabilties zu steigern? Sie haben auf jeden Fall könnte das, wenn gewünscht. Meine Vermutung ist, dass die Industrie nur nicht braucht diese Art von Rechenleistung in normalen Desktop / Server-Maschinen.

GPUs bleiben kann oder nicht so populär wie sie jetzt sind, aber die Grundidee ein ziemlich beliebter Ansatz zu hohen Leistung Verarbeitung wird immer. Ein Trend, der jetzt kommen wird, ist der externe „Beschleuniger“, um die CPU mit großen Floating-Point-Arbeitsplätzen zu unterstützen. Eine GPU ist nur eine Art von Beschleuniger.

Intel ist die Freigabe eines neuen Beschleunigers die Xeon Phi , die sie hoffen, können die GPU als HPC-Beschleuniger herauszufordern. Der Cell-Prozessor einen ähnlichen Ansatz hat, dafür allgemeine Aufgaben einen Haupt-CPU mit, und Offloading rechenintensive Aufgaben zu anderen Verarbeitungselementen, einige beeindruckende Geschwindigkeiten zu erreichen.

Accelerators im Allgemeinen scheinen im Moment von Interesse zu sein, so sollten sich um zumindest für eine Weile. Unabhängig davon, ob die GPU bleibt, wie der De-facto-Beschleuniger, bleibt abzuwarten.

Ihre Wahrnehmung, die GPUs sind schneller als CPUs auf der falschen Vorstellung von einigen embarassingly parallelen Anwendungen, die gerne von der PS3, NVIDIA und ATI-Hardware angewandt erstellt basieren.

http://en.wikipedia.org/wiki/Embarrassingly_parallel

Die meisten realen Welt Herausforderungen sind nicht leicht in diese Art von Aufgaben abbaubar. Der Desktop-CPU ist viel besser geeignet für diese Art von Herausforderung sowohl von einem Feature-Set und Performance-Gesichtspunkten.

Ich erwarte, dass die gleichen Dinge, die CPUs für verwendet werden?

Ich meine gerade dies wie eine Spielerei mir scheint. Ich zögere zu sagen, „das wird nirgendwo“, wenn es um Technologie geht aber GPUs primäre Funktion ist Grafik-Rendering und CPUs primäre Funktion ist alles andere Verarbeitung. die GPU Mit irgendetwas anderes tun, nur scheint whacky.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow