Grid-Computing

This transcript was generated automatically and has not been manually reviewed. It may therefore contain errors. The spoken word in the recording is always authoritative.

Till Schulte-Coerne: Ja, hallo und herzlich willkommen zu einer weiteren Folge des innoQ-Podcasts. Mein Name ist Till Schulte-Coerne, heute mit mir hier mein Kollege Thomas Kentemich. Thomas, stell dich doch am besten einfach mal kurz vor.

Thomas Kentemich: Ja hallo, ich bin Thomas Kentemich, bin seit ca. zwei Jahren bei der innoQ und arbeite jetzt hier hauptsächlich mit Java und Groovy im Backend auf der Serverseite. Habe allerdings in meiner Vergangenheit relativ viel gearbeitet in dem Bereich Parallel-Computing / Grid-Computing und ich glaube darüber soll der Podcast heute gehen.

Till Schulte-Coerne: Ja, das wäre auf jeden Fall eine gute Idee. Mal gucken wo es uns hinführt. Ja, also Thema – hast du schon angesprochen – soll Grid- Computing ganz im Allgemeinen sein. Ich persönlich kann mir da fast nichts drunter vorstellen, kannst du es vielleicht mal kurz erklären, was es genau ist?

Thomas Kentemich: Ich sollte vielleicht anfangen, dass ich mal historisch ein bisschen aufarbeite, warum man überhaupt auf die Idee gekommen ist, von der Idee “Ich habe einen Computer da stehen, mit einem Prozessor” wegzugehen zu sowas kompliziertem wie einem Grid oder einer massiv parallelen Architektur – was ein Grid letztendlich ist. Ja die Motivation ist ganz einfach: man möchte im Grunde aus dem Material, was man an Hardware zur Verfügung hat, das bestmögliche raussuchen, wobei man das jetzt von zwei Seiten eigentlich beleuchten kann. Nämlich einmal in Sachen Geschwindigkeit bei einer gegebenen Problemgröße, d.h. also, ich möchte einfach ein mathematisches Problem oder ein Simulationsproblem, was ich habe, in möglichst kurzer Zeit lösen. Oder auch andersrum, ist auch eine Motivation dazu: ich möchte im Prinzip immer größere Problemgrößen haben, die ich dann in einer endlichen Zeit oder in einer vorgegebenen Zeit lösen kann. Und es gab eine Zeit lang im Prinzip Lösungen, die so funktionierten, dass man eine einzige CPU immer schneller gemacht hat. Das ist eigentlich der traditionelle Ansatz, indem man z.B. die Registerbreiten erhöht. Sag, man hat ursprünglich mal 4-bit Register gehabt und ist mittlerweile bei 64-bit Registern angekommen, was natürlich eine wesentlich schnellere Verarbeitung von z.B. Floating Point Zahlen oder auch größeren Integers bietet. Man ist natürlich dazu übergangen, was jeder kennt, dass die Taktfrequenz von CPUs immer stärker erhöht worden ist. Das ist das sogenannte Moore’sche Gesetz. Ungefähr jedes Jahr verdoppelt sich im Grunde genommen die Fläche eines Chips, die Frequenzen werden erhöht. Diese ganzen Ansätze stoßen natürlich irgendwo an eine Grenze und das war dann der Punkt, wo man gesagt hat: “Ich muss von einer CPU weggehen auf etwas, was mehrere CPUs nutzt.”

Till Schulte-Coerne: Und wo ist dann genau der Unterschied, ob ich jetzt eine CPU oder ein Board habe, wo 20 CPUs drauf sind. Ist das schon Grid-Computing oder bedeutet es letzten Endes mehr?

Thomas Kentemich: Nein, da muss man die Begriffe noch etwas weiter erklären. Wenn ich jetzt 20 CPUs in einen Sack stecke oder auf ein Board – wie du gerade gesagt hast – hat das natürlich noch nichts mit Parallelität zu tun. Vielleicht sollte man zur Begriffsklärung erstmal sagen – was öfter verwechselt wird oder geklärt werden muss – es gibt einmal Concurrency und es gibt Parallelität. Concurrency bedeutet zunächst mal, dass ich mehrere Tasks in meiner Anwendung unabhängig voneinander ausführen kann. D.h. also, ich habe zunächst mal von meinem Programmansatz oder von meinen Datenstrukturen her die Möglichkeit, das Ganze auf mehrere unabhängige Teile zu verteilen, ohne dass die erstmal miteinander was zu tun haben. Eine klassisches Beispiel ist z.B., jeder moderne Kernel, wie z.B. der Linux-Kernel oder auch Windows, kann die mittlerweile vorhandene Multicores nutzen, indem es verschiedene Tasks auf verschiedenen Kernen rechnet. Das ist Concurrency, hat aber nichts damit zu tun, dass diese Sachen interagieren. Parallelität kommt dann ins Spiel, wenn ich sage: “Ich habe nicht nur Programmteile, die unabhängig voneinander sind, sondern sie gehören zu einem einzigen Problem und müssen halt entsprechend für die Lösung des Problems Daten austauschen.”

