Stephen Jones ist leitender Softwareentwickler bei SpaceX und ehemaliger CUDA-Architekt bei NVIDIA
In diesem Beitrag gibt Stephen Jones seine Perspektive auf Aspekte der Technologie wieder, die für Neu skalieren's Benutzer. Als wichtiger Beitrag zu CUDAViele Rescale-Benutzer haben mithilfe seiner Arbeit an der GPU-Technologie Analysen durchgeführt und andere haben mithilfe von CUDA-Bibliotheken eigene Codes erstellt. Da ich nach einigen Jahren in der allgemeinen Softwareentwicklung wieder mit technischer Software arbeite, fand ich es aus persönlicher Sicht interessant, Stephen einige Fragen zu den technologischen Fortschritten der letzten Jahre und seiner Einschätzung zukünftiger Trends zu stellen.

Um den Ball ins Rollen zu bringen, begann ich mit der Entwicklung des Parallelrechnens:
Stephen Jones: Vor etwa 10 Jahren wurde die gesamte Datenverarbeitung parallelisiert. Die einzelnen Prozessoren wurden nicht mehr schneller, und Moores Gesetz wurde durch das Hinzufügen weiterer Prozessoren fortgesetzt (Consumer-Prozessoren haben alle mindestens 4 Kerne, Server können 16 oder mehr haben – jedes nicht-parallele Programm nutzt daher nicht mehr als 25 % der Maschine). Ich denke, ein wichtiger Effekt entsteht dadurch, dass sich parallele Programmierung in mehreren grundlegenden Punkten von serieller Programmierung unterscheidet, was sie wesentlich schwieriger macht. Ich gehe davon aus, dass parallele Programmierung in Zukunft nicht mehr von Menschen, sondern von Werkzeugen (Compilern, Bibliotheken, automatisierten Programmiersprachen) durchgeführt wird, und dass dies einen grundlegenden Wandel in der Herangehensweise an die gesamte Programmierung bedeuten wird.

Bei Rescale haben wir einen vielfältigen Kundenstamm. Viele unserer Partner in der Industrie oder Akademie Arbeiten Sie vor Ort mit High Performance Computing (HPC)-Clustern. Ich habe Stephen gefragt, was HPC für ihn bedeutet:
Stephen Jones: Ich sehe das als einen allgemeinen Begriff, der die neueste Computertechnologie abdeckt. Das Universum ist komplex, und wir sind weit davon entfernt, es präzise modellieren zu können. Daher finden wir immer neue Aufgaben für immer größere Computer. Die technologischen Fortschritte, die die Computer leisten, eröffnen neue Probleme, die wir vorher nicht lösen konnten. HPC wird es immer geben und ein Nischenmarkt bleiben. Andererseits wird es aufgrund der bereits erwähnten Komplexität des Universums nicht so schnell durch „leistungsfähigere“ Desktops ersetzt werden. Es fungiert als ein sehr interessanter Technologie-Inkubator, sowohl in Bezug auf Hard- als auch Software.

Ingenieure und Wissenschaftler weltweit nutzen die Plattform neu skalieren um die Ressourcen ihrer Organisation zu ergänzen und zu erweitern. Ich fragte Stephen, wie er die Nutzung von Cloud-Technologien im HPC sieht:

Stephen Jones: Das ist einer der großen Wegbereiter der letzten zehn Jahre. Insbesondere Amazons Cloud ist bahnbrechend und (meiner Meinung nach) eine der erstaunlichsten Neuerungen in der Computerwelt. Bei der Finanzierung eines Startups kann man heute sagen: „Meine Infrastruktur ist AWS, also geben wir kein Geld für Hardware aus.“ Besonders interessant ist, dass es HPC und grundlegende IT-Infrastruktur ermöglicht. So können Startups mit Massive-Scale-Computing neue Wege gehen, die für so kleine Unternehmen bisher unerreichbar waren. Tatsächlich können wir 10-mal so viele Leute für HPC entwickeln lassen wie je zuvor, und das muss zu neuen, interessanten Anwendungen führen.

In meiner Rolle als Anwendungsingenieur hier bei Rescale habe ich kürzlich einige Open-Source-Pakete erstellt und installiert, die die Vorteile von CUDA nutzen und NVIDIA Hardware auf der Rescale-Plattform. Ich habe Stephen nach seinen persönlichen Erfahrungen mit der Arbeit an CUDA gefragt:

Stephen Jones: Es fällt mir natürlich schwer, objektiv zu sein, da ich jahrelang der Architekt von CUDA war. Parallele und HPC-Programmiersprachen zeichnen sich durch einen Ansatz aus, der auf den kleinsten gemeinsamen Nenner setzt – niemand möchte in hochkomplexen Code investieren, der nur auf einer einzigen Maschine läuft und den Kauf einer anderen Maschine verhindert. Das Ergebnis ist das Problem des „von einem Komitee entworfenen Codes“, gepaart mit dem „Meister von nichts“. CUDA ist interessant, weil es bewusst ins andere Extrem geht – es funktioniert nur auf einem einzigen Maschinentyp, kann aber dadurch Grenzen verschieben, da es nicht durch den Versuch eingeschränkt ist, es allen recht zu machen. CUDA ist derzeit erfolgreich, weil die NVIDIA-GPU im HPC-Bereich weit verbreitet ist. Dadurch untersucht CUDA viele neue Aspekte des Programmiermodells als Erstes. Viele CUDA-Funktionen finden in der einen oder anderen Form ihren Weg in andere Sprachen (OpenCL, OpenMP, Renderscript), weil sie sich als nützlich erweisen. Der eigentliche Vorteil von CUDA liegt darin, dass die Sprachentwickler Hardware-Unterstützung von den Chipentwicklern erhalten (da sie im selben Unternehmen arbeiten) und so neue Möglichkeiten eröffnen, die unabhängigen Sprachentwicklern verwehrt bleiben. CUDA bietet viele innovative Funktionen, und dank dieser engen Zusammenarbeit werden in Zukunft noch mehr folgen.

Mir ist bei neuen Codes aufgefallen, dass Forscher durch den gezielten Einsatz von Python in wissenschaftlichen Projekten eine höhere Produktivität erzielen. Ich fragte Stephen, welche Kombination von Tools (darunter auch Sprachen) er Wissenschaftlern oder Ingenieuren empfehlen würde, die maximale Produktivität erreichen möchten, damit sie ihre eigentliche Arbeit erledigen können:

Stephen Jones: Ich bin der Meinung, dass man Software immer in der höchstmöglichen Programmiersprache und mit möglichst wenigen Zeilen schreiben sollte. Selbst bei Hochleistungscode beanspruchen oft nur 10 % der Codezeilen 90 % der Zyklen. Wenn diese 10 % einen bekannten Algorithmus (lineare Algebra, Fourier-Transformation usw.) implementieren, kann man oft auf eine Standardimplementierung zurückgreifen, die jemand anderes optimiert hat.

Das bedeutet, dass Sie oft alles in einer höheren Programmiersprache wie SciPy oder NumPy erledigen und die zugrunde liegenden Bibliotheken für die Hauptarbeit verwenden können. Ich würde sagen, Sie wären verrückt, wenn Sie das nicht täten – es führt zu wartungsfreundlicherem Code mit weniger Zeilen und weniger Fehlern, und was für die Industrie am wichtigsten ist: Sie können viel einfacher Leute einstellen, die Python beherrschen, als Leute, die sich mit komplexen, parallelen Programmiersprachen auskennen. Ihre Codebasis hat dann eine viel längere Lebensdauer.

Interessant wird es, wenn die CPU-intensiven Operationen keine Standardalgorithmen sind. Sie müssen sie dann selbst implementieren, und auch hier empfehle ich die höchstmögliche Programmiersprache. Dabei ist die Balance zwischen Wartbarkeit und Leistung zu berücksichtigen: Möglicherweise möchten Sie akzeptieren, nicht die Spitzenleistung zu erreichen, um dafür wartbareren, zukunftssicheren Code zu schreiben. Mit NumPy beispielsweise kann ich einige CUDA-bezogene Parallelisierungen in einem Python-Framework durchführen, mit einer beachtlichen Beschleunigung bei sehr geringem Aufwand.

Bei SpaceX strebe ich etwa 75 % der Spitzenleistung an, da die restlichen 25 % die Entwicklung des Codes deutlich erschweren und – was am wichtigsten ist – die Zukunftssicherheit beeinträchtigen. Diese zusätzlichen 25 % sind es einfach nicht wert, wenn ich ihn alle paar Jahre für neue Architekturen neu programmieren muss. Zugegeben, wir verwenden Python nicht für unseren Performance-Code, aber wir nutzen es für eine Vielzahl von Dingen, die in C++ viel zu kompliziert wären.
Was Entwicklungstools angeht, achte ich immer darauf, welche Sprache und/oder Plattform die besten Diagnosetools bietet. Debugger, Profiler und Analysetools können mir buchstäblich 50 % meiner Entwicklungszeit sparen. Daher greife ich zuerst auf eine Kombination aus diesen Tools und einer höheren Programmiersprache zurück. Wie Sie sehen, bin ich ein Python-Fan, aber es hängt wirklich vom Anwendungsfall ab. Matlab bietet ebenfalls hervorragende Tools, ist allerdings an ein Framework gebunden.

