Massengeschmack-TV Shop

Folge 3: Im Klimarechenzentrum


#1

Hier kann darüber diskutiert werden!


#2

Entschuldigung, dass der erste Kommentar direkt ein Besserwisserkommentar ist, aber: Im Text steht “Terrabyte”, sollte aber “Terabyte” sein. :nerd_face:

Davon ab gefällt mir die Folge als Informatiker sehr gut. Frage mich aber, warum, die nicht auf GPUs setzen. :thinking: Man müsste zumindest etwas Energie in die Speicherverwaltung stecken.


#3

Im großen und ganzen eine nette Folge, aber…

was mich etwas gestört hat war der holprige Gesprächsverlauf, der jedoch von beiden Seiten verschuldet war.
Einige Kommentare zu den Erklärungen fand ich etwas unnötig und kindisch.

Schade finde ich auch, dass es viel zu wenige tiefgründigere Fragen gab.
Wenn man schon die Möglichkeit hat, eine Führung durch solch ein Rechenzentrum zu machen, dann sollte da auch mehr bei rum kommen.

Ein roter Faden hat meiner Meinung nach komplett gefehlt.
Was genau sollte man aus dieser Folge mitnehmen?
Die technischen Einzelheiten des Rechenzentrums oder Informationen über das Klima?

Ich finde es etwas schade, dass man sich anscheinend fast keine Mühe gibt.
Nur da hin fahren und ein paar Fragen stellen reicht meiner Meinung nach einfach nicht aus um so etwas als teil eines Bezahlabos zu bringen.

Fazit zu dieser Folge:
Unangenehmer Gesprächsverlauf gemischt mit teils unnötigen und kindischen Kommentaren.
Kein roter Faden und somit keine fundierten Fragen, die diese Folge sehenswert gemacht hätten.
Mehr vorarbeit hätte auf jeden Fall gut getan.

MfG,
Bopfos


#4

Als jemand, der in einem verwandten Gebiet arbeitet, kann ich ungefähr vier Gründe aufzählen, warum nicht breit auf GPUs gesetzt wird:

  1. Die Portierung komplexer numerischer Codes nach CUDA oder OpenCL ist zeitaufwendig und zieht umfangreiche Tests nach sich. Es muss schließlich sichergestellt werden, dass zum Beispiel der neue GPU-Solver genauso zuverlässig arbeitet wie die alte CPU-Routine.

  2. Nicht jedes Problem lässt sich gut mit GPUs bearbeiten. Die volle Rechenleistung spielen sie nur bei einfachen, massiv parallelisierbaren Berechnungen ohne Abhängigkeiten und Kommunikation aus. Moderne Hydrodynamik-Codes in der Physik besitzen zum Beispiel in aller Regel eine GPU-Routine für die Gravitation (direct nbody oder Barnes-Hut-Tree), andere Bestandteile hingegen lassen sich aufgrund des großen Kommunikationsaufwands nicht effektiv auf GPUs rechnen und profitieren eher von CPU-Features wie Caching, speculative execution und branch prediction. Neuerdings wird an Raytracing-Routinen gearbeitet, mit denen der Strahlungstransport auf GPUs ausgelagert werden kann.

  3. CPU-Cluster sind sehr verbreitet, große GPU-Cluster hingegen noch immer vergleichsweise selten.

  4. Die Aussichten für CUDA und OpenCL sind angesichts der aktuellen Entwicklungen auf dem Prozessormarkt (Explosion der Corezahl pro CPU) eher bescheiden.


#5

Erneut ein sehr interessantes Thema sowie eine gute (aber auch naheliegende ;)) Wahl der Einrichtung.

Die Umsetzung war dieses Mal allerdings nicht so überzeugend. Die Anmoderation wirkte schon sehr hastig vorgetragen - dort würde ich prinzipiell sagen: Sobald ein minimaler Versprecher drin ist -> neu aufzeichnen. Das kann man ja auch nachher machen, wenn man einen Termin hat und es deswegen vorher zeitlich schlecht einplanen kann. Im Gespräch selbst finde ich es nicht so tragisch und gerade bei den Interviewten, die möglicherweise das erste Mal vor einer Kamera stehen, kann man es auch eher verzeihen.

