Highspeed Data Processing

„Im Bereich der Netzwerktechnologie gehen Kunden eigentlich davon aus, dass sie immer beliebig viel und schnell übertragen können. So haben wir es auch die letzten 10 Jahre irgendwie gelernt.“

Willkommen zu Folge 5 unserer Staffel „Querverlinkt - Technik über dem Tellerrand“. Am Anfang der Staffel haben wir euch ja versprochen, dass wir technisch auch mal in die Tiefe gehen. Und das machen wir mit unserem heutigen Gast Prof. Dr.-Ing Thorsten Herfet vom Informatik Campus der Universität des Saarlandes. Prof. Herfet lehrt und forscht im Bereich der Nachrichtentechnik und hier vor allem zu den Themen Telekommunikation sowie Audio- und Videoübertragung. Auch wir haben uns für heute aus den eigenen Reihen Verstärkung mitgebracht, und zwar Dirk Leinenbach, er ist Leiter der Software- und Produktentwicklung bei consistec. In dieser Runde diskutieren wir heute über High-Speed Data Processing. Warum müssen Daten immer schneller verarbeitet werden? Ein sehr spannendes Zukunftsthema. Viel Spaß beim Hören!

Transkription

Thomas Sinnwell: Heute geht es um das Thema High-Speed Data Processing. Dazu habe ich zwei äußerst kompetente Gesprächspartner mit unterschiedlichem Background gewinnen können. Zum einen Prof. Dr. Thorsten Herfet vom Informatik Campus an der Universität des Saarlandes, und dann den Informatiker Dr. Dirk Leinenbach, der die Softwareentwicklung bei der Firma consistec leitet. Der Corona-Thematik geschuldet ist Prof. Herfet heute zugeschaltet und Dirk Leinenbach und ich sitzen mit gebührendem Abstand in einem sehr komfortablen Aufnahmestudio. Ich freue mich sehr über diese Runde und das heutige Thema starten möchte ich mit meinen Gästen. Beginnen werde ich mit Prof. Herfet. Ihre Forschungsschwerpunkte, das sind Bereiche wie Cyber-Physical Networking, Low Latency Streaming, High Mobility OFDM Systems. Sicherlich Begriffe, die nicht jedem geläufig sind. Ich würde Sie bitten, die mal kurz zu erläutern, was sich dahinter verbirgt. Und gleichzeitig wäre es sehr schön, wenn Sie sich unseren Zuhörern kurz vorstellen würden.

Prof. Dr. Thorsten Herfet: Vielen Dank, Herr Sinnwell! Ab einem bestimmten Alter ist es ja nicht ganz so einfach, sich kurz vorzustellen.

Thomas Sinnwell: Das ist wohl wahr. Ja.

Prof. Dr. Thorsten Herfet: Aber ich bin promovierter Nachrichtentechniker, habe in Dortmund promoviert. Ich war dann zehn Jahre lang in der Industrie sehr lange Forschungsleiter bei der Firma Grundig und dann noch einige Jahre bei Intel und bin seit 2004 tatsächlich am Campus der Universität des Saarlandes. Obwohl von Hause aus Nachrichtentechniker, dort in der Informatik. Und das klärt auch schon ein bisschen die Forschungsschwerpunkte, weil mein Hintergrund war immer digitale Fernseh- und Kinotechnik. Das heißt, Bilddaten, die an sich ja schon mal hohe Datenmengen machen, zu verarbeiten und diese Daten dann auch zu übertragen. Im Rahmen der Informatik ist dann völlig klar, dass die Übertragung nicht mehr typische Rundfunknetze sind, sondern dass die Übertragung tatsächlich Netzwerke sind, größtenteils zum Beispiel IP-basierte Netzwerke. Und dementsprechend beschäftigt sich viel der Forschung damit, sogenannte Cyber-Physical Networks zu betrachten. Das sind Netzwerke, in denen verschiedenste Geräte, verschiedenste Arten von Daten miteinander kommunizieren, das können Videodaten, das können Audiodaten, das können Sensordaten sein, aber gemeinsam miteinander interagieren und gesteuert werden müssen. Da entstehen dann durchaus hohe Datenraten und vor allen Dingen sehr viele verschiedene Datenströme. Und das Thema Latenz- und Resilienz-gewahre Übertragung ist da sozusagen mein Steckenpferd. Auch das klingt jetzt ein bisschen nach Fremdwort, aber es heißt, dass man gleichzeitig versucht, Garantien zu geben, wie lange eine Übertragung dauert und wie sicher sie ist. Und für die, die ein bisschen technisch versiert sind, die wissen, dass sich diese beiden Punkte widersprechen. Um extrem verlässlich zu sein, braucht man unendlich lang, und wenn man sehr kurz sein will, ist man nicht mehr verlässlich. Das heißt, dieses Zusammenspiel zu optimieren, ist eines unserer Forschungsgebiete im Bereich Cyber-Physical Networking.

Thomas Sinnwell: Superspannende Themen und an der Stelle für die Zuhörer gibt’s natürlich dann auch die Berührpunkte zu uns, weil es geht letztendlich auch um IP-basierte Dienste. Auch ein Thema, was uns in Unternehmen stark umtreibt. Dann komme ich auch schon zu meinem zweiten Gast, das ist der Dirk Leinenbach. Er verantwortet die Softwareentwicklung bei der consistec. Dirk, sei doch so lieb, stell dich kurz vor und gehe vielleicht auch mal auf dein Faible für Hardware-Architekturen ein.

Dr. Dirk Leinenbach: Ja, gerne. Die Hardware-Geschichte, das kommt bei mir auch aus der Ausbildung. Ich habe in Saarbrücken Informatik studiert vor knapp 20 Jahren, damals Master oder Diplom damals noch gemacht am Lehrstuhl für Rechnerarchitektur. Das heißt, wir haben Prozessoren designt, so wirklich Low-Level Geschichten vom Transistor an aufwärts. Ich habe danach promoviert in Saarbrücken, eine Zeit lang ein bisschen einen Ausflug in die Theorie gemacht, formale Software-Verifikation. Auch interessant, aber nicht unbedingt High Performance related. Und ich bin jetzt seit über zehn Jahren bei der consistec für Softwareentwicklung zuständig und da mit dem Schwerpunkt auf der Echtzeitverarbeitung sehr hoher Datenmengen. Da sehe ich auch so ein paar Überlappungen zu Prof. Dr. Herfet, da geht’s nämlich genau darum, dass man sehr viele Informationen jede Sekunde hat und auch ganz viele verschiedene Kommunikationsströme, die vermischt sind und die man oft noch mal auseinander sortieren möchte.