Till Schulte-Coerne: Ich habe mal irgendwo gelesen, das eine ist, wenn man ganz viele kleine Probleme gleichzeitig lösen möchte, aber sehr schnell. Und das andere ist, wenn man ein sehr großes Problem oder eine geringe Zahl von großen Problemen parallelisieren eben muss, ne? Letzten Endes sowas in die Richtung.

Thomas Kentemich: Ja die Schwierigkeit dabei, bei diesem Ansatz, wenn man sagen wir mal… Zunächst mal ist es so, nicht alle Programme – besonders ältere Programme und gerade in der wissenschaftlichen Community hat man es halt oft mit älteren Programmen zu tun – sind überhaupt erstmal darauf vorbereitet concurrent abzulaufen, sondern die sind halt von ihrer Datenstruktur her oft so gebaut, dass sie sehr monolithisch sind, dass sie halt im Grunde gar nicht verteilt werden können.

Till Schulte-Coerne: “int main”.

Thomas Kentemich: Genau so ist das. Oder auch Fortran ist auch z.B. noch sehr verbreitet mit großen statischen Arrays, die man halt so ohne weiteres nicht aufteilen kann. Das große Problem ist halt, wenn ich den Schritt vollziehe zu einem Concurrent-Programm, muss ich zunächt mal meine Programmstruktur anpassen, damit das Programm überhaupt in der Lage ist, sowas abzubilden. Bei einem parallel Programm gibt’s jetzt wiederum verschiedene Ansätze, wie ich die Datenstrukturen verwende und unter welchem Paradigma so ein Programm läuft, ne? Der große Oberbegriff ist z.B., dass man es nach den Memory-Strukturen klassifiziert. Wir haben also shared-memory und distributed-memory oder geteilter Speicher und verteilter Speicher. Und dementsprechend muss ich verschiedene Programmiermodelle anwenden.

Till Schulte-Coerne: Also das bedeutet jetzt, Grid-Computing – um mal auf das Thema zurück zu kommen – ist letzten Endes eine Gesamtarchitektur um Concurrency, äh Parallelität zu etablieren – eben gerade nicht Concurrency. Oder wie soll man sich… Also es ist jetzt nicht rein eine Hardware-Architektur, sondern bezieht sich auch mit auf die Software z.B.?

Thomas Kentemich: Genau, also Grid-Computing ist eigentlich entstanden, also zunächst mal die Parallel-Rechner waren zuerst da und das Grid-Computing hat halt da im Grunde genommen die Idee hinzugefügt, die eigentlich entstanden ist durch eine Analogie zum World Wide Web. Das World Wide Web hat halt Informationen global verteilt verfügbar gemacht und die Idee hinter Grid- Computing ist jetzt eigentlich nicht nur Informationen global verfügbar zu machen, sondern Rechenleistung global verfügbar zu machen.

Also ein guter Vergleich ist halt, der immer wieder angeführt wird, ist unser Stromnetzwerk. Wir haben irgendwo große Kraftwerke, die Leistung zur Verfügung stellen und was ich als Benutzer eigentlich nur machen muss, ist, ich muss mein Gerät in die Steckdose einstecken, habe entsprechend dann die Leistung, die ich vom Kraftwerk abrufen kann.

Das ist genau die Idee, die hinter Grid-Computing steckt. Ich habe also große Compute-Server, die in der Lage sind, Probleme zu berechnen und ich habe im Grunde genommen Client-Anwendungen, mit denen ich dann global von überall auf diese Infrastruktur zugreifen kann.

Till Schulte-Coerne: Also Grid nicht im Sinne von Gitter oder ähnlichem, also irgendeiner Struktur, sondern wirklich in dem Sinne, das ist ein Netz.

Thomas Kentemich: Genau, da steckt das englische power grid, also die Übersetzung ins Deutsche für unser Stromnetz im Grunde genommen dahinter.

Till Schulte-Coerne: Und wie grenzt man das z.B. gegen das ja heute so populäre Cloud-Computing ab? Oder ist das schon wieder durch, ich weiß es gar nicht.

Thomas Kentemich: Ich würde mal sagen, über Grid-Computing haben wir schon gesprochen, als Cloud-Computing noch gar nicht gab. Also Cloud-Computing ist eigentlich eine Verbindung zwischen dem Grid-Computing – der Idee, ich verteile für mathematische Anwendungen Rechenleitungen im Netz – und der Verknüpfung mit der Idee, wir benutzen z.B. Web-Browser und Web-Technologien, um auf diese verteilte Ressourcen zuzugreifen. Also Cloud-Computing geht mehr in die Richtung, das für die Allgemeinheit zur Verfügung zu stellen.

Till Schulte-Coerne: Ist ja auch irgendwie ein Marketing-Begriff unter dem eh jeder denkt, was er will. Also letzten Endes würdest du es eher als ein Aspekt davon betrachten.

Thomas Kentemich: Genau, es ist im Grunde genommen halt eine Erweiterung des Grid-Computing und eine Modernisierung dieses Begriffs eigentlich. Grid- Computing hat angefangen eben gerade in der akademischen, wissenschaftlichen Welt, um eben nicht nur eine Ressource, einen Großcomputer nutzen zu können, sondern mehrere zur Bearbeitung von Problemen.