Ein Wort zu anderen Sprachen. Insbesondere Haskell erfreut sich derzeit großer Beliebtheit. Als funktionale Programmiersprache parallelisiert es viel natürlicher als eine imperative Sprache und sieht interessant aus. Die Wissenschaft ist sehr daran interessiert, aber ich denke, der Talentpool ist zu klein, um es in der Industrie einzusetzen: Gute Leute zu finden ist schon für Python schwer genug, geschweige denn für C.
Ich fragte ihn anschließend, wie er die Zukunft von FORTRAN sehe, einer Sprache, die in technischen Analysen immer noch häufig verwendet wird.

Stephen Jones: Es wird verschwinden, da Computer es immer weniger ausführen können. Es ist nicht von Natur aus parallel, daher muss man ein Framework wie MPI darum herum aufbauen. Ich denke, dass größere (Exascale-)Computer mit MPI immer schwieriger zu programmieren sein werden und dass dies das Ende von FORTRAN bedeuten wird. Im Gegensatz zu C ist FORTRAN in der Low-Level-Programmierung nicht präsent und wird daher verschwinden, sobald die verstaubten Decks endlich neu geschrieben werden.
Ein letztes Wort, ein Blick in die Kristallkugel: Ich glaube, die Zukunft des Programmierens liegt im Software-Schreiben von Software. Das heißt, ich werde ein Programm schreiben, das die Programme für mich schreibt. Compiler leisten bereits viel für uns; High-Level-Frameworks wie Ruby bewältigen alle Arten von Komplexität in der Webprogrammierung; Autoparallelisierung (sic) ist derzeit ein großes Schlagwort (obwohl sie noch nicht so weit ist). Computer werden immer schwieriger zu programmieren sein, und wir werden es nur mit der Hilfe anderer Computer schaffen …
Als wir zum Thema der Zusammenarbeit mit Leuten kamen, die ich gerne „echte Ingenieure“ nenne (Offenlegung: Mein erster Ingenieurjob war in einer Schiffsreparaturwerft), war Stephen ebenso offen.

STephen Jones: Es ist wirklich interessant, als Software-Experte in einem reinen Maschinenbau-Umfeld zu arbeiten. Ein Computer ist ein Werkzeug wie jedes andere Laborgerät, und niemand könnte sich Ingenieursarbeit ohne ihn vorstellen. Allerdings nutzen Nicht-Software-Ingenieure in allen Ingenieurbüros, die ich kenne, sie wie Werkzeuge (das heißt auf eine softwaretechnisch eher unbedarfte Art und Weise).

Schließlich ist Softwareentwicklung und ihre Beziehung zum Ingenieurwesen ein Thema, das mich wirklich interessiert. Ich habe Stephen nach seiner Meinung dazu gefragt.

Stephen Jones: Das ist ein weiterer wichtiger Punkt. Ich erlebe es täglich bei SpaceX und versuche, diese Lücke zu schließen. Vor ein paar Monaten besuchte ich eine Konferenz zum Thema technische Simulation und traf dort ein Dutzend Leute, die alle überraschend ähnliche Geschichten zu erzählen hatten (wie ich auch) – mangelndes Softwareverständnis ist weit verbreitet und ein echtes Handicap für Ingenieure. Wir müssen Ingenieure viel besser ausbilden, als wir es in der Bedienung und Programmierung von Computern tun – es ist nicht wie mit einer Bohrmaschine oder einer Säge, deren Bedienung man einfach so im Job lernen kann. Unternehmen, die sich die Zeit für diese Ausbildung nehmen, profitieren deutlich von technischer Innovation und Produktivität. Das gilt übrigens für alle Wissenschaften, nicht nur für die Ingenieurwissenschaften. Während meiner Arbeit im HPC-Bereich für NVIDIA traf ich unzählige brillante Physiker, Chemiker und Biologen, die mit diesen hochkomplexen Supercomputern ihre Spitzenforschung kaum betreiben konnten. Am erfolgreichsten waren diejenigen, die aktiv das Programmieren gelernt hatten, anstatt sich einfach durchzuwursteln. Oft leisten weniger erfahrene Physiker bessere Arbeit, weil sie den Computer effektiver nutzen können. Es besteht unbestreitbar die Einstellung – sowohl in der Wissenschaft als auch in der Technik –, dass Software „weniger rein“ sei. Ich vermute jedoch, dass sich dies als generationsübergreifend erweisen wird, da die Menschen heute von Kindheit an mit Computern in der Hand aufwachsen.

Vielen Dank an Stephen für seine einzigartige Perspektive. Neu skalieren, werden wir weiterhin daran arbeiten, Wissenschaftlern und Ingenieuren die Erreichung ihrer Ziele zu ermöglichen, indem wir ihnen die skalierbaren Computerressourcen bereitstellen, die sie benötigen.