Thomas Sinnwell: Ja, besten Dank! Wenn man das Ganze jetzt mal in Deutsch ausspricht, dann geht’s ja um die schnelle Verarbeitung von Daten. Hört sich dann deutlich dröger an, ist aber oft so im Vergleich zur englischen Sprache. Aber das Thema ist alles andere als dröge und es bringt eine ganze Menge Herausforderungen mit sich. Aber bevor wir auf diese Herausforderungen zu sprechen kommen, finde ich es einfach mal spannend, der Frage nachzugehen: Wo kommt das denn her? Warum sind wir denn mittlerweile oder müssen wir große Datenmengen in sehr kurzer Zeit verarbeiten können? Starten würde ich ganz gern mit Herrn Herfet. Ich würde auch noch so das Thema vielleicht 5G Ihnen mitgeben wollen. Ich denke, das ist was, was der Zuhörer oder was viele Zuhörer kennen, und das hat ja schon ein bisschen was mit der Thematik zu tun.

Prof. Dr. Thorsten Herfet: Ja, 5G ist sicherlich eines der Netzwerke, weil wir vor allen Dingen von der Verarbeitung in Netzwerken reden, welches diese Themen am meisten betrifft. Aber um erst mal das Thema Hochgeschwindigkeitsdatenverarbeitung abzudecken, es ist ja so, dass wir in vielen Bereichen als Menschen die Daten auch konsumieren, das heißt, die Zeitvorstellung, die wir haben, um mit Daten umzugehen und wie schnell Daten auf uns reagieren sollen oder müssen, ist eigentlich vorgegeben durch uns als Menschen. Jeder weiß das, wenn er Daten über sein Handy verschickt und wenn er eine WhatsApp-Nachricht verschickt, dann ist es ein Unterschied, ob ich ein paar Textzeilen verschicke oder ein 20-sekündiges hochaufgelöstes Video. Wir sind es aber mehr und mehr gewohnt, dass eben auch diese visuellen Inhalte, also hochaufgelöste Videos, ganz normale Daten sind. Gleiches gilt für diese Cyber-Physical Networks, die wir vorhin angesprochen haben, wo Drohnen miteinander kommunizieren, die auch Video übertragen, damit man die Blicke der verschiedenen Drohnen sieht. Soll heißen, wir sind in einer Zeit, in der eine unglaubliche Explosion an Daten erfolgt, einfach dadurch, dass sowohl wesentlich mehr Geräte miteinander kommunizieren als auch der Inhalt der eigentlichen Daten, sprich Video, immer größer wird. Und das führt unweigerlich dazu, dass wir eben Hochgeschwindigkeitsdatenverarbeitung und Hochgeschwindigkeitsdatenübertragung benötigen. 5G ist eines der ersten Netzwerke, was versucht, diese verschiedenen Anwendungsszenarien miteinander zu kombinieren. Also nicht mehr ein reines Sprachtelefonie-Netzwerk mit ein bisschen Datenunterstützung zu sein, sondern tatsächlich all diese Szenarien abzudecken.

Thomas Sinnwell: Mir ist grad bei Ihren Ausführungen noch so meine eigene Erfahrungswelt mit der Umstellung von ISDN auf SIP durch den Kopf gegangen, weil da der Begriff Latenzen gefallen ist. Am Anfang hatte man ja tatsächlich noch das Problem, dass alles etwas zeitversetzt war. Das kann man sich dann auch gut vorstellen, dass es umso dramatischer wird, je breitbandiger die Daten sind, je größer die Datenmengen sind, die man verarbeiten muss. Jetzt sind dann solche großen Datenmengen unterwegs in Netzwerken, Netzwerke müssen gesteuert werden, man muss in Netzwerken Fehler finden können. Dirk, kannst du da noch ein paar Ausführungen dazu machen?

Dr. Dirk Leinenbach: Ja. Bei den Netzen würde ich mal sagen, hat man im Prinzip mehrere Ebenen. Das eine ist die reine Übermittlung der einzelnen Bits und Bytes. Das ist eine ganze Menge an Daten, die schickt man da rüber, und wie der Herr Herfet gesagt hat, macht es natürlich einen Unterschied, ob ich jetzt Daten brauche, wo es auf jede Millisekunde ankommt, weil ich gerade telefoniere und jede Millisekunde-Schwankung da sehr stark merke. Oder ob es darum geht, einfach eine große Datenmenge, nehmen wir mal ein großes Bild, das einfach in ein paar Sekunden zu übermitteln, wo es aber egal ist, wie das genau passiert. Spannend wird es jetzt auch, und das ist jetzt mein Alltag, wenn man Fehler oder Probleme in solchen Übertragungen finden will, egal ob das jetzt tatsächlich falsch übermittelte Daten sind oder Performance-Probleme, die man analysieren möchte. Dafür brauche ich, egal was ich mir angucke, ich brauche immer ein Messgerät, das mindestens so gut ist wie die Dinge, die ich betrachten möchte. Beim Mikroskop brauche ich ein Mikroskop, das genau genug hingucken kann, bei einem analogen Signal brauche ich ein Oszilloskop, das eine passende Zeitauflösung hat, um zu sehen, was da schiefgeht. Und wenn ich Netzwerkdaten mir anschauen möchte, brauche ich eben ein Gerät, das Netzwerkdaten auch in Echtzeit verarbeiten kann, um dann schauen zu können, was da los war. Und wenn es nur darum geht, dass ich aus 10.000 Video-Calls, die gerade laufen, die paar Pakete rausschneide, die mich betreffen und von denen ich dann schauen möchte, was los ist.

