#184 GPU Programmierung - von CUDA bis OpenMP mit Peter Thoman

GPU-Programmierung: Andere Chips und eine andere Art zu programmieren

In der heutigen Zeit dreht sich fast alles in der IT um AI. Und damit auch oft um den sich positiv entwickelnden Aktienkurs von Nvidia. Warum Nvidia? Als Hersteller von Grafikkarten bzw. Grafikchips (kurz GPUs) profitieren sie deutlich von den hohen Nachfragen nach dieser Art von Chips. Das Ganze hat die Frage aufgeworfen: Inwieweit ist die Programmierung auf bzw. für eine GPU anders als bei einer klassischen CPU?

In dieser Episode behandeln wir dieses Thema: Paralleles Programmieren auf der GPU.

Wir bröseln das Buzzword-Bingo auf und schauen uns an, was der Unterschied zu verteiltem vs. parallelem Rechnen ist, was HPC und CUDA eigentlich ist, ob bzw. wie man auf Grafikkarten ohne Frameworks programmieren kann, welche algorithmischen Use Cases neben AI und Transformer-Modelle existieren, wie man einen Algorithmus für die GPU programmiert und was man alles vermeiden sollte, sprechen über Speicherzugriffsmuster und warum Matrizen-Multiplikationen so gut auf GPUs funktionieren aber auch was Performance-Portabilität bedeutet und ob es Probleme mit der Heterogenität von Grafikkarten und Chips gibt.

Und das alles mit Dr. Prof. Peter Thoman.

Bonus: Wie besucht man möglichst effizient alle Städte in Deutschland? Das Problem des Handlungsreisenden.

Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners

Das schnelle Feedback zur Episode:

👍 (top) 👎 (geht so)

Feedback

EngKiosk Community: https://engineeringkiosk.dev/join-discord
Buy us a coffee: https://engineeringkiosk.dev/kaffee
Email: stehtisch@engineeringkiosk.dev
LinkedIn: https://www.linkedin.com/company/engineering-kiosk/
Mastodon: https://podcasts.social/@engkiosk
Bluesky: https://bsky.app/profile/engineeringkiosk.bsky.social
Twitter: https://twitter.com/EngKiosk

Sprungmarken

(00:00:00) Intro

(00:01:28) Paralleles Programmieren auf der GPU mit Peter Thoman

(00:07:26) Was ist was? Verteiltes vs. paralleles Rechnen, HPC, CUDA und mehr

(00:08:34) Info/Werbung

(00:09:34) Was ist was? Verteiltes vs. paralleles Rechnen, HPC, CUDA und mehr

(00:22:34) Wie hat die Berechnung auf der GPU begonnen?

(00:33:23) Use-Cases für die GPU

(00:45:58) Matrizenmultiplikation und Neuronale Netze auf der GPU

(00:55:11) Heterogenität der Grafikkarten und Chips

(01:00:10) Dein Einstieg in die GPU-Programmierung

Hosts

