Wie umfangreich kann auf GPU Leistung zugegriffen werden?

[davidnet]

Der Titel klärt vielleicht nicht alles, daher hier etwas detailierter.

1. Inwiefern kann man die Leistung, welche eine GPU erbringt, für andere Zwecke als Grafikberechnung nutzen?
2. Mit welchen Tools / Sprachen / Befehlen kann man die GPU manipulieren?
3. Kann eine GPU vollumfänglich als "CPU" & "RAM" verwendet werden?
4. Kann ich in der Theorie eine virtuelle Maschine auf meiner GPU laufen lassen?
5. Gibt es in der Praxis bereits Erfahrungen, eine virtuelle Maschine auf einer GPU zu betreiben?
6. Die grossen Supercomputer nutzen ja auch GPU's für ihre Berechnungen, wie funktioniert da der Zugriff oder das Abrufen dieser geballten GPU Leistung? Werden spezielle Linux Systeme eingesetzt?
7. AMD oder NVIDIA, bei welchen Karten kann man die GPU Leistung besser/einfacher/komfortabler "missbrauchen"
8. Warum diese Fragen? Weil ich hier einen Server (Desktop-Format) stehen habe. Mich reizt der schnelle VRAM der GPU und die Leistung des Grafik-Prozessors.

Irgendwie habe ich noch im Kopf, dass die GPU ihre Berechnungen nicht überprüft, stimmt das? Überprüfen im Sinn von, es kommen bei einer GPU häufiger zu Berechnungsfehlern, welche sich aber in der Grafik kaum auswirken und somit egal sind?

Vielen Dank, Gruss David

 

[New_Escaflowne]

Kurze Antworten da schon spät:

1. GPU kann für alles benutzt werden, bei dem man viele unabhängige Berechnungen machen kann. Dadurch kann man das parallelisieren und so die parallele Architektur der GPU nutzen. Bsp. Matrixenrechnung
2. OpenCL ist herstellerunabhängig, CUDA für NVIDIA, AMD hat glaube ich auch eine Sprache
3. Jeder GPU Kern ist wesentlich "schwächer" als ein CPU-Kern. Der Vorteil liegt in der parallelen Architektur. Du kannst die GPU nur für Sachen effizient nutzen, die du massiv parallelisieren kannst (100 Threads und mehr). Damit das dann auch wirklich gut ist, musst du auch die spezielle Architektur der GPU bei der Programmierung beachten.
4. Keine Ahnung, stelle ich mir aber schwierig vor.
5. Keine Ahnung
6. Keine Ahnung, dürfte aber auch OpenCL oder CUDA sein. So Supercomputer machen ja nichts anderes als extrem komplexe Berechnungen zu lösen. Die Steuerung wird wohl ein Linux-Server übernehmen.
7. So weit ich gehört habe ist CUDA zumindest etwas angenehmer als OpenCL. Insgesamt ist GPU-Programmierung aber meiner Meinung nach nicht so angenehm, da man afaik nur recht primitive Mittel in den Programmiersprachen hat.