Thomas Sinnwell: Ich würde jetzt noch ganz gerne auf das Thema zu sprechen kommen, wenn man dann diese Daten halt erfasst - und du hast es ja gerade ausgeführt, das muss ich auch hinreichend schnell können - und wenn ich all diese Daten dann habe, ist das erst mal gut und schön, aber letztendlich möchte man Erkenntnisse daraus gewinnen, das heißt, ich muss diese Daten analysieren. Das ist auch eigentlich ein Thema, was so, ich glaube, seit 2015 auch ganz stark hochgekommen ist. Könntest du da noch ein paar Ausführungen dazu machen?

Dr. Dirk Leinenbach: Bei der Analyse von solchen Daten, das sind ja Daten, die sind einfach da. Man sagt immer so schön, Echtzeit, das heißt, die prasseln auf mich ein und wenn ich nicht direkt darauf reagiere, sind sie weg, weil sie erst mal nur vorbeifließen. Wenn ich die analysieren will, …

Thomas Sinnwell: Jetzt könnte ich auf die Idee kommen, ach, das muss ich doch nur puffern.

Dr. Dirk Leinenbach: Ja, das kann man puffern, allerdings ist bei den Datenraten, von denen wir reden, jeder Puffer sehr schnell voll. Mit sehr schnell meine ich da wirklich Sekundenbruchteile oder wenn ich extrem große Puffer habe, vielleicht ein paar Sekunden. Das heißt, wenn ich nicht in Echtzeit mithalten kann bei der Verarbeitung, dann läuft mein Puffer zwangsläufig immer mehr voll und irgendwann ist er voll und dann muss ich Daten verwerfen. Das heißt, ich muss in Echtzeit tatsächlich mitkommen, ich kann mir das nicht aufheben und über Nacht als Batchanalyse laufen lassen, sondern ich muss in Echtzeit was mit den Daten machen. Da gibt’s dann typischerweise zwei Varianten, wenn ich sie nicht komplett verarbeiten kann. Die eine ist, ich mache eine statistische Analyse, keine Ahnung, ich zähle einfach mal mit, wie viele Pakete habe ich gesehen, wie viele von der Art, wie viele von jener Art. Dann kann ich mir bunte Graphen malen und kann eine Analyse machen. Oder, oder auch und, ich wähle ein …

Thomas Sinnwell: Würde ich vielleicht gerade einwerfen bei diesen statistischen Verfahren, was so ein naheliegender Gedanke ist, dass das natürlich auch je nach Anwendungsdomäne sehr verzerrend sein kann. Beispielsweise bei vielen Diensten ist es ja so, dass im Allgemeinen wenig los ist und dann zu sehr kurzen Zeiten passiert viel. Beispielsweise weil Batch-Jobs laufen, weil eine Diskussion auf einer Plattform in Gang gesetzt wird, weil sehr viele Sensoren anschlagen und plötzlich miteinander kommunizieren, und dann ist natürlich eine statistische Mittelung erst mal nicht hilfreich. Da gibt es ja noch andere Ansätze und ich nehme an, darauf möchtest du jetzt zu sprechen kommen?

Dr. Dirk Leinenbach: Ja, ich wollte darauf hinaus, dass man einerseits auch einzelne Teile der Kommunikation sich rausgreifen kann. Wenn man jetzt weiß, es gibt einen bestimmten Kommunikationsstrom, der ein Problem hatte, dann kann ich mir eben ganz selektiv solche Daten raussuchen und kann die genauer anschauen. Dann habe ich nicht mehr die exorbitante Datenmenge, die ich nicht sichten kann. Aber ich muss natürlich entweder vorher wissen, dass genau dieser Datenstrom ein Problem haben wird, dann kann ich ihn einfach in Echtzeit herausfiltern und kann mich auf diesen Strom konzentrieren. Das geht gut, wenn ich ein Problem nachstellen kann, wenn ich quasi ein reproduzierbares Problem habe. Wenn ich hingegen ein Problem habe, das ich nicht reproduzieren kann, dann muss ich erst einmal möglichst viele Details aufzeichnen und dann im Nachhinein die aufgezeichneten Daten nochmal nachfiltern, um sie mir dann detailliert anzuschauen. Das ist etwas, was wir …

Thomas Sinnwell: Ich dachte jetzt auch an das Thema reaktive Streams, an letztendlich die Kafka-Akka-Welt.

Dr. Dirk Leinenbach: Das Thema ist bei uns auch interessant, das ist aber bei uns eher nachher ein Tool, um die Analyse umzusetzen. Da spielst du jetzt quasi auf die Stabilität der Analyse ein oder die Robustheit, dass man also eine Analyse, wenn man sie verteilt oder irgendwo komplexe Netzwerke hat, dass dann auch mal Teile kurzfristig wegfallen können oder überlastet sein können und man dennoch eine zuverlässige Analyse hinkriegt, indem man zum Beispiel mit gewissen Tools wie Apache Kafka oder ähnlichen Systemen Daten zwischenpuffert oder verschiedene Systembestandteile voneinander entkoppelt.

Thomas Sinnwell: Wenn ich das richtig verstanden habe - aber das kann auch sicherlich Herr Herfet mir dann noch mal bestätigen oder widerlegen - wenn ich mich so recht entsinne, ging doch dieses Aktorenkonzept schon auf Erlang zurück?

Dr. Dirk Leinenbach: Ja, Erlang ist eine Software oder eine Programmiersprache besser gesagt, die gibt’s, glaube ich, in der Kommunikationswelt schon seit Ende der 80er, Anfang der 90er. Wurde, glaube ich, ursprünglich mal von Ericsson entwickelt und ist eigentlich nur ein System, um Aufgaben, Rechenaufgaben oder Dinge, die man erledigen möchte, auf ganz viele unabhängige CPUs oder Aktoren zu verteilen. Das heißt, man hat eine Möglichkeit, Dinge parallel zu tun, ohne dass man sich gewisse Probleme einfängt, die das typischerweise hat, dass man miteinander kommuniziert, dass man sich synchronisieren muss. Und dieses so genannte Aktorenmodell, das von Erlang oder auch von moderneren Lösungen umgesetzt wird, ermöglicht mir das eben, ohne dass ich mir als Programmierer allzu viele Gedanken um Synchronisation machen muss. Was den Charme hat, dass ich sehr gut hunderte, tausende CPUs ausnutzen kann, ohne in diese typischen Probleme zu laufen, Fehler zu bauen.