Wolfgang Gassler (https://gassler.dev)
Andy Grunwald (https://andygrunwald.com/)

Feedback

EngKiosk Community: https://engineeringkiosk.dev/join-discord
Buy us a coffee: https://engineeringkiosk.dev/kaffee
Email: stehtisch@engineeringkiosk.dev
LinkedIn: https://www.linkedin.com/company/engineering-kiosk/
Mastodon: https://podcasts.social/@engkiosk
Bluesky: https://bsky.app/profile/engineeringkiosk.bsky.social
Twitter: https://twitter.com/EngKiosk

Transkript

Das Transkript wurde automatisiert per Speech-to-Text erstellt und kann daher Fehler enthalten.

Wolfi Gassler (00:00:00 - 00:00:30)

Andi, ich habe mal eine Frage an dich. Und zwar kürzlich habe ich mit meinem Neffen versucht, so einen neuen Computer zusammenzubauen und bin draufgekommen, irgendwie ist dasselbe, was in meiner Jugend noch in war, immer noch in. Man optimiert da irgendwie Grafikkarten, nur jetzt blinkt nur alles bunt in diesem komischen Gehäuse drin. Bei uns waren die Gehäuse noch geschlossen, jetzt sind es so transparente Gehäuse. Warst du auch so jemand, der früher optimiert hat und sich so eine spezielle Grafikkarte gekauft hat, um deine, keine Ahnung, was für Ballerspiele du da immer gespielt hast, früher spielen zu können?

Andy Grunwald (00:00:30 - 00:01:19)

Ja, und ich habe sogar teilweise versucht, damals die Taktfrequenz des Rams irgendwie ordentlich, ich sag mal, auszusuchen in dem Shop und allem drum. Heutzutage frage ich mich, hat das überhaupt damals eine Relevanz gespielt? Habe ich da überhaupt irgendwas gemerkt? Und jetzt habe ich mir aber auch mal moderne Hardware angesehen und habe festgestellt, ach du Kacke, Grafikkarten, die haben inzwischen eigene Stromanschlüsse und sind so groß wie, ich sag mal, ein Mainboard gefühlt. Also das ist alles so ein bisschen explodiert. Inzwischen habe ich davon Abstand genommen, weil das ist mir einfach viel zu kompliziert geworden. Du musst ja wirklich jede Woche irgendwie Toms Hardware Blog lesen, um überhaupt noch mal irgendwo klarzukommen, um zu wissen, was irgendwie so ein bisschen up to date ist. Also ich weiß es nicht mehr, aber ja, hatte ich auch mal. Aber warst du auch so ein Typ mit Wasserkühlung oder warst du immer noch mit Lüftern unterwegs?

Wolfi Gassler (00:01:19 - 00:01:49)

Also mein Neffe hat jetzt eine Wasserkühlung. Keine Ahnung, ob er das wirklich braucht. Ich bezweifle es mal, aber er wollte das unbedingt. Ich glaube, zu meiner Zeit hat es einfach keine Wasserkühlung gegeben, zumindest nicht im leistbaren Rahmen. Also wir hatten ganz klassische Kühler, die sich gedreht haben und die dann auch irgendwann Lärm gemacht haben. Aber meine eigentliche Frage ist ja, ich habe gerade jetzt kürzlich wieder mal auf den Nvidia Aktienkurs geschaut und so in den letzten fünf Jahren hat der ja eine Steigerung gehabt von %. Ist das der Grund, dass jetzt alle spielen, dass Nvidia so reich geworden ist?

Andy Grunwald (00:01:49 - 00:01:59)

Die Beziehung musst du mir jetzt mal sagen. Also die machen ja Grafikkarten und wenn die Firma, die Grafikkarten macht, mehr wert ist, dann spielen alle.

Wolfi Gassler (00:01:59 - 00:02:01)

Ja, das ist jetzt meine Frage an dich.

Andy Grunwald (00:02:01 - 00:02:06)

Du bist ja der Clé, er ist eher Fomo. So nach dem sollte ich vielleicht jetzt spielen.

Wolfi Gassler (00:02:06 - 00:02:07)

Und machst du es?

Andy Grunwald (00:02:07 - 00:02:26)

Ich würde gern, aber ich weiß ganz genau, wenn ich mir eine Konsole kaufen würde, eine Grafikkarte kaufen würde oder ähnliches, dann würde ich da so viel Zeit reinsetzen. Besonders wenn jetzt Civilization wurde gerade, glaube ich, neu released. Aber Die Frage ist ja, Nvidia Grafikkarten, geht es da um Spiele, geht es da um GPU Berechnungen, geht es um AI? Ich habe dieses Buzzword Bingo schon gesagt, um was geht es da?

Wolfi Gassler (00:02:26 - 00:03:43)

Ich wollte schon fast sagen, lebst du unterm Stein, wenn du jetzt mit deinen spielen um die Ecke kommst und nicht von AI sprichst, aber du hast dich noch mal gerettet, Andi. Also es ist ja gerade der große Hype um das ganze AI Game. Und da habe ich mir eigentlich mal gedacht, wir haben überhaupt noch nie irgendwie eine Episode zu GPU gehabt oder zur Programmierung, aber Grafikprozessoren. Und nachdem wir beide ja jetzt wenig in dem ganzen Bereich zu Hause sind, habe ich mir überlegt, OK, wer könnte uns da weiterhelfen und wer ist denn ein absoluter Spezialist in diesem Bereich? Und ich habe mich mal zurück, Carina, die kann mich erinnern, an der Uni vor, schätze mal so 20 Jahren oder so, haben wir teilweise auch so Öffentlichkeitsarbeitsevents gehabt für Jugendliche und so, dass die die Uni kennenlernen. Und da hat es jemanden gegeben, der damals vor 20 Jahren schon an GPUs herumgeschraubt hat und sich überlegt hat, wie kann man auf GPUs programmieren. Das war lang vor der Cuda Zeit. Und dann habe ich mir gedacht, eigentlich brauchen wir genau diese Person, weil die kann uns da weiterhelfen. Und es freut mich sehr, dass diese Person heute zu uns in das Podcast Studio gefunden hat, weil der Peter hat nicht nur vor 20 Jahren an dem Ganzen herumgearbeitet, sondern er arbeitet immer noch und hat jetzt 20 Jahre mehr Erfahrung in dem ganzen GPU Bereich und kann uns daher sicher perfekt weiterhelfen. Und damit willkommen, Peter.

Peter Thoman (00:03:43 - 00:03:58)

Ja, vielen Dank. Ich hilfe euch da hoffentlich und gerne weiter. Und ja, ich habe schon vermutlich länger mit GPUs programmiert und da General Purpose GPU Programming, wie wir es damals genannt haben, gemacht, als es empfehlenswert ist vielleicht.

Andy Grunwald (00:03:58 - 00:04:25)

Ich ziehe meinen Hut vor jedem, der sich länger als fünf oder sechs Jahre mit einem Thema beschäftigt. Und wenn ich höre, dass jemand sich 20 Jahre mit GPU Programmierung beschäftigt, sage ich, OK, wow. Du bist inzwischen Professor in der Forschungsgruppe für verteilte und parallele Systeme an der Universität im schönen Innsbruck. Du hast deine Forschungsinteressen im Bereich GPU Computing, parallele Laufzeitsysteme und Compiler für HPC. Das ist glaube ich, High Performance Computing.

Peter Thoman (00:04:25 - 00:04:25)

Ja, genau.

Andy Grunwald (00:04:25 - 00:05:31)

Du unterrichtest advanced c GPU computing und Performance Oriented Computing. Du bist Mitgründer der PHC GmbH, die sich unter anderem mit der Portierung von Spielen beschäftigt, also ziemlich viel GPU Programmierung. Du machst Consulting im Bereich Optimierung von Algorithmen und warst an einem EU Projekt zur Medikamentenforschung beteiligt, wo ziemlich viel auch GPU Cluster genutzt wurden, zumindest für diverse Berechnungen. Wolfgang hat es gerade angeteasert, das ganze GPU Game machst du schon seit über 20 Jahren, bevor es CUDA gab. Was CUDA überhaupt ist, klären wir gleich noch. Und du schreibst oder hast ein paar Libraries in dem Bereich Parallel Computing, unter anderem eine high Level C API, die es ermöglicht, GPU Compute Cluster anzusprechen und nicht nur einzelne GPUs, die sich Celerity nennt. Und was wir im Vorgespräch noch herausgefunden haben, du bist Reddit Nerd mit knapp über Posts.

Peter Thoman (00:05:31 - 00:05:33)

Das ist auch richtig. Vielleicht hätte ich es nicht erwähnen sollen.

Wolfi Gassler (00:05:33 - 00:05:55)

Ich bin ja froh, dass da irgendwas normales in der Auflistung kommt, weil davor, das habe ich alles eigentlich nicht verstand. Es ist so ganz, ganz weit weg eigentlich, dieser ganze C hardwarenahe Programmierbereich. Also ich bin wirklich froh, dass du da bist, aber wenigstens bist du Reddit User. Das ist high level, da kann ich noch mithalten. Zwar nicht mit den Posts, aber zumindest mit ein paar Posts.

Peter Thoman (00:05:55 - 00:05:58)

Ich bin auch nicht sicher, ob es erstrebenswert ist, unbedingt mitzuhalten.

Wolfi Gassler (00:05:58 - 00:07:06)

Naja, es zeigt auf jeden Fall, dass du auch in der Community sehr stark involviert bist, abseits von den Libraries, die natürlich auch zur Verfügung stehen. Aber gehen wir mal gleich in das ganze Thema rein. Wie ich schon erwähnt habe, der ganze Bereich ist für mich relativ neu und man hört da ja super viele Schlagwörter. Also CUDA ist ja nur eines und von CUDA spricht irgendwie jede Person, wenn man über gpu Programmierung spricht. Aber es gibt natürlich auch ganz allgemein das verteilte Rechnen, parallele Rechnen, High Performance Computing ist auch noch so ein Schlagwort. Jetzt CUDA ist Nvidia, aber es gibt ja auch dann noch AMD irgendwie so, die irgendwo mitspielen, am Rande zumindest, die immer auch wieder behaupten, sie sind schneller als Nvidia. Also gibt es da auch Frameworks dafür. Dann habe ich so aus meiner Studienzeit auch noch so im Kopf openmp, OpenCL, wenn es darum geht, irgendwie verteilt etwas zu programmieren und schneller zu machen. Also ist schon lange her bei mir, aber scheinbar auch immer noch ein Thema. Vielleicht kannst du uns einfach mal so einen Rundumschlag geben, was es denn so gibt am Markt, was diese Begriffe bedeuten, worüber wir heute sprechen und worüber wir nicht sprechen und was jetzt wirklich die gpu Programmierung betrifft.

Peter Thoman (00:07:06 - 00:07:54)

Ja, sehr gerne. Also grundsätzlich, du hast ganz am Anfang angesprochen, verteiltes und paralleles Rechnen. Es gibt da natürlich eine große Überschneidung. Man kann grundsätzlich sagen, dass bei parallelen Rechnen meint man meistens, dass man den gleichen Algorithmus ausführt auf irgendeiner parallelen Architektur. Also sei das jetzt eine GPU oder sei es eine CPU mit mehreren Cores oder was ähnliches. Und bei distributed oder verteilten Berechnungen spricht man meistens von so was wie heutzutage Cloud Computing, wo man wirklich Tasks einfach asynchron irgendwo anders berechnen lässt. Und worum es, wenn wir jetzt von GPUs im speziellen reden, heute wirklich geht, sind mehr Algorithmen, die man einzeln verteilt auf einem parallelen Hardware System wie einem GPU. Dafür gibt es eben sehr, sehr viele Libraries und APIs und das bekannteste davon ist sicher CUDA.

Wolfi Gassler (00:07:54 - 00:08:01)

Das heißt aber, wenn ich jetzt irgendwie so ein Hardware Cluster habe mit Shared Memory, ist das dann distributed oder ist das parallel Programming?

Peter Thoman (00:08:02 - 00:08:10)

Das ist eine sehr spezifische Frage und eine sehr interessante auch vielleicht eine, die ein bisschen heutzutage out of date ist, weil niemand mehr Cluster mit Shared Memory baut.

Wolfi Gassler (00:08:11 - 00:08:14)

Du merkst, wie alt ich bin, im.

Peter Thoman (00:08:14 - 00:08:57)

Vergleich zu mir natürlich gleich. Aber ja, es gab früher diese großen Cluster mit Shared Memory, wo dann schon vorher 10 Jahren TB an RAM haben konnte und so. Es war natürlich sehr spannend. Die waren eigentlich auch immer parallel Systems. Also alles, was an einer Location steht, vielleicht im Endeffekt in einem Rechenzentrum, das wäre dann vielleicht eben wirklich high Performance Computing, was du vorher auch erwähnt hast. Aber es fällt unter diesen Parallel Programming Teil eher als distributed. Also natürlich ist der Speicher dann auch irgendwo distributed in so einem Cluster, aber wirklich von distributed parallelism redet man eigentlich erst dann, wenn es, wie soll man sagen, im geografischen Raum verteilt ist, bis zu einem gewissen Grad und nicht nur lokal.

Wolfi Gassler (00:09:57 - 00:10:02)

Und wenn wir von GPU sprechen, dann sind wir eigentlich immer im Parallel Programming, wenn ich die richtig verstanden habe.

Peter Thoman (00:10:02 - 00:10:11)

Ja, man kann natürlich heutzutage GPUs verwenden in der Cloud, aber da ist Programmieren der GPUs deswegen kein Cloud Programmieren, sondern immer noch parallel Programming.

Andy Grunwald (00:10:11 - 00:10:17)

Wenn ich jetzt mehrere GPUs habe in mehreren Servern, ist das dann parallel Distributed Computing?

Peter Thoman (00:10:17 - 00:10:41)

Technisch korrekt müsste man sagen, das wäre dann Distributed Memory Parallel Computing. Aber Distributed Computing in dem Sinne würde man es wahrscheinlich nicht nennen, weil das eben wirklich sich meistens auf sowas wie Cloud Computing bezieht oder sonst irgendwas, wo es weiter im Raum verteilt ist. Also wenn du jetzt in deinem Computer acht GPUs hast, haben die zwar separate Speicherbereiche, aber sie sind deswegen nicht distributed im normalen Sprachgebrauch, sagen wir mal.

Andy Grunwald (00:10:41 - 00:11:12)

Aber ist das Aufsplitten eines Algorithmus bzw. Der Daten eines, was man da berechnet, macht man das anders, wenn man jetzt parallele Programmierung bzw. Distributed computing macht? Ne, ist doch eigentlich dieselbe Art von Datenaufteilung, oder? Ich meine, du hast einen Teilbereich, auf dem gerechnet wird und der wird halt nur anders verteilt. Entweder übers Netzwerk an eine andere computing Einheit irgendwo oder halt auf einer GPU an anderen, an eine andere Prozessor Unit.

Peter Thoman (00:11:12 - 00:11:56)

Oder aus einer sehr high level Perspektive ist das natürlich irgendwo wahr. Also algorithmisch betrachtet, ja, man würde es so aufteilen, aber in der Praxis trifft es nicht ganz zu, weil der große Unterschied ist eigentlich die Latenz. Und aufgrund dieser Unterschiede in der Latenz gibt es dann ganz unterschiedliche Strategien. Und es gibt einfach Algorithmen, die für eine dieser Vorgehensweisen geeignet sind und welche, die für eine andere geeignet sind. Also im Distributed Computing hat man Latenzen, die zumindest in, sagen wir mal, minimal zumindest Millisekunden gemessen werden. Meistens einige Millisekunden, sagen wir mal, parallel computing Mikrosekunden oder in dem Bereich. Also wir haben dann Faktor 1000 in der Latenz und der ändert einfach komplett, was für Algorithmen man wo ausführen kann.

Andy Grunwald (00:11:56 - 00:12:03)

Und wenn wir von Latenz sprechen, sprechen wir wirklich, okay, ich schiebe jetzt Daten übers Netzwerk und da muss jemand was entgegennehmen und so. Der ganze Hack Mac, der da halt dazu kommt.

Peter Thoman (00:12:03 - 00:12:04)

Genau, genau.

Wolfi Gassler (00:12:04 - 00:12:17)

Ist ja auch der Speicherzugriff, oder? Wenn jetzt plötzlich irgendwie, also die verschiedenen Prozesse können ja nicht so einfach auf denselben Speicherbereich zugreifen, wenn sie verteilt irgendwo in der Welt herum verteilt sind. Eben, ja.

Peter Thoman (00:12:17 - 00:12:28)

Also sobald wir distributed Memory haben, dann ist eigentlich Speicherzugriff ja auch wirklich Versenden von Daten. Also das ist dann mehr oder weniger die gleiche Latenz, beziehungsweise potenziell sogar mehr.

Wolfi Gassler (00:12:29 - 00:12:41)

Jetzt, wenn wir ins Parallel Programming einsteigen. Und ich habe schon ein paar Schlagwörter erwähnt, kannst du uns die mal aufdröseln, was es da so gibt und was dann auch die gpu Programmierung betrifft?

Peter Thoman (00:12:41 - 00:14:07)

Ja, also du hast einige Dinge erwähnt, wie gesagt, CUDA, sehr weit verbreitet von Nvidia für ihre GPUs entwickelt, fürs programmieren ihrer GPUs und inzwischen verwenden sie das als Überbegriff für so viele Technologien, dass wir gar nicht auf alle eingehen können. Aber es ist halt das Softwarepaket, das Nvidia zur Verfügung stellt, was du auch erwähnt hast, was man vielleicht kurz erwähnen sollte ist, OpenMP hat jetzt a priori nichts mit GPUs zu tun, gibt es schon länger als GPU Computing, aber es ist ja ein Interface, um leichter, sagen wir mal, Algorithmen parallelisieren zu können. Früher nur auf CPUs, inzwischen auch auf GPUs. Und das ist ein standardisiertes Interface, was von verschiedenen Compilern implementiert wird. Es gibt dann von diversen Herstellern ihre Konkurrenzprodukte zu CUDA, von AMD wäre das RockM heutzutage und von Intel gibt es Level Zero und es gibt auch noch weitere Dinge von AMD. Also da kann man jetzt genau auf einen Begriff deuten, aber es gäbe auch noch HIP. Und bei Intel gibt es eigentlich kein higher Level Interface, aber sie unterstützen das offene Format SICKL von Kronos und das ist wieder weiterer Begriff, also sollte vielleicht auch darauf eingehen. Vielleicht kennen manche OpenGL Grafik Library für Grafikprogrammierung, das ist auch von der Kronos Gruppe, das ist so Industriekonsortium, die versuchen interessante Standards zu setzen, die dann von verschiedenen Hardwareherstellern implementiert werden können. Und der für GPU Computer von der neue heißt Zykl und der ältere wäre OpenCL.

Wolfi Gassler (00:14:07 - 00:14:16)

Und wenn ich jetzt openmp z.B. verwende, um GPUs anzusprechen, dann greift OpenMP wieder darunter auf Cuda zu oder wie funktioniert das?

Peter Thoman (00:14:16 - 00:14:41)

Das hängt dann davon ab, wie man es kompiliert und was genau für einen Compiler man verwendet und was der dahinter macht. Aber der wird dann potenziell CUDA verwenden oder zumindest das sogenannte PTX Format generieren für die eigentlichen Programme, die am GPU laufen. Das ist intermediate Format für GPU Programme von Nvidia und das gleiche würde generieren für alle anderen unterstützten Hardware architekturen.

Wolfi Gassler (00:14:41 - 00:14:56)

Jetzt hast du erwähnt Interface, OpenMP stellt so ein Interface zur Verfügung. Wie kann man sich das vorstellen? Ist jetzt ein bisschen schwierig natürlich, ohne da irgendwie Code zu zeigen, aber Interface ist für mich einfach so Funktionskopf. Wie funktioniert das in OpenMP oder auch.

Peter Thoman (00:14:56 - 00:15:26)

In CUdA z.B. ja, da unterscheiden sich die Technologien jetzt doch ein bisschen. Also in OpenMP im Speziellen funktioniert es so, dass man mehr oder weniger Annotationen an seinen Code dran schreibt. Also das kann man sich vorstellen so ähnlich wie Kommentare, nur dass der Compiler sie halt interpretieren kann bis zu einem gewissen Grad. Also z.b. wenn man irgendeine Schleife hätte in seinem Programm, dann schreibt man bei OpenMP einfach im einfachsten Fall über die Schleife drüber pragma openmp parallel und dann weiß OpenMP, dass diese Schleife parallel sein soll und parallelisiert sie.

Wolfi Gassler (00:15:26 - 00:15:38)

Das heißt, ich muss gar nicht genau spezifizieren, wie. Das macht im Idealfall die Library für mich, dass dann jeder Run von dieser Schleife in irgendeiner Form auf einem anderen CPU Core oder so gerechnet wird.

Peter Thoman (00:15:38 - 00:15:54)

Das ist die Grundidee von OpenLB. Und für, sagen wir es mal, Programm, wo du in jeder Iteration deiner Schleife genug Arbeit machst und wo du es nur auf CPUs verteilen willst, kann das auch in der Praxis sehr gut funktionieren. Es wird natürlich dann bei schwierigeren Situationen meistens schwieriger, aber das ist die gute Idee.

Wolfi Gassler (00:15:54 - 00:16:04)

Jetzt sind wir bekannt für die Bullshit Bingo Karte, oder in dem Fall ist es weniger Bullshit, aber für die Bingo Karte würde ich mal sagen. Opencl haben wir als Begriff noch offen. Wo kann man den einordnen?

Peter Thoman (00:16:04 - 00:16:28)

Ja, OpenCL ist auch ein Standard von Kronos, also von diesem Industriekonsortium und schon älter, also es gibt fast so lang wie Cuda. Ich würde sagen, es ist jetzt nicht mehr so weit verbreitet und auch nicht so erfolgreich, weil es nie so richtig von allen Hardwareherstellern gut unterstützt worden ist. Wie gesagt, der neuere Standard von dem gleichen Industriekonsortium wäre eben dieses SICK.

Andy Grunwald (00:16:28 - 00:16:42)

Ich finde es schön, weil wenn ich nach OpenCL google, dann kommt als zweites Suchergebnis, bei mir ist OpenCL immer noch relevant, eine Frage auf Reddit und das hast du ja gerade mehr oder weniger bestätigt. Die weitere Frage, die ich habe.

Wolfi Gassler (00:16:42 - 00:16:45)

Und schon wieder neuer Post, den Beta machen kann, relevanter.

Andy Grunwald (00:16:46 - 00:17:19)

Ja, ich leite den gerne weiter für deinen und ersten Antwortpost. Jetzt haben wir hier gerade ziemlich viele Buzzwords gedroppt und wenn ich danach google, wenn ich nach OpenMP google, finde ich auch Open MPI. Ist das die größte Confusion, die man haben kann in der Search Engine Optimization Welt? Open MPI und OpenMP ist nämlich, glaube ich, nicht das gleiche. Das eine wird beschrieben als openmp API Specification for parallel programming und das andere wird beschrieben als Open Source High Performance Computing.

Peter Thoman (00:17:19 - 00:17:57)

Ja, das ist eine sehr interessante Sache, die du da gefunden hast. Eine, über die sich mein Kollege Philipp immer sehr ärgert, der diese Sachen unterrichten muss direkt. Es ist so, MPI ist ein Standard, um Distributed Memory Cluster zu programmieren und hat nichts mit OpenMP zu tun, natürlich a priori. Openmpi ist eine Implementierung von diesem Standard und hat bis auf einen Charakter den gleichen Namen wie OpenMP, aber ansonsten nichts damit zu tun. Aber nicht gar nichts, was eigentlich besser wäre, sondern sind trotzdem beide für etwas relativ ähnliches, aber grundverschiedenes gebaut. Also ja, etwas verwirrend.

Andy Grunwald (00:17:57 - 00:18:04)

Ja, ich klassifiziere das unter naming is hard oder ich verschwende einfach keinen weiteren Gedanken auf Naming, aber.

Wolfi Gassler (00:18:04 - 00:18:09)

Oder es war absichtlich, um da die Klicks oder die Besucher abzugrasen.

Peter Thoman (00:18:09 - 00:18:16)

Beide dieser Technologien sind so alt, dass ich sagen würde, sind so sehr auf SEO gegangen, das hat es damals noch nicht gegeben. Weiß eher nicht.

Andy Grunwald (00:18:16 - 00:18:57)

Ich nehme an, alle hatten nur Gutes im Sinne, deswegen unterstellen wir da nichts Böses. Meine Frage ist jetzt aber, das bedeutet immer, wenn ich etwas auf meiner Grafikkarte laufen lassen möchte, auf der GPU, muss ich eins dieser Frameworks oder APIs verwenden. Also kurzum, und das wäre dann die Folgefrage, jedes Spiel, was ich irgendwie habe, hat das CUDA oder openmp oder. Klar, OpenGL hattest du gerade schon genannt. Ich weiß gar nicht, ob OpenGL und. Ne, OpenGL war der Nachfolger von Directd oder sowas, gab es ja auch noch mal. Naja, meine Frage ist eigentlich, brauche ich die unbedingt, oder. Also hat jedes Spiel irgendwie eine dieser Libraries integriert?

Peter Thoman (00:18:57 - 00:19:23)

Nein, also es gibt sehr, sehr wenig Spiele in der Geschichte von Spielen, die irgendeins dieser Libraries integriert haben, weil das alles GPU Compute Libraries sind und nicht Libraries für Grafik. Also natürlich kommen GPUs aus der Grafikschiene, aber es ist dann eben, hat sich herausgestellt, dass man auch andere Berechnungen ganz gut drauf machen kann. Und dadurch sind dann diese ganzen Libraries und Technologien, von denen wir jetzt gesprochen haben, entstanden. Spiele verwenden grundsätzlich hauptsächlich Rendering APIs, aber.

Andy Grunwald (00:19:23 - 00:19:45)

Ich meine so die Berechnung von Raytracing und Co. Kann man doch eigentlich auch relativ einfach, und das ist jetzt hier in Anführungszeichen mit relativ. Also für mich ist auf der GPU gar nichts, einfach weil ich damit noch nie gearbeitet habe. Aber so Raytracing ist doch auch nur klassische Berechnung. Ich schieße strahlen durch den Raum und gucke, treffe ich irgendwas und wann treffe ich es und so.

Peter Thoman (00:19:45 - 00:20:13)

Du könntest es mit diesen APIs implementieren, das wäre dann aber sehr langsam im Vergleich, weil GPUs haben spezielle Hardwareeinheiten, um so etwas wie Raytracing durch eine klassische Grafik mit Rasterisation zu beschleunigen. Und diese spezielle Hardware könntest du nicht verwenden mit diesen generischen Compute APIs, von denen wir jetzt bisher gesprochen haben. Dafür bräuchte man sowas wie, es gibt eigentlich nur zwei Möglichkeiten, entweder DirectX oder Vulkan, was ein weiterer Kronos Standard ist, aber in dem Fall für GPU Grafik Programmierung.

Wolfi Gassler (00:20:13 - 00:20:21)

Jetzt muss ich nur noch mal, weil Andi da OpenGL eingeworfen hat, also OpenGL ist schon noch die offene Variante und hat mit DirectD wenig zu tun, oder?

Peter Thoman (00:20:21 - 00:20:23)

Oder habe ich falsch im Kopf? Das ist richtig.

Wolfi Gassler (00:20:23 - 00:20:27)

Also bin ich schon noch mit meinem Open Source Gedanken im richtigen Universum.

Peter Thoman (00:20:27 - 00:20:52)

Die Relation zwischen OpenGL und Vulkan ist auch so, dass OpenGL eigentlich mehr oder weniger bis zum gewissen Grad von Vulcan abgelöst wurde. Nicht zu 100, %, weil sehr viel näher an der Hardware und bis zu einem gewissen Grad komplexer ist. Aber heutzutage, wenn man high End Grafikprodukt entwickelt, dann verwendet man entweder Walken oder Direct d oder Metal, wenn man auf Apple programmiert. Habe ich noch nie verwendet, aber das.

Andy Grunwald (00:20:52 - 00:21:06)

Ist wie gesagt, hartes Wortgame. Wenn wir gerade haben wir OpenMP, OpenMPI gesagt und jetzt gerade haben wir über OpenGL und OpenCL gesprochen. Also ich weiß nicht, so langsam könnte das auch Absicht sein, aber kannst du.

Wolfi Gassler (00:21:06 - 00:21:30)

Mal erklären, jetzt hast du schon gesagt, es ist aus der Gaming Welt gekommen, wann ist es entstanden und warum hat man überhaupt dann auf GPUs gesetzt? Also es gibt die CPU und die kann ja auch schnell rechnen und das meiste funktioniert ja auf der CPU. Also warum gab es überhaupt die große Änderung, dass man da auf GPU plötzlich gegangen ist? Weil es ist ja auch eine ganz andere Architektur.

Peter Thoman (00:21:30 - 00:22:11)

Ja, also ich würde sagen, wie du schon ganz am Anfang mal kurz erwähnt hast, vor inzwischen ungefähr 20 Jahren haben eigentlich in erster Linie Forscher mal festgestellt, dass diese Grafikkarten, dass jetzt zum ersten Mal damals beliebige Berechnungen in sogenannten Pixel Shadern machen können. Also man ist draufgekommen, d Rendering, man will immer interessantere Eigenschaften von D Objekten darstellen dann im Endeffekt. Und um Programmierern da zu erlauben, das besonders flexibel zu machen, hat es ihm dann die Möglichkeit gegeben, diesen Prozess zu programmieren, mit am Anfang extrem kurzen Programmen, die halt maximal, sagen wir so was wie 20 Hardware Instruktionen haben dürfen oder so.

Wolfi Gassler (00:22:11 - 00:22:19)

Kannst du mal erklären, was Shader grundsätzlich ist? Weil für mich kommt ja von Schatten, oder? Das Wort.

Peter Thoman (00:22:19 - 00:22:56)

Ja, also wenn du dir vorstellst, du willst irgendein Objekt darstellen in D Rendering, dann hat das eine Oberfläche und du musst irgendwie beschreiben, wie diese Oberfläche im Endeffekt dargestellt wird. Ganz einfach gesprochen, was für Farbe kriegt das Pixel ganz am Ende, das auf dieser Oberfläche sich befindet. Und eben um dieses Pixel einzufärben in einer flexiblen Art und Weise, hat man sogenannte Shader erfunden, was eben diese kurzen Programme sind, die beschreiben, wie das Pixel eingefärbt werden soll, auf Basis von so Inputs wie einer Textur z.B. natürlich, aber so was wie, aus welcher Richtung kommt das Licht her und wie soll das weiterverarbeitet werden?

Wolfi Gassler (00:22:56 - 00:23:10)

Und das Programm wird dann wirklich für jeden einzelnen Pixel einmal aufgerufen. Also wenn ich da so eine hd Auflösung habe, ich weiß nicht, wie viele Millionen Pixel das dann da sind, dann wird das kleine Programm x Millionen mal aufgerufen, um ein Bild zu generieren.

Peter Thoman (00:23:10 - 00:23:42)

Ja, genau so ist es auch, aber eigentlich nur, wenn dein Programm extrem optimiert ist, weil es ist so, dass du das nicht nur für jedes Pixel aufrufen musst, was du im Endeffekt siehst, sondern auch für alle, die verdeckt sind. Also aus der Perspektive wird es sogar noch sehr viel öfter aufgerufen im Normalfall, aber ja, und das ist auch genau der Punkt. Deshalb, weil sie dafür ausgelegt waren, solche Berechnungen auf so vielen Pixeln durchzuführen, eignen sich GPUs eben irgendwie von der Hardware heraus inhärent gut, extrem datenparallele Berechnungen durchzuführen, wie z.b. auf diesen Pixeln.

Wolfi Gassler (00:23:42 - 00:23:48)

Und wie viel Berechnungen können da dann durchgeführt werden oder wie viel Pixel können parallel berechnet werden?

Peter Thoman (00:23:48 - 00:24:27)

Das ist eine etwas kompliziertere Frage, weil um sie wirklich korrekt zu beantworten, müssen wir jetzt sagen, wie viel Pixel werden parallel in der Hardware gleichzeitig berechnet, was von sehr vielen Faktoren abhängt. Man startet beim GPU grundsätzlich aus der User Perspektive, also Programmierer meine User Perspektive, alle Pixel gleichzeitig. Also vom Programmiermodell her geht man davon aus, dass alle diese Berechnungen gleichzeitig laufen. Wirklich in der Hardware läuft dann gewisser Bruchteil dieser Berechnungen wirklich parallel, aber die Hardware kann extrem schnell zwischen den verschiedenen Berechnungen hin und herschalten und man kann das eigentlich von außen nicht beeinflussen.

Wolfi Gassler (00:24:27 - 00:24:38)

Und in welcher Größenordnung bewegt sich das ganze? Also klassischer, ich weiß nicht, kann man es vergleichen, CPU kann nur eine Sache parallel rechnen oder ich habe halt sechs Cores, können sechs Sachen parallel berechnet werden?

Peter Thoman (00:24:38 - 00:24:49)

Ja, also von modernen high End GPU bewegt sich das im Bereich, sagen wir mal hunderte bis tausende Pixel, die wirklich parallel gleichzeitig laufen.

Andy Grunwald (00:24:49 - 00:25:12)

Das bedeutet, so eine Grafikkarte hat dann auch so eine Art Scheduler, weil du hast gerade gesagt, okay, man schmeißt jetzt einfach alle Millionen Pixel irgendwie rein und klar, das Ding hat irgendwie nur eine worker Kapazität, nenne ich das jetzt mal ganz simpel. Und die Grafikkarte bzw. Die GPU vielleicht sogar, das weiß ich jetzt gerade nicht, ob das die GPU wirklich ist oder ob das jetzt irgendwie ein anderer Chip ist, der hat dann so eine Art, sag mal Scheduler wie bei der CPU eigentlich.

Peter Thoman (00:25:12 - 00:25:39)

Ja, genau. Also jede Recheneinheit, es ist ja auch so, dass man sagen kann, bei der GPU, sie hat sozusagen mehrere Cores, nur jeder dieser Cores kann dann noch einmal sehr viel parallel berechnen in so einer Art vektorisierten Vorgehensweise. So ähnlich wie auch ein CPU Core, nur noch viel paralleler. Und jeder dieser Cores hat eigentlich eine Hardware Scheduling Einheit, die aktiv die wirklichen Pixel oder auch Berechnungen, je nachdem was man gerade darauf macht, auf diese Hardware scheduled.

Wolfi Gassler (00:25:39 - 00:25:46)

Dann wäre jetzt meine naive warum verwendet man überhaupt noch CPUs? Wenn GPUs viel schneller sind, könnte man ja nur mehr GPUs verwenden.

Peter Thoman (00:25:46 - 00:26:55)

Sehr gute Frage. Und es läuft eben aufs Gleiche raus, dass die GPUs dafür entwickelt wurden, eine Sache extrem gut zu können, nämlich diese Pixel einfärben, original betrachtet. Und was man dafür z.B. braucht, ist extrem hoher paralleler Durchsatz von Berechnungen. Was man dafür in Bezug auf die Hardwarearchitektur benötigt, ist sehr hohe Speicherbandbreite z.B. was man dafür nicht unbedingt braucht, ist z.B. sehr niedrige Latenz bei Zugriffen. Was man auch nicht braucht, ist, dass man ganz leicht in z.B. nebeneinander liegenden Pixeln verschiedene Pfade durchs Programm wählen kann. Also dass z.B. in einem Pixel irgendein if true wird und im anderen false. Das kann ab und zu mal passieren, aber normalerweise laufen die alle sehr konvergent durchs Programm durch. Und deswegen sind GPUs sehr gut, wenn man diesen extrem hohen Grad an Parallelismus mit relativ einfachen Zugriffsmustern hat, relativ einfachen Algorithmen. Aber sie werden potenziell extrem langsam im Vergleich zu CPUs, wenn man komplexeres Zugriff Muster hat oder ein Algorithmus, wo man nicht vorhersehen kann, in welche Richtung der als nächstes geht, also wie das Programm sich verhält.

Wolfi Gassler (00:26:55 - 00:26:59)

Aber heißt es dann, dass ich kein if programmieren darf in dem Sinne?

Peter Thoman (00:26:59 - 00:27:16)

Du darfst ein if programmieren, aber wenn dein if dann wirklich, sagen wir mal, in einem Schachbrettmuster in jedem Pixel anders sich verhält, dann kannst du auf dem GPU halt potenziell plötzlich nur mehr zweiunddreißig der Performance haben, die du sonst gehabt hättest. Und am CPU ist es eh egal.

Andy Grunwald (00:27:16 - 00:27:24)

Das liegt dann am Caching, oder woran liegt das? Oder dass die möglichen Ergebnisse wirklich so komplett unterschiedlich sind oder die möglichen Berechnungssteps? Oder woran liegt das?

Peter Thoman (00:27:24 - 00:28:07)

Das liegt primär daran, dass die Programmierung von GPUs gaukelt dir eigentlich mehr oder weniger vor, dass du diese ganz tausenden an Cores jetzt ansprichst, aber in Wirklichkeit sind es eigentlich keine Cores, sondern nur einzelne Lanes in einer Vektoreinheit, wie man sie am CPU hätte. Und die müssen eigentlich alle das gleiche machen, weil was anderes kann die Hardware nicht. Also sobald du dann im Programm in eine Situation reinlaufen würdest, wo diese zwei und dreiig oder 64 oder was auch immer Einheiten in dieser großen Vektoreinheit was verschiedenes machen, läuft das Programm nicht mehr effizient, weil es muss ja dann entweder hintereinander in der Zeit durchführen oder sonst sich irgendwas überlegen. Der Scheduler am GPU bedeutet das jetzt.

Andy Grunwald (00:28:07 - 00:28:34)

Praktisch gesprochen, wenn ich jetzt einen komplexen Algorithmus habe, der ziemlich viele verschiedene Pfade hat, dass dieser dann, und innerhalb der ziemlich verschiedenen Pfade werden immer andere Berechnungsteile ausgeführt, wirklich andere Operationen, dass dieser dann wohlmöglich nicht so performant abläuft, weil der halt, wie du sagtest, schachbrett mustertechnisch, je nachdem welcher Pfad da gerade angesprochen wird, halt komplett anders verlaufen kann.

Peter Thoman (00:28:34 - 00:29:15)

Ja, also wenn du wirklich einen Algorithmus hast, der sehr viel verschiedene Pfade erstens hat und das ist wichtig, auch nimmt, weil es hängt schon davon ab, was passiert wirklich zur Laufzeit dann, ja, dann wird er vermutlich nicht besonders gut performen. GPU, natürlich kannst du da verschieden vorgehen, um das vielleicht zu optimieren. Also z.b. wenn wir es wieder von Pixel sprechen oder eben auch von den Threads, die da im Endeffekt am GPU laufen. Wenn die, die nebeneinander ausgeführt werden, den gleichen Pfad durchs Programm wählen, dann können sie wieder effizient laufen. Also wenn du irgendwie die Möglichkeit hast, die anders anzuordnen, dann könnte ich vielleicht doch bessere Performance und GPU erzielen, aber das ist dann absolut nicht mehr trivial. Auf jeden Fall.

Wolfi Gassler (00:29:15 - 00:29:34)

Du hast zuerst erwähnt, dass Speicherbandbreite hoch ist, aber die Speicherlatenz nicht niedrig oder auch hoch in dem Fall, also negativ hoch. Wie funktioniert das? Weil grundsätzlich muss das ja schon schnell sein, da wird ja auch viel herumgeschaufelt wahrscheinlich. Also warum ist der Latenz dann unwichtig?

Peter Thoman (00:29:34 - 00:30:06)

Genau, könnte diese Frage vermutlich nur jemand beantworten, der wirklich in der Hardware drin ist, was es nicht mein Bereich ist, aber grundsätzlich einfach so, dass man eben speicher Hardware im Endeffekt optimieren kann, auch den Speichercontroller auf Durchsatz oder auf Latenz. Natürlich ist beides wichtig, aber wie alles im Engineering gibt es dann Trade off und GPUs gehen mehr in die Richtung Trade off, mehr Bandbreite, höhere Latenz und CPUs gehen mehr in die Richtung Trade off, weniger Bandbreite, dafür niedrigere Latenz und das im ganzen Speichercontroller und auch im Cache und dem Speicher selbst.

Wolfi Gassler (00:30:06 - 00:30:15)

Aber GPU ist schon noch mal schneller als jetzt, keine Ahnung, RAM Zugriff oder so. Also da liegen dann schon noch mal welten dazwischen, oder?

Peter Thoman (00:30:15 - 00:31:02)

Da muss ich jetzt ein bisschen ausholen. Gerne. Also CPUs und GPUs haben beide Cache bzw. Auch mehrere Levels an Cache. GPUs und CPUs haben auch beide RAM. Also wenn wir jetzt den RAM am GPU den VRAM sozusagen auf der einen Seite haben und auch den klassischen Hauptspeicher auf der CPU Seite. Und grundsätzlich normalerweise in einem normalen PC System ist es so, dass der CPU signifikant mehr RAM zur Verfügung hat, aber weniger Bandbreite zu diesem RAM und dass der CPU pro Thread, den er ausführt, signifikant mehr Cash zur Verfügung hat. Der GPU hat gesamt viel mehr Cash, das ist richtig, aber er führt ja auch gleichzeitig sehr, sehr viel mehr Threads aus. Das heißt, jeder Thread, der am GPU läuft, hat eigentlich Zugriff auf weniger Cash.

Wolfi Gassler (00:31:02 - 00:31:15)

Und was ich mich noch erinnern kann, so aus alten Tagen, was es auch immer geheißen hat, dass sie auf der GPU nicht springen kann. Also das ist auch sehr tödlich, wenn ich irgendwo im Speicher herumspringe. Stimmt das noch?

Peter Thoman (00:31:15 - 00:31:55)

Das hat früher sehr gestimmt, also da war es richtig tödlich und inzwischen stimmt es eigentlich auch immer noch. Also wenn du wirklich die maximale Bandbreite erzielen willst am GPU von Speicherzugriffen, dann brauchst du sehr spezifisch designte Speicherzugriffe, die optimal den Speichercontroller ausnutzen. Aber die Auflagen sozusagen, um diese hohe Bandbreite zu erzielen ans Programm, sind weniger kompliziert oder streng heutzutage, als wir jetzt noch vor 10 Jahren oder sowas waren. Also man hat da als Programmierer hat man es etwas leichter, gute Performance aus dem Speichercontroller zu holen am GPU heute als vor 10 Jahren, sagen wir mal.

Andy Grunwald (00:31:55 - 00:32:16)

Jetzt hört man immer, dass CPUs immer schneller, schneller, schneller wurden. Und da stelle ich mir natürlich gerade die Frage, wenn wir jetzt kein AI Modell trainieren wollen, was ist denn eigentlich mal ein guter Use Case für eine GPU? Und wenn ich jetzt keine Grafikengine ändern möchte, sondern wenn wir einen klassischen Algorithmus darauf laufen lassen, was würdest du sagen ist der Stereotypenalgorithmus, den man einer GPU geben würde?

Peter Thoman (00:32:16 - 00:33:00)

Ja, also der Stereotypenalgorithmus würde ich sagen, der trifft jetzt nicht mehr zu, weil du schon gesagt hast, du willst keine AI drauf laufen lassen. Und der Stereotypenalgorithmus wäre natürlich Matrix Multiplikation und das was die Leute heutzutage AI nennen, ist auch Matrix Multiplikation. Also der läuft natürlich gut drauf. Ansonsten auch viele Algorithmen, die jetzt so in der Simulation verwendet werden, in der klassischen wissenschaftlichen, physikalischen Simulation z.B. oder chemischen Simulation, die sogenannte Stencil algorithmen sind. Also eigentlich Algorithmen, wo man auf gewisse, den zukünftigen Zustand an einen gewissen Punkt ausrechnen, auf Basis von drumherum liegenden Punkten oder sowas. Also Dinge mit vorhersehbaren Speicherzugriffen und Berechnungen mehr oder weniger.

Wolfi Gassler (00:33:00 - 00:33:19)

Also das klingt aber alles nach irgendwie so räumlichen Konzepten immer. Auch wenn ich jetzt irgendwas wissenschaftliches vorher berechnen will, da ist immer irgendwie eine Matrix oder d Raum, d Raum. Also es ist schon irgendwie. Kann man immer wieder auf dieses Grafikproblem zurück mappen oder gibt es auch andere Bereiche, die man gut machen könnte?

Peter Thoman (00:33:19 - 00:34:05)

Also man kann natürlich auch, wie man z.b. jetzt an diesen large language models sieht, man kann ja auch einen Satz im Endeffekt in der Matrix mappen, wenn man sich genug anstrengt. Aber ja, man muss seine Probleme grundsätzlich in d d oder d, sagen wir mal Speichergefüge einbetten können irgendwie. Ansonsten wird die Performance sehr viel schlechter. Also auch so was wie wenn das Problem ist da von Baumstruktur arbeitet oder sowas, dann willst du im Endeffekt trotzdem irgendwie diese Baumstruktur einbetten können in den eindimensionalen Speicher z.B. und dann halbwegs effizient darauf zugreifen können. Und je weniger direkt, sagen wir mal, sich ein Problem in diese klassischen D d Muster einordnen lässt, umso schwieriger wird es, ein effizientes GPU Programm für das Problem zu schreiben.

Andy Grunwald (00:34:05 - 00:34:10)

Ich stelle mir gerade die kann man nicht jedes Problem auf ein räumliches Problem rummappen?

Peter Thoman (00:34:10 - 00:34:35)

Also wenn wir jetzt gerade vom Speicherzugriff sprechen, dann ist die Antwort jedes Problem ist immer eine schwierige Frage. Sagen wir jedes Problem, was du auf dein CPU ausrechnen kannst. Ja, weil natürlich im Endeffekt ist dein Speicher auch nur Sequenz von durchnummerierten Bytes. Also es ist ja d Datenstruktur. Aber die Sprünge sozusagen werden dann halt so komplex, dass es irgendwann sich nicht mehr effizient auf den GPU übertragen lassen würde. Da ist immer die Unterscheidung zwischen was ist möglich und was ist in irgendeiner Weise sinnvoll.

Andy Grunwald (00:34:35 - 00:34:42)

Naja, nehmen wir jetzt einfach mal das da gibt es ja dieses Traveling Salesman Problem. Kann man jetzt dieses.

Wolfi Gassler (00:34:42 - 00:34:49)

Ich sag mal, Andi, wenn du so gescheit um die Ecke kommst mit so Beispielen, kannst du das jetzt erklären auch noch?

Andy Grunwald (00:34:49 - 00:35:06)

Das ist glaube ich, was ist der optimalste Weg, alle Punkte zu besuchen? Ist das richtig? Ein kombinatorisches Optimierungsproblem? Du hast keine Ahnung, irgendwie 15 Städte in Deutschland. Was ist der optimalste Weg, alle Städte zu besuchen? Das ist glaube ich der Trail. Das ist glaube ich das Problem, richtig?

Wolfi Gassler (00:35:07 - 00:35:09)

Hätte jetzt so spontan gesagt. Klingt richtig.

Andy Grunwald (00:35:10 - 00:35:45)

So und das funktioniert zwar vielleicht mit 15 Städten, ne? Was ist die kürzeste Route? Genau, ich glaube, was die kürzeste Route von. Wenn du alle Punkte berechnen möchtest. Und ich glaube bei 15 Städten gibt es schon, ich habe gerade hier Wikipedia sogar auf eins, zwei, drei, 43 Milliarden Möglichkeiten so und dann geht das natürlich mit 16 Städten ziemlich hoch, alles gut. So und das ist natürlich ein relativ schwieriges Problem für eine CPU. Und meine Frage ist jetzt, wenn wir von jedem Problem sprechen, könnte man das jetzt nicht irgendwie auch auf Matrix, auf eine Matrix Kalkulation ummünzen, nennen wir es mal GPU laufen lassen?

Peter Thoman (00:35:45 - 00:37:01)

Ja, also grundsätzlich würde ich damit sagen, das ist nicht nur ein schwieriges Problem für CPU, das ist einfach ein schwieriges Problem als solches. Das sagt seine Komplexitätskategorie sozusagen komplett unabhängig von jeder Hardware aus. Das ist eines der interessanten Dinge von diesem Problem. Und aus der gpu Sicht jetzt insbesondere ist die Frage, kann man das Problem parallelisieren oder noch präziser, kann man den besten Algorithmus parallelisieren, mit dem man das Problem berechnen kann? Weil es ist manchmal der Fall, ja man könnte einen parallelen Algorithmus finden, z.B. in dem Fall könnte man den parallelen Algorithmus finden, man probiert alle Möglichkeiten, die es gibt, parallel aus und rechnet und schaut, welche am besten funktioniert. Das lässt sich sehr leicht parallelisieren, dauert bis zum Hitzetod des Universums, zu viele Städte macht, also das wird nichts bringen, dass es sehr effizient parallel läuft, sondern es wird halt nur etwas kürzer laufen lassen, weil das Problem ist halt, das Problem wächst mit einem nicht linearen Faktor und die Faktor an GPUs, die du oder GPU korst, die du drauf werfen kannst, ist immer linear. Also das bringt eigentlich nichts im Endeffekt, du musst irgendwie einen effizienteren oder smarteren Algorithmus oder in dem Fall Heuristik finden. Und das Problem mit smarteren Heuristiken ist dann, dass die meistens zu mehr Branching in deinem Code führen und deswegen dann nicht besonders gut für ein GPU geeignet sind.

Andy Grunwald (00:37:01 - 00:37:20)

Da ich nicht so smart bin, um den Algorithmus zu optimieren, habe ich mir eigentlich gedacht, ich schmeiße Hardware drauf und da man jetzt wie gesagt die CPU relativ schnell ausmaxen kann damit, habe ich gedacht, OK, GPUs klingt interessant, schmeiß ich einfach mal GPUs drauf. Also das ist so meine, da komme ich auch erstmal ein Stück weit, wie weit weiß ich dann jetzt auch nicht.

Peter Thoman (00:37:20 - 00:37:37)

Das ist das Problem mit der Komplexitätsklasse von so Algorithmen, dass du dann, ja, du kannst, du kannst zehnmal so viel GPUs draufschmeissen, dann kannst du vielleicht eine Stadt dazu tun oder wahrscheinlich auch nicht, wenn du schon zu viele hast, weil die Größe vom Problem halt viel schneller wächst, als die Anzahl GPUs, die du drauf werfen kannst.

Andy Grunwald (00:37:37 - 00:37:50)

Ja, was ist das nun mal für eine Komplexitätsklasse? Ist das NP vollständig? Da verlässt sich mein Studium schon wieder. Das ist jetzt nicht so die Problemklasse, in der ich mich in der Industrie normalerweise mit beschäftige.

Wolfi Gassler (00:37:50 - 00:37:52)

Ist es NP complete? Kann sein, oder?

Peter Thoman (00:37:52 - 00:38:03)

Ja, bin jetzt relativ sicher. Ist auch nicht mein Hauptthema natürlich, weil wir beschäftigen uns mehr mit Dingen, die man berechnen kann auf GPUs und GPU Clustern. Sinnvoll, aber ja, NP schwer ist es.

Wolfi Gassler (00:38:04 - 00:38:46)

Wobei da gibt es auch nochmal einen Unterschied zwischen Complete und Hard, je nachdem, wie man dann Subklassen bilden kann. Egal, geht in eine ganz andere Richtung. Meine Frage wäre eher praktischere Frage, bei OpenMP hast du schon erwähnt, da kannst du einfach Annotationen machen und dann wird deine Schleife automatisch im Idealfall irgendwie super parallelisiert, auf mehrere Cores aufgeteilt und es funktioniert. Jetzt klingt das ganze ja, ich muss das in irgendeinen Raum mappen für GPU, sie muss mir da Sachen überlegen. Das klingt für mich wesentlich komplizierter, damit ich da irgendwie etwas auf der GPU parallelisieren kann. Bin ich da richtig oder gibt es da auch Möglichkeiten, wenn ihr einen Algorithmus habt mit ein paar Annotationen schon das ganze zu parallelisieren auf einer GPU?

Peter Thoman (00:38:47 - 00:39:33)

Also es gibt grundsätzlich eben die Möglichkeit, OpenMP sogenanntes Offloading für Accelerators zu verwenden, wo die Idee wäre, dass es genau das gleiche macht, aber du schreibst halt zwei Wörter mehr hin oder so und dann kriegst du ein Programm auf der GPU. Das kann in speziellen Fällen gut funktionieren, aber eher selten. Grundsätzlich würde ich sagen, wenn du in deinem Programm z.B. zwei verschachtelte Schleifen hast, die irgendwas ausführen, was parallel ausgeführt werden kann, dann hast du ja mehr oder weniger schon einen zweidimensionalen Raum, nämlich den Iterationsraum von diese zwei schleifen, indem du deine Berechnung machst und das wäre dann der Raum, den du auf dem GPU mappst. Also es klingt vielleicht im ersten Moment etwas komplexer, als es eigentlich ist, weil in der Praxis läuft es doch darauf hinaus, parallele Schleifen sozusagen zu finden oder Schleifennester.

Wolfi Gassler (00:39:33 - 00:39:40)

Das heißt, die Matrixmultiplikation ist ja auch genau sowas mit zwei Schleifen, oder? Wenn ich das richtig im Kopf habe.

Peter Thoman (00:39:40 - 00:39:45)

Ja, drei. Aber du würdest wahrscheinlich parallelisieren über die äußerste oder über die äußeren zwei.

Andy Grunwald (00:39:45 - 00:39:47)

Hast du das gerade Schleifennester genannt?

Peter Thoman (00:39:47 - 00:39:53)

Ja, ich denke, das ist der deutsche Begriff, weil ich sehr selten in Deutsch über diese Dinge spreche, aber ja, was ist auf Englisch?

Andy Grunwald (00:39:53 - 00:39:55)

Nested loop sehr wahrscheinlich, oder?

Wolfi Gassler (00:39:55 - 00:39:56)

Ah, okay.

Peter Thoman (00:39:56 - 00:39:58)

Was ist das sonst auf Deutsch? Schleifen?

Andy Grunwald (00:39:59 - 00:40:04)

Keine Ahnung, ich habe den deutschen Begriff noch nie gehört und noch nie genutzt, aber ich finde ihn fast eigentlich ganz cool. Schleifen Nest.

Peter Thoman (00:40:04 - 00:40:10)

Ich weiß nicht, ob das stimmt. Wie gesagt, in Deutsch über diese Dinge sprechen ist sowieso schwierig. Ich kann mich noch erinnern, da gibt.

Wolfi Gassler (00:40:10 - 00:40:14)

Es kein Adjektiv, oder bei der ersten.

Peter Thoman (00:40:14 - 00:40:26)

Vorlesung, die ich gehört habe zum Thema Grafikprogrammierung, die war damals noch von einem Professor, der alles auf Deutsch erklärt hat, hat er von der Parkettierung gesprochen und es hat für mich sehr lange gebraucht, bis ich verstanden habe, dass es um Tessellation geht, aber ja.

Andy Grunwald (00:40:27 - 00:40:38)

Aber heißt das dann im Umkehrschluss, dass jetzt alle Algorithmen, die jetzt nicht im ein, zwei dreidimensionalen Raum stattfinden, schlechte Use Cases für GPUs sind?

Peter Thoman (00:40:38 - 00:41:14)

Nein, das kann man so überhaupt nicht sagen. Also in der Physik z.b. gibt es viele Probleme, die halt in irgendeinem siebendimensionalen Raum oder sonst wo berechnet werden, eigentlich von der Semantik her, wo das Problem passiert, aber im Endeffekt sich relativ effizient auf d oder d oder dreidimensionale Datenstrukturen mappen lassen. Und das ist meistens auch schon passiert von den Physikern, damit sie überhaupt in einem Programm sinnvoll damit umgehen können, unabhängig jetzt von GPU Programmierung oder nicht. Also man kann diese Dimensionalität sozusagen von der Berechnung nicht unbedingt direkt auf das Problem und die konkrete Dimensionalität von dem Problem ummünzen.

Andy Grunwald (00:41:14 - 00:41:29)

Gibt es denn irgendwie so eine Daumenregel, ab welchem Workload es überhaupt Sinn macht, sich mit einer GPU zu beschäftigen? Denn ich hatte ja gerade gesagt, CPUs werden immer schneller und so weiter und wenn ich jetzt 1000 Datensätze hab, die jage ich vielleicht auch relativ so schnell durch durch meine CPU.

Peter Thoman (00:41:29 - 00:42:25)

Ja, es gibt da denke ich zwei Dinge, die man beachten sollte grundsätzlich einerseits in den Grad an Parallelismus und andererseits die Menge an Berechnungen pro Speichermenge, die man durchführt. In Bezug auf den Grad an Parallelismus, wenn man nicht, sagen wir mal mindestens tausende oder besser zehntausende unabhängige parallele Berechnungen hat, dann rentiert es sich nicht, die wirklich auf dem GPU zu portieren. Und andererseits bezüglich Datenmenge, insbesondere wenn man im Moment schon ein Programm hat, das halt am CPU läuft und man hat seine ganzen Daten im CPU, dann müsste man diese ganzen Daten ja erst einmal auf den GPU bringen, um dort irgendeine Berechnung zu machen. Und diese Übertragung ist nicht besonders schnell, also zumindest im Vergleich zu normalen Speicherzugriffen und so weiter. Und das bedeutet, man muss zumindest ordentliche Menge an Berechnungen machen, damit sich das rentiert. Also wenn etwas auf dem CPU in sagen wir mal Millisekunden oder Sekunden durchläuft, dann rentiert es sich meistens nicht, das auszulagern.

Andy Grunwald (00:42:25 - 00:43:12)

Vor kurzem hatten wir eine Episode, da haben wir über ein wissenschaftliches Paper gesprochen, das nannte sich Scalability, but at what costs and costs stand for configuration that outperforms a single thread? Da ging es also um den Overhead, der gemacht werden muss, um eine Berechnung auf mehreren Threads auszuführen und ab wie viel Threads dann die Berechnung einen Single thread outperformt. Also kurzum, was ist der kalkulatorische Overhead? Und jetzt hatten wir gerade von dem Grad des Parallelismus oder der Parallelisierung gesprochen. Gibt es sowas auch? Also misst du sowas auch, ab wann es sich das überhaupt lohnt, die Berechnung aufzusplitten? Weil im Endeffekt, wenn du die Berechnung parallel durchführst, das Ergebnis muss ja am Ende schon noch irgendwie wieder zusammen merchen in der Regel.

Peter Thoman (00:43:12 - 00:44:03)

Ja, das hängt jetzt natürlich erst einmal davon ab, was macht der Algorithmus eigentlich? Also wenn wir jetzt wieder von dieser physikalischen Simulation sprechen, das Ergebnis eigentlich auch bis zu gewissen Grad paralleler Datensatz, weil er z.b. den Zustand von jeder Zelle im Raum oder sowas beschreibt. Aber grundsätzlich ist zusammen merchen von Ergebnissen kein großes Problem, weil das kann der GPU sehr schnell machen. Das Problem ist, mehr große Datensätze zum GPU zu transportieren oder wieder zurück zum CPU zu transportieren. Also das wäre der größere Unterschied. Und diese grundsätzliche Frage, was ist der Overhead oder wie groß ist der Overhead im Vergleich zum besten sequenziellen Algorithmus, das geht ein bisschen zurück auf das, was ich früher gesagt habe, nämlich das, was sich nicht nur dafür interessiert, wie gut kann man das jetzt parallelisieren, sondern wie gut kann man den besten sequenziellen Algorithmus parallelisieren. Wenn man den Algorithmus viel schlechter machen muss, um dann gut parallelisieren zu können, dann kann es sein, dass sich das nicht mehr rentiert.

Andy Grunwald (00:44:03 - 00:44:11)

Ach, also ich meine, viele Leute, die haben einen Hammer und versuchen eine Schraube reinzuballern. Funktioniert auch, ist halt nur nicht ganz so geil.

Peter Thoman (00:44:11 - 00:44:29)

Ja, das gab es am Anfang, wo gpu Programmierung ganz neu war, hat man ganz gut Paper publizieren können, wo man einfach irgendein Algorithmus paralysiert hat, wenn er nicht state of the artist und dann halt sagt, schau, jetzt läuft es hundertmal so schnell wie ein CPU, das ist doch super toll. Da hat niemand so genau nachgefragt. Inzwischen, zumindest in der, sagen wir mal, Research Community, ist da etwas die Leute wieder etwas kritischer.

Wolfi Gassler (00:44:30 - 00:45:13)

Es war auch zu meinen Zeiten in der Datenbank Forschungsgruppe, wir haben uns auch ein GPU Cluster oder halt so einen Server, GPU Server angeschafft, haben uns gedacht, da kann man sicher mit Datenbanken auch was cooles machen, war aber doch schwieriger, als man sich so denkt. Aber jetzt kommen wir mal zum ganz klassischen Workload, also so neuronale Netze. Kannst du mal erklären, warum es eigentlich gut passt, neuronale Netze einfach zu berechnen auf der GPU, beziehungsweise vielleicht bevor wir in dieses Thema einsteigen, kannst du mal, weil jetzt haben wir so viel über Matrixmultiplikation gerechnet und das ist vielleicht, was man sich noch grundsätzlich vorstellen kann, kannst du mal so ganz schnell skizzieren, wie sowas dann abläuft, so eine Matrixmultiplikation, was es da für Teile gibt, wenn ich das ganze auf der GPU parallelisiere?

Peter Thoman (00:45:13 - 00:45:31)

Die einfachste Methode zur Parallelisierung wäre natürlich, dass du sozusagen über die aus die Elemente im Output parallelisierst. Also du musst einen Wert für jeden Wert in der Output Matrix berechnen und für jeden dieser Output Werte würdest du dann einen separaten Thread oder sowas starten am GPU.

Wolfi Gassler (00:45:31 - 00:45:43)

Das heißt, ein Pixel wäre im Prinzip ein Wert in dieser, im Output, in der Resultatmatrix. Vielleicht Andy, kannst du mal die Matrixmultiplikation erklären? Was eine Matrixmultiplikation ist, wie gesagt, mit.

Andy Grunwald (00:45:43 - 00:46:09)

Solchen theoretischen Mitteln beschäftige ich mich in der Praxis in der Regel nicht. Ich habe das, vielleicht mal kurzer Schwank aus meiner Jugend, ich hatte Statistik eins und Statistik zwei in meinem Bachelorstudiengang und ich glaube Statistik eins habe ich dann, da kam nämlich 11 Matrix Multiplikation vor, ich glaube, da bin ich mit einer 3,7 durchgerutscht und da habe ich dann mit bestandenes bestanden abgehakt. Also da kannst du mich jagen, aber ich las lieber sein.

Wolfi Gassler (00:46:09 - 00:46:26)

Also ich hab zur Vorbereitung ehrlich gesagt auch noch mal nachschauen müssen, wenigstens bist du ehrlich. Ja eben. Also wenn ich es richtig im Kopf habe, multipliziert man immer die Zeile mit der Spalte, bildet da dann die Summe und das ist dann der Wert in der finalen Result Matrix.

Peter Thoman (00:46:26 - 00:46:45)

Ja, das ist richtig, Danke, gut vorbereitet. Aber wenn man sich das so vorstellt, wie du es gerade erklärt hast, dann sieht man ja auch irgendwie, dass das relativ parallelisierbar ist, weil das Resultat in einem Wert der Ausgabematrix hängt nicht vom Resultat an irgendeiner anderen Stelle ab.

Wolfi Gassler (00:46:45 - 00:47:06)

Und das heißt, ich würde dann meine zwei Matrizen, also die multipliziert werden, komplett in den Speicher legen. Das ist eine d Matrize oder mal zwei halt, also zwei Matrizen und die lege ich einfach in Speicher und ein kleines Programm weiß dann, welche Elemente miteinander multipliziert werden müssen und addiert werden müssen.

Peter Thoman (00:47:06 - 00:47:15)

Genau, du hast mehr oder weniger ein kleines Programm pro Ausgabeelement, das berechnet genau die Berechnung, die du gerade beschrieben hast, wo es die Elemente der Zeilen mit den Spalten multipliziert.

Andy Grunwald (00:47:16 - 00:47:20)

Und der Speicher wird read only zu allen Berechnungen geshared oder wird der kopiert?

Peter Thoman (00:47:20 - 00:48:02)

Ja, der Speicher wäre grundsätzlich mal einfach im GPU RAM abgelegt, aber da kommen wir dann auch zum Problem, wenn man es so implementieren würde, dann wäre es ziemlich gut parallel und wird potenziell auch schon schneller laufen als auf dem CPU jetzt. Aber du liest halt sehr häufig die gleichen Elemente aus dem Speicher, die du dann wieder verwendest und da wird es dann komplizierter. Also da kommt es dann zu so Dingen wie Blocking der Berechnung und zum effizienten Verwenden von Cache, dadurch, dass man auf diese Blöcke in einer besseren Reihenfolge zugreift. Also das wäre dann, wie man optimierte Matrix Matrix Multiplikation implementieren würde für GPUs. Muss man natürlich nicht, weil dafür gibt es Libraries von den Herstellern, die das mit sehr hoher Effizienz machen.

Wolfi Gassler (00:48:03 - 00:48:32)

Und wenn ich mir das jetzt noch mal vorstelle, muss es Programm, das da abläuft pro Zelle im Resultat. Das Programm sollte ja gleich sein, aber das Programm muss ja dann irgendwie Parameter bekommen, auf wo es gerade operiert. Also sind es dann irgendwie so klassische Parameter und jeder Pixel bekommt dann die Location und weiß dann durch, keine Ahnung, weiß automatisch welche Zeile, welche Spalte und holt sich dann die Daten einfach aus dem Speicher.

Peter Thoman (00:48:32 - 00:49:11)

Also die ganz konkrete Art, wie das Programm diese Information gibt, hängt von der jeweiligen API ab. Aber grundsätzlich in jeder API entspricht das Ausführen von so einem sogenannten Kernel Programm am GPU ein Aufruf, dem man d, d oder d Range gibt, in der er ausgeführt werden soll. Also du sagst jetzt z.b. du willst dieses gpu Programm ausführen auf einer 10 mal 10 range und das kriegt dann als Parameter entweder in ein Register oder in einer magischen Variable oder sonst irgendwie den x Index und den y Index in deinem Raum, den du abdecken willst, rein. Und auf Basis von diesen Indizes kannst du natürlich dein Speicherzugriff machen.

Wolfi Gassler (00:49:11 - 00:49:22)

Aber ich kann nur einen Kernel definieren. Also ich kann jetzt nicht sagen, ich habe tausend verschiedene Programme, sondern ich habe einen Kernel und der wird dann mit anderen Parametern jeweils auf meinen Pixeln oder Zellen in dem Fall aufgerufen.

Peter Thoman (00:49:22 - 00:49:44)

Du kannst natürlich viele Kernels haben, aber nur ein Kernel wird parallelisiert, zumindest auf einem Teil von GPU. Früher hätte ich sagen können, auf dem ganzen GPU läuft immer nur ein Kernel. Inzwischen ist es nicht mehr so. Also es kann moderner GPU auf verschiedenen Teilen verschiedene Kernels zu einem Zeitpunkt ausführen, aber alle müssen auf jeden Fall genug Parallelismus bieten, dass sie sinnvoll die Hardware verwenden können.

Wolfi Gassler (00:49:44 - 00:50:02)

Okay, jetzt haben wir die Matrix Multiplikation, was ja so das einfachste ist, was es eigentlich gibt. Dann gehen wir mal zu irgendwas, was eigentlich grundsätzlich schon niemand mehr versteht, neurale Netze oder niemand, aber wenige Leute. Warum sind die gut geeignet für GPUs oder warum sind GPUs gut geeignet für neuronale Netze?

Peter Thoman (00:50:02 - 00:50:45)

Besonders, ja, ich bin jetzt auch nicht Experte für neuronale Netze, sagen wir mal so, aber ich weiß grundsätzlich, wie die Programme mit GPUs arbeiten. Und der Grund ist im Endeffekt, dass die meisten Berechnungen, die da passieren, Matrix Multiplikation sind. Also deswegen eignen sich die GPUs gut. Sie eignen sich gut für Matrixmultiplikation, eignen sie sich auch gut dafür von der Hardware her. Insbesondere sehr wichtig, vor allem im Ausführen jetzt von so Sprachmodelle oder sowas, ist Speicherdurchsatz, weil die auf extrem viel Speicher zugreifen müssen, relativ wenig Berechnungen drauf machen. Und auch da sind die GPUs natürlich mit ihrem Durchsatz optimierten Speicher relativ gut dabei. Also da kann man halt TB pro S Speicherbandbreite haben, die man danach braucht.

Andy Grunwald (00:50:45 - 00:52:28)

Ich finde es wirklich, wirklich, wirklich faszinierend, denn wenn man mal aus der Perspektive aus dem Internet spricht, aus der Webwelt, dann gibt es da Leute, die schrauben in PHP ein Kontaktformular in WordPress und wir unterhalten uns jetzt gerade über den Overhead, dass man ein paar Zahlen aus einer Spalte und aus einer Zeile öfters liest. Das erinnert mich so irgendwie immer an so Diskussionen, man hat jetzt irgendein Programm in C, da kennt ihr sehr wahrscheinlich diesen mehr oder weniger Trick, dass man, wenn man struct definiert, dass man dann die struct fields, dass die Reihenfolge da eine gewisse Anordnung haben muss, um halt das Memory Padding vermeiden. Also hat man String und Int und allem drum und dran und dann je nachdem, wie man das ordert. Und bisher habe ich in meiner Karriere sehr, sehr, sehr oft gesagt, also wenn wir uns mit diesem Problem beschäftigen müssen, dann haben wir ganz andere Probleme. Und jetzt mache ich einen Podcast darüber, okay, ja, diese Zahl wird ein paar mal öfter gelesen und dieses paar mal ist dann sehr wahrscheinlich sechs oder 7 Millionen mal, stelle ich. Aber ich finde es faszinierend, auf welche Art von, ich sag mal, Optimierung Leute kommen müssen, bzw. Wie ganz genau sich einzelne Algorithmen wirklich angesehen werden müssen. Das bringt mich irgendwie halt zu der Frage, wie viele Leute gibt es eigentlich, die gpu Programmierung, ich sag mal in Anführungszeichen, wirklich auf dem Kasten haben, weil wenn ich dir zuhöre, es gibt ja super viele Anti patterns und Fallstricke, dass dann vielleicht sogar später die Komplexität eines gpu Algorithmus alles andere irgendwie in den Schatten stellt. Dann ist man ja nur noch damit beschäftigt, den ganzen Kram da laufen zu lassen, anstatt wirklich mal zum Ergebnis zu kommen.

Peter Thoman (00:52:28 - 00:53:43)

Ja, also das ist eigentlich ein guter Einwand und sehr wichtige Fragestellung bei der ganzen gpu Programmierung. Wie kann man es einfacher gestalten? Grundsätzlich würde ich aber mal sagen, man muss jetzt nicht jeden Algorithmus so im Detail optimieren, wie Matrix Multiplikation optimiert wurde. Bzw. Matrix Multiplikation ist ja auch schon sehr gut optimiert von den Hardwareherstellern und es gibt auch eine Reihe von anderen Algorithmen, den so Standard Libraries wie z.B. den ganzen CUDA Libraries bereits implementiert sind. Und wenn man dann sein Problem oder auch nur Teilproblem von seinem Problem, was sehr hohen Performance einfluss hat, auf einen dieser existierenden Algorithmen runterbrechen kann, was häufig der Fall ist, dann kann man vom GPU profitieren, ohne sich mit diesen Details zu sehr auseinandersetzen zu müssen. Diese Detailoptimierung denke ich natürlich schon eher was für Experten und auch wie du richtig angemerkt hast, erhöht es natürlich dann den Maintenance Aufwand enorm. Insbesondere auch deswegen, weil solche Detailoptimierungen gerade besonders anfällig dafür sein, dass sie mit neuerer Hardware wieder nicht mehr funktionieren bzw. Pessimisations sind statt Optimisations. Also wenn sich an der Hardware zu viel ändert, dann ist eine gewisse Blockgröße z.B. plötzlich eher negativ, weil es immer so in den Cache reinpasst oder sowas.

Andy Grunwald (00:53:43 - 00:54:46)

Wie ist das denn, wenn man jetzt auf einer GPU programmiert mit der Heterogenität der Grafikkarten selbst? Also ich meine, Grafikkarten entwickeln sich ja auch weiter, da gibt es vielleicht auch jetzt andere Chip Architekturen mit anderen Instruktionen und Auf einmal hat man da, ich sag mal, einen Cluster mit wirklich verschiedenen Grafikkarten. Man versucht da seinen Algorithmus laufen zu lassen und der eine ist vielleicht ein bisschen langsamer, weil er die Instruktionen irgendwie nicht kann oder virtualisiert betreiben muss oder ähnliches. Ist das in der Praxis ein Problem oder sagst du, ne, inzwischen gibt es ein Standard Instruktion Set, was hier GPU kann und das ist eigentlich völlig egal, gib mir einfach irgendeine andere Grafikkarte. Oder sagst du, ja, ab dem Jahr 2015 kamen nur noch Grafikkarten mit diesem Instruktionssatz auf den Markt. Also ich denke halt gerade auch an Cloud Hardware, die ich dann einfach mieten kann. Ich nehme einfach irgendwelche GPU Cluster bei Amazon, weil ich jetzt gerade keinen top 500 Computer im Keller von meiner Uni stehen habe. Also wie ist das da mit der Hardware?

Peter Thoman (00:54:46 - 00:55:47)

Ja, also ich denke, die ganze Frage, das ist der große Bereich, in dem die Frage diskutiert wird in der Forschung, nennt sich Performance Portabilität. Und die Performance Portabilität auf GPUs, gerade zwischen verschiedenen Herstellern, ist nicht unbedingt besonders gut. Aber ich würde trotzdem sagen, die meisten Optimierungen und insbesondere eigentlich der komplexeste Teil bei einem größeren Programm, nämlich das Mapping vom Original Algorithmus zu irgendwas, was grundsätzlich auf GPUs funktioniert, dieser Teil der Arbeit ist unabhängig davon, was für spezielle gpu Architektur jetzt wir gerade ansprechen wollen, die Detailoptimierungen. Je mehr man ins Detail geht, umso hardware spezifischer wird man. Und da muss man sich dann irgendwann überlegen, wie sehr man das für sein spezielles Problem machen will, weil vielleicht die letzten 5 % Performance rausholen auf einer Hardware, macht es potenziell auf andere Hardware sogar langsamer oder auch auf zukünftiger Hardware vom gleichen Hersteller. Und das macht man eben nur für sowas wie Matrix Multiplikation, wo man sich dann halt weltweit ein paar gw Sport, wenn es 5 % effizienter ist, aber.

Wolfi Gassler (00:55:47 - 00:56:09)

In der Praxis verwenden dann Leute irgendwie Cuda oder verwenden die dann sowieso Abstraktionen. Und du hast ja auch Simsical und Celerity, das ist richtig ausspricht. Verwendet man dann sowas, was komplett alles oder alles, aber viel abstrahiert, oder ist schon durchaus noch üblich, dass man runtergeht auf eine tiefere Ebene und Cuda direkt anspricht?

Peter Thoman (00:56:09 - 00:56:46)

Also ich würde sogar sagen, Celerity steht auf so einer hohen Ebene, dass es jetzt wirklich der klassische Anwendungsprogrammierer direkt verwenden würde. Und wenn wir jetzt natürlich von dieser Anwendung sprechen, die im Moment sicher den Großteil aller GPUs weltweit verwendet, nämlich die ganzen ML Anwendungen, dann verwenden die meisten Leute im Endeffekt tensorflow, was Python Interface ist und dich natürlich von diesen ganzen Dingen, die wir jetzt besprochen haben, relativ abschirmt. Also du gibst dann mehr oder weniger an, was du willst, das passiert mehr, als was wirklich passiert auf den jeweiligen GPUs.

Wolfi Gassler (00:56:46 - 00:56:57)

Und kannst du kurz erklären, was Celerity macht und Simsical, nachdem wir da den Autor quasi von diesen Bibliotheken oder zumindest Co Autor am Mikrofon sitzen haben?

Peter Thoman (00:56:57 - 00:57:52)

Ja, ich versuche mich da jetzt kurz zu halten, aber Simsical ist hauptsächlich eben für Programmierer gebaut, die GPU Programme schreiben wollen, aber das gpu Programm auch sinnvoll testen wollen und auch während Development schnelle Feedback Cycles haben wollen. Weil ein Problem von diesen ganzen GPU Interfaces ist, dass wenn wir jetzt, die müssen das Programm ja nicht nur für CPU generieren, sondern auch speziell für GPU und es dauert meistens relativ lang und wenn man es programmiert, dann will man Sekunden, idealerweise Feedback Cycle haben und nicht Minuten, weil dadurch wird man sehr viel unproduktiver, meiner Erfahrung nach. Und das ist eines der Dinge, für die SimSicl entwickelt wurde. Also die Idee von Simsicl ist, man implementiert Sickl, aber ohne GPU Support. Was jetzt natürlich super seltsam klingt, weil es ist der ganze Sinn von Sickl, dass man damit seine GPUs programmieren kann. Aber die Idee ist, man führt es einfach auf sein CPU aus, kriegt dann sehr schnelles Feedback und hat sehr viel besseren Support dafür, seine Programme debuggen zu können.

Wolfi Gassler (00:57:52 - 00:57:55)

Und ZYCL ist eine Abstraktionsebene, habe ich das richtig verstanden?

Peter Thoman (00:57:55 - 00:58:01)

Genau eines dieser Interfaces, die wir am Anfang besprochen haben, nämlich der neue Kronos Standard für gpu Programmierung.

Andy Grunwald (00:58:01 - 00:58:05)

Aber wie darf ich mir das vorstellen? Ist das dann ein gpu Simulator?

Peter Thoman (00:58:06 - 00:58:41)

Nein, nicht voll, weil also wirklich den GPU auf der Hardware Ebene zu simulieren, wird ja viel zu lange dauern, sondern die Idee ist mehr, es simuliert die Ausführung vom Programm auf der Ebene vom Standard, wie der vorschreibt, dass das Programm ausgeführt werden sollte. Es hat aber auch so Features für Testing, wie z.B. dass es simulieren kann GPUs mit verschiedenem Grad an Vektorparallelismus oder sowas, damit dann de Programm ausgeführt wird in verschiedenen Reihenfolgen der Threads zueinander und so weiter, die auf Probleme aufmerksam machen können, weil du irgendeinen Fehler in der Parallelisierung hast oder sowas.

Andy Grunwald (00:58:42 - 00:58:58)

Jetzt höre ich diese Podcast Episode und denke mir, ich verstehe nur Spanisch, ich mag Fremdsprachen, ich möchte Spanisch lernen. Was gibst du mir an die Hand, damit ich meinen ersten Algorithmus auf meiner lokalen GPU auf meinem Apple MacBook laufen lassen kann? Also was würdest du mir empfehlen? Wo fange ich an?

Peter Thoman (00:58:58 - 00:59:06)

Das ist eine sehr schwierige Frage für mich, weil ich keine Ahnung habe, was wirklich alles auf Apple im Speziellen funktioniert, weil Apple natürlich immer sehr speziell sein muss.

Wolfi Gassler (00:59:06 - 00:59:19)

Apple hat irgendwas, du darfst ja nicht so ernst nehmen mit seiner nischen Hardware, die niemand hat. Also gehen wir mal von einer sinnvollen Hardware aus, die man sich da in der Cloud so mietet oder so mit CUDA oder keine Ahnung was läuft.

Andy Grunwald (00:59:19 - 00:59:24)

Dann nimm mal ein IBM SyncPad, was ich hier noch rumfliegen habe. Das hat bestimmt auch irgendwie eine Grafik.

Wolfi Gassler (00:59:24 - 00:59:26)

Die haben keine GPUs, glaube ich zumindest.

Andy Grunwald (00:59:26 - 00:59:58)

Meinst oder von mir aus auch irgendeine AWS GPU Kiste. Also ich möchte, ich habe jetzt ein Stück Code, von mir aus auch, und jetzt gehe ich echt weit weg, in JavaScript, Python, oder was weiß ich nicht. Vielleicht nicht in C. Vielleicht nicht in C, vielleicht noch nicht gerade in Rust, aber von mir aus auch in Rust, ist mir auch egal. Was gibst du mir in der Hand, dass ich das jetzt mal testen kann und dass ich so einen kleinen Wow Effekt habe, so innerhalb von drei, 4 Stunden ein bisschen rumprobieren und dann ich möchte mal den Wow Effekt haben. Geil, ich habe jetzt eine Berechnung der GPU.

Peter Thoman (00:59:58 - 01:01:10)

Ja, also wenn du jetzt dein Python Programm hast, dann gibt es so Dinge wie Number, die dir erlauben, GPUs aus sehr relativ high level Python Perspektive zu verwenden und damit kannst du relativ schnell diesen Wow Effekt haben. Also wir haben dieses Jahr gefördertes Bootcamp gehabt mit mehreren Firmen, die eben genau mit solchen Codes zu uns gekommen sind, mit ihrem beiden Prototyp oder sonst irgendwas und die halt sich gefragt haben, wie kann man das schneller machen? Und da kann man schon innerhalb, sagen wir mal, idealerweise weniger Stunden oder vielleicht weniger Tage wirklich so ein Production Code, zumindest irgendein Teil davon parallelisieren am GPU. Also das wäre eine Möglichkeit. Number wenn man jetzt Python Code im speziellen hätte, wenn man klassischer mehr mit C oder sowas unterwegs ist, dann würde man vermutlich für den Anfang doch zu Nvidia gehen wollen, weil die haben sehr gutes Lernmaterial, die haben da auch viel rein investiert und sehr gute Tools zum debuggen und so weiter, was man jetzt bei anderen Hardwareherstellern, bei anderen APIs häufig vermisst. Also für mehr so klassisches GPU programmieren will man wahrscheinlich doch zumindest für den Anfang zu CUDA gehen und später dann vielleicht, wenn man sie ein Produkt haben will, so etwas, was auf mehr als nur einem Hardwarehersteller funktioniert.

Wolfi Gassler (01:01:10 - 01:01:17)

Und wenn ich SQL lernen will, oder gibt es da sinnvolle Dokumentation oder wie kann ich damit losstarten?

Peter Thoman (01:01:17 - 01:01:38)

Ja, also für SICKL gibt es inzwischen sehr viel sinnvollere Dokumentation als noch vor, sagen wir mal einiger Zeit. Es gibt die SICKL Academy, das wird gesponsert unter anderem von Intel und da haben auch sogar wir unseren ganz kleinen Teil beigetragen. Das heißt, an der Uni Sickl Academy findet man einfach, wenn man es sucht und die hat mehrere. Das geht eigentlich ziemlich vom Anfang von GPU Programmierung los, halt anhand von SICK.

Wolfi Gassler (01:01:38 - 01:01:54)

Wir verlinken natürlich das ganze auch von Nvidia, aber auch die Cyclical Academy natürlich in den Shownotes. Jetzt muss ich dir aber trotzdem noch mal fragen, Celerity oder wie spricht man es richtig? Celerity. Okay, was macht das ganze? Ist das auch hilfreich?

Peter Thoman (01:01:54 - 01:02:42)

Okay, also greifen wieder die Story von vorher auf. Du hast jetzt angefangen GPUs zu programmieren und nach zwei Tagen denkst du, das ist das beste, seid geschnitten Brot, wir müssen damit weitermachen. Du willst jetzt nicht nur einen GPU verwenden, weil du denkst, wenn du mit einem GPU schon so viel schneller bist, wie schnell bist du dann mit 10 oder mit 100 oder mit 1000 GPUs? Und da würde jetzt Celerity ins Spiel kommen. Also die Idee von Celerity ist, dass du dich nicht damit auseinandersetzen musst. Es ist eh schon schwierig genug, haben wir uns gedacht, GPUs zu programmieren. Du musst dich nicht auch noch damit auseinandersetzen, wie verteilst du jetzt dein Programm auf mehrere GPUs, sondern du schreibst so, als hättest du einen GPU wie Zickl. Und Celerity verteilt dann dein Programm hoffentlich nahezu optimal auf GPU Cluster. Das wäre die Idee.

Wolfi Gassler (01:02:42 - 01:02:49)

Ich hoffe, der Andi wird es verwenden, wenn er mal ein Problem hat, was er auf mehrere GPUs über einen Cluster hinweg optimieren kann.

Andy Grunwald (01:02:49 - 01:03:22)

Ja, das habe ich täglich und ich denke mir jeden Abend, genau dieses Problem habe ich. Aber ich hatte einfach nur noch keine Zeit, mir meine eigene Library zu schreiben. Meine Frage ist ja, ich habe gerade schon diese Box angesprochen, Grafikkarten und GPUs als Commodity für den End Consumer und nicht nur für die großen Leute, die da Chips im großen Stil kaufen, wie Musk und Co. Wo geht es hin in den nächsten Jahren mit dem GPU computing? Wird das alles Massenware? Berechnen wir bald nichts mehr auf der CPU? Was sagt deine Glas Google Peter?

Peter Thoman (01:03:22 - 01:05:00)

Predictions are difficult, particularly about the future, aber grundsätzlich, GPU Computing bleibt uns sicher erhalten. Für den AI Hype im Speziellen wird es sehr spannend, weil da gibt es natürlich extrem viele Interessenten, die spezialisiertere Hardware als GPUs spezifisch für diese Anwendungen bauen. Und ich denke vor allem für die Inference, also den Teil, wenn man mal ein Modell trainiert hat und dann versucht auszuführen, wo im Moment die meisten gpu Stunden reingebraten werden, weil immer wenn man irgendjemand auf ChatGPT geht, nachher braucht es ordentlich GPUs. Ich denke, vor allem für diesen Teil wird sich wahrscheinlich eher spezialisiertere Hardware etablieren, außer es ändert sich groß was am algorithmischen Fundament dieser ganzen AI Dinge. Für mehr den Research Teil, das Trainieren und so weiter, denke ich, bleiben auch da weiterhin wahrscheinlich GPUs sehr, sehr relevant, weil sie einfach ein bisschen flexibler sind als diese hochspezialisierte Hardware. Und für andere Berechnungen, von denen es geht, haben, so Simulationen und so weiter, denke ich auch, dass GPU Compute weiterhin sehr relevant bleiben wird. Ich denke nicht unbedingt, dass es sich. Inzwischen sind GPUs schon sehr viel flexibler als sie vor 15 Jahren waren. Ich denke nicht, dass sich GPUs noch sehr stark weiter zu noch flexiblerer Programmierung hin entwickeln werden. Einfach aus dem Grund, weil man dann irgendwann die Vorteile im Hardware Design verliert durch diese etwas einfachere Hardware, die erlauben, höhere Performance zu erzielen für eben diese speziellen Anwendungen als auf dem CPU. Also irgendwo bleibt diese Trennung dann doch, denke ich, erhalten.

Andy Grunwald (01:05:01 - 01:05:44)

Aber ich meine, die Spezialisierung von Chips, die geht ja schon seit längerem voran. Also ich meine, Google hat ja schon vor einigen Jahren diese TPUs announced tensor processing units. Und ich glaube, Apple baut auch eigene Chips und also jeder große Hyperscaler. Ich glaube, Amazon hat jetzt gerade auch auf den letzten Reinvent im November, Dezember eigene Chips vorgestellt. Und wenn wir da an Spezialisierung denken, heißt das dann, mal ganz plakativ gesprochen jetzt und von sehr generalisiert, dass man diese Chips, dass sie wirklich ganz knallhart auf Matrizenoperationen, ich sag mal, optimiert sind. Nehmen wir das mal als Beispiel, aber dafür jetzt keine Grafikengine mehr rendern können.

Peter Thoman (01:05:44 - 01:05:57)

Ja, oberflächlich sagen wir mal gesprochen, aber eigentlich korrekt ist es so. Also die sind halt noch spezialisierter GPUs schon relativ spezialisiert, aber ist ja noch sehr viel spezialisierter auf die Bedürfnisse von eben diesen ML Workloads.

Andy Grunwald (01:05:57 - 01:06:08)

Verstehe. Da muss ich ja in Zukunft wirklich aufpassen, wenn ich GPUs kaufe, wie wenn ich Schneeketten für meine Reifen kaufe. Da muss ich nämlich auch immer ganz, muss ich immer dreimal nachgucken, passen die hier, passen die hier nicht.

Wolfi Gassler (01:06:08 - 01:06:18)

Ja, aber Andi, das ist ihr habt keinen Schnee in Duisburg und keine Berge. Du brauchst genauso wenig Schneeketten, wie du irgendwie spezielles GPU Teil brauchst für deine Workloads.

Andy Grunwald (01:06:18 - 01:06:37)

Also es gilt wie immer im Haben ist besser als brauchen. Was ist, wenn ich ganz plötzlich in einer Situation eine Matrizenoperation auf einer GPU wird mich jetzt weiterbringen. Ich sage es dir, der neue Thermomix wurde gerade vorgestellt, der wird bestimmt auch Matrizenpokalkulation drin haben.

Wolfi Gassler (01:06:37 - 01:06:42)

Der ist sicher auch AI Optimist und schlag mich tot.

Andy Grunwald (01:06:42 - 01:07:04)

Ich war noch nicht auf der Landingpage, aber bestimmt. Peter, vielen lieben Dank, dass du uns wenigstens einen kleinen Einblick in die gpu Programmierung bieten konntest. Wir hatten schon im Vorgespräch kurz darüber gesprochen, dass es natürlich auch in einer Stunde sehr, sehr schwierig ist, dieses ganze Thema zu besprechen. Denn das, was du lehrst, das geht über 40 Stunden, 50 Stunden, was hattest du gesagt?

Peter Thoman (01:07:04 - 01:07:11)

Ja, hängt vom speziellen Fach ab, aber ja, in dem Bereich. Also ein Semester lang, jede Woche 3 Stunden oder sowas.

Andy Grunwald (01:07:11 - 01:08:58)

Genau. Und dann mit Slides und ich glaube, du hattest auch gesagt, nur die Einführung dauert irgendwie zwei bis 4 Stunden mit etlichen Slides. Also deswegen können wir natürlich. Ich bin mir gar nicht sicher, ob wir schon an der Oberfläche kratzen oder nur das Thema mal ganz kurz gemalt haben. Aber ich habe dir auf jeden Fall zu danken. Ziemlich viele Begriffe sind hier durch den Podcast geflogen, die mir zuvor noch nie was gesagt haben. Und es ist auch ein bisschen peinlich, dass ich mich geäußert habe, dass ich nicht aus dem Stegreif die Matrizen berechnung erklären konnte. Aber nur gut, das stempel ich unter dem Bereich ab. Man muss nicht alles wissen, man muss nur wissen, wo man nachschlägt. Die ganzen Buzzwords und unglaublich komplizierten Wörter, die wir genannt haben, die finden natürlich alle auch in den Shownotes. Und alle Links zu CUDA, OpenGL, Open CL, den Nvidia Self Pace Trainings der Zykl Akademie, aber auch Links zu Simzycle und Celerity. Wie ist das? Wie spreche ich das richtig aus? Celerity findet ihr natürlich auch alle in den Shownotes, falls ihr da mal ein bisschen rumspielen wollt. Und ja, innerhalb von vier bis 8 Stunden kriegt er bestimmt irgendwo einen kleinen Algorithmus auf einer GPU zum Fliegen. Und vielleicht hat CUDA ja auch ein Beispiel Algorithmus, den einfach mal deployen und vielleicht könnte man auch einen Wettbewerb machen. So der erste, der weiß ich nicht, irgendwas JavaScript technisches auf irgendeiner GPU laufen lässt und bei uns in der Community vorstellt, der kriegt irgendwie eine Engineering Chaos Taste oder so. Das fände ich mal ganz interessant als kleinen Abend Hackathon. Peter, hast du noch irgendetwas, was du unseren Hörerinnen und Hörern mitgeben möchtest zum Thema GPUs, was du schon die ganze h sagen wolltest?

Peter Thoman (01:08:58 - 01:09:04)

Vielleicht, wenn man sich die Zeit nimmt, kann es ganz interessant sein und wenn man Puzzles mag, besonders.

Wolfi Gassler (01:09:05 - 01:09:18)

Okay, also du motivierst alle. Scheint ein leichter Einstieg zu sein. Superleicht, aber ist auch eine gute Zusammenfassung, aber deckt sich mit meinem Bild von der ganzen Welt, muss ich zugeben.

Andy Grunwald (01:09:19 - 01:09:46)

Das war's von uns. Wenn ihr Feedback zu der Episode habt, wisst ihr, wo ihr dies abladen könnt. In unserer Diskussion auf Social Media oder schreibt uns eine e Mail. Auch wenn ihr Feedback an Peter habt oder mit ihm in Kontakt treten wollt, dann auf der einen Seite googelt ihn natürlich, auf der anderen Seite könnt ihr das Feedback natürlich auch gerne an uns senden und wir leiten es liebend gern weiter. Das war's von uns. Vielen Dank, Peter und wir sagen tschüss, bis zum nächsten Mal.

Peter Thoman (01:09:46 - 01:09:46)

Tschüss.

Wolfi Gassler (01:09:46 - 01:09:46)

Ciao.

#184 GPU Programmierung - von CUDA bis OpenMP mit Peter Thoman

Shownotes / Worum geht's?

Feedback

Links

Sprungmarken

Hosts

Feedback

Transkript

Wolfi Gassler (00:00:00 - 00:00:30)

Andy Grunwald (00:00:30 - 00:01:19)

Wolfi Gassler (00:01:19 - 00:01:49)

Andy Grunwald (00:01:49 - 00:01:59)

Wolfi Gassler (00:01:59 - 00:02:01)

Andy Grunwald (00:02:01 - 00:02:06)

Wolfi Gassler (00:02:06 - 00:02:07)

Andy Grunwald (00:02:07 - 00:02:26)

Wolfi Gassler (00:02:26 - 00:03:43)

Peter Thoman (00:03:43 - 00:03:58)

Andy Grunwald (00:03:58 - 00:04:25)

Peter Thoman (00:04:25 - 00:04:25)

Andy Grunwald (00:04:25 - 00:05:31)

Peter Thoman (00:05:31 - 00:05:33)

Wolfi Gassler (00:05:33 - 00:05:55)

Peter Thoman (00:05:55 - 00:05:58)

Wolfi Gassler (00:05:58 - 00:07:06)

Peter Thoman (00:07:06 - 00:07:54)

Wolfi Gassler (00:07:54 - 00:08:01)

Peter Thoman (00:08:02 - 00:08:10)

Wolfi Gassler (00:08:11 - 00:08:14)

Peter Thoman (00:08:14 - 00:08:57)

Wolfi Gassler (00:09:57 - 00:10:02)

Peter Thoman (00:10:02 - 00:10:11)

Andy Grunwald (00:10:11 - 00:10:17)

Peter Thoman (00:10:17 - 00:10:41)

Andy Grunwald (00:10:41 - 00:11:12)

Peter Thoman (00:11:12 - 00:11:56)

Andy Grunwald (00:11:56 - 00:12:03)

Peter Thoman (00:12:03 - 00:12:04)

Wolfi Gassler (00:12:04 - 00:12:17)

Peter Thoman (00:12:17 - 00:12:28)

Wolfi Gassler (00:12:29 - 00:12:41)

Peter Thoman (00:12:41 - 00:14:07)

Wolfi Gassler (00:14:07 - 00:14:16)

Peter Thoman (00:14:16 - 00:14:41)

Wolfi Gassler (00:14:41 - 00:14:56)

Peter Thoman (00:14:56 - 00:15:26)

Wolfi Gassler (00:15:26 - 00:15:38)

Peter Thoman (00:15:38 - 00:15:54)

Wolfi Gassler (00:15:54 - 00:16:04)

Peter Thoman (00:16:04 - 00:16:28)

Andy Grunwald (00:16:28 - 00:16:42)

Wolfi Gassler (00:16:42 - 00:16:45)

Andy Grunwald (00:16:46 - 00:17:19)

Peter Thoman (00:17:19 - 00:17:57)

Andy Grunwald (00:17:57 - 00:18:04)

Wolfi Gassler (00:18:04 - 00:18:09)

Peter Thoman (00:18:09 - 00:18:16)

Andy Grunwald (00:18:16 - 00:18:57)

Peter Thoman (00:18:57 - 00:19:23)

Andy Grunwald (00:19:23 - 00:19:45)

Peter Thoman (00:19:45 - 00:20:13)

Wolfi Gassler (00:20:13 - 00:20:21)

Peter Thoman (00:20:21 - 00:20:23)

Wolfi Gassler (00:20:23 - 00:20:27)

Peter Thoman (00:20:27 - 00:20:52)

Andy Grunwald (00:20:52 - 00:21:06)

Wolfi Gassler (00:21:06 - 00:21:30)

Peter Thoman (00:21:30 - 00:22:11)

Wolfi Gassler (00:22:11 - 00:22:19)

Peter Thoman (00:22:19 - 00:22:56)

Wolfi Gassler (00:22:56 - 00:23:10)

Peter Thoman (00:23:10 - 00:23:42)

Wolfi Gassler (00:23:42 - 00:23:48)

Peter Thoman (00:23:48 - 00:24:27)

Wolfi Gassler (00:24:27 - 00:24:38)

Peter Thoman (00:24:38 - 00:24:49)

Andy Grunwald (00:24:49 - 00:25:12)

Peter Thoman (00:25:12 - 00:25:39)

Wolfi Gassler (00:25:39 - 00:25:46)

Peter Thoman (00:25:46 - 00:26:55)