Bzgl. des roten Fadens stimme ich @Bopfos zu: Den habe ich auch vermisst :wink: . Erst ging es um Daten, danach um die Unterscheidung Klima/Wetter, dann um die Modellbildung, zwischendurch kurz um das Gebäude, anschließend um die Visualisierung, dann wurden Rechner und Archiv besichtigt, wobei es wieder um Daten und kurz das Gebäude ging, danach gab es noch Visualisierungen. Gerade der Einstieg wirkte irgendwie seltsam.

Die Fragen wurden immer sehr passend beantwortet, weshalb man mit einer klaren Themenstruktur (etwa: Klima/Wetter -> Modellbildung -> Daten -> Rechner/Archiv/Gebäude -> Visualisierung) wohl eine deutlich bessere Abgrenzung hätte erreichen können.

Den Erläuterungen konnte man sehr gut folgen, gerade durch die ganzen Darstellungen. Das Highlight war für mich der interaktive Globus zur Visualisierung: Was ein geiles Teil :smiley: .

Ich denke, dass man mit wenigen Anpassungen (Anmoderation, Gesprächsstruktur) noch deutlich mehr hätte rausholen können, da das Thema sehr viel hergibt. Einen Überblick in die Themenvielfalt konnte man aber trotzdem erlangen :slight_smile: .


#6

Als jemand, der in der GPU-Programmierung arbeitet, kann ich dazu auch was antworten :slight_smile:

  1. Klar, da muss schon Energie reingesteckt werden und meiner Erfahrung nach ist da momentan das Know-How der Programmierer das Problem. Auf GPUs zu programmieren unterscheidet sich erheblich von CPU-Programmierung, sobald man optimieren muss.
  2. Das stimmt inzwischen nur noch eingeschränkt. Gerade mit CUDA und den SMs aktueller Grafikarchitekturen lassen sich sehr komplexe und auch divergente Algorithmen sehr gut auf GPUs portieren. Caching ist genauso auch ein GPU-Feature und wird dort mindestens genauso exzessiv genutzt, wie auf CPUs. Branch Prediction ist auch schon längst kein Fremdwort mehr für GPUs. Speculative Execution wird in einer Abwandlung dort auch verwendet.
  3. Das stimmt. GPU-Cluster sind eher selten, obwohl sie für das gleiche Geld ein Vielfaches der Leistung eines CPU-Clusters auf gleichem Kostenniveau ermöglichen können.
  4. Da muss ich widersprechen. Zumindest für CUDA. OpenCL ist tatsächlich auf einem absteigenden Ast, aber der Grund ist eher, dass sich viele Firmen davon entfernen (allen voran Apple). Mit Vulkan gibt es aber eine sehr gute Alternative. Dass die Corezahl der CPUs “explodiert” würde ich auch eher verneinen. Eher kommen sie jetzt so langsam aus dem Quark. Bei GPUs hat eine einzelne schon knapp 100 Cores (die man selbstverständlich nicht so “frei” programmieren kann, wie CPU Cores)

Gerade die Differentialgleichungen bei Wetterberechnungen sollten sich besonders leicht in CUDA formulieren lassen. Dafür sind GPUs ja geradezu gemacht. Mir ist zumindest bisher keine Differenzialgleichung auf 2 oder 3 Dimensionen untergekommen, bei denen eine GPU nicht jede CPU weit hinter sich gelassen hätte. Natürlich immer vorausgesetzt, dass der Programmierer Ahnung hat, von dem was er tut. :smile:


#7

Herr Mertke, das Gitter hat eine Funktion…: Ästhetik. Von Technikern gerne unterschätzt.

Mich überfordert die Folge ehrlich gesagt etwas. Ich kämpfe damit, einzunicken. Das mag mein Problem sein, aber ich kanns ja mal erwähnen. Ich möchte mal einen Vergleich bemühen. Angenommen, wir nehmen uns eine Folge der WDR-Sendung “Quarks” vor. Dann wäre die TRIP-Folge wie ein ungeschnittenes Interview für eine Quarks-Sendung, das als Bonus ins Netz gestellt wird. Mir fehlt die Aufbereitung des Themas und ein Überbau, in dem das Interview eingebettet ist. Mir fehlt sozusagen der Charakter eines Magazins.