Thomas Sinnwell: Und ich bin dadurch auch in der Lage sowas Ähnliches zu machen wie beim Puffern, nur wesentlich robuster, und habe die Chance, dass die Systeme, wenn Datenvolumen stark ansteigen, vielleicht in der Verarbeitung ein bisschen zurückfallen, aber dann auch wieder aufholen können.

Dr. Dirk Leinenbach: Ja, also das Aktorenmodell erst einmal hilft mir nur, mit zu wachsen in der Leistungsfähigkeit, dass wenn ich mehr CPU-Kerne habe, dass ich dann auch mehr arbeiten kann. Die Flexibilität, die du jetzt erwähnt hast, dass ich mal eine Zeit lang Dinge aufhebe, um dann nach zu arbeiten, das ist auch ein wichtiger Punkt. Manchmal hat man halt mal Highlights, nehmen wir mal Silvester 12 Uhr nachts, da hat man ein paar SMS mehr als an anderen Tagen, da kann man auch durchaus mal ein paar Sekunden lang nicht mehr mithalten oder ein paar Minuten, man muss halt im Durchschnitt mithalten können. Und für die Zeiten, wo die Last deutlich über dem Durchschnitt ist, kann man sich dann mit Puffern behelfen, solange man es noch mal nacharbeiten kann. Das müssen die Systeme natürlich hergeben, sowohl bei der Übermittlung von Daten als auch bei der Analyse, aber im Durchschnitt muss ich bei Echtzeitnetzen natürlich immer mithalten können, sonst ist irgendwann jeder Puffer voll, egal wie groß.

Thomas Sinnwell: Da sind wir ja nahtlos schon übergegangen in Software-Fragestellung und ich denke, diese Herausforderungen bei High-Speed Data Processing, die betreffen sowohl die Hardware als auch die Software. Was da jetzt in der letzten Zeit auch immer stärker hochkommt, das sind die GPUs. Herr Herfet, ich denke, da können Sie uns auch viel dazu sagen. Ich erinnere mich da auch an Ihre Zeit beim Intel Visual Center. Und ich würde Sie bitten, vielleicht mal zum Hardware-Part ein bisschen was für unsere Zuhörer zu sagen.

Prof. Dr. Thorsten Herfet: Mhm (bejahend). Die Einleitung war schon sehr in die Richtung, weil tatsächlich der Terminus GPU aus dem Bereich der Grafik kommt. Und ich hatte tatsächlich neun Jahre lang die Freude, das Intel Visual Computing Institute an der Universität des Saarlandes zu leiten. Es ist aber mittlerweile so, und ich denke, das ist auch das Thema von heute, dass die Architektur, die verschiedenen Architekturen, gar nicht mehr unbedingt in den Anwendungsbereichen eingesetzt wird, aus denen sie stammen und von denen sie kommen. Also im Prinzip für die Zuhörerschaft gab es immer die CPU, also die zentralen Einheiten, die typischerweise relativ mächtige Prozessoren haben, die viele verschiedene Operationen ausführen können, die einen schnellen Zugriff auf einen sehr großen Speicher ermöglichen. Und die Parallelität, also das, was Sie auch gerade mit Erlang angesprochen haben, hält sich in Grenzen. Das heißt, wir reden hier typischerweise von vielleicht einer hohen einstelligen bis zu einer niedrigen, ganz niedrigen zweistelligen Anzahl paralleler Prozessoren, die benutzt werden können. Dann kamen die sogenannten GPUs, die grafischen Processing Units, also diejenigen, die eigentlich dafür gemacht waren, sehr, sehr viele, soll heißen, tausende von Operationen parallel auszuführen, weil ich in der Grafik typischerweise ganz viele Bereiche des Bildschirms völlig unabhängig voneinander mit Texturen füllen kann. Und die haben aber, weil man natürlich eine begrenzte Anzahl von Transistoren und eine begrenzte Anzahl von Speichern hat, pro ausführende Einheit viel, viel weniger Speicher zur Verfügung und sie können auch nur viel, viel einfachere Operationen machen. Das heißt, man hat jetzt sozusagen zwei Architekturen, die eine kann sehr komplexe Operationen, aber nicht ganz so viele parallel, die andere kann sehr, sehr viele parallele Operationen, aber längst nicht so komplex und längst nicht mit so viel Speicher machen. Und dann gibt’s noch dritte Architekturen, nämlich sozusagen selbstprogrammierte Architekturen wie FPGAs, die ihre Stärke eher in der Zulieferung und Abführung von Daten haben. Wo ich also frei entscheiden kann, was ich dann mit den Daten mache, aber ich kriege die Daten erheblich schneller in den Schaltkreis rein als ich das in einer normalen Speicherarchitektur mit GPUs oder CPUs habe. Das Spannende eigentlich daran ist, dass es sehr, sehr schwer ist von vornherein vorauszusagen, wenn ich ein Problem lösen will, wenn ich einen Algorithmus habe, auf welcher dieser Architekturen läuft der eigentlich am schnellsten? Und wenn ich das weiß, auf welcher Architektur er am schnellsten läuft, muss ich eigentlich heutzutage auch noch für diese Architektur programmieren. Da gibt’s sehr, sehr viele Arbeiten am Saarland Informatik Campus, Kollegen von mir, also das ist nicht Aufgabe des Nachrichtentechnikers, aber Kollegen von mir haben Programmiersprachen entwickelt, die man so orchestrieren kann, dass man sozusagen den eigentlichen Algorithmus und die Steuerung, auf wie viel parallelen Architekturen dieser Algorithmus schlussendlich durchgeführt wird und wie die Speicherarchitektur ist, das wird dann beim Übersetzungsvorgang gemacht. Das heißt, Sie können sozusagen ein und denselben Quellcode sowohl für eine GPU als auch für eine CPU übersetzen. Sehr, sehr praktisch, weil es heutzutage - und das wird Herr Leinenbach als Entwickler sicherlich wissen - ein enormer Aufwand sein kann, wenn man ein Problem mit einem Quellcode für eine GPU und auch speziell für eine GPU löst. Dann schreibt man bei AMD GPUs in OpenCL, dann schreibt man bei Nvidia in CUDA oder ähnlichen Derivaten. Das kann sehr, sehr viel Aufwand sein und es ist nicht sehr wiederverwendbar. Und das ist sehr spannend, also einmal herauszufinden, wie programmiere ich die verschiedenen Architekturen, gleichzeitig aber auch, welche ist für das Problem, was ich jetzt angehe, eigentlich die am besten geeignete?