Till Schulte-Coerne: Und wo ist dann z.B. auf der anderen Seite die Abgrenzung gegen ja wahrscheinlich statische Strukturen, wie Cluster und ähnliche Dinge?

Thomas Kentemich: Ja, da unterscheiden sich jetzt im Wesentlichen, da muss man unterscheiden zwischen “Was macht ein Parallel-Rechner oder ein Grid eigentlich aus?”. Es besteht natürlich zum einen aus CPUs, die eine Rechenleistung zur Verfügung stellen, entsprechend mit Speicher und was man da halt alles braucht. Und zum anderen ist beim Parallel Computing halt ganz wichtig, die Kommunikationsnetzwerke, die dazwischen sind. Ich hatte eben schon gesagt, ein paralleles Programm zeichnet sich halt dadurch aus, dass die Teile des Programms miteinander kommunizieren müssen. Das kann man vielleicht verdeutlichen, ein ganz populärer Ansatz ist z.B., nehmen wir mal an, ich habe ein Problem, was im Grunde auf einem rechteckigen Gitter beruht. Eine Parallelisierung davon wäre jetzt z.B., ich teile das Gitter in n Teile auf und rechne jedes Teilproblem auf einer CPU. Das ist so ein klassischer Parallelisierungsansatz. Solange diese Teile jetzt nicht miteinander zu tun haben, ist auch alles in Ordnung und wird nicht weiter schwierig. Aber in dem Moment, wo ich jetzt Daten, die die CPU eins hat, auf CPU zwei brauche, muss ich die Daten irgendwie zur Verfügung stellen.

Till Schulte-Coerne: Spielen da in diese Rechtecke auch solche Sachen wie Map and Reduce und ähnliche Algorithmen dann rein?

Thomas Kentemich: Das ist eine Spezialisierung dieser Sachen, die man hat. Kommunikationsmuster können wir vielleicht später nochmal drauf zurück kommen. Worum es halt geht ist, um ein paralleles Programm effizient zu betreiben, brauche ich nicht nur CPU-Leistung, sondern auch Kommunikationsleistung. Man kann sich ja vorstellen, in dem Moment, wo jetzt ein Teil-Computer einer solchen parallelen Maschine oder eines Grids Daten rüber schaufeln muss auf die andere Seite, ist er natürlich nicht in der Lage, Berechnungen auszuführen. Es sei denn er ist intern wieder parallel, aber das ist ein Spezialfall. Auf jeden Fall hat man immer Kalkulation und Kommunikation. Also ein balancierter Parallelrechner zeichnet sich dadurch aus, dass er im Prinzip schnell rechnen kann, aber auch schnell kommunizieren kann. Und beim Grid ist das jetzt gerade so ein Spezialfall, weil die Grids sind in der Regel über Internet gekoppelt, also über normale Standardnetzwerke, was natürlich bedeutet, dass die CPU dadrin eine wesentlich höhere Rechenleistung haben, als die Kommunikationsleistung ist. D.h. also, auf Grid passen im Grunde genommen nur besondere Arten von Algorithmen, die relativ kommunikationsarm sind. Man sagt auch, die sind lose gekoppelt. Wenn ich jetzt eine Anwendung habe, die sehr viele Daten austauscht, dann läuft die natürlich besser auf einer Architektur wie einem Cluster oder einem speziellen Super-Computer, der ein dedizierte Netzwerk hat, welches möglicherweise eine wesentlich höhere Geschwindigkeit zum Datenaustausch bietet.

Till Schulte-Coerne: Höhere geografische Nähe und ähnliches.

Thomas Kentemich: Genau.

Till Schulte-Coerne: Und ein Beispiel wäre dann wahrscheinlich, was vielen vielleicht in den Kopf kommt – ist jetzt schon ein wenig vorbei, dass es auf Jedermanns Bildschirm war – wäre dann sowas, wie SETI@home vielleicht. Ist das eine Form von Grid-Computing?

Thomas Kentemich: Ja.

Till Schulte-Coerne: Also damals ging es ja darum, das Strahlen aus dem All analysiert wurden – von der NASA glaube ich –, die dann Daten-Häppchen weltweit verteilt haben, wenn ich das so richtig wiedergebe.

Thomas Kentemich: Genau. SETI@home oder – gibt auch einige andere – Folding@home, die sich mit Faltung von Proteinstrukturen [beschäftigen]. Es gibt auch noch einige andere Projekte, die sich mit Arzeimittel-Zielinteraktion beschäftigen. Das ist eine Klasse von Problemen, die nennt man so schön: embarrassingly parallel, was im wesentlichen bedeutet, die Dinge haben keine Kommunikation. Das heißt also, das ist eine hervorragende Anwendung, um sie auf einem globalen Grid zu rechnen. Das geht sogar so weit, SETI@home z.B. analysiert Radiosignale aus dem Weltall. Der Server bei SETI stellt im Grunde genommen einen kurzen Daten-File mit den Signalen zur Verfügung. Die werden dann auf alle angeschlossenen Rechner – in dem Fall sind das einfach ganz normale PCs, wo die Benutzer ihre CPU zur Verfügung stellen, wenn sie z.B. ansonsten den Bildschirmschoner laufen lassen würden. Es gibt einige von den Programmen, die Rechnen sogar als Bildschirmschoner, da kann man zugucken. Die werden auf die Computer übertragen, der Computer zu Hause unter dem Schreibtisch oder der Laptop, der grad nichts zu tun hat, rechnet und schickt das Ergebnis an SETI zurück. Und der hat nichts mit den 100.000 anderen Computern zu tun, die auch in diesem Programm grad zufällig drin sind.

