GTX 1070 vs. GTX 1080: GPU- & RAM-Performance?

[Faust2011]

Gesucht... gefunden: Bitfäule - Tücken bei Speicherung und Übertragung großer Datenmassen

Den Printartikel müsste ich nun hier suchen gehen Ist es denn überhaupt interessant für Dich?

 

[ascer]

...sieht spannend aus. Wenn das keinen allzu großen Aufwand für dich bedeutet, gern.

EDIT: Es ist letztlich halt immer schön und von mir definitiv präferiert, seine Entscheidungen möglichst faktenbasiert zu treffen. Gerade wenn es bei ECC vs. non-ECC RAM um Mehrausgaben geht (wenn auch keine besonders großen).

 

[xxMuahdibxx]

Solange die KI nicht bei 0 oder 1 von Tod oder Leben entscheidet sind wohl gekippte Bits nicht so tragisch wenn schon dann hat der Programmierer ein Problem.

Am Ende ist eine CRC Prüfung für KI Befehle wichtig um halt solche Errors auszuschliessen.

 

[Faust2011]

Ok, kurz zum c't Artikel. Ich weiß ja nicht, inwieweit ich hier den Artikel zusammenfassen kann und darf. Letztlich geht es dort um das Thema Datenspeicherung (also auf physikalischen Datenträgern), wobei auch die Datenübertragungsstrecken als Fehlerquelle ("Trotz ECC sind Datenfehler möglich") mit eingeschlossen sind. Es wird dann im Artikel auch von "Silent Data Corruption" gesprochen, und dass sie tatsächlich existiert.

 

[emeraldmine]

muss dauernd (seit dem Thread) dran decken wie oft mein "stabiles" PC System schon seit Erbauung abgeschmiert ist, sicher 50+ Male.

 

[ascer]

@Faust2011: ...kommt der Artikel denn ungefähr zu demselben Ergebnis wie die großangelegte Studie von Google, die ich gepostet hab? Das wäre dann besonders interessant. Vor allem weil der Artikel ja sicherlich eher Praxisszenarien beleuchtet hat, wohingegen die Studie ja ausschließlich ECC-RAM in Googles Rechenzentren analysierte.

@emeraldmine: 50+ system failures? Du hast Windows laufen, richtig?^^ Und/Oder (viel) OC?

Meine Linux-Workstation ist ebenso wie mein Linux-Thinkpad noch nie abgestürzt. Ich habe nur alle 2-3 Monate immer mal wieder eine unbenutzbare GUI, was an einem abgestürzten oder ge'freez'tem oder nicht mehr auf user-input hörendem KDE liegt. Da reicht es dann i.d.R. auf der System-Shell plasmashell / KDE zu killen und neu zu starten.
Liegt aber sicherlich eher an Manjaro/Arch, das ist halt immer aktuell aber dafür nicht rock-solid wie ein Debian stable beispielsweise.

Dann gibt es natürlich ein paar schlecht geportete Applikationen...aber wirkliche Systemabstürze kenne ich von Linux kaum.

...wobei man natürlich fairerweise sagen muss, dass unter Windows auch viel mehr Schrottsoftware von Drittanbietern läuft, das macht ein System selbstredend viel anfälliger für Fehler.

 

[emeraldmine]

Du hast Windows laufen, richtig?^^ Und/Oder (viel) OC?

Eben windoof, und kein OC , aber zuviel drang diverse Freeware zu testen.

 

[Faust2011]

Dein Google-Artikel dreht sich nur um Speicherfehler (im flüchtigen RAM). Der c't Artikel ist da viel weitgehender und nicht nur auf das RAM fokussiert. Dementsprechend ist auch das Fazit nicht direkt vergleichbar.

 

[ascer]