Thomas Sinnwell: Das ist dann auch eine ganz wunderbare Überleitung zu dir, Dirk.

Dr. Dirk Leinenbach: Ja, ich wollte grad schon antworten. Das ist definitiv im Moment ein sehr spannendes Thema auch für die Softwareentwickler. Ich komme ja selbst aus dem Prozessordesign, das heißt, ich habe in die Wiege gelegt bekommen diese Idee, ich habe Hunderttausende, Millionen, heutzutage Milliarden von Transistoren, die alle gleichzeitig irgendwas tun. Also da habe ich wirklich ganz extreme Parallelität. Ich habe auch noch in meiner Zeit FPGAs wirklich Low Level mit Hardwarebeschreibungssprachen Verilog oder VHDL entwickelt, wo man auch in diesen Karten noch auf Transistorenebene quasi nachdenkt. Das ist heutzutage, wie Sie gesagt haben, Herr Herfet, eher so, dass man auch solche Karten und gerade auch die GPUs oder CPUs in C oder C++ programmiert. Das heißt, da ist man auf einer doch anderen Abstraktionsebene. Dennoch hat man gerade in diesen Grafikkarten oder auf den FPGAs eine erheblich höhere Parallelität als auf normalen CPUs und, zumindest bis vor kurzem oder bis aktuell, auch ganz unterschiedliche Programmiermodelle. Also da muss ich, um wirklich effizienten Code zu haben, sehr genau wissen, auf welcher Hardware mein Programm läuft? Wie ist die Speicheranbindung? Habe ich geshartes Memory zwischen Host und der Grafikkarte? Wie viele Kerne habe ich? Wie sind die verschaltet? Welche Möglichkeiten hat ein Kern? Wie teilen die sich irgendwelche Register oder Caches? Also da muss ich wirklich viel wissen, um es effizient zu machen. Es gibt aber auch in der Industrie, Intel fällt mir da ein, ganz erhebliche Bestrebungen da einheitliche Programmiermodelle zu finden, damit ich eben mein Programm einmal schreibe und dann erst bei der Anwendung auf einem konkreten Rechner entscheiden zu müssen, lass ich das jetzt auf der CPU, auf der GPU oder auf beidem laufen, auf fünf Rechnern, auf 100 Rechnern. Und das, hoffe ich mal sehr, gibt uns Softwareentwicklern die Möglichkeit, uns auf das Algorithmische noch mal irgendwann zurückzuziehen und alles andere sozusagen einfach nur als Kostenfaktor zu sehen, wieviel Hardware welcher Art habe ich gerade zur Verfügung, und dann das passende Hardware-Setup zu wählen und den Code einfach weiter zu verwenden. Das wäre mein Traum. Und ich glaub, da geht’s im Moment tatsächlich hin. Natürlich wie immer, wenn man Abstraktionen einführt, man verliert etwas an Effizienz. Das fängt damit an, wenn man nicht mehr Assembler-Code schreibt, sondern in C oder C++. Auf der anderen Seite können da auch automatische Tools wie Compiler durchaus heutzutage besser optimieren als die meisten Menschen das von Hand können. Und da wäre auch meine Hoffnung, dass das in Zukunft mit solchen Abstraktionen so ist. Das heißt, dass ich irgendwann, wenn ich Code mit Intel oneAPI oder ähnlichen Tools entwickle und übersetze, besseren Code habe, als wenn ich mich ein halbes Jahr hinsetze und die Sachen von Hand code.

Thomas Sinnwell: Herr Herfet, müssen wir noch weiter träumen oder können wir wirklich hoffen?

Prof. Dr. Thorsten Herfet: Ich glaube, wir können wirklich hoffen. Vielleicht nicht, dass die Automatisierung besser ist als das Handoptimierte, aber was jetzt in den Ausführungen von Herrn Leinenbach noch nicht so drin war, ist, die Prozessoren, sowohl GPUs als auch CPUs, entwickeln sich sehr, sehr schnell weiter. Das heißt, selbst wenn ich suboptimal optimiere, also ich habe noch 20 %, die ich gewinnen kann, brauche aber ein halbes Jahr, um einen Ingenieur dazu zu bringen oder einen Informatiker dazu zu bringen, den Code so zu optimieren, dass er wirklich 100 % ausschöpft, in dem halben Jahr ist der Prozessor schon wieder 30 % schneller geworden. Das heißt, der suboptimale Code läuft auf dem neuen Prozessor schneller als der handoptimierte auf dem neuen Prozessor. Insofern ist es tatsächlich so, dass es Sinn macht, die Dinge zu optimieren, selbst wenn man nicht an den handoptimierten Code herankommt. Wenn man nur nahe genug herankommt und sozusagen der Trade-Off mit der Zeit und auch natürlich den Kosten, die man braucht, das von Hand zu machen, sozusagen dann eine positive Endbilanz hat, dann macht es absolut Sinn, das automatisch zu machen. Und es entwickeln sich auch die Architekturen sehr, sehr schnell weiter. Denken Sie jetzt nur an den gesamten Bereich Deep Learning, GPUs sind eigentlich heutzutage gar keine GPUs mehr, sondern das sind schon fast TPUs für Tensor Processing Units, weil die eigentlich darauf optimiert sind, dass sie Deep-Learning-Algorithmen laufen lassen. Weil natürlich die Grafikkartenhersteller erkannt haben, das sind Dinge, die sind hochparallel, aber eigentlich ganz einfach. Ein Neuron ist eigentlich sehr, sehr einfach, macht ein bisschen Multiplizieren und ein bisschen Addieren und dann vielleicht noch eine kleine Kennlinie, und das ist es. Das heißt, das ist eine Architektur, die natürlich danach riecht, dass man sie auf Grafikkarten auch implementiert, und solche Dinge ergeben sich auch immer. Dem läuft man mit einer Handoptimierung doch sehr, sehr langsam hinterher. Insofern: Ja. Wir können hoffen, wir sollen auch hoffen, und es ist ja auch an der Uni des Saarlandes durchaus ein Forschungsschwerpunkt. Wie gesagt, nicht bei mir, sondern bei Kollegen von mir, aber ich darf ja auch mal ein bisschen Werbung für die Kollegen machen.

