Skysnake
Lötkolbengott/-göttin
AW: GPU kommt später: Fermi-Nachfolger Kepler von Nvidia für 2012 bestätigt
Wenn du IEEE erfüllst, dann gibt es da kein besser oder schlechter mehr. Dafür ist der Standard ja da
Was die Stabilität angeht, klar, da müssen die Hersteller etwas schauen, aber DAS Problem ist das nicht. Schließlich hast du auch einr ganz klar umrissene Umgebung, also z.B. Klimaanlage, die die Raumtemp unter 25°C hält, wenig Luftfeuchtigkeit etc. etc. etc.
Und das mit den Programmierern ist halt so ne Sache. Es gibt ja genug Probleme, die kannst du einfach vergessen auf ne GPU zu portieren. Selbst wenn die GPU unendlich schnell wäre, einfach deswegen, weil allein der Datentransfer auf die GPU und zurück schon länger braucht als die CPU überhaupt für die Aufgabe.
Das Problem bei der GPU-Programmierung ist es auch nicht wirklich, die Programme zum laufen zu bekommen, oder relativ effizienten Code zu schreiben, das kennen die Leute ja von den Clustern her. Wir nehmen also mal an, die Parallelisierung an und für sich ist eh schon gegeben. Das Problem sind die begrenzten Bandbreiten. Die CPU hat im Vergleich zur GPU pro ALU VIEL VIEL VIEL mehr Speicherbandbreite zur Verfügung, und auch die Caches sind VIEL VIEL VIEL Größer, die die effektive Bandbreite, die einem zur Verfügung stellt auch nochmals erhöht.
Kleines Bsp.: Wir haben dieses Semester eine Matrixmultiplikation programmieren müssen. Bei jeder Implementierung war unsere Rechenleistung durch die Speicherbandbreite limitiert. Angefangen von 8 GFlop/s komplett ohne Optimierungen über 80 GFlop/s mit der Standardoptimierung durch Slices/Submatrizen, was man auch bei CPUs macht um die Datenlokalität zu erhöhen, bis hin zu 220 GFlop/s mit nochmals verbesserten Zugriffsmuster um für die Slices, um den Datentransfer zu minimieren und auch nochmals einer Optimierung am Codeablauf, um mehr Parallelität auf Instruktionsebene zu erhalten, da man die Latenzen noch nicht ganz versteckt hatte. Das Tolle an den letzten beiden Optimierungen ist, dass das nochmals einen Faktor 2 im Speed gebracht hat, aber gerade von dem Problem mit den Latenzen eben NICHTS im CUDA-Programmerguide drin steht. Hab das selbst nur durch Zufall raus bekommen, da AMD dies selbst anspricht in seinem Guide. Das ist halt auch nen riesen Problem. Die Hersteller geben einem teilweise nicht alle nötigen Infors, bzw. es sind auch teilweise einfach viel viel viel viel zu viele Sachen, die man beachten muss. Das macht die ganze Sache sehr kompliziert, und ohne ein tieferes Verständnis von der Hardware, denkt man an die meisten Probleme gar nicht.
Wenn du IEEE erfüllst, dann gibt es da kein besser oder schlechter mehr. Dafür ist der Standard ja da
Was die Stabilität angeht, klar, da müssen die Hersteller etwas schauen, aber DAS Problem ist das nicht. Schließlich hast du auch einr ganz klar umrissene Umgebung, also z.B. Klimaanlage, die die Raumtemp unter 25°C hält, wenig Luftfeuchtigkeit etc. etc. etc.
Und das mit den Programmierern ist halt so ne Sache. Es gibt ja genug Probleme, die kannst du einfach vergessen auf ne GPU zu portieren. Selbst wenn die GPU unendlich schnell wäre, einfach deswegen, weil allein der Datentransfer auf die GPU und zurück schon länger braucht als die CPU überhaupt für die Aufgabe.
Das Problem bei der GPU-Programmierung ist es auch nicht wirklich, die Programme zum laufen zu bekommen, oder relativ effizienten Code zu schreiben, das kennen die Leute ja von den Clustern her. Wir nehmen also mal an, die Parallelisierung an und für sich ist eh schon gegeben. Das Problem sind die begrenzten Bandbreiten. Die CPU hat im Vergleich zur GPU pro ALU VIEL VIEL VIEL mehr Speicherbandbreite zur Verfügung, und auch die Caches sind VIEL VIEL VIEL Größer, die die effektive Bandbreite, die einem zur Verfügung stellt auch nochmals erhöht.
Kleines Bsp.: Wir haben dieses Semester eine Matrixmultiplikation programmieren müssen. Bei jeder Implementierung war unsere Rechenleistung durch die Speicherbandbreite limitiert. Angefangen von 8 GFlop/s komplett ohne Optimierungen über 80 GFlop/s mit der Standardoptimierung durch Slices/Submatrizen, was man auch bei CPUs macht um die Datenlokalität zu erhöhen, bis hin zu 220 GFlop/s mit nochmals verbesserten Zugriffsmuster um für die Slices, um den Datentransfer zu minimieren und auch nochmals einer Optimierung am Codeablauf, um mehr Parallelität auf Instruktionsebene zu erhalten, da man die Latenzen noch nicht ganz versteckt hatte. Das Tolle an den letzten beiden Optimierungen ist, dass das nochmals einen Faktor 2 im Speed gebracht hat, aber gerade von dem Problem mit den Latenzen eben NICHTS im CUDA-Programmerguide drin steht. Hab das selbst nur durch Zufall raus bekommen, da AMD dies selbst anspricht in seinem Guide. Das ist halt auch nen riesen Problem. Die Hersteller geben einem teilweise nicht alle nötigen Infors, bzw. es sind auch teilweise einfach viel viel viel viel zu viele Sachen, die man beachten muss. Das macht die ganze Sache sehr kompliziert, und ohne ein tieferes Verständnis von der Hardware, denkt man an die meisten Probleme gar nicht.