Till Schulte-Coerne: Das ist eigentlich schon keine Klasse von Concurrency mehr, sondern geht schon fast – ääh, entschuldigung, jetzt habe ich es wieder verwechselt. Keine Parallelität…

Thomas Kentemich: Es ist concurrent, aber gar nicht mehr parallel.

Till Schulte-Coerne: Also eher langweilige Probleme. Aber relevant für die Menschheit wahrscheinlich.

Thomas Kentemich: Genau.

Till Schulte-Coerne: Ja. Du hattest eben schon mal kurz die Kommunikationsmuster angesprochen.

Thomas Kentemich: Ja.

Till Schulte-Coerne: Ich habe glaube ich nach Map/Reduce gefragt. Was gibt es denn da so alles? Wie sieht sowas üblicherweise aus? Also ich hab jetzt meine 2.000 Rechner, die über ein mittel-schnelles Netz verbunden sind. Was lasse ich jetzt darauf los?

Thomas Kentemich: Ja gut, das ist natürlich sehr stark problemgetrieben, was man da los lässt. Es gibt solche Standard-Kommunikationsmuster – ich rede jetzt mal nicht über shared memory Kommunikations, weil die passiert ja im Grunde genommen dadurch, dass man einen gemeinsamen Speicher hat. Aber die richtig großen Maschinen, die massiv parallel sind, haben eigentlich alle eine distributed memory Architektur. D.h. also, die Speicher sind nicht lokal, sondern ich muss über irgendeinen Mechanismus über den Draht gehen. Und das nennt man in der Regel, was man da so macht, ist sogenanntes Message passing. Also im Grunde genommen mache ich eine Sende- und eine Empfangsoperation. Das sind die Grundoperationen, die ich dafür brauche. Ich sende einen Teil Daten und ich kann von dem anderen empfangen. Es gibt eine riesen Variation, wie ich die Adressierungen mache, wie ich Kommunikationsräume gegeneinander absetze. Und da gibt es jetzt wiederum, muss man unterscheiden, der simpelste Baustein ist eigentlich eine, wie ich sagte Sende- und Empfangsoperation. D.h., der eine Partner sagt: “Ich schicke dir Daten.”, der andere muss sagen: “Ich bin bereit zu empfangen.”, er empfängt die Daten und kann dann mit den Daten weiterrechnen. Dieses Muster hat z.B. den Nachteil, dass der Empfänger in der Regel blockiert, solange die Daten noch nicht da sind. Das ist also eine blockierende Kommunkations. Das ist eins von den Standard-Kommunikationsmustern. Das ist nicht so gut, weil in der Zeit, wo der sozusagen in dem Receive hängt und wartet, kann er nicht rechnen. Und ich kaufe mir die Maschine, um zu rechnen, nicht um Däumchen zu drehen.

Das bedeutet also, als der Stelle kommt jetzt ein zweites Kommunikationsmuster sehr stark rein, das ist die nicht-blockierende Kommunikation. Was bedeutet, auf der Sender-Seite habe ich ein nicht-blockierendes Senden, d.h. also, ich warte gar nicht, dass der andere die Daten entgegen nimmt, sondern mache sowas – wie die Amerikaner so schön sagen – fire and forget. Also ich schicke das raus und der Empfänger wird es schon irgendwann empfangen. Der Empfänger auf der anderen Seite signalisiert nur, “Ich wäre im Prinzip bereit die Nachricht zu empfangen.”, stellt möglicherweise Speicherplatz zur Verfügung, wo die abgelegt werden kann. Es kommt eine Nachricht und die landet in dem Speicherbereich, aber der ist noch gar nicht so weit die anzunehmen, sondern rechnet gerade noch. Dieses Muster hat den großen Vorteil, dass ich jetzt Kalkulation und Kommunikation überlappen kann, was einen großen Performance-Gewinn bringt normalerweise.

Till Schulte-Coerne: Du delegierst letzten Endes die Warterei auf den Kernel, auf den Betriebssystem-Kernel. Das ist ja auch etwas, was man aktuell relativ häufig sieht im Umfeld des node.js-Hypes z.B., wo es ja auch um diese asynchrone Programmierung geht. Ist das dann noch üblicherweise das Muster, in dem dann Programme geschrieben werden, die auf solchen Grids laufen? Sind die asynchron? Macht man nur asynchrones IO mit Scala oder node.js?