Meine Meinung:
GPU ja, wenn man parallelisierbare Berechnungen hat und weiß, wie man massiv-parallel programmiert (das ist nicht trivial!). Für was anderes sind die eigentlich nicht zu gebrauchen.
Dazu noch eine Sache: Bei weitem nicht alles ist parallelisierbar! Und der Speedup, den man durch Parallelisierung erhalten kann, ist nach oben begrenzt durch den seriellen Anteil der Berechnung (siehe Amdahl's Law).

 

[Nilson]

GPUs sind gut darin, wenn es um viele (gleichzeitige) Fließkommaoperationen geht, eine CPU eher bei vielen Ganzzahlen (nacheinander).

Erstere braucht man oft bei aller Art von Vektor (linearer Algebra) und Grafikberechnung, letztere braucht man am ehesten "klassischen" Programmen.

Leider lässt sich die Leistung nicht in einander umrechnen. Ist wie bei nem Sportwagen und nem LKW. Beide haben 400 PS, aber mit nem LKW wird man kaum die 120 km/h knacken, wärend der Sportwagen bei mher als 100kg Last schlap macht.

 

[SoDaTierchen]

1. Je nach Programmiererfahrung zwischen gar nicht und sehr vielseitigen Möglichkeiten.
2. DirectCompute (Windows), OpenCL, CUDA (NVidia)
3. nein. Grafik-Prozessoren rechnen größtenteils auf Streams, nicht auf Speicherbereichen. Das mag sich auf den ersten Blick kleinlich anhören, ist aber spätestens wenn du das selbst programmierst ein extremer Mehraufwand.
4. nein. die GPU kann keine CPU emulieren. noch weniger ne netzwerkkarte. und schon gar kein usb. du hättest in deiner virtuellen maschine keine hardware, die du ansprechen kannst. Das macht sich besonders für fehlende Tastatur und Maus bemerkbar.
5. nein
6. die führen berechnungen aus, die aber vorher speziell auf die grafikkarten angepasst wurden. die karten sind rechenknechte, keine virtualisierungsmeister. vorteil ist eben, dass du dort sehr stark parallelisiert arbeiten kannst (>100fache Kernzahl auf der GPU)
7. Reine Gewöhnungssache. NVidia bietet CUDA zusätzlich an, wer aber OpenCL gewöhnt ist, wird davon keinen Vorteil sehen. Jedoch sind die Kepler-Desktopkarten ewtas schwächer in dem Bereich (trotzdem fähig!)
8. Leistund und VRAM dürfen dich reizen, aber hier kannst du nur berechnen. Und das teils auch nur sehr speziell

Der letzte Teil ist so richtig, aber nicht weiter dramatisch. Die über CUDA/OpenCL/DirectCompute gesteuerten Rechnungen sind schon korrekt, nur weniger Präzise -> das kann man mit geeigneter Programmierung abfangen oder umgehen.

Edit & Nachtrag: Diese geringere Präzision ist übrigens der Grund für die "Fehler", weil hier manches Mal Rundungsprobleme auftreten, speziell bei der Rasterung der 3D-Objekte in das 2D-Pixelsystem. Andere Probleme können wegen zu niedrigen Spannungen / zu hohen Temperaturen auftreten. Insgesamt verursacht eine gepflegte Grafikkarte tatsächlich keine merkbaren Fehler

 

[davidnet]

Vielen Dank für die interessanten Antworten!

Naja, parallele Berechnungen kommen bei der Virtualisierung ja überhaupt nicht vor.

 

[Nai]

4. Die GPUs unterstützen diverse Features von einer CPU nicht, die allerdings für Betriebssysteme wichtig sind zB. Interrupts, (Software-)Threadmanagement (Threadmanagement ist in Hardware gegeossen und daher nicht programmierbar), programmierbare PCI-E Kommunikation uvm.
Zusätzlich sind diverse Limitierungen vorhanden, wie eine maximale Anzahl an ausführbaren Befehlen pro GPU Programm.

Selbst wenn diese Features vorhanden wären und es diese Limitierungen nicht gebe, so hätte man mit dem GPU-Aufbau massive Performanceprobleme ein Betriebssystem performant auf einer GPU laufen zu lassen.

Ein Grund hierfür ist die vorgehensweise der GPU um Latenzen bei Registerabhängigkeiten zu überbrücken. Eine CPU umgeht dieses Problem durch komplexes Pipelining mit Out of Order Execution, Sprungvorhersage und grosse Cache um Speicherlatenzen so gering wie möglich zu halten. Eine GPU besitzt all dies nicht, sondern stützt sich auf massives SMT; dieses ist interessanterweise von der Grundidee her demjenigen SMT von modernen Prozessoren recht ähnlich. Jedoch kann eine moderne CPU durch SMT momentan bis zu 2 Threads pro Kern beherbergen; bei einem 4 Kerner sind das dann 8 Threads.
Eine Fermi GPU hingegen kann insgesamt bis zu 24576 Threads gleichzeitig beherbergen. Dies sind 48 Threads pro Kern.
Will man eine GPU auslasten, so muss man ihr einerseits ersteinmal genügend Thrads zur verfügung stellen, was in den meisten Anwendungsgebieten bei der Virtualisierung schlecht möglich ist. Gleichzeitig hat es zur Folge, dass ein einzelner sequentieller Thread "in etwa" nur ein 25 tausendstel der Rechenleistung einer GPU ausnutzen kann.

Das nächste Problem ist das SIMT-Modell der GPUs. Man hat eine Steuereinheit, welche immer Befehle an eine Gruppe von 32 Threads (Warp) herausgibt. Wollen einige dieser Threads den Befehl nicht ausführen, so nehmen die Threads nicht an dem Befehl teil. Die entsprechenden Rechenkerne der Threads bleiben ungenutzt, wodurch man im Worst Case nur 1/32 der Rechenleistung der GPU erzielt.
Deshalb will man bei GPGPU zusätzlich noch erreichen, dass die Threads eines Warps immer wenn nur auch irgendwie möglich den selben Kontrollfluss durch das Programm beschreiten. Dies ist allerdings meist nur bei Datenparallelen Algorithmen sinnvoll möglich. Bei einem Betriebssystem wo man viele Threads, von denen jeder potentiell seinen eigenen Prozess ausführt, kann man dies schlechter ausnutzen. Auch sind insbesondere GPU-spezifische Optimierungen des Programmes zwingend erfoderlich, so dass die meisten Standardprogramme, wenn man sie auf der GPU laufen lassen können würde, eine niedrige Performance hätten.

Würde man diese beiden Probleme noch beheben, dann hätte man etwas wie Intels Larabee; von der Rohperformance langsamer als eine GPU dafür vielseitiger nutzbar und Programmierbar.

7. Bei Nvidia mit CUDA. OpenCLs Programmierinterface ist *einfach* nur schrecklich. Zusätzlich kann man diverse wesentliche GPU Features von NVIDIA nutzen.

Zur Genauigkeit: Neuere GPUs unterstützen den FP Standard. Allerdings besitzen sie schnellere Funktionen für manche Berechnungen für diejenigen Fälle wo die Genauigkeit mehr oder weniger egal ist.
Zur Fehlerkorrektur: Nvidias Karten unterstützen diverse Fehlerkorrekturen innerhalb ihres Speicher (zB. Registerspeicher, ECC-RAM). In wie weit diese Features auch bei Consumer Karten aktiv sind weiss ich nicht. Fehlerkorrektur bei den Berechnungen selbst findet nicht statt.