Suboptimal ist auch, wenn sich der Interviewte verspricht bzw. verzettelt, “nochmal” sagt und noch einmal neu ansetzt. So etwas schneidet man doch!?


#8

Eventuell hättest Du mehr Verständnis für die Situation der Wissenschaftler, wenn Du selbst in der Naturwissenschaft tätig wärst. Im Angesicht von “publish or perish”, befristeten Verträgen und sonstigen prekären Bedingungen greift der Postdoc natürlich zuerst auf bestehende Methoden zurück und modifiziert diese, bevor komplette Neuentwicklungen in Angriff genommen werden.

Ansonsten muss ich dir für den Bereich der numerischen Magnetohydrodynamik (Navier-Stokes plus Maxwell) widersprechen: Alle in meinem Bereich etablierten Codes (FLASH, ENZO, PENCIL) setzen vorwiegend auf CPU-Solver. Für FLASH wird gerade ein GPU-Raytracingmodul entwickelt, um den Strahlungstransport zu berechnen. Vor drei Jahren erst wurde - nach umfangreicher Analyse des Beschleunigungspotentials - ein Barnes-Hut-Treealgorithmus zur Lösung der gravitativen Poisson-Gleichung in CUDA als FLASH-Modul inplementiert. Der GPU-Godunov-Solver hingegen erwies sich als Fehlschlag, wobei speziell das adaptive mesh refinement Probleme bereitete. Die Zahl und Lage der Simulationsblöcke ist nämlich nicht konstant, sondern wird an die Dynamik des Systems angepasst.

Deine bescheidene Schlussfolgerung wäre nun “Inkompetenz beim Programmierer”? Warum sind gerade Informatiker immer so unglaublich von sich selbst überzeugt … DAUs sind immer die anderen, nicht wahr :slight_smile:


#9

Das stimmt, es ist alles etwas sehr technisch. Gerade die Erklärung der Algorithmen. Da es relativ gut in mein berufliches Feld fällt, kam es mir natürlich nicht so “langweilig” vor. Ich denke, das könnte in diesem Magazin häufiger problematisch werden, es jedem Recht machen zu können.


#10

Von Inkompetenz hab ich nichts gesagt. Es ist einfach die fehlende Erfahrung in der GPU-Programmierung. Ich hab auch lange in der Forschung gearbeitet (vorwiegend 3D-Rekonstruktionen, z.b. Computertomographie). Da ist mir schon sehr stark aufgefallen, dass eben nicht so viel Energie in die Portierung auf GPUs gesteckt wurde, sondern eher darauf, dass die Algorithmen korrekt sind und funktionieren. Die Optimierung für das unterliegende System kam da an zweiter Stelle oder eben gar nicht. Was ja auch völlig in Ordnung ist, aber dann kann in dem Bereich auch keine Erfahrung aufgebaut werden.

Mit deinen Algorithmen kenn ich mich zugegebenermaßen nicht aus, aber ich kann mich erinnern, dass es gerade zu GPU-Optimierungen für Adaptive Mesh Refinement einige Vorträge gab, die ich mir damals angehört hatte. Allerdings nur halbherzig, da es mich nicht sonderlich interessiert hatte :sweat_smile: Aber mit CUDA hat man auch die Möglichkeiten auf dynamischen “Grids” zu arbeiten.

Wenn man sich dafür mit der Hardwarearchitektur auseinandersetzt, sind da erhebliche Performancesprünge möglich. Man muss sich halt daran gewöhnen, dass man einen Algorithmus für jede GPU-Architektur separat anpassen muss. Leider eignen sich solche Themen natürlich gar nicht für die Forschung. Das musste ich damals auch lernen, auch wenn ich nicht wirklich (glücklicherweise!) Stress mit befristeten Arbeitsverträgen, Publikationsdruck und solchen “Späßen” hatte. Und ich halte die Richtung, in die das Forschungsumfeld sich entwickelt auch nicht für erstrebenswert, aber das ist natürlich ein Thema, was hier nicht hin gehört.

Ich habe aber auch ehrlich gesagt übersehen bzw. nicht daran gedacht, dass es ja kein Unternehmen ist, sondern eine gemeinnützige GmbH (wie ich gerade lese), wo man natürlich nicht sehr risikofreudig sein darf/sollte und auf altbewährte Dinge zurückgreift.