So, eine Gainward GeForce GTX 1080 Phoenix Golden Sample ist jetzt bestellt. Ich hab mich bei der Auswahl mainly an dem CB-Artikel über die 1080 Partnerkarten orientiert: da schnitten Palit/Gainward ja sehr gut ab; die Zotac AMP! Extreme oder vielleicht die ASUS ROG Strix hätte ich sonst noch im Blickfeld gehabt...

...allerdings war nur die Gainward sofort verfügbar und auch günstiger, über meinen Bezugsweg.

Ich werde dann demnächst mal berichten.

 

[ascer]

Die 1080 ist jetzt da und anfangs hatte ich erstmal jede Menge Probleme.
Zuerst war der Rechner komplett tot, nichtmal das BIOS war mehr zugänglich. Der error code vom MB war auch nicht hilfreich: "check south bridge" -> wer kann mit sowas bitte *irgendwas* anfangen? Ich habe dann also die Karte erstmal wieder ausgebaut und das neuste (Ende 2013^^) Beta-BIOS auf mein ASRock Z68 Extreme 4 Gen3 geflasht. Da habe ich dann auch herausgefunden, dass Sandy-Bridge CPUs nur PCI-E 2.0 supporten, für 3.0 bräuchte ich min. einen Ivy-Bridge von Intel - lustig.
However, im Beta-BIOS gibt es jetzt einen PCI-E 3.0 emulation-mode, der neuere 3.0 Grafikkarten auch auf Sandy-Bridge lauffähig machen soll. Läuft tatsächlich

Nächstes Problem war dann mein Manjaro (Arch-Fork) Linux: Blackscreen beim booten. Selbst als ich im Grub bootloader die hochkompatiblen Vesa-Treiber ge'forced hab. Nach unzähligen resets hatte ich irgendwann keine Lust mehr. Hab dann die X-Session komplett unterdrückt und im Grub erstmal eine config implementiert, die direkt in die Konsole bootet.
Dort angekommen habe ich dann über die Konsole meinen "alten" Kernel 4.4 rausgeschmissen, den neusten 4.7er Kernel installiert und noch dazu auch gleich die proprietären Treiber von NVIDIA.

Nun läuft das System wieder ohne Probleme

---

Also auf zur nächsten Etappe: GPGPU-Performance testen.

Ich mach bestimmt noch weitere Tests, aber für's erste habe ich mein eigenes Ökosystem mit meinen Experimenten getestet, vor allem weil ich diese mit den Ergebnissen von unserem Supercomputer (Uni) vergleichen kann, wo die GPU-Nodes aktuell mit Tesla K40 Karten ausgestattet sind.

Nachdem ich CUDA 8.0, cuDNN 5.1 und cuFFT 6.0 fertig eingerichtet hatte, folgte direkt TensorFlow v.0.11.0rc1 - seit heute für CUDA 8 available

"Schon" konnten die Experimente beginnen und mit den Ergebnissen bin ich ziemlich zufrieden.

[table="width: 500"]
[tr]
[td]---------------------------->[/td]
[td]time (MNIST; 1 epoch)[/td]
[td]time (wCNN; 100k samples)[/td]
[td]time (sCNN - small; 100k samples)[/td]
[td]time (sCNN - big; 10k samples)[/td]
[/tr]
[tr]
[td]GTX 1080[/td]
[td]< 5ms[/td]
[td]9m 08s[/td]
[td]28m 12s[/td]
[td]11m 06s[/td]
[/tr]
[tr]
[td]Tesla K40[/td]
[td]< 20ms[/td]
[td]22m 20s[/td]
[td]1h 02m 38s[/td]
[td]42m 32s[/td]
[/tr]
[tr]
[td]2x Xeon E5-2630v3[/td]
[td]83ms[/td]
[td]3h 17m 08s[/td]
[td]11h 49m 51s[/td]
[td]9h 18m 00s[/td]
[/tr]
[/table]

* MNIST: handschriftliche Ziffern (25x25 img size) erkennen
* wCNN: weakly-supervised CNN (200x150 img size)
* sCNN - small: fully-supervised CNN (200x150 img size)
* sCNN - big: fully-supervised CNN (800x600 img size)