Thomas Kentemich: Man muss da auch an der Stelle wieder sehr stark aufs Problem gucken. Es gibt einmal die Geschichte, dass ich natürlich asynchron kommunizieren kann. Aber gleichzeitig verlangen viele Programme oder viele Problemstellungen, dass ich an gewissen Stellen Synchronisationspunkte einbaue, einfach um die Geschichten wieder in Gleichschritt zu bringen, weil ansonsten das auseinander läuft. Es gibt also neben diesen Kommunikationsmustern, die ich gerade hatte, gibt es halt eine Klasse von Synchronisationspunkten, die heißen klassischerweise Barrier. Ein Barrier funktioniert so, dass ich halt sozusagen einen Wartepunkt habe, wie eine Verkehrsampel, wo erstmal alle hinkommen müssen und dann geht es weiter. Was bei den Kommunkationsmuster dann natürlich noch sozusagen auf diese Primitive wie Send und Receive oben drauf kommt, ist natürlich, dass ich solche Sachen habe, wie Getter und Scatter. Also ich verteile was von einem Prozessor auf n andere oder ich sammle von n anderen ein. Und darauf wieder aufgesetzt gibt es wieder solche Sachen wie Reduce – da sind wir wieder bei dem, was du eben als Beispiel brachtest – wo ich halt z.B. eine parallele Summe bilde über n Knoten und am Ende muss ich die alle zusammen summieren. Das ist dann so eine Reduce-Operation, wo ich am Ende ein Ergebnis bekomme, bei diesen Sachen. Und es gibt noch einen ganzen Sack voll anderer Operationen, die aber mehr oder weniger spezieller sind jetzt sage ich mal. Das waren eigentlich so die Grund-Primitive, die man da so zur Verfügung hat.

Till Schulte-Coerne: Ja, wir reden ja jetzt auch… Wenn ich am Anfang an Grid- Computing gedacht habe, habe ich eher so in der Hardware-Kategorie gedacht. Aber wir reden ja jetzt eigentlich über Software.

Thomas Kentemich: Wir haben gerade über Software geredet, ja.

Till Schulte-Coerne: Genau, das merke ich auch langsam. Die Frage ist halt, also wenn man das Thema Grid-Computing mit dem gesamten Stack mehr oder weniger assoziiert, was ist denn dann üblicherweise das, was ich dann einsetze? Gibt es da spezielle Programmiersprachen, die man für Grid-Computing benutzt? Oder nutzt man da Java für oder wie genau funktioniert das?

Thomas Kentemich: Also das ist eigentlich, soweit ich das auch immernoch beobachte, relativ konservativ auch, sage ich jetzt mal. Das liegt zum einen daran, dass natürlich die wissenschaftlichen Programme sehr konservativ sind. D.h., da besteht die Tendenz, eine einmal bestehende, funktionierende Lösung weiter zu verwenden. Und wenn die nunmal Fortran oder in C geschrieben ist, dann verwendet man die weiter. Und für die eigentliche Umsetzung der Parallelisierung wird halt auch im Grunde – es gibt eine ganze Reihe von, sagen wir mal von wissenschaftlichen Ansätzen. Aber das meiste, was du auch im kommerziellen Umfeld – also viele Firmen in der Automobil-Industrie z.B. setzen mittlerweile auch parallelisierte Versionen von bestimmten Programmen ein – die setzen in der Regel alle auf sowas auf, wie dieses Message Passing Interface, was ein Standard ist eigentlich. Das ist eine Library-Lösung, d.h. also, ich schreibe ein Programm mit bestimmten expliziten Kommunikationsfunktionen, linke dazu eine Library, die jetzt halt speziell optimiert ist für die Architektur, auf der ich laufe und dann habe ich ein Programm, was ich sozusagen ausführen kann.

Till Schulte-Coerne: Aber das passiert jetzt nicht automatisch?

Thomas Kentemich: Nein, das passiert nicht automatisch, das ist alles noch immer ein manueller Prozess. Es gibt auch Ansätze, gerade im Bereich shared memory, also jetzt nicht verteilte Speicher, sondern wo ich im Prinzip n CPUs auf einer Maschine habe, die alle einen gemeinsamen Speicher haben. Da gibt es auch automatisierte Lösungen, z.B. die modernen Compiler sind alle in der Lage, Auto- Parallelisierung auf Loops zu machen. Im Prinzip Schleifen selber zu verteilen auf verschiedene Threads bzw. sie können auch auto-vektorisieren. D.h. also, sie benutzen die Vektoreinheiten der CPUs automatisch, ohne dass ich im ersten Schritt jetzt hingehen muss und muss explizit irgendwas tun. Das funktioniert in der Regel auch bis zu einem gewissen Punkt ganz gut, aber meistens kommen die irgendwann an eine Grenze, wo man dann doch manuell Hand anlegen muss, ne.

Till Schulte-Coerne: Jaja, die Magie hat ihre Grenzen. Wenn du die shared memory Thematik erwähnst, denkst du denn dann bei Grid-Computing eigentlich schon an jeden Heim-Rechner, wo ein Quad-Core Prozessor drin ist? Ist das für dich auch schon Grid-Computing?

Thomas Kentemich: Naja, wir haben ja an dem Beispiel von SETI gesehen, dass das schon Grid-Computing sein kann. Wobei…

Till Schulte-Coerne: Wobei, bei SETI ergibt es sich ja erst durch das Gesamtsystem.

Thomas Kentemich: Ein Grid ist ein Gesamtsystem. Du kannst…