#11

Mal ne Frage an euch beiden “Fachleute”. Die Problematik die sich dort bei der Berechnung usw. stellt ist doch die gleiche wie beim Rendering oder sehe ich das falsch? Es ist ja auch beim Rendern so das auf CPUs und eben nicht auf GPUs gesetzt wird aufgrund der verschiedenartigen Struktur. Ich hab mich damals als ich anfing oberflächlich mit dem Thema auseinandergesetzt weil ich naiv dachte: Ok, dann brauch ich jetzt Mainboards wo möglichst viele Grafikkarten draufpassen um schnell rendern zu können. Weil ich will ja “Grafik” machen und sowas machen GPUs. Aber eben genau so ist es ja nicht und das hat soweit ich es verstehe eben nichts damit zu tun das im Bereich der GPUs einfach nur noch nicht genug “geforscht” wurde bzw. genügend Mittel eingesetzt wurden, sondern es hat strukturelle bzw. prinzipielle Gründe.

Rein interessehalber: Was arbeitet ihr beide denn?


#12

Zu der Zeit, als sich die Offlinerenderer entwickelt haben, waren GPUs tatsächlich nicht dazu geeignet bzw. auch noch gar nicht erfunden. Die Algorithmen der Offlinerenderer unterscheiden sich grundsätzlich von denen, die in der Rastergrafik von Videospielen von der GPU beschleunigt werden. Rastergrafik ist auf Echtzeit und dementsprechend weniger auf Realismus ausgerichtet. Bei Offlinerenderern ist das genau umgekehrt, denn die sollen in erster Linie “korrekte” Bilder erzeugen und die Zeit, die sie dafür benötigen ist nur zweitrangig.

Der anfängliche Name von “Grafikkarten” ist vielleicht auch etwas irreführend. “Rastergrafikkarten” wäre wahrscheinlich besser gewesen. Und heutzutage eher “General-Compute-Karten”.

Erst als im Laufe der Jahre dynamisch programmierbare Teile (die sogenannten Shader) in der Rastergrafik eingeführt wurden, hat sich herausgestellt, dass GPUs wunderbar denselben simplen Algorithmus rasend schnell auf sehr große Datenmengen anwenden kann. Eigentlich genau das was beim Lösen von Differentialgleichungssystemen gebraucht wird.

Im Laufe der letzten Jahre haben sich die GPUs sogar noch weiter entwickelt, soweit, dass sie sich schon teilweise wie CPUs programmieren lassen. Das Wissen über diese Entwicklung kommt - meiner Erfahrung nach - aber nur sehr langsam in der Forschung an, was man ja auch an den anfänglichen Argumenten hier in der Diskussion teilweise erkennen kann. Und in der Forschung herrscht ja teilweise auch ein hoher Publikationsdruck und das Anpassen eines Algorithmus auf eine bestimmte Hardware ist auch leider nicht sonderlich “publikationswürdig”.

In letzter Zeit nutzen auch immer mehr Offlinerenderer GPUs (z.b. ProRender von AMD, das in Cinema4D genutzt werden kann, oder auch Otoy Octane, die komplett auf GPU-Rendering setzen). Das dauert leider seine Zeit und kostet die involvierten Firmen auch viel Mühe, die bestehenden Algorithmen für die Ausführung auf GPUs anzupassen.

Um den Kreis zu den Wetterberechnungen zu schließen: Es wurde ja im Beitrag erwähnt, dass die Kommunikation zwischen den Rechnern der Flaschenhals ist. Da helfen GPUs natürlich auch nicht. Die Berechnungen zwischen der Kommunikation könnte man aber mit hoher Wahrscheinluchkeit sehr gut für GPUs optimieren, wenn man das Geld investieren würde. Aber, wie gesagt, für eine nichtkomerzielle Organisation wäre es evtl. ein zu großes Risiko, die gesamte Rechnerinfrastruktur umzustellen. Vor allem, ohne zu wissen, wie viel Geld am Ende tatsächlich eingespart werden kann.