Mit Pascal hat NVIDIA da imho eine gute GPGPU-Architektur geschaffen; ich bin mal gespannt wie sich Volta nächstes Jahr schlägt, die soll ja explizit für Deep Learning optimiert sein.

Unabhängig davon absolviert die GTX 1080 bis jetzt jedes Experiment (je nach Architektur) 2 bis 5x so schnell wie eine K40 und 10 bis teilweise 50x so schnell wie die Xeon-CPUs (zwei 8-Kern Xeons bei 2,4 GHz, also 16 Cores mit 32 Threads).

 

[Faust2011]

Mich würde interessieren, wie stark sich der Rohleistungsunterschied einer GTX 1070 (~7 TFLOPs) im Vergleich zu einer GTX 1080 (~9 TFLOPs) in der Praxis bemerkbar macht? Und ob dort auch der Unterschied der CUDA-Cores (1920 bei der GTX 1070 vs. 2560 bei der GTX 1080) relevant ist?

Weiterhin wüsste ich gerne, ob sich der Unterschied in der RAM-Bandbreite (GTX 1070 mit GDDR5 ~250 GB/s vs. ~330 GB/s mit GDDR5X bei der 1080) in der Praxis bemerkbar macht?

Hallo!

Nachdem Du nun die GTX 1080 gekauft und getestet hast, wie siehst Du nun die Punkte Rohleistungsunterschied und RAM-Bandbreite, wie Du sie im Eingangspost aufgeworfen hast? Bist Du zufrieden, gerade im Vergleich zur Tesla oder liegt der Engpass für Deine Programme gar nicht dort sondern woanders?

 

[ascer]

Gute Frage!

Noch hatte ich leider keine Möglichkeit, die 1080 direkt mit einer 1070 zu vergleichen.

Nichtsdestoweniger ist die Leistung für float32-Simulationen (single precision) unglaublich gut (siehe Vergleich mit einer K40), sodass eine 1080 definitiv eine sehr gute, sehr preisgünstige Wahl für ML-/AI-Simulationen darstellt.
Das einzige, was mir da fehlen würde, wäre auch noch eine gute float16-Performance (half precision).

float64-Simulationen (double precision) sind recht selten, die sehr geringe Leistung dort ist also eher irrelevant. Was ansonsten gerade für Image Processing / Analysis noch schön wäre, wäre eine hohe INT8-Leistung, wie sie die Titan X bietet. Ist für diesen unschlagbaren Preis der 1080 aber verkraftbar: man kann Bildinformationen ja sehr einfach in einen Intervall [0.0, 1.0] kippen und dann wieder die float32-Performance nutzen.

Overall, auch ohne explizit die 1070 dagegen getestet zu haben, glaube ich, dass die 1080 die bessere Wahl ist. Das Preis-/Leistungsverhältnis für die Rohleistung der 1070 ist definitiv besser und ich denke, die Rohleistung einer 1070 sollte für eine Workstation für derartige Simulationen definitiv auch ausreichen.
Die Speicherbandbreite könnte aber zum Flaschenhals werden - je nach Simulation. Bei MNIST z.B. taktet der 1080 VRAM sogar runter, die utilization geht nie über wenige 10 GB/s.
Bei meinem großen sCNN hingegen läuft der VRAM auf vollem Takt und die utilization geht selten sogar über 300 GB/s -> hier wäre die 1070 dann schon lange im Limit, weshalb der VRAM der 1070 da ein Flaschenhals wäre.

Abschließend kann man wohl sagen, dass die 1070 sicherlich die bessere Preis-/Leistungsleistungsalternative wäre. Für größere Experimente glaube ich aber, dass die 1070 ihre Rohleistung nicht voll wird ausspielen können, weil teilweise eben sogar der GDDR5X der 1080 ins Limit läuft.

...in diesen Fällen macht sich dann eine Tesla mit HBM2 und massiver Speicherbandbreite sicher bezahlt...

 

[Faust2011]

Ich hoffe, es ist nicht zu offtopic: Was genau simulierst Du denn? Und ist das für Deinen Job oder reines Privatvergnügen?

 

[ascer]

Wüsste nicht, warum das Off-Topic sein sollte

Generell: Vieles.

Meistens (>=90% der Zeit) sind es aber sehr spezifische Dinge: ich bin Student und spezialisiere mich auf künstliche Intelligenz, besonders forschungsnahe Ansätze wie Deep Learning. Selbiges mache ich auch im Nebenjob, der freundlicherweise einen Großteil der Karte sponsort - sonst wäre das Investment für mich auch unmöglich gewesen.

Vom Kontext her bin ich meist in der Robotik unterwegs, wo ich i.d.R. visuelle Stimuli mit künstlichen neuronalen Netze verarbeite. Manchmal implementiere ich da Experimente von Hand (früher z.B. mal testweise CUDA C + cuDNN), generell bin ich aber viel häufiger dabei die Modelle mathematisch zu beschreiben. Für die Umsetzung nehme ich mittlerweile (anstatt alles selbst zu implementieren) meist TensorFlow (die ML/AI library von Google). Damit kann man ziemlich fix Experimente bauen, eben spezifische Modelle sehr schnell in Code umsetzen. Weiterer Vorteil von TF ist, dass es bei vorhandener GPU dein Modell "on-the-fly" in CUDA C übersetzt und mit libraries wie cuDNN, cuFFT usw. umgehen kann.
D.h. mehr Zeit für mich beim Entwerfen von Modellen, da ich dann weniger Zeit in die Implementierung stecken muss.

Eine besonders schnelle GPU (+VRAM) ist da dann natürlich schön, weil die Simulationen sonst Ewigkeiten brauchen würden. Die meisten großen Experimente von mir beschäftigen Xeon Octa-Cores min. mehrere Tage...und wenn man jedes Mal so lang auf die Ergebnisse warten muss, bremst das den Workflow natürlich ungemein^^

 

[Faust2011]

Hört sich interessant an. Mit Deiner Spezialisierung bist Du bestimmt auch gut in den nächsten Jahr(en|zehnten) auf dem Arbeitsmarkt aufgehoben. Als ich Student war (vor ca. 15 Jahren) fing man im Fachbereich gerade an, Bildverarbeitung einzuführen. Da gehörte auch die semantische Analyse von Bildern bzw. Bildsequenzen mit dazu.

Du erwähnst hier sehr oft Nvidia. AMD hat letztes Jahr ihre OpenSource-Initiative gestartet und GpuOpen ins Leben gerufen. Da heißt es auf der Website:

Introducing GPUOpen — an AMD initiative designed to enable developers to create ground-breaking PC games, computer generated imagery and GPU computing applications for great performance and lifelike experiences using no cost and open development tools and software.

Die haben dort verschieden Bibliotheken veröffentlicht und das nicht nur für Grafik (Ambient Occlusion, Geometry, Shadow, Tress), sondern auch für den wissenschaftlichen Bereich. Ist das ein Thema bei Dir am Lehrstuhl oder privat?

 

[Müs Lee]

Kleiner Einschub: AMD ist im GPGPU-Bereich so gut wie kein Thema, weil CUDA dort vorherrschend ist. AMD hat zwar einen Geschwindigkeitsvorteil in OpenCL, aber das nutzt nun mal so gut wie keiner. CUDA ist schnell, anscheinend einfacher zu handeln und es gibt vollständige Bibliotheken für so gut wie alles, was in OpenGL entweder selbst geschrieben oder zu CUDA konvertiert werden muss. AMD hat dein genanntes Programm nicht umsonst gestartet, denn sie müssen wieder Boden gewinnen. Nvidia hatte CUDA kräftig vorangetrieben, und die Vorteile ggü OpenCL waren klar vorhanden. Selbst viele Opensource-FEM/FVM-Programme zur Struktur- oder Strömungssimulation laufen nur unter CUDA, falls GPGPU unterstützt wird.

 