Thomas Sinnwell: Definitiv! Das ist ja mehr als begründet. Ich denke, auf unseren Informatik Campus können wir wirklich sehr stolz sein. Das ist sicherlich ein dickes Aushängeschild hier im Saarland. Du guckst gerade so, Dirk, möchtest du das noch ergänzen?

Dr. Dirk Leinenbach: Nein, da kann ich nur zustimmen. Also die Geschichte, wir hatten ja noch gar nicht betrachtet, dass der Informatiker, der den Code optimiert, selbst auch noch mal eine Menge Geld kostet. Das kommt ja noch obendrauf. Das hängt natürlich von der Stückzahl ab. Wenn ich den Code dann eine Million-mal laufen lasse irgendwo, sind die Prozessorkosten vielleicht relevanter als der eine Programmierer. Trotzdem ist es natürlich auch spannender als Programmierer, sich auf einer anderen Ebene Gedanken zu machen. Und man hat ja auch vor einigen Jahren schon ähnliche Situationen gehabt. Ich habe einen Prozessor, der hatte früher mal einen Kern und das war's. Dann muss ich den einen Kern möglichst effizient ausnutzen. Irgendwann gab's dann zwei Kerne, vier Kerne, acht Kerne, heutzutage ein paar hundert Kerne. Dann kann ich das Programm parallelisieren. Dadurch wird es typischerweise, da die Teile miteinander reden müssen, insgesamt weniger effizient werden pro Kern. Allerdings dadurch, dass ich sehr viel mehr Kerne habe als früher und die auch weniger Strom zum Beispiel verbrauchen als ein Kern, der sehr schnell ist, bin ich trotzdem in Summe schneller. Ich bin nicht mehr so effizient im Sinne von, ich gucke, multipliziere die Prozessoren mit den Megahertz und gucke, wieviel mache ich in der Zeit, aber in Summe bin ich schneller und ich kann vor allem besser skalieren. Wenn nächstes Jahr ein Prozessor mit doppelt so vielen Kernen rauskommt, wird mein Code automatisch schneller, wenn er gut parallelisiert, und ich kann das dann einfach wieder mitnehmen, was ich lange oder mittlerweile nicht mehr auf einzelnen Kernen kann. Wenn ich zurückgucke, vor fünf Jahren war ein einzelner Kern nicht wesentlich langsamer als heute ein einzelner Kern. Eine ganz andere Situation als in meiner Jugend, als noch quasi jedes halbe Jahr die einzelnen Prozessorkerne an sich wesentlich schneller wurden und man als Softwareentwickler diesen sogenannten Free Lunch hatte. Man hat einfach ein halbes Jahr gewartet und die Software wurde schneller. Und mittlerweile kriegt man das nur noch, wenn man gut parallelisieren kann. Und zwar auf allen Ebenen, und da ist natürlich die Nutzung von Spezial-Hardware gerade jetzt besonders spannend. Weil auch wir haben jetzt im täglichen Bedarf, wenn wir in Netzwerkpakete gucken, wenn wir da Dinge analysieren, das ist streng genommen kein furchtbar komplexer Code. Ich brauche da keine Floating Point Einheit mit doppelter Genauigkeit, die 500 Quadratwurzeln im Takt analysieren kann. Das brauche ich alles nicht. Mir reicht‘s im Prinzip, wenn ich möglichst viele Daten hin und her schaufeln kann, ein paar Bits vergleichen. Und teilweise reicht‘s mir wirklich, wenn ich mit 8 Bit oder 16 Bit Genauigkeit schnell rechnen kann. Das bringt mir viel mehr als alle ausgefuchstesten mathematischen Operationen. Die braucht vielleicht jemand anders, der 3D-Spiele programmiert, aber ich brauche die nicht. Mir ist Parallelität da wichtiger.

Thomas Sinnwell: Hört sich jetzt vielleicht ein bisschen so an, als ob man einfach immer nur warten muss und die Weiterentwicklung der Prozessoren hilft dann schon. Jetzt nehme ich so wahr, dass es gerade bei unserem Thema High-Speed Data Processing durchaus so ist, dass ich auch über die Software wirklich die Konzepte, wie ich da rangehe, wirklich auch um jedes Detail kämpfen muss. Und es eben nicht damit gut sein lassen kann, einfach zu warten, dass die nächste Prozessorgeneration kommt. Da gibt’s ja auch unterschiedliche Ansätze. Kannst du da vielleicht noch ein bisschen was für die Zuhörer sagen? Wir hatten es eben ja schon gestreift, aber …

Dr. Dirk Leinenbach: Ja, ich kann’s. Wir hatten es eben, glaube ich, ein bisschen ohne Kontext gestreift. Aber jetzt kommt so langsam die Begründung dafür hoch. Ich muss natürlich dafür sorgen, dass mein Programm auch mit mehr Prozessoren schneller wird. Und dafür ist es eben wichtig, dass die unterschiedlichen Teile der Software unabhängig voneinander laufen können, soweit wie möglich. Sprich, die dürfen nicht alle ständig aufeinander gegenseitig warten müssen. Das ist ein wichtiger Punkt, da muss man also bei der Entwicklung von Algorithmen dran denken. Und dann muss man die Kommunikation zwischen den Teilen so asynchron umsetzen, wie man das sagt. Also das heißt, wenn ich jetzt mit jemandem rede, dann schicke ich eine Nachricht weg optimalerweise und mache dann erst mal mit was anderem weiter, und irgendwann kommt eine Antwort und dann kümmere ich mich wieder um dieses Thema. Wir hatten Erlang eben als Beispiel, das geht in diese Richtung. Da gibt’s schon durchaus seit längerer Zeit gute Konzepte, wie man das softwaretechnisch machen kann. Und die werden heutzutage einfach immer wichtiger und sind auch bei uns sehr wichtig. Einerseits eben diese Isolation von verschiedenen Teilen, die mir dabei hilft, wenn ich an ein einzelnes Stück Code denke, nochmal die Parallelität im Kopf ausblenden zu können. Und gleichzeitig die Sache auch robuster macht, weil wenn, jetzt sag ich mal, ich habe da ein paar tausend Programmteile, Threats, die parallel arbeiten, und ich sorge dafür vom Grobansatz, dass das kein Problem ist, wenn einer davon mal abstürzt oder nicht zurande kommt.