Um deine letzte Frage noch zu beantworten: Ich hab einige Jahre in der Forschung im Bereich “Computer Vision” gearbeitet. Jetzt bin ich einem Unternehmen angestellt, wo ich Kunden bei der Migration ihrer Algorithmen von der CPU zur GPU unterstütze.

Und um noch etwas zur Sendung zu sagen: Mir gefällt diese Art der “Dokumentation” ziemlich gut. Diese undestillierten Gespräche finde ich sehr angenehm und man erfährt auch etwas über die Personen, die dahinter stehen. Klar kann man die Informationsdichte erhöhen oder optimieren, aber genaz ehrlich: Dann lese ich mir lieber ein Paper oder einen guten Artikel zu dem Thema durch. Denn so ein Video würde dann keinen wirklichen Mehrwert bieten.

Also: Mach weiter so, Thomas! :+1: :smiley:


#13

Sehe ich auch so. Bitte beibehalten, das verleiht dem Format Charakter.


#14

13 Beiträge wurden in ein neues Thema verschoben: Renderdiskussion (Ausgelagert aus Trip 3)


#27

Halbwegs zum Thema passend wäre mal eine Bitcoin-Miningfarm in Skandinavien oder der Global Seed Vault, falls man mal wieder etwas weiter raus möchte.


#28

Hi,

Nette Folge, aber ehrlich gesagt erscheint er mir doch etwas kindlich / naiv wie Thomas daran geht. Auf mich macht er den Eindruck das er mit grossen Augen im RZ gestanden ist und von “Petabytes” und der schieren Menge an Rechenkapazitäten beeindruckt ist.
Auch über die Frage vor der Tape Library, das Tapes ja veraltete Technologie wären musste ich ehrlich gesagt ein wenig lächeln - das ist ne 08/15 Tape Library, die man in jedem 08/15 RZ findet (wenngleich nicht überall mit 10000 Tapes :slightly_smiling_face: ).

Also für mich war der “technik-Teil” ziemlich unspannend, weil total Naiv. Wenn es um Klima, etc. geht ist es sehr spannend und die unaufgeregte Art ist äusserst erfrischend!

Definitiv: Weiter so! Jede Folge wird besser. Top.

Atti


#29

Ich arbeite als wissenschaftlicher Angestellter einer Bildungseinrichtung im Bereich der numerischen Simulation magnetohydrodynamischer Systeme, habe den Aufschwung der GPUs ganz konkret und praktisch miterlebt und an meinem Institut mitgestaltet. Da wir keine wirtschaftlichen Interessen verfolgen, sondern den wissenschaftlichen Nutzen an erster Stelle sehen, bewertet mein Institut die Sache naturgemäß etwas anders. Noch ein weiteres Problem: CUDA ist aufgrund der Festlegung auf einen Hersteller besonders problematisch, im Gegenzug wird OpenCL nicht immer in der aktuellsten Fassung unterstützt.


#30

Ah ok, ja, mit dem beruflichen Hintergrund kann ich deinen etwas anderen Blickwinkel bzw. den des Instituts durchaus nachvollziehen.


#31

Das mit CUDA und OpenCL ist leider richtig. Wir haben damals auch auf OpenCL gesetzt, einfach um eine größere Hardwarepalette zu untersützen. Und mussten uns auch auf eine relativ frühe Versionsnummer festsetzen, damit wir auf Hardware von beiden großen Herstellern genutzt werden konnten. Unsere neu entwickelten Methoden sollten in der Medizin Anwendung finden, die in dem Bereich weit hinterhehinkt und teilweise sogar Diagnosen auf Basis der Ergebnisse von schlicht falsch formulierten Algorithmen stellt. Getreu nach dem Motto “Ham wa immer schon so gemacht!”

Damals war ich zwar bei einer Universität angestellt, die Stelle wurde aber von einem PPP-Unternehmen finanziert. Daher war es so ein Zwischending von forschungs- und gewinnorientiert. Und da hab ich dann schon festgestellt, dass mir die Entwicklung neuer Methoden weniger Spaß macht, als die Implementation und Optimierung bestehender Methoden :sweat_smile:


#32

Da muss sich Thomas aber beeilen, denn aktuell verschrotten wohl einige Miner bereits ihre Serverfarmen, weil sich das ganze nicht mehr lohnt.