Till Schulte-Coerne: Aber ich mein, ist ein einfacher Rechner mit vier Prozessor-Kernen für dich schon ein Grid?

Thomas Kentemich: Nein, auf keinen Fall, weil das ist natürlich – wenn der isoliert da steht, kann er Teil eines Grids werden, aber es ist bis jetzt keine…

Till Schulte-Coerne: Weil es keine verteilte Kommunikation…

Thomas Kentemich: Genau. Außer den SETI-Anwendungen gibt es im Grunde genommen keinen Ansatz, wo man sagen kann, ich kann jetzt bei meinem Nachbarn z.B. zwei CPUs abzweigen, weil der jetzt gerade nichts zu tun hat und könnte darauf mein Photoshop Bild rendern oder berechnen.

Till Schulte-Coerne: Bot-Netze vielleicht noch.

Thomas Kentemich: Ja. Da spielt natürlich eine Menge, gerade wenn man über solche Ansätze nachdenkt wie allgemeine Computer zur Verfügung zu stellen für ein globales Grid, da spielen natürlich Sicherheitsaspekte und – sage ich jetzt mal – persönliche Gründe eine große Rolle. Warum soll ich meinem Nachbarn jetzt meine CPU zur Verfügung stellen, ist eine Frage, die sich sicherlich einige Leute stellen würden, wenn man so einen Ansatz versuchen würde.

Till Schulte-Coerne: Üblicherweise ist es ja auch nicht der Nachbar, der die Wettervorhersage für morgen berechnen will, sondern ein kommerzielles Institut. Dann wird es nochmal eine Nummer schlimmer. Aber wenn irgendwann dann die Wetter-Institute – sind das so die klassischen Kunden, sozusagen? Also wo setzt man solche Algorithmen ein, außer in der Wissenschaft?

Thomas Kentemich: Ja also, das sind eigentlich die Großen. Die großen Treibenden der Parallelitätsgeschichte waren eigentlich immer einerseits die Wetterinstitute, also die halt Wetterberechnungen machen. Die sind auch heute noch die größten Abnehmer für, ich sage mal, zivile Parallel-Rechner. Also ich habe eine zeitlang mal gearbeitet mit dem europäischen Zentrum für mittelfristige Wettervorhersage. Die sitzen in England, das ist eine europäische Initiative. Und die hatten zu der Zeit immer die größte Maschine. Das lag halt daran, dass Wetterberechnung von der CPU-Last und überhaupt auch des Speicherbedarfs der groß ist, also sehr aufwendig ist und die hatten ein zweites Problem, dass die Wettervorhersage natürlich fertig sein sollte, bevor das Wetter von morgen natürlich da ist. Und das war am Anfang ein riesen Problem, weil die einfach nicht schnell genug rechnen konnten. Und mittlerweile ist es so, die haben immernoch riesen Maschinen, die werden auch immernoch größer, haben aber jetzt mittlerweile etwas umgeschwenkt, weil die sind schon in der lange, eine Wettervorhersage sehr schnell zu berechnen – sagen wir mal innerhalb von Stunden, was man halt braucht. Aber was die heute machen ist, die benutzen diese großen, riesigen Maschinen eigentlich, um mehrere Vorhersagen parallel laufen zu lassen und damit parametrisierte Studien zu machen. Also die drehen ein bisschen an den Simulationsparametern, lassen mehrere Simulationen parallel laufen und dann guckt jemand Menschliches drauf und sagt: “Ok, das ist die Wettervorhersage für morgen.” Und so läuft es halt auch bei den ganz großen Rechnern, die es jetzt gibt, mit Hunderttausenden von CPUs, die sind natürlich – es gibt keine Anwendung, die auf 100.000 CPUs gleichzeitig läuft.

Till Schulte-Coerne: Also letzten Endes, wenn dann irgendwann noch viel mehr Ressourcen da sind, dann bist du dir auch relativ sicher, dass sich dann auch irgendjemand Sachen ausdenkt, die das dann auch wieder auslasten.

Thomas Kentemich: Also das ist ganz sicher so. Das ist schon immer so gewesen. Je größer die Maschine ist, desto schneller waren die Probleme da, die man da auch wieder nicht drauf rechnen konnte. Das ist so eine Art Naturgesetz, ne. Die Maschine ist nie groß genug.

Till Schulte-Coerne: Im Kontext der Berechnung, der hochperformanten Berechnung, insbesondere von Fließkommazahlen und Ähnlichem, taucht ja jetzt ständig das Wort GPU auf. Also Graphics Processor Unit.

Thomas Kentemich: Genau.

Till Schulte-Coerne: Wie spielt das da so rein? Also ist das einfach ein weiterer Knoten in deinem Grid, die Grafikkarte dann, oder wie genau?