Thomas Sinnwell: Du hast jetzt gesagt von Threats, wenn ein Threat abstürzt. Vielleicht noch für die Zuhörer: Was ist ein Threat?

Dr. Dirk Leinenbach: Ein Threat ist so ein einzelner Teil in der Programmausführung, der auf einem CPU-Kern läuft, typischerweise. In einer optimalen Welt würde ich als Entwickler immer nur so von einem sogenannten Single Threat denken, weil dann muss ich mir um Kommunikation und Parallelität nicht so viele Gedanken machen. Ich muss aber dafür sorgen, dass das Gesamtsystem diese Einzelteile eben miteinander koordiniert. Also stell dir vor, du hast eine Million Menschen, die ein Problem für dich lösen sollen, dann musst du das Problem natürlich erst mal in eine Million Stücke zerteilen. Und wenn da jeder mit jedem ständig reden muss, dann sind die Leute nur noch am Reden und arbeiten nicht an den Einzelproblemen. Das heißt, der wichtigste Aspekt ist eben, dein Gesamtproblem runter zu brechen auf eine Million Teile oder optimalerweise viele hundert Millionen oder Milliarden Teile und dass dann jeder dieser eine Million Menschen, die für dich arbeiten, sein kleines Stück macht, das dann weitergibt und das nächste kleine Stück machen kann, und möglichst zwischendurch nicht auf andere wartet. Ähnlich ist das hier in der Softwareentwicklung, je besser ich ein Problem runterbrechen kann in unabhängige Teile, desto besser. Und dann gibt’s eben Werkzeuge wie Erlang oder andere Aktorenmodelle oder auch andere Ansätze, um das dann technisch wirklich umzusetzen, diese Unabhängigkeit.

Thomas Sinnwell: Um dein Bild da wieder aufzugreifen von einer Million Menschen, da helfen ja diese Aktorenmodelle und diese reaktiven Stream-Konzepte auch, den Fall abzudecken, dass da auch welche krank werden und Urlaub machen bei den Menschen und weg sind. Trotzdem soll aber die ganze Verarbeitung noch weitergehen und nicht in sich zusammenbrechen. Du hattest das Thema zeitversetzte Daten, die ich verarbeiten muss.

Dr. Dirk Leinenbach: Genau. Also da gibt’s dann einfach verschiedene Werkzeuge. Du hattest eben Kafka erwähnt, das ist eins davon. Aber da gibt’s im Prinzip ganz viele, mit denen ich einfach diese Aktoren, diese Menschen, diese Programme voneinander isolieren kann. Das heißt, die schicken ihre Nachricht ab und dass die Nachricht irgendwann ankommt und dass die auch bei irgendjemandem ankommt, wenn der zwischendurch krank wird und durch jemand anders ersetzt wird, darum kümmern sich dann diese Werkzeuge. Und das ist eben ein wichtiger Punkt, dass diese Entkopplung besteht, dass also die zwei Aktoren, die miteinander kommunizieren, dass die nicht unbedingt darauf angewiesen sind, sich zu kennen, zu wissen, was macht der andere gerade, sondern die schicken ihre Nachricht und irgendwann kommt eine Antwort. Und wenn der erste Empfänger nicht reagiert, dann wird ein anderer probiert oder der Empfänger fängt quasi noch mal von vorne an. Das ist ganz wichtig, weil ich hier einfach, wenn ich sehr viele Aktoren habe, die gleichzeitig aktiv sind, dann steigt einfach die Wahrscheinlichkeit, dass auch seltene Probleme ständig auftreten und dann muss ich eben mit dem Problem umgehen. Es ist dann viel besser oder viel effizienter, sozusagen fehlertolerant zu sein. Ich gehe einfach davon aus, irgendwann wird was schiefgehen, als dass ich versuche, um jeden Preis Fehler zu verhindern. Das ist in der Regel viel teurer als einfach zu sagen: Gut, dann passiert halt was und dann korrigiere ich den Fehler lieber im Nachhinein.

Thomas Sinnwell: Gut. So zusammenfassend kann man jetzt sagen, wir haben uns die Hardware angeschaut, haben festgestellt, Prozessoren entwickeln sich regelmäßig weiter, Parallelität wird hochgetrieben. Es gibt mit den GPUs jetzt den Ansatz, einfache Aufgaben, die aber in einer unendlich großen Stückzahl parallel durchführen zu können. Davon profitiert der ganze AI-Bereich, also der Bereich Künstliche Intelligenz. Wir hatten das Thema, wenn ich die ganzen Daten, jetzt schon mal in der Lage bin, die zu steuern durch die Netze, wenn ich schauen kann, dass Latenzen noch stimmen, kann ich natürlich ganz neue Dienste anbieten, viele neue Möglichkeiten schaffen. Und jetzt würde ich noch mal gern so einen Ausblick machen und uns ein bisschen wieder von der Technik lösen. Was wird das denn für uns Techniker auf der einen Seite, aber vielleicht auch für unsere Gesellschaft jetzt in den nächsten Jahren bedeuten? Was kommt denn da so auf uns zu? Vielleicht Herr Herfet, wenn Sie starten möchten?