[ascer]

Das ist ja recht schick, GPUOpen kannte ich so noch gar nicht, ich wusste nur das AMD mit clBLAS, clFFT, clRNG und clSPARSE dabei ist, Äquivalente zu cuBLAS, cuFFT, cuRAND und cuSPARSE zu bauen.

Nichtsdestoweniger trifft der Post von Müs Lee es schon ganz gut. Ich selbst habe zwar noch nichts direkt in OpenCL gebaut, aber ich habe vielerorts schon mitbekommen, dass es unkomfortabler und schwerer zu optimieren sein soll als CUDA. Kann ich mir auch vorstellen: OpenCL ist viel neuer, OpenCL ist quelloffen, OpenCL muss auf einer Vielzahl von Devices laufen (GPUs im PC, APUs, Smartphones, ...) und vor allem ist OpenCL ja viel jünger als CUDA.

NVIDIA hat halt eine Plattform, bei der sie selbst die Hardware diktieren und selbst die Software für schreiben. Außerdem sitzen die schon deutlich länger an CUDA und sie haben sehr viel Manpower in die entsprechende Softwareentwicklung gesteckt.

Da kommt dann noch hinzu, dass manche Sachen, wie etwa clSPARSE, noch in der Beta sind. Andere Sachen, wie etwa cuDNN (CUDA Deep Neural Networks) noch gar kein Äquivalent von AMD haben und wieder andere, wie clBLAS z.B. (das es schon länger gibt), einfach deutlich ineffizienter sind als cuBLAS.

Theoretisch gesehen wäre es sehr schön, wenn AMD da mal ordentlich loslegt. Die haben ja meistens die größere Rohleistung, sind dabei auch noch günstiger und man bekommt selbst bei relativ preisgünstigen Karten häufig ordentlich Speicher und schnelle Speicherinterfaces.
An der Software hapert es dann aber leider gewaltig.

Es wäre auch besonders deshalb sehr schön, weil es von NVIDIA wiederum keine ordentlichen APUs gibt und Jetson TX1 auch eine ziemlich neue, noch nicht wirklich ausgereifte Entwicklung ist. Deshalb haben Roboter sehr häufig Intel NUCs oder schlichtweg ARM Boards. ODROIDs mit Samsung Exynos Chips z.B.
Dort ist es für uns immer super umständlich, OpenCL zu nutzen, eben wegen der fehlenden Software.

Ordentliche Software dafür von AMD + idealerweise sogar NUCs (die AMD APUs wären im low-power Bereich *KLASSE* dafür) wären enorm gut.

Leider sehe ich da AMD aber nicht wirklich in die Gänge kommen. Intel hat vor kurzem ja Movidius und ein paar andere gekauft, mit denen Intel in ML/AI und Robotik durchstarten wird/will. NVIDIA ist mit ihrem Jetson TX1 und anderen Produkten (z.B. für autonomes Fahren) gerade schon dabei...AMD ist da auch mal wieder zu spät, obwohl sie die idealen APUs dafür hätten...


Zu der letzten Frage: Nein, bei uns am Lehrstuhl ist das kaum ein Thema. Ich bin an einer Universität, sofern die nicht aus historischen Gründen eher technisch ausgerichtet ist, würde man explizite Forschung dieser Art eher an einer TU oder eventuell noch einer FH finden.

Solche Sachen gibt es bei uns zwar auch immer wieder mal, sind aber i.d.R. nur ein kleiner Teil größerer Forschungsprojekte. Der Hauptfokus liegt hier schon auf Theorie, Grundlagenforschung oder "praktische" Anwendung neuer Modelle/Architekturen in Robotik, ML/AI, ...