Thomas Kentemich: Ja, die gehört eigentlich nicht unbedingt ins Grid rein, sondern das ist eigentlich mehr so eine Geschichte, das ist sozusagen der Supercomputer unterm Schreibtisch. Das ist also, eine Grafikkarte, die ich benutze, ist ein ganz spezieller Parallelrechner, der sich nur für eine ganz spezielle Klasse von Problemen eignet, ne. Da muss man jetzt ein bisschen weiter ausholen. Also eine Grafikkarte ist im Grunde genommen nichts anderes als ein hochperformanter Vektorprozessor. D.h. also, der ist darauf spezialisiert bestimmte Vektoroperationen sehr, sehr schnell auszuführen. Und ich kann das nutzen für bestimmte Klassen von Problemen, um das sehr kostengünstig zu machen. Weil das Ding steckt in meinem Desktop drin, es ist – sagen wir mal – eine Standard-schnelle Grafikkarte von einer bestimmten Firma, kostet – weiß ich nicht – 300, 400 Euro. Das ist von dem Kostenaufwand her sehr überschaubar. Es gibt mittlerweile von denen eine ganz gute Unterstützung, Programme auf diese Grafikkarten drauf zu bringen.

Till Schulte-Coerne: Auch automagisch? Oder explizit?

Thomas Kentemich: Nein, also es gibt automatische Lösungen. Es wird aber zum großen Teil auch explizit programmiert. Das ist dann dieses CUDA z.B. Das ist von Nvidia. Das ist halt eine Bibliothek, die die zur Verfügung stellen, wo man das auch mit – im Prinzip so, wie ich das früher gesagt habe – so mit expliziten Kommunikationsanweisungen die Daten vom Hauptrechner auf die Grafikkarte rüber schaufelt. Dann hat man einen Programmteil, der auf der Grafikkarte läuft, die Berechnung macht und die Daten werden wieder zurück geschaufelt. Das ist aber immernoch weitestgehend ein manueller Prozess. Es gibt mittlerweile sowas wie OpenMP, was das halt so ein bisschen kapselt.

Till Schulte-Coerne: Also letzten Endes hat das einfach für euch Grid-Freaks eine weitere Optimierungsmöglichkeit oder ein weiteres Potential geschaffen, wo ich bestimmte Klassen von Problemen hin delegieren könnt.

Thomas Kentemich: Ja.

Till Schulte-Coerne: Und dann nochmal schneller…

Thomas Kentemich: Ja, die Dinge werden eigentlich im Prinzip eigentlich hauptsächlich als Co-Prozessoren eingesetzt, interessanterweise jetzt. Weil die ganz großen Maschinen, die wir haben, also die Supercomputer, die richtig mehrere Tausende von CPUs haben, die sind mittlerweile fast alles Hybrid- Rechner. Also die haben einmal normale CPUs auf ihren Boards stecken und haben einen Satz von Grafikkarten drin stecken, die die als numerische Co-Prozessoren benutzen für Vektoroperationen.

Till Schulte-Coerne: Wo auch kein Monitor dran angeschlossen ist.

Thomas Kentemich: Da ist kein Monitor angeschlossen, das darf auch nicht sein, weil die Dinger sollen auch nicht. Es gibt also eine spezielle z.B. von Nvidia, gibt’s spezielle Karten, die zwar Grafikkarten sind, aber keine Grafikkarten- Ausgänge mehr haben. Die kann mal also im Prinzip rein als Co-Prozessoren betreiben. Die werden auch so betrieben.

Till Schulte-Coerne: Ja. Jetzt haben wir einige Zuhörer sicherlich total angefixt. Und die wollen jetzt direkt anfangen, ihre Hello World-Anwendung in die Grid zu bringen, nicht mehr in die Cloud. Was ist denn so üblicherweise der Punkt, wo man merkt: “Ok, ich habe jetzt hier ein Problem, ich brauche sowas.”? Wann passiert das üblicherweise? Weiß ich das immer von vornherein? Oder können Probleme wachsen oder wie sieht das aus? Was sind so die klassischen Kunden?

Thomas Kentemich: Ja, so wie ich das eben schon gesagt habe, ist im Grunde genommen – das ganze hat damit zu tun, dass ich irgendwie an die Grenze komme. Also entweder komme ich an die Grenze der Laufzeit, das einfach mein Problem, was ich habe, zu lange braucht. Das ist ein sicheres Zeichen, dass ich es halt auch auf der neuesten Generation von Prozessoren nicht mehr in der Zeit durch bekomme, die ich brauche. Oder es ist halt das Zeichen, dass ich im Grunde genommen eine tolle Idee habe und dafür eine große Menge von Daten analysieren muss z.B. oder eine große Menge an Daten prozessieren muss und es einfach auf meiner Maschine nicht mehr schaffe, weil irgendwelche Ressourcen ans Ende kommen. Also die ganze Geschichte mit Grid-Computing, Parallel-Computing hat wie gesagt sehr viel damit zu tun, dass ich an diese Grenze komme. Der Schritt, wenn man jetzt von einer Anwendung, die man jetzt einfach so schon hat, zu einer paralleler Anwendung ist ein großer, in der Regel. Weil eben, wie ich auch gerade eben schon sagte, man normalerweise Programmstrukturen ändern muss, Datenstrukturen ändern muss. Ein guter Einstieg für sowas ist sicherlich, wenn man sagt, man bleibt jetzt erstmal auf dem kleinen Feld “Ich habe eine Multiprozessor-Maschine” – was für viele Anwendungen vielleicht ja auch ok ist. Da kann man anfangen, mal mit OpenMP oder OpenCL – das ist eine Variante im Grunde genommen davon, was von den meisten Compilern von Intel oder auch von GNU mittlerweile unterstützt wird – kann man anfangen, kleinere Sachen, wie der Berechnungsloop, der bei mir die meiste Zeit braucht, zu versuchen auf verschiedene Kerne zu verteilen. Das ist ein Einstieg, den jeder einfach gehen kann.