Prof. Dr. Thorsten Herfet: Ich glaube, dass die ganz großen Quantensprünge, was tatsächlich ganz neue Anwendungen betrifft, vermutlich gar nicht so der Fall sind, weil wir in einer Zeit leben, in der die Wunschliste schon so unheimlich groß ist. Wir haben es ganz am Anfang gehabt, Bilder werden heutzutage so verarbeitet wie Sprache oder Musik vor 15 Jahren, und Sprache oder Musik vor 15 Jahren wurde so verarbeitet wie Text, nochmal 15 Jahre weiter zuvor. Das heißt, wir bewegen uns eigentlich in einem Umfeld, in dem es als ganz selbstverständlich erachtet wird, dass man diese irrsinnigen Datenmengen und diese Kommunikation von unglaublich vielen, tausenden, zehntausenden, schlussendlich vielleicht sogar hunderttausenden von Sensoren und Aktoren in Fabriken, indem man das mehr oder minder als gegeben hinnimmt. Also ich sag mal, der normale Kunde, wahrscheinlich auch die Zuhörer, würden den Unterschied dazwischen, ob jetzt zehn Sensoren miteinander reden in einer Fabrik zum Beispiel, oder ob das zehntausend sind, gar nicht bemerken. Wir als Techniker, Sie als diejenigen, die das beobachten müssen, merken den Unterschied sehr wohl, wir müssen es programmieren, wir müssen es irgendwie schaffen. Aber es ist interessant zu sehen oder mit zu bekommen, dass es sozusagen nicht so ist, dass jetzt etwas entsteht, was komplett neu ist im Bereich der Netzwerktechnik. Ich habe ja auch noch das zweite Standbein visuelle Anwendung, und da passiert schon was. Da geht’s dann in Zukunft weg vom klassischen zweidimensionalen Bild, egal ob das auf dem Fernseher oder woanders passiert, hin zu sogenannten Lichtfeldern, also dass man im Prinzip 3D ohne Brillen gucken kann. Da passieren auch neue Anwendungsfelder. Aber im Bereich der Netzwerktechnologie habe ich so das Gefühl, dass die Kunden im Prinzip davon ausgehen, das ist eh ein unerschöpfliches Fass und ich kann eigentlich beliebig viel und beliebig schnell übertragen. So haben wir es auch die letzten zehn Jahre irgendwie gelernt. Das heißt, da existieren auch, jetzt wenn ich beyond 5G, also an 6G oder 7G denke, da entstehen nicht unbedingt die Dinge, wo jeder Wow sagt, sondern eigentlich eher die Dinge, wo jeder sagt: Ja. Ich dachte, das ging eigentlich schon. Und das ging nur nicht, weil es derartig viele Daten sind und eben eine derartig, um zum Thema zurückzukommen, derartig hohe Geschwindigkeit in der Datenverarbeitung erforderte, dass es bis dahin noch nicht möglich war. Also ich glaube, wir haben da noch sehr viel zu tun, und der Wunsch auf der Kundenseite, der ist schon lange da.

Thomas Sinnwell: Ich hoffe, dass es uns heute gelungen ist, den Zuhörern ein bisschen mitzugeben, dass die Erwartungshaltung, die da besteht, dass das für uns Techniker schon richtige Herausforderungen sind, um das auch alles immer umzusetzen.

Prof. Dr. Thorsten Herfet: Aber ist ja auch schön, wir sind …

Thomas Sinnwell: Aber das macht ja auch Spaß, also sonst …

Prof. Dr. Thorsten Herfet: … ja Ingenieure, wir wollen ja Probleme lösen.

Thomas Sinnwell: Genau. Sonst hätten wir den Beruf ja auch nicht ergriffen.

Dr. Dirk Leinenbach: Genau. Es soll ja spannend sein. Ich habe ähnliche Erfahrungen, auch wenn ich das bei mir selbst beobachte. Man sieht ja, eigentlich, wenn man vorwärts in der Zeit geht, sieht man kaum gefühlt, dass sich was ändert. Gefühlt ist mein iPhone heute genauso schnell wie mein iPhone vor drei Jahren. Das Internet war damals gefühlt schon superschnell überall. Heute ist es das auch. Interessanterweise hat sich das Internet per Handy auch schnell angefühlt für mich, als es noch UMTS war oder GPRS. Allerdings, wenn man jetzt zurückguckt, wenn ich heute das alte iPhone noch mal auspacke und anschalte, dann fühlt sich das langsam an. Also man merkt schon, dass sich Dinge entwickeln, aber man merkt es, wenn man die Entwicklung mitmacht, finde ich, sehr viel weniger, als wenn man rückwärts nochmal zurückschaut. Wenn ich überlege, früher, du hast dir genau überlegt, wann gehst du mit dem Modem ins Internet? Wann machst du was? Wann schickst du eine SMS? Weil damals hat eine SMS Geld gekostet. Das war einfach ein ganz anderes Verhalten als heute, wo das Netzwerk einfach immer da ist. Ich frag mich heute manchmal: Warum habe ich überhaupt WLAN daheim? Das LTE-Netz ist genauso gut, manchmal sogar besser. Manchmal funktionieren Dinge besser, wenn ich aus dem WLAN rausgehe. Ich glaube, das wird sich auch so weiterentwickeln, dass das immer natürlicher wird, dass man ständig alles zur Verfügung hat. Dateien, warum soll ich eine Datei auf meinem eigenen Rechner speichern? Aus dem Internet kommt sie im Zweifelsfall schneller als von meiner Festplatte. Das sind Dinge, ich glaube, das wird immer natürlicher, und irgendwann wird das komplett verschwimmen. Ob man das dann mag oder nicht, ist noch mal eine andere Frage. Aber rein von der Leistungsfähigkeit ist das schon sehr spannend, was da im Moment passiert.

Thomas Sinnwell: Dann möchte ich mich bei meinen Gästen ganz herzlich bedanken. Ich hoffe, dass es uns gemeinsam gelungen ist, so einen Einblick in die Welt der Techniker zu geben bezüglich des Themas High-Speed Data Processing. Wir alle können dann an der Stelle einfach mitnehmen: Da kommen noch viele fluffigere Anwendungen auf uns zu, auch wenn es nicht alles revolutioniert. Und damit es funktioniert, müssen viele Techniker ordentlich arbeiten. Vielen Dank fürs Zuhören! Tschüss!

Dr. Dirk Leinenbach: Ciao!

Prof. Dr. Thorsten Herfet: Tschüss!

So, das war‘s von uns für heute, wenn auch etwas technischer. Natürlich hoffen wir, dass wir euch auch diesmal gut unterhalten haben. Weiterführende Links gibt’s wie immer in den Shownotes. Und wenn ihr Lust auf mehr habt, dann freuen wir uns natürlich, wenn ihr uns abonniert. Im nächsten Podcast drehen wir den Spieß einfach mal um. Wie wir das machen, lasst euch überraschen. 4. Februar 2021: Schaltet ein! Es lohnt sich!