Maxwell war einfach ein Glücksgriff für Nvidia, deshalb ist Pascal nur ein Maxwell Shrink mit höheren Taktraten (Maxwell/Pascal mit selben Takt = selbe Performance) und Volta zeigt fast nur Verbesserungen im Profi Bereich, aber mal abwarten, vllt. ist da doch mehr dahinter.
Maxwell war für die HPC-Gemeinde ein Totalausfall, d.h. alle Maxwell GPUs sind rein auf GPU Jobs optimiert. Mit Pascal gibt es wieder einen HPC Chip - den GP100, der gleich auch ein Meilenstein war. D.h. der Sprung vom GK110 zum GP100 ist sehr groß. In vielerlei Sicht muss man den GP100 eher mit den XeonPhis 200 von Intel vergleichen und nicht mit AMDs GCN GPUs. Der nun vorgestellte GV100 ist der Nachfolger des GP100s und definitiv nicht auf Grafikperformance optimiert. Die Quadro GP100 ist bei Grafik auch langsamer als die Quadro P6000, die auf dem GP102 basiert. Man kann daher aus den Daten des GV100 kein wirklich sinnvollen Schlüsse für die GPUs der Volta Familie schließen. Man sollte auch nicht den Fehler machen und die GP100/GV100 als GPU betrachten, das bekommen diese Chips auch auf die Reihe, aber dafür sind sie nicht optimiert. Es sind Coprozessoren für das technischwissenschaftliche Rechnen.
Fangen wir bei der alten C/C++ Sprache an, die laut Computersprachexperten elendig ineffizient sein sollen.
Da ich selbst Software entwickle und so viele Sprachen kenne und einige beherrsche, in welcher Hinsicht sollen sie ineffizient sein? Bei dem Thema LOCs trifft es zu, man bekommt mit anderen Sprachen am Tag mehr Arbeit getan, aber der Code ist dann entsprechend lahm. Wenn man schnellen Programmcode haben will, läuft das noch immer auf Ada, C, C++ oder Fortran hinaus. Es gibt noch ein paar wenige neuere Sprachen, die auch nicht schlecht sind, aber da hat man oftmals das Problem, dass es für die gewünschte Plattform keine Compiler gibt, keine hoch optimierenden Compiler, es fehlt an Werkzeugen für die Codeanalyse es fehlt an Debuggersupport, … Die Liste kann man nahezu beliebig verlängern.
Dann die ollen alten Instruction Sets, die auch längst überholt sind und durch elegantere Sachen wie ARM ersetzt werden könnten.
Intel führt beständig neue Instrunctionssets ein, um die Effizienz der Plattform zu erhöhen. Das klappt mit den neuen AVX, AVX2, AVX512 auch ganz gut. Das Problem sind die Altlasten der total vermurksten x86 Architektur. IA32 stammt aus einer Zeit, als man sich über solche Dinge noch keinerlei Gedanken machen musste. Die Befehlslänge ist daher total unterschiedlich was das Decoden erschwert und die Cache Misses erhöht. Bei einer modernen CPU ist die Minimierung der Cache Misses das wichtigste Ziel der Optimerung.
Macht nur keine Sau, weils niemand kaufen würde. Ohne Windows - mööp. Ohne X86 - mööp. Ihr versteht schon...
Das ist ein reines Windows Problem! Mein erster Kontakt mit einem 64Bit System ist nun gut 20 Jahre (!) her, und wenn man damals einige wenige Dinge (ByteOrder, die korrekte Verwendung der C Basistypen) beachtete hatte, dann läuft der Code vollkommen unverändert noch heute effizient und schnell. Nur reden wir hier über UNIX/Linux Code und nicht über Windows Code. Die CPU Architektur der Plattform ist dabei sch***egal, darum kümmert sich der Compiler, daher sollte man i.d.R. kein Assembler nutzen, das bringt zu wenig um den Aufwand zu rechtfertigen. Gerade für das technischwissenschaftliche Rechnen ist das wichtig, da man sehr viel Geld in die Software steckt und den Code nicht jedesmal neuschreiben kann wenn irgend ein neuer Hype vorhanden ist. Dazu ist man vollkommen unabhängig von der Hardware. Es ist egal, ob da ein MIPS, ARM, HP-PA, Alpha, Power, SPARC, IA32, IA64 oder Intel64 drin steckt. Bis auf Alpha und IA64 habe ich auf allen Systemen schon Software entwickelt.
AMD haut regelmäßig tolle neue Technologien raus, die kaum eine Sau nutzt.
Da ich nicht nur eine Firma erlebt habe, AMD ist was die Software betrifft eine einzige Zumutung. Daher ist es enorm schwierig Software für AMD zu optimieren. Ja, man kann schnelle Programme für AMD Hardware schreiben, der Aufwand ist aber enorm.
Mir tut AMD da ein wenig leid. Die treiben mit ihrem Einkommen an der roten Linie so viel Innovation, dass Nvidia und Intel eigentlich rot vor Scham werden müssten.
Die Hardware von AMD ist gut, die Software ist der letzte Dreck, und genau deshalb nutzten so viele lieber nVidia und Intel. Ein simples Beispiel: Will man Programmcode optimieren, muss man dazu spezielle Software einsetzen einen sogenannte Profiler. Intels Software kann unter Linux als Serverprozeß gestartet werden und ein jeder Nutzer kann ohne Privilegien sein Programm profilen. Tja, mit AMD geht das natürlich nicht man muss root sein, damit man den AMD Profiler einsetzen kann, was natürlich bei einem Cluster mit zig Nutzern aus Sicherheitsgründen kategorisch ausgeschlossen ist.
Wenn die Softwareentwickler OpenCL benutzen würden, könnte AMD in den Rechenzentren ne Menge erreichen. Aber seit über 10 Jahren gibts nur CUDA, CUDA und wieder CUDA.
OpenCL für AMD ist nicht OpenCL für nVidia, deshalb muss man den Programmcode so oder so portieren. Dazu ist das ganze CUDA Umfeld dramatisch besser.
Ich mag CUDA nicht, hauptsächlich weil es proprietär ist. Ich frag mal so: Warum nicht gleich OpenCL? Ist bei gleichem Entwicklungsaufwand der Softwarehersteller genauso schnell wie CUDA (evtl. sogar noch schneller), offen, wird aktiv weiterentwickelt, sehr flexibel und ist kompatibel mit Nvidia, Intel und AMD.
Weil der Entwicklungsaufwand mit OpenCL deutlich höher ist! AMD liefert für OpenCL faktisch nur einen Compiler und sonst nichts. nVidia liefert eben nicht nur den CUDA Compiler sondern massenweise Libraries mit, analog verhält sich das bei Intel.
- - - Updated - - -
Ich warte immer noch auf das Argument FÜR CUDA.
Der Softwarestack ist der wichtigste Grund für CUDA. Wollte man zu Anfang ein Programm schreiben das wissenschaftliche Rechnungen ausführte, dann musste man bei AMD mit OpenCL alles selbst machen. Bei nVidia hat man einfach die cuBLAS und cuFFT Libraries eingebunden und das Multiplizieren zweier Matrizen einfach durch DGEMM (…A,B,C…) erschlagen, bei AMD durftest Du die Matrixmultiplikation selbst programmieren. Mit der Zeit gab es dann eine Pseudo BLAS von AMD, da war nur eine Routine implementiert die DGEMM (SGEMM, CGEMM und ZGEMM schon nicht mehr), weil man nur diese Routine für den Linpack braucht.
Erst seit wenigen Jahren gibt es nun die ersten Ansätze von universitären Arbeitsgruppen BLAS und LAPACK als OpenSource Projekte für GPGPUs und die XeonPhis umzusetzen: siehe Magma Library, ViennaCL, … Und bitte nicht wundern von der Magma Library gibt es drei Versionen CUDA, OpenMP (Intel), OpenCL (AMD).
Soweit völlig korrekt. Er ist ein Biologe, kein Programmierer. Ich bin Ingenieur für Signalverarbeitung und kein C/C++ Hacker. Ich bastle Prototypen. In meinem Bereich gibts aber auch einige Kollegen, die Machine-Learning machen sollen. Und auf einmal kommen Leute an, die dann verlangen, dass wir auch C/C++ können sollen.
Das Programmieren-können gehört meines Erachtens zwingend dazu. Es muss nicht gleich C oder C++ sein, es gibt auch noch andere Möglichkeiten z.B. Python -> NumPy.
Matlab ist nennt, aber stößt relativ schnell an seine Grenzen. Es wird gerne von Wissenschaftlern eingesetzt, die sich weigern zu programmieren. Die Probleme fangen an, wenn man die Software zur Beschleunigung der Arbeit auf einem Cluster ausführen will. Da kommt sofort das Lizenzproblem nach oben, daher entweder Matlab Compiler oder lieber gleich GNU Octave, dafür gibt es auch OpenCL Backends.
Recht einfach: Wenn ich mir ein auto kaufe,
Um einen nachvollziehbaren Vergleich zu bringen: Mit dem nVidia PKW kann man beim Händler vom Hof fahren, bei AMD muss man den PKW-Bausatz auf dem Hof zuerst zusammenbauen.
Vielleicht will ich das gar nicht?
Dann nutze ein anderes Programm.