Genauso kann er sich, wenn das noch ein bisschen weiter gehen soll, Richtung Vektor-Computing, kann man anfangen, sich mit CUDA oder OpenMP zu beschäftigen, was ein bisschen mehr Aufwand bedeutet. Für den Einsatz im kommerziellen Umfeld, also wenn man, ich sage mal man möchte gerne eine kommerzielle Application umsetzen, ist es natürlich so, da wird in der Regel dann wahrscheinlich eine Cluster-Lösung in Frage kommen, wo man dann halt eben auch besser verteilen kann. Die Probleme noch besser verteilen kann auf wirkliche Hardware-Ressourcen.

Till Schulte-Coerne: Also du denkst, unsere klassische Kundschaft im Banken- Sektor oder in der Telekommunikation wird eher kein Grid sich in den Keller stellen, sondern…

Thomas Kentemich: In der Telekommunikation nicht, die Banken sind – das ist aber jetzt glaube ich nicht der Kreis, den wir direkt haben – die sind natürlich wahnsinnig interessiert daran, Finanzmodelle z.B. möglichst schnell zu rechnen. Da kommt dann halt dieses Sekunden-Trading, was die betreiben, kommt da mit rein. Ich möchte halt bestimmte Portfolios in möglichst ganz kurzer Zeit analysieren, um zu gucken, ob der Kauf, den ich in der nächsten Sekunde tätigen will, eine gute oder eine schlechte Auswirkung hat.

Till Schulte-Coerne: Aber das Vorgehen ist dann eher statisch, d.h., man stellt sich dann halt eine ganz bekannte und nicht wachsende, fixe Anzahl von Rechnern, also eben ein Cluster in den Keller eher und würde nicht diesen dynamischen Aspekt in Kauf nehmen.

Thomas Kentemich: Da würde man nicht aufs Grid gehen, sondern das hat ja auch was damit zu tun, dass ich in so einem Fall, in so einer speziellen Anwendung auch die totale Kontrolle über das Gerät brauche. Ich mein, es gibt da auch immer so den Aspekt “Kann ich die Daten denn überhaupt überall hinbringen oder brauche ich die Daten tatsächlich lokal bei mir?” Es ist auch letztendlich eine Abwägungssache, ob man Geld investiert und sich eine eigene Infrastruktur hinstellt, was viel Geld kostet. Und gerade im Bereich von Parallel-Computing wird das sehr schnell, sehr teuer. Oder ob man versuchen kann, was anderes mit zu benutzen. Wobei ich im Moment nicht weiß, dass irgendeiner, ich sage mal, wirklich Computing – also im Sinne von Ingenieur mäßigem Computing – einfach so als Serviceleistung anbietet.

Till Schulte-Coerne: Gibt es denn, wenn man jetzt als Privatmensch sich für das Thema interessiert, Projekte oder Frameworks, an denen man sich beteiligen kann? Also gibt es irgendwelche Initiativen, wo man einfach mitmachen kann oder sowas ähnliches?

Thomas Kentemich: Also man kann natürlich…

Till Schulte-Coerne: Oder ist das Thema so ausgefallen und teuer letzten Endes?

Thomas Kentemich: Wenn man natürlich selber programmieren will, ist es natürlich so, da weiß ich jetzt nicht, dass es da etwas gibt, was so direkt im Sinne eines Open-Source-Projekt gilt. Open-Grid oder wie man es nennen möchte oder Open- Source-Grid. Kenne ich nicht. Es gibt ein sehr lustiges Projekt, das ist vielleicht was für Schulen oder auch für jemanden, der sich vielleicht so ein bisschen Geld investieren will. Es gibt eine Initiative von der Universität von South Hampton, diese kleinen RasPis – also die Rechner, die wir auch sicherlich rumliegen haben – in einen Parallelrechner zu verarbeiten. Da kann man also 64 von den Dingern, das ist sehr nett gemacht. Der Sohn von dem, der das Projekt betreibt, der hat ein Lego-Gehäuse gebaut, wo die Rechner, die Platinen drin sind und hat da halt einen kleinen Parellelrechner mit NPA mit 64 CPUs. Das ist halt als Modell für Schulen oder auch für Universität, um die Schüler, die Studenten da mal ran zu bringen, ist das gar keine so schlechte Idee, weil es ist kostenmäßig sehr überschaubar, man kann da nicht viel kaputt machen, bei den Dingern und es ist trotzdem ein richtiger Parallelrechner.

Till Schulte-Coerne: Ja, vielen Dank. Ich habe sehr viel erfahren. Hast du noch irgendwelche abschließenden Worte zum Thema? Oder fällt dir nichts ein? Dann sage ich einfach so: Vielen Dank und bis zum nächsten Mal.

Thomas Kentemich: Gut.