00:17 Einführung
03:35 Größenordnungen
06:55 Phasen der supply chain Optimierung
12:17 Die S-Kurven der Hardware
15:52 Bisherige Entwicklung
17:34 Hilfswissenschaften
20:25 Moderne Computer
20:57 Latenz 1/2
27:15 Latenz 2/2
30:37 Rechnen, Taktfrequenz
36:36 Rechnen, Pipelining, 1/3
39:11 Rechnen, Pipelining, 2/3
40:27 Rechnen, Pipelining, 3/3
46:36 Rechnen, superskalar 1/2
49:55 Rechnen, superskalar 2/2
56:45 Speicher 1/3
01:00:42 Speicher 2/3
01:06:43 Speicher 3/3
01:11:13 Datenspeicherung 1/2
01:14:06 Datenspeicherung 2/2
01:18:36 Bandbreite
01:23:20 Fazit
01:27:33 Bevorstehende Vorlesung und Publikumsfragen
Beschreibung
Moderne supply chains benötigen Rechenressourcen, um zu funktionieren, genauso wie motorisierte Förderbänder Strom benötigen. Dennoch bleiben träge supply chain Systeme allgegenwärtig, während die Rechenleistung von Computern seit 1990 um mehr als das 10.000-fache gestiegen ist. Ein mangelndes Verständnis der grundlegenden Eigenschaften moderner Rechenressourcen – selbst in IT- oder data science Kreisen – trägt wesentlich zur Erklärung dieses Sachverhalts bei. Das Software-Design, das den numerischen Rezepten zugrunde liegt, sollte den zugrunde liegenden Rechenunterbau nicht antagonisieren.
Vollständiges Transkript
Willkommen zu dieser Reihe von supply chain Vorträgen. Ich bin Joannes Vermorel, und heute werde ich „Moderne Computer für supply chain präsentieren.“ Westliche supply chains wurden bereits vor langer Zeit digitalisiert, manchmal vor bis zu drei Jahrzehnten. Computerbasierte Entscheidungen sind allgegenwärtig, und die damit verbundenen numerischen Rezepte tragen verschiedene Namen wie Bestellpunkte, Min-Max Inventar und Sicherheitsbestände, jeweils mit unterschiedlichen Graden menschlicher Aufsicht.
Nichtsdestotrotz, wenn wir heutzutage große Unternehmen betrachten, die ebenso große supply chains betreiben, sehen wir Millionen von Entscheidungen, die im Wesentlichen computergesteuert sind und die Leistung der supply chain antreiben. Folglich läuft die Verbesserung der supply chain performance schnell darauf hinaus, die numerischen Rezepte zu verbessern, die die supply chain steuern. Dabei führt es unweigerlich dazu, dass überlegene numerische Rezepte – mit besseren Modellen und genaueren Prognosen – am Ende deutlich mehr Rechenressourcen kosten.
Rechenressourcen sind für supply chain eine Herausforderung, da sie viel Geld kosten, und es gibt immer die nächste Evolutionsstufe für das nächste Modell oder das nächste Prognosesystem, das das Zehnfache an Rechenressourcen erfordert als das vorherige. Ja, das könnte zu einer besseren supply chain performance führen, aber es geht mit höheren Rechenkosten einher. In den letzten Jahrzehnten hat sich die Hardware von Computern enorm weiterentwickelt, aber wie wir heute sehen werden, wird dieser Fortschritt, obwohl er noch andauert, häufig durch Enterprise-Software antagonisiert. Infolgedessen wird die Software nicht schneller, wenn modernere Hardware zum Einsatz kommt; im Gegenteil, sie kann sehr häufig langsamer werden.
Ziel dieser Vorlesung ist es, dem Publikum ein gewisses Maß an mechanischer Sympathie zu vermitteln, sodass Sie beurteilen können, ob ein Stück Enterprise-Software, das dazu dienen soll, numerische Rezepte zur Steigerung der supply chain performance umzusetzen, die vorhandene und künftige Rechenhardware – wie sie bereits existiert und in einem Jahrzehnt existieren wird – annimmt oder ob es diese antagonisiert und somit im Wesentlichen nicht das volle Potenzial der heutigen Rechenhardware ausschöpft.
Einer der verwirrendsten Aspekte moderner Computer ist der Umfang der eingesetzten Größenordnungen. Aus der supply chain perspective haben wir in der Regel etwa fünf Größenordnungen, und das ist bereits eine Herausforderung; meist sind es sogar weniger. Fünf Größenordnungen bedeuten, dass man von einer Einheit zu 100.000 Einheiten gelangen kann. Erinnern Sie sich daran, dass ich in früheren Vorlesungen das Gesetz der kleinen Zahlen erwähnt habe. Wenn Sie eine große Anzahl von Einheiten haben, werden Sie diese nicht einzeln verarbeiten, sondern in Kartons verpacken, sodass wesentlich weniger Kartons übrig bleiben. Ebenso, wenn Sie viele Kartons haben, werden Sie diese auf Paletten verpacken, sodass Sie eine deutlich geringere Anzahl von Paletten haben. Economies of scale führen zu Prognosen von Mengen, und aus der supply chain perspective, wenn es um den Fluss physischer Güter geht, ist eine 10%ige Ineffizienz bereits recht signifikant.
Im Bereich der Computer ist es ganz anders; hier bewegen wir uns mit 15 Größenordnungen, was absolut gigantisch ist. Von einer Einheit zu einer Million Milliarden Einheiten – die Zahl ist so groß, dass sie kaum vorstellbar ist. Wir gehen von einem Byte aus, das nur acht Bits umfasst und dazu verwendet werden kann, einen Buchstaben oder eine Ziffer darzustellen, bis hin zu einem Petabyte, das einer Million Gigabytes entspricht. Ein Petabyte entspricht in etwa der Größenordnung der Menge an Daten, die Lokad derzeit verwaltet, und große Unternehmen, die große supply chains betreiben, arbeiten ebenfalls mit Datensätzen in der Größenordnung eines Petabytes.
Wir gehen von einem FLOP (Gleitkommaoperationen pro Sekunde) zu einem petaFLOP, also einer Million GigaFLOPS. Diese Größenordnungen sind absolut gigantisch und sehr trügerisch. In der supply chain Arena, in der 10% bereits als ineffizient gelten, passiert es im Bereich der Computer typischerweise, dass es nicht um eine Ineffizienz von 10% geht, sondern um eine Ineffizienz um den Faktor 10 und manchmal um mehrere Größenordnungen. Wenn also etwas in Bezug auf die Leistung im Bereich der Computer schiefgeht, beträgt Ihre Strafe nicht 10 %; stattdessen wird Ihr System 10-mal langsamer sein, als es sein sollte, oder 100-mal, und manchmal sogar 1000-mal langsamer als vorgesehen. Genau darum geht es: um eine echte Abstimmung, die eine Art mechanischer Sympathie zwischen der Enterprise-Software und der zugrunde liegenden Rechenhardware erfordert.
Wenn man ein numerisches Rezept in Betracht zieht, das eine überlegene supply chain performance liefern soll, gibt es ein Set von Reifestufen, die konzeptionell von Interesse sind. Offensichtlich können die praktischen Ergebnisse variieren, aber typischerweise haben wir bei Lokad die folgenden Stufen identifiziert: Es soll funktionieren, es soll korrekt sein, es soll schnell sein und es soll günstig sein.
“Make it work” bedeutet zu beurteilen, ob ein Prototyp eines numerischen Rezepts tatsächlich die beabsichtigten Ergebnisse liefert, wie z. B. höhere Service Levels, weniger veraltete Bestände, eine bessere Auslastung der Anlagen oder jedes andere Ziel, das aus der Perspektive der supply chain erstrebenswert ist. Das Ziel ist zunächst, sicherzustellen, dass das neue numerische Rezept in der ersten Reifestufe tatsächlich funktioniert.
Anschließend muss man es “make it right” machen. Aus der Perspektive der supply chain bedeutet das, einen im Wesentlichen einzigartigen Prototyp in etwas mit Produktionsqualität zu verwandeln. Dies beinhaltet typischerweise, dem numerischen Rezept ein gewisses Maß an Korrektheit durch Design hinzuzufügen. Supply chains sind riesig, komplex und, was noch wichtiger ist, sehr chaotisch. Wenn Sie ein numerisches Rezept haben, das sehr fragil ist, selbst wenn die numerische Methode gut ist, ist es sehr leicht, Fehler zu machen, und am Ende entstehen viel mehr Probleme, als der ursprünglich beabsichtigte Nutzen. Das ist kein Gewinnkonzept. Es korrekt zu machen bedeutet, sicherzustellen, dass Sie etwas haben, das mit minimalen Reibungsverlusten im großflächigen Einsatz bereitgestellt werden kann. Danach wollen Sie dieses numerische Rezept schnell machen – und wenn ich schnell sage, meine ich in Bezug auf die reale Zeit. Wenn Sie die Berechnung starten, sollten Sie die Ergebnisse innerhalb von Minuten oder höchstens ein bis zwei Stunden erhalten – aber nicht länger. Supply chains sind chaotisch, und es wird in der Geschichte Ihres Unternehmens einen Zeitpunkt geben, an dem es zu Störungen kommt, wie Containerschiffe, die mitten im Suezkanal festsitzen, eine Pandemie oder ein Lager das überschwemmt wird. Wenn das passiert, müssen Sie in der Lage sein, schnell zu reagieren. Ich sage nicht, dass dies in den nächsten Millisekunden geschehen muss, aber wenn Ihre numerischen Rezepte Tage zur Fertigstellung benötigen, entsteht erhebliche operative Reibung. Sie benötigen Systeme, die innerhalb eines kurzen menschlichen Zeitrahmens betrieben werden können – sie müssen also schnell sein.
Denken Sie daran, dass moderne Enterprise-Software in Clouds läuft und Sie jederzeit für mehr Rechenressourcen auf Cloud-Plattformen zahlen können. Ihre Software kann also tatsächlich schnell sein, einfach weil Sie sich viel Rechenleistung mieten. Es ist nicht so, dass die Software selbst so gestaltet sein muss, dass sie die gesamte Rechenleistung einer Cloud ausnutzt, sondern sie kann schnell und sehr ineffizient sein, nur weil Sie so viel Rechenleistung von Ihrem Cloud-Anbieter mieten.
Die nächste Stufe besteht darin, die Methode günstig zu machen, das heißt, sie soll nicht zu viele Cloud-Rechenressourcen verbrauchen. Wenn Sie diese letzte Stufe nicht erreichen, bedeutet das, dass Sie Ihre Methode nie verbessern können. Wenn Sie eine Methode haben, die funktioniert, korrekt und schnell ist, aber viele Ressourcen verbraucht, und Sie dann zur nächsten Stufe eines numerischen Rezepts übergehen wollen – welches unweigerlich noch mehr Rechenressourcen erfordert als Ihre derzeitige Lösung – werden Sie feststecken. Sie müssen Ihre bestehende Methode extrem schlank machen, damit Sie mit numerischen Rezepten experimentieren können, die weniger ressourcenintensiv sind als Ihre aktuelle.
Diese letzte Stufe ist der Punkt, an dem Sie die zugrunde liegende Hardware moderner Computer wirklich nutzen müssen. Mit den ersten drei Stufen kommen Sie oft ohne allzu große Affinität aus, aber die letzte ist entscheidend. Denken Sie daran, wenn Sie die “günstig machen”-Stufe nicht erreichen, können Sie nicht iterieren, und Sie werden feststecken. Deshalb ist es, selbst wenn es die letzte Stufe ist, ein iterativer Prozess, und es ist unerlässlich, alle Stufen durchzugehen, wenn Sie wiederholt iterieren wollen.
Die Hardware macht Fortschritte, und es scheint eine exponentielle Entwicklung zu sein, doch in Wahrheit setzt sich dieser exponentielle Fortschritt der Computerhardware aus Tausenden von S-Kurven zusammen. Eine S-Kurve beschreibt einen Verlauf, bei dem Sie ein neues Design, einen neuen Prozess, ein neues Material oder eine neue Architektur einführen, und zunächst ist es nicht wirklich besser als das, was Sie zuvor hatten. Dann setzt die Wirkung der beabsichtigten Innovation ein, es kommt zu einem Anstieg, gefolgt von einem Plateau, nachdem alle Vorteile der Innovation ausgeschöpft wurden. Plateauende S-Kurven sind charakteristisch für den Fortschritt in der Computerhardware, der aus Tausenden dieser Kurven besteht. Aus Laienperspektive erscheint dies als exponentielles Wachstum. Experten hingegen sehen, dass die einzelnen S-Kurven ein Plateau erreichen, was zu einer pessimistischen Sichtweise führen kann. Selbst die Experten erkennen nicht immer das Aufkommen neuer S-Kurven, die alle überraschen und das exponentielle Wachstum des Fortschritts weiter vorantreiben.
Obwohl die Computerhardware weiterhin Fortschritte macht, liegt die Fortschrittsrate bei weitem nicht mehr auf dem Niveau der 1980er oder 1990er Jahre. Das Tempo ist mittlerweile viel langsamer und recht vorhersehbar, weitgehend aufgrund der massiven Investitionen, die erforderlich sind, um neue Fabriken zur Herstellung von Computerhardware zu errichten. Diese Investitionen belaufen sich oft auf Hunderte Millionen Dollar und bieten eine Sichtbarkeit von fünf bis zehn Jahren in die Zukunft. Obwohl der Fortschritt sich verlangsamt hat, haben wir immer noch eine ziemlich genaue Vorstellung davon, was in Bezug auf den Fortschritt der Computerhardware im nächsten Jahrzehnt passieren wird.
Die Lehre für Enterprise-Software, die numerische Rezepte implementiert, ist, dass Sie nicht passiv darauf vertrauen können, dass zukünftige Hardware alles für Sie verbessert. Die Hardware macht zwar weiterhin Fortschritte, aber diese Fortschritte zu nutzen, erfordert Anstrengungen von Seiten der Software. Sie werden in der Lage sein, mit der Hardware, die in einem Jahrzehnt existiert, mehr zu erreichen – aber nur, wenn die Architektur im Kern Ihrer Enterprise-Software die zugrunde liegende Computerhardware annimmt. Andernfalls könnten Sie tatsächlich schlechter abschneiden als heute – ein Szenario, das gar nicht so unvernünftig klingt.
Diese Vorlesung ist die erste des vierten Kapitels in dieser Reihe von supply chain Vorträgen. Ich habe das dritte Kapitel über supply chain personae noch nicht abgeschlossen. In den folgenden Vorlesungen werde ich vermutlich zwischen dem aktuellen Kapitel, in dem ich die Hilfswissenschaften der supply chain behandle, und dem dritten Kapitel über supply chain personae abwechseln.
Im allerersten Kapitel des Prologs habe ich meine Ansichten über supply chain sowohl als Fachgebiet als auch als Praxis vorgestellt. Wir haben gesehen, dass supply chain im Wesentlichen eine Ansammlung vertrackter Probleme ist, im Gegensatz zu harmlosen Problemen, die von gegnerischem Verhalten und Wettbewerbsspielen geprägt sind. Daher müssen wir der Methodik große Aufmerksamkeit schenken, weil naive, direkte Herangehensweisen in diesem Bereich schlecht funktionieren. Aus diesem Grund war das zweite Kapitel der Methodik gewidmet, die benötigt wird, um supply chains zu untersuchen und Praktiken zu etablieren, um sie im Laufe der Zeit zu verbessern.
Das dritte Kapitel, Supply Chain Personae, konzentrierte sich auf die Charakterisierung der supply chain Probleme selbst, mit dem Motto “verliebe dich in das Problem, nicht in die Lösung.” Das vierte Kapitel, das wir heute eröffnen, handelt von den Hilfswissenschaften der supply chains.
Hilfswissenschaften sind Disziplinen, die das Studium einer anderen Disziplin unterstützen. Es gibt kein Werturteil; es geht nicht darum, dass eine Disziplin einer anderen überlegen ist. Zum Beispiel ist die Medizin nicht der Biologie überlegen, aber die Biologie ist eine Hilfswissenschaft für die Medizin. Die Perspektive der Hilfswissenschaften ist gut etabliert und in vielen Forschungsgebieten, wie den medizinischen Wissenschaften und der Geschichte, verbreitet.
In den medizinischen Wissenschaften umfassen die Hilfswissenschaften unter anderem Biologie, Chemie, Physik und Soziologie. Ein moderner Arzt würde als inkompetent gelten, wenn er keinerlei Kenntnisse in Physik hätte. Zum Beispiel ist das Verständnis der Grundlagen der Physik notwendig, um ein Röntgenbild zu interpretieren. Gleiches gilt für die Geschichte, die eine lange Reihe von Hilfswissenschaften aufweist.
Wenn es um supply chain geht, ist eine meiner größten Kritiken an typischen supply chain Materialien, Kursen, Büchern und Aufsätzen, dass sie das Thema behandeln, ohne in irgendeine Hilfswissenschaft einzutauchen. Sie behandeln supply chain, als ob es sich um ein isoliertes, in sich abgeschlossenes Wissensgebiet handeln würde. Ich bin jedoch der Ansicht, dass moderne supply chain Praxis nur durch die vollständige Nutzung der Hilfswissenschaften von supply chains erreicht werden kann. Eine dieser Hilfswissenschaften, und der Schwerpunkt der heutigen Vorlesung, ist die Rechnerhardware.
Diese Vorlesung ist nicht ausschließlich eine supply chain Vorlesung, sondern vielmehr eine Vorlesung über Rechnerhardware mit supply chain Anwendungen im Blick. Ich bin der Ansicht, dass dies grundlegend für das moderne Praktizieren von supply chain ist, im Gegensatz zur Vorgehensweise vor einem Jahrhundert.
Schauen wir uns moderne Computer an. In dieser Vorlesung werden wir betrachten, was sie für supply chain leisten können, wobei wir uns insbesondere auf Aspekte konzentrieren, die einen massiven Einfluss auf die Leistung von Enterprise-Software haben. Wir werden Latenz, Rechenleistung, Speicher, Datenspeicherung und Bandbreite untersuchen.
Die Lichtgeschwindigkeit beträgt etwa 30 Zentimeter pro Nanosekunde, was relativ langsam ist. Betrachtet man die charakteristische Distanz für eine moderne CPU, die mit 5 Gigahertz (5 Milliarden Operationen pro Sekunde) arbeitet, so beträgt die Hin- und Rückstrecke, die das Licht in 0,2 Nanosekunden zurücklegen kann, nur 3 Zentimeter. Das bedeutet, dass aufgrund der Begrenzung durch die Lichtgeschwindigkeit keine Interaktionen über 3 Zentimeter hinaus stattfinden können. Dies ist eine harte Einschränkung, die durch die Gesetze der Physik auferlegt wird, und es ist unklar, ob wir sie jemals überwinden können.
Latenz ist eine außerordentlich schwierige Einschränkung. Aus der Perspektive von supply chain haben wir mindestens zwei Arten der Verteilung von Rechnerhardware. Wenn ich von verteilter Rechnerhardware spreche, meine ich Rechnerhardware, die viele Geräte umfasst, die nicht denselben physischen Raum einnehmen können. Offensichtlich müssen Sie diese voneinander getrennt halten, einfach weil sie eigene Abmessungen haben. Der erste Grund für verteiltes Rechnen liegt jedoch in der Natur von supply chains, die geografisch verteilt sind. Per Definition erstrecken sich supply chains über verschiedene Regionen, und folglich wird auch die Rechnerhardware über diese Regionen verteilt sein. Betrachtet man die Lichtgeschwindigkeit, so ist es bereits sehr langsam, selbst wenn sich Geräte nur drei Meter voneinander entfernt befinden, da es 100 Taktzyklen für den Hin- und Rückweg benötigt. Drei Meter stellen aus der Perspektive der Lichtgeschwindigkeit und der Taktfrequenz moderner CPUs eine beträchtliche Distanz dar.
Eine weitere Art der Verteilung ist horizontale Skalierung. Die moderne Methode, mehr Rechenleistung zur Verfügung zu haben, besteht nicht darin, ein Rechengerät zu besitzen, das 10-mal oder eine Million Mal leistungsstärker ist; so wird es nicht konstruiert. Wenn Sie mehr Rechenressourcen wünschen, benötigen Sie zusätzliche Rechengeräte, mehr Prozessoren, mehr Speicherschips und mehr Festplatten. Durch das Aufstapeln der Hardware können Sie mehr Rechenressourcen zur Verfügung haben. Allerdings benötigen all diese Geräte Platz, und so endet man damit, die Rechnerhardware zu verteilen, einfach weil man sie nicht in einen zentimetergroßen Computer zentralisieren kann.
Wenn es um Latenzen geht, stellen wir fest, dass die Latenzen im professionellen Internet (die Latenzen, die man in einem Rechenzentrum erhält, nicht über das heimische WLAN) bereits innerhalb von 30 % der Lichtgeschwindigkeit liegen. Zum Beispiel beträgt die Latenz zwischen einem Rechenzentrum in der Nähe von Paris, Frankreich, und New York, Vereinigte Staaten, nur 30 % der Lichtgeschwindigkeit. Dies ist eine unglaubliche Leistung der Menschheit; Informationen fließen im Internet nahezu mit Lichtgeschwindigkeit. Ja, es gibt noch Verbesserungspotenzial, aber wir nähern uns bereits den harten Grenzen, die die Physik auferlegt.
Folglich gibt es mittlerweile sogar Unternehmen, die Kabel über den Meeresboden der Arktis verlegen möchten, um London mit Tokyo zu verbinden – ein Kabel, das unter dem Nordpol verlaufen würde, um ein paar Millisekunden Latenz bei Finanztransaktionen einzusparen. Grundsätzlich sind Latenz und die Lichtgeschwindigkeit sehr reale Herausforderungen, und das Internet, das wir haben, ist im Wesentlichen so gut, wie es jemals sein wird, sofern nicht bahnbrechende physikalische Erkenntnisse gemacht werden. Allerdings steht in den nächsten zehn Jahren nichts dergleichen bevor.
Weil Latenz ein äußerst schwieriges Problem darstellt, sind die Auswirkungen auf Enterprise-Software erheblich. Hin- und Rückwege des Informationsflusses sind tödlich, und die Leistung Ihrer Enterprise-Software hängt weitgehend von der Anzahl der Hin- und Rückwege zwischen den verschiedenen Subsystemen ab, die in Ihrer Software existieren. Die Anzahl dieser Rundreisen charakterisiert die nicht weiter reduzierbare Latenz, die Sie erleiden. Die Minimierung von Rundreisen und die Verbesserung der Latenzen sind für die meisten Arten von Enterprise-Software, einschließlich solcher, die der prädiktiven Optimierung von supply chains gewidmet sind, das Hauptproblem. Die Verringerung der Latenz entspricht oft einer besseren Leistung.
Ein interessanter Trick – auch wenn nicht jeder Anwesende ihn in der Produktion einsetzen wird – besteht darin, die durch Latenz eingeführten Komplikationen zu adressieren. Die Zeit selbst wird flüchtig und verschwommen, wenn man in den Bereich der Nanosekunden-Berechnungen eintritt. Genaue Uhren sind in der verteilten Rechnerwelt schwer zu finden, und ihr Fehlen führt zu Komplikationen in der verteilten Enterprise-Software. Zahlreiche Hin- und Rückwege sind nötig, um die unterschiedlichen Teile des Systems zu synchronisieren. Aufgrund des Mangels an einer genauen Uhr enden Sie mit algorithmischen Alternativen wie Vektoruhren oder mehrteiligen Zeitstempeln, das sind Datenstrukturen, die eine partielle Anordnung der Gerätezählungen in Ihrem System widerspiegeln. Diese zusätzlichen Rundreisen können die Leistung beeinträchtigen.
Ein cleveres Design, das Google vor über einem Jahrzehnt adaptiert hat, war die Nutzung von Chip-Scale-Atomic-Clocks. Die Auflösung dieser Atomuhren ist erheblich besser als die von quartzbasierten Uhren, die in elektronischen Armbanduhren oder Computern zu finden sind. NIST demonstrierte ein neues Setup eines Chip-Scale-Atomic-Clock mit noch präziserem täglichen Drift. Google verwendete interne Atomuhren, um die verschiedenen Teile ihrer global verteilten SQL-Datenbank, Google Spanner, zu synchronisieren, um Rundreisen einzusparen und die Leistung global zu verbessern. Dies ist ein Weg, die Latenz mittels sehr präziser Zeitmessungen zu überwinden.
Blicken wir ein Jahrzehnt in die Zukunft, wird Google vermutlich nicht das letzte Unternehmen sein, das solch einen cleveren Trick anwendet, und sie sind relativ erschwinglich, da Chip-Scale-Atomic-Clocks etwa 1.500 $ pro Stück kosten.
Nun werfen wir einen Blick auf die Rechenleistung, also das Rechnen mit einem Computer. Die Taktfrequenz war in den 80er und 90er Jahren die magische Zutat zur Leistungsverbesserung. Tatsächlich würde sich die Leistung Ihres Computers effektiv verdoppeln, wenn Sie die Taktfrequenz über alle Bereiche hinweg verdoppeln könnten, ganz gleich, um welche Art von Software es sich handelt. Alle Software würde gemäß der Taktfrequenz linear schneller laufen. Es ist äußerst interessant, die Taktfrequenz zu erhöhen, und sie verbessert sich weiterhin, obwohl die Verbesserung im Laufe der Zeit abgeflacht ist. Vor fast 20 Jahren lag die Taktfrequenz bei etwa 2 GHz, und heutzutage beträgt sie 5 GHz.
Der Hauptgrund für diese abgeflachte Verbesserung ist die Power Wall. Das Problem besteht darin, dass, wenn Sie die Taktfrequenz eines Chips erhöhen, sich der Energieverbrauch ungefähr verdoppelt, und dann müssen Sie diese Energie abführen. Das Problem ist die thermische Ableitung, denn wenn Sie die Energie nicht ableiten können, baut sich Wärme in Ihrem Gerät auf, bis es beschädigt wird. Heutzutage hat sich die Halbleiterindustrie von mehr Operationen pro Sekunde zu mehr Operationen pro Watt gewandelt.
Diese Regel, dass eine 30%ige Erhöhung den Energieverbrauch verdoppelt, ist ein zweischneidiges Schwert. Wenn es Ihnen nichts ausmacht, ein Viertel Ihrer Rechenleistung pro Zeiteinheit auf der CPU einzubüßen, können Sie tatsächlich den Energieverbrauch halbieren. Das ist besonders interessant für Smartphones, bei denen Energiesparmaßnahmen entscheidend sind, und auch für Cloud Computing, wo einer der Hauptkostentreiber die Energie selbst ist. Um kosteneffiziente Rechenleistung im Cloud Computing zu erreichen, kommt es nicht darauf an, superschnelle CPUs zu haben, sondern eher darauf, untertaktete CPUs zu verwenden, die so langsam wie 1 GHz sein können, da sie mehr Operationen pro Sekunde für Ihre Energieinvestition liefern.
Das Problem der Power Wall ist so gravierend, dass moderne CPU-Architekturen allerlei clevere Tricks einsetzen, um es abzumildern. Zum Beispiel können moderne CPUs ihre Taktfrequenz regulieren, sie für einen kurzen Moment anheben und dann wieder senken, um Wärme abzuleiten. Sie können auch auf sogenanntes Dark Silicon zurückgreifen. Die Idee dahinter ist, dass, wenn die CPU die heißen Bereiche auf dem Chip abwechseln kann, es leichter ist, die Energie abzuführen, als wenn ständig derselbe Bereich aktiver Taktzyklen ausgesetzt ist. Dies ist ein sehr wesentlicher Bestandteil des modernen Designs. Aus der Perspektive der Enterprise-Software bedeutet das, dass Sie in der Lage sein sollten, horizontal zu skalieren. Sie sollten in der Lage sein, mit vielfach mehr CPUs mehr zu leisten, auch wenn diese Prozessoren einzeln schwächer sind als die bisherigen. Es geht nicht darum, bessere Prozessoren im Sinne von durchgängig überlegenen Geräten zu erhalten, sondern darum, Prozessoren zu haben, die mehr Operationen pro Watt liefern, und dieser Trend wird sich fortsetzen.
Vielleicht werden wir in einem Jahrzehnt mit Mühe sieben oder vielleicht acht Gigahertz erreichen, aber ich bin mir nicht einmal sicher, ob wir dorthin gelangen. Wenn ich mir die Taktfrequenz in den meisten Cloud Computing Anbietern im Jahr 2021 ansehe, liegt sie typischerweise bei etwa 2 GHz, sodass wir wieder bei der Taktfrequenz von vor 20 Jahren landen, und das ist die kosteneffektivste Lösung.
Die Erreichung der heutigen CPU-Leistung erforderte eine Reihe wichtiger Innovationen. Ich werde einige davon vorstellen, insbesondere die, die den größten Einfluss auf das Design von Enterprise-Software haben. Auf diesem Bildschirm sehen Sie den Befehlsfluss eines sequentiellen Prozessors, wie Prozessoren im Wesentlichen bis in die frühen 80er Jahre hergestellt wurden. Eine Reihe von Befehlen wird von oben nach unten ausgeführt, was die Zeit darstellt. Jeder Befehl durchläuft eine Reihe von Phasen: holen, decodieren, ausführen und zurückschreiben.
Während der Fetch-Phase holen Sie den Befehl, registrieren, greifen auf den nächsten Befehl zu, erhöhen den Befehlszähler und bereiten die CPU vor. In der Decode-Phase dekodieren Sie den Befehl und erzeugen den internen Mikrocode, den die CPU intern ausführt. Die Ausführungsphase beinhaltet das Abrufen der relevanten Eingaben aus den Registern und das tatsächliche Berechnen, und in der Write-Back-Phase wird das gerade berechnete Ergebnis in einem der Register abgelegt. In diesem sequentiellen Prozessor benötigt jede einzelne Phase einen Taktzyklus, sodass es vier Taktzyklen dauert, um einen Befehl auszuführen. Wie wir gesehen haben, ist es sehr schwierig, die Frequenz der Taktzyklen selbst zu erhöhen, aufgrund zahlreicher Komplikationen.
Der Schlüsseltrick, der seit den frühen 80er Jahren zur Anwendung kommt, ist das Pipelining. Pipelining kann die Berechnung Ihres Prozessors enorm beschleunigen. Die Idee ist, dass, weil jeder Befehl eine Reihe von Phasen durchläuft, diese Phasen überlappt werden, sodass der Prozessor selbst eine gesamte Pipeline von Befehlen hat. In diesem Diagramm sehen Sie einen Prozessor mit einer Pipeline-Tiefe von vier, bei der immer vier Befehle gleichzeitig ausgeführt werden. Sie befinden sich jedoch nicht in derselben Phase: ein Befehl befindet sich in der Fetch-Phase, ein anderer in der Decode-Phase, ein weiterer in der Execute-Phase und einer in der Write-Back-Phase. Mit diesem einfachen Trick, hier dargestellt als Pipeline-Prozessor, haben wir die effektive Leistung des Prozessors einfach durch Pipelining der Operationen vervierfacht. Alle modernen CPUs nutzen Pipelining.
Die nächste Stufe dieser Verbesserung wird als Super-Pipelining bezeichnet. Moderne CPUs gehen weit über das einfache Pipelining hinaus. In Wirklichkeit umfasst ein echter moderner CPU eher 30 Phasen. Im Diagramm sehen Sie einen Prozessor mit 12 Phasen als Beispiel, in Wirklichkeit wären es jedoch eher 30 Phasen. Mit dieser tieferen Pipeline können 12 Operationen gleichzeitig ausgeführt werden, was sehr gut für die Leistung ist, während immer derselbe Taktzyklus verwendet wird.
Es gibt jedoch ein neues Problem: Der nächste Befehl startet, bevor der vorherige abgeschlossen ist. Das bedeutet, wenn Befehle voneinander abhängig sind, entsteht ein Problem, weil die Berechnung der Eingaben für den nächsten Befehl noch nicht abgeschlossen ist und gewartet werden muss. Wir möchten die gesamte uns zur Verfügung stehende Pipeline ausnutzen, um die Rechenleistung zu maximieren. Daher holen moderne CPUs nicht nur einen Befehl zur Zeit, sondern etwa 500 Befehle gleichzeitig. Sie blicken weit voraus in die Liste der anstehenden Befehle und ordnen sie neu, um Abhängigkeiten zu mindern, und verflechten die Ausführungsabläufe, um die volle Tiefe der Pipeline auszunutzen.
Es gibt viele Faktoren, die diesen Prozess verkomplizieren, vor allem Verzweigungen. Eine Verzweigung ist einfach eine Bedingung in der Programmierung, wie zum Beispiel bei einer “if”-Anweisung. Das Ergebnis der Bedingung kann wahr oder falsch sein und je nach Ergebnis führt Ihr Programm entweder das eine oder das andere Logikstück aus. Dies erschwert das Abhängigkeitsmanagement, da die CPU die Richtung der kommenden Verzweigungen erraten muss. Moderne CPUs verwenden Zweigvorhersage, die auf einfachen Heuristiken basiert und eine sehr hohe Vorhersagegenauigkeit aufweist. Sie können die Richtung von Verzweigungen mit über 99 % Genauigkeit vorhersagen, was besser ist, als das die meisten von uns im echten supply chain Kontext tun können. Diese Präzision ist notwendig, um super tiefe Pipelines auszunutzen.
Um Ihnen eine Vorstellung von der Art der Heuristiken zu geben, die für die Zweigvorhersage verwendet werden, lautet eine sehr einfache Heuristik: Der Zweig wird in dieselbe Richtung gehen, in die er beim letzten Mal gegangen ist. Diese einfache Heuristik erreicht etwa 90 % Genauigkeit, was ziemlich gut ist. Wenn Sie dieser Heuristik eine Wendung hinzufügen – dass der Zweig in dieselbe Richtung geht wie beim letzten Mal, jedoch den Ursprung berücksichtigen, sodass es derselbe Zweig ist, der vom gleichen Ursprung kommt – erreichen Sie etwa 95 % Genauigkeit. Moderne CPUs verwenden tatsächlich recht komplexe Perzeptronen, eine Technik des maschinellen Lernens, um die Richtung der Verzweigungen vorherzusagen.
Unter den richtigen Bedingungen können Sie Verzweigungen ziemlich genau vorhersagen und so die volle Pipeline nutzen, um das Maximum aus einem modernen Prozessor herauszuholen. Aus der Perspektive der Softwareentwicklung müssen Sie gut mit Ihrem Prozessor zusammenarbeiten, insbesondere was die Zweigvorhersage betrifft. Wenn Sie nicht kooperieren, bedeutet das, dass der Zweigvorhersager es falsch einschätzen wird, und wenn das passiert, wird die CPU die Richtung des Zweigs vorhersagen, die Pipeline organisieren und beginnen, Vorberechnungen durchzuführen. Sobald der Zweig tatsächlich eintritt und die Berechnung im Grunde abgeschlossen ist, wird die CPU feststellen, dass die Zweigvorhersage falsch war. Eine falsche Zweigvorhersage führt nicht zu einem falschen Ergebnis; sie bedeutet einen Leistungsabfall. Die CPU hat keine Alternative, als die gesamte Pipeline oder einen großen Teil davon zu leeren, bis weitere Berechnungen durchgeführt werden, und dann mit der Berechnung neu zu beginnen. Der Leistungseinbruch kann sehr erheblich sein, und man kann leicht ein oder zwei Größenordnungen an Leistung einbüßen, bedingt durch Unternehmenssoftwarelogik, die nicht gut mit der Zweigvorhersagelogik Ihrer CPU harmoniert.
Ein weiterer bemerkenswerter Trick jenseits des Pipelining ist die superskalare Instruktion. CPUs verarbeiten typischerweise Skalare oder Paare von Skalaren gleichzeitig – zum Beispiel zwei Zahlen mit 32-Bit-Fließkommapräzision. Sie führen skalare Operationen aus, also im Wesentlichen die Verarbeitung einer Zahl nach der anderen. In den letzten zehn Jahren verfügen moderne CPUs jedoch nahezu alle über superskalare Instruktionen, die tatsächlich mehrere Vektoren von Zahlen verarbeiten und Vektoroperationen direkt durchführen können. Das bedeutet, dass eine CPU einen Vektor von, sagen wir, acht Fließkommazahlen und einen zweiten Vektor von acht Fließkommazahlen nehmen, eine Addition durchführen und einen Vektor von Fließkommazahlen erhalten kann, der die Ergebnisse dieser Addition darstellt. All dies geschieht in einem einzigen Zyklus.
Beispielsweise ermöglichen spezialisierte Befehlssätze wie AVX2, Operationen mit 32-Bit-Präzision in Paketen von acht Zahlen durchzuführen, während AVX512 dies in Paketen von 16 Zahlen ermöglicht. Wenn Sie in der Lage sind, diese Befehle zu nutzen, können Sie buchstäblich eine Größenordnung an Verarbeitungsgeschwindigkeit gewinnen, da ein Befehl, ein Taktzyklus, viel mehr Berechnungen durchführt als das sequentielle Verarbeiten von Zahlen. Dieser Prozess ist als SIMD (Single Instruction, Multiple Data) bekannt und ist sehr leistungsstark. Er treibt den Großteil des Fortschritts in puncto Rechenleistung in den letzten zehn Jahren an, und moderne Prozessoren sind zunehmend vektorbasiert und superskalar. Aus der Perspektive der Unternehmenssoftware ist dies jedoch relativ knifflig. Beim Pipelining muss Ihre Software “mitspielen”, und vielleicht tut sie dies zufällig auch in Bezug auf die Zweigvorhersage. Bei superskalaren Instruktionen gibt es jedoch nichts Zufälliges. Ihre Software muss in den meisten Fällen explizit bestimmte Dinge tun, um diese zusätzliche Rechenleistung zu nutzen. Das bekommen Sie nicht umsonst; stattdessen müssen Sie diesen Ansatz aktiv verfolgen und typischerweise die Daten so organisieren, dass Sie Datenparallelismus haben und die Daten in einer Weise angeordnet sind, die für SIMD-Befehle geeignet ist. Es ist keine Raketenwissenschaft, aber es passiert nicht zufällig, und es verschafft Ihnen einen enormen Leistungsschub.
Moderne CPUs können mittlerweile viele Kerne haben, und ein einzelner CPU-Kern kann einen eigenständigen Instruktionsfluss liefern. Bei sehr modernen CPUs, die über viele Kerne verfügen – heutige Prozessoren können typischerweise bis zu 64 Kerne haben – gibt es 64 unabhängige, gleichzeitige Ausführungsflüsse. Damit kann man in etwa eine Rechenleistung von einem Teraflop erreichen, was das obere Limit an Verarbeitungskapazität eines sehr modernen Prozessors darstellt. Wenn Sie jedoch darüber hinaus gehen möchten, können Sie sich GPUs (Graphical Processing Units) anschauen. Trotz vermuteter Annahmen können diese Geräte für Aufgaben eingesetzt werden, die nichts mit Grafik zu tun haben.
Eine GPU, wie die von NVIDIA, ist ein superskalarer Prozessor. Anstatt wie bei High-End-CPUs bis zu 64 Kerne zu besitzen, können GPUs mehr als 10.000 Kerne haben. Diese Kerne sind wesentlich einfacher und nicht so leistungsstark oder schnell wie reguläre CPU-Kerne, aber es gibt sie in vielfacher Anzahl. Sie heben SIMD auf ein neues Niveau, bei dem man nicht nur Pakete von 8 oder 16 Zahlen gleichzeitig verarbeiten kann, sondern buchstäblich Tausende von Zahlen zur Ausführung von Vektorbefehlen gleichzeitig heranziehen kann. Mit GPUs kann man auf einem einzelnen Gerät leicht 30-plus Teraflops erreichen, was enorm ist. Während die besten CPUs auf dem Markt etwa einen Teraflop liefern, erreichen die besten GPUs 30-plus Teraflops. Das ist mehr als eine Größenordnung Unterschied, was sehr signifikant ist.
Gehen Sie noch einen Schritt weiter, etwa bei spezialisierten Berechnungen wie der linearen Algebra (übrigens, Dinge wie maschinelles Lernen und deep learning sind im Wesentlichen überall matrixbasierte lineare Algebra), können Sie Prozessoren wie TPUs (Tensor Processing Units) einsetzen. Google hat sich entschieden, sie Tensors zu nennen, wegen TensorFlow, aber in Wirklichkeit wären TPUs treffender als Matrix Multiplication Processing Units zu bezeichnen. Bemerkenswert bei der Matrixmultiplikation ist, dass nicht nur eine enorme Datenparallelität involviert ist, sondern auch eine immense Wiederholung, weil die Operationen sehr repetitiv sind. Indem man eine TPU als systolisches Array organisiert, also im Grunde ein zweidimensionales Gitter mit Recheneinheiten auf dem Gitter, kann man die Petaflop-Grenze durchbrechen – und allein auf einem Gerät über 1000 Teraflops erreichen. Allerdings gibt es einen Haken: Google realisiert dies mit 16-Bit-Fließkommazahlen statt der üblichen 32-Bit. Aus der Sicht der Supply chain Optimierung ist eine 16-Bit-Präzision nicht schlecht; sie bedeutet, dass Sie bei Ihren Operationen etwa 0,1 % Genauigkeit haben, und für viele maschinelle Lern- oder statistische Operationen ist 0,1 % Genauigkeit vollkommen ausreichend, vorausgesetzt, es wird richtig gehandhabt und ohne sich anzusammelnde Verzerrungen.
Was wir beobachten, ist, dass der Fortschritt im Bereich der Computerhardware – wenn man nur die Rechenleistung betrachtet – dahin geht, dass man auf Geräte setzt, die spezialisierter und starrer sind. Dank dieser Spezialisierung können enorme Leistungsschübe erzielt werden. Gehen Sie von superskalaren Instruktionen aus, gewinnen Sie eine Größenordnung; setzen Sie auf eine Grafikkarte, gewinnen Sie ein bis zwei Größenordnungen; und bei reiner linearer Algebra gewinnen Sie im Wesentlichen zwei Größenordnungen. Das ist sehr signifikant.
Übrigens sind all diese Hardwaredesigns zweidimensional. Moderne Chips und Verarbeitungsstrukturen sind sehr flach. Ein moderner CPU-Chip umfasst nicht mehr als 20 Schichten, und da diese Schichten nur wenige Mikrometer dick sind, sind CPUs, GPUs oder TPUs im Wesentlichen flache Strukturen. Man könnte sich fragen: “Was ist mit der dritten Dimension?” Nun, es stellt sich heraus, dass wir wegen der Power Wall, also des Problems der Energieabfuhr, nicht wirklich in die dritte Dimension vordringen können, da wir nicht wissen, wie die gesamte in das Gerät geförderte Energie abgeführt werden soll.
Was wir für das nächste Jahrzehnt vorhersagen können, ist, dass diese Geräte im Wesentlichen zweidimensional bleiben werden. Aus der Sicht der Unternehmenssoftware ist die wichtigste Erkenntnis, dass Sie Datenparallelismus bereits im Kern Ihrer Software verankern müssen. Tun Sie dies nicht, werden Sie den Fortschritt, der in Bezug auf reine Rechenleistung erzielt wird, nicht voll ausschöpfen können. Es darf kein nachträglicher Gedanke sein, sondern muss tief in der Architektur verankert sein, nämlich auf der Ebene, auf der Sie all die Daten organisieren, die in Ihren Systemen verarbeitet werden müssen. Andernfalls bleiben Sie auf den Prozessoren hängen, die wir noch vor zwei Jahrzehnten hatten.
In den frühen 80er-Jahren war der Speicher genauso schnell wie die Prozessoren, das heißt, ein Taktzyklus galt sowohl für den Speicher als auch für die CPU. Dies ist heute jedoch nicht mehr der Fall. Im Laufe der Zeit, seit den 80ern, ist das Verhältnis zwischen der Geschwindigkeit des Speichers und den Latenzen, um Daten zuzugreifen, die sich bereits in den Registern der Prozessoren befinden, kontinuierlich gestiegen. Wir begannen mit einem Verhältnis von eins, und heute liegt es typischerweise bei über tausend. Dieses Problem ist als Memory Wall bekannt und hat sich in den letzten vier Jahrzehnten nur noch verstärkt. Es steigt zwar heutzutage, wenn auch sehr langsam, vor allem weil die Taktgeschwindigkeit der Prozessoren nur sehr wenig zunimmt. Da sich die Prozessoren in Bezug auf die Taktgeschwindigkeit kaum weiterentwickeln, wächst dieses Problem der Memory Wall nicht weiter. Dennoch befinden wir uns momentan in einem Zustand, in dem der Zugriff auf den Speicher im Wesentlichen drei Größenordnungen langsamer erfolgt als der Zugriff auf Daten, die bequem in der CPU lokalisiert sind.
Diese Perspektive macht alle klassischen Algorithmen, wie sie heute noch an den meisten Universitäten gelehrt werden, völlig obsolet. Der klassische algorithmische Ansatz geht davon aus, dass der Zugriff auf den Speicher uniforme Zeiten benötigt, also dass das Abrufen eines beliebigen Speicherbereichs stets dieselbe Zeit in Anspruch nimmt. Aber in modernen Systemen ist das absolut nicht der Fall. Die Zeit, die benötigt wird, um auf einen bestimmten Speicherbereich zuzugreifen, hängt stark davon ab, wo sich die tatsächlichen Daten physisch innerhalb Ihres Computersystems befinden.
Aus unternehmenssoftwaretechnischer Sicht hat sich herausgestellt, dass leider die meisten Softwaredesigns, die in den 80er und 90er Jahren etabliert wurden, dieses Problem völlig ignoriert haben, weil es im ersten Jahrzehnt nur eine geringe Rolle spielte. Es hat sich erst in den letzten beiden Jahrzehnten wirklich aufgebauscht, sodass die meisten der heute in Unternehmenssoftware beobachteten Muster diesem Design völlig entgegenstehen, da sie davon ausgehen, dass der Zugriff auf den gesamten Speicher in konstanter Zeit erfolgt.
Übrigens, wenn man an Programmiersprachen wie Python (erstmals 1989 veröffentlicht) oder Java (1995) denkt, die objektorientierte Programmierung bieten, dann geht das völlig gegen die Art und Weise, wie der Speicher in modernen Computern funktioniert. Wann immer Sie Objekte haben – und es wird noch schlimmer, wenn Sie späte Bindungen wie in Python haben – müssen Sie Zeiger verfolgen und willkürliche Sprünge im Speicher durchführen, um irgendetwas zu tun. Sollte einer dieser Sprünge unglücklich verlaufen, weil er in einem Bereich erfolgt, der sich nicht bereits in der CPU befindet, kann dies bis zu tausendmal langsamer sein. Das ist ein sehr großes Problem.
Um das Ausmaß der Memory Wall besser zu verstehen, ist es interessant, einen Blick auf die typischen Latenzen in einem modernen Computer zu werfen. Wenn wir diese Latenzen in menschliche Zeit umrechnen, nehmen wir an, ein Prozessor würde mit einem Taktzyklus pro Sekunde arbeiten. Unter dieser Annahme entspräche die typische Latenz der CPU einer Sekunde. Wenn Sie jedoch auf Daten im Speicher zugreifen möchten, kann das bis zu sechs Minuten dauern. Während Sie also eine Operation pro Sekunde ausführen können, müssen Sie sechs Minuten warten, wenn Sie auf den Speicher zugreifen möchten. Und der Zugriff auf Festplatten kann bis zu einen Monat oder sogar ein ganzes Jahr dauern. Das ist unglaublich lang, und genau darum geht es bei diesen Größenordnungen an Leistung, von denen ich zu Beginn dieser Vorlesung sprach. Wenn man es mit 15 Größenordnungen zu tun hat, ist das sehr trügerisch; man realisiert nicht unbedingt den massiven Leistungseinbruch, der eintreten kann – buchstäblich kann man am Ende den menschlichen Äquivalent von Monaten warten, wenn die Informationen nicht am richtigen Ort abgelegt werden. Das ist absolut gigantisch.
Übrigens kämpfen nicht nur Unternehmenssoftwareingenieure mit dieser Evolution moderner Computerhardware. Betrachtet man die Latenzen, die man mit superschnellen SSD-Karten wie der Intel Optane-Serie erzielt, sieht man, dass die Hälfte der Latenz beim Zugriff auf den Speicher dieses Geräts tatsächlich durch den Overhead des Kernels, in diesem Fall des Linux-Kernels, verursacht wird. Es ist das Betriebssystem selbst, das die Hälfte der Latenz erzeugt. Was bedeutet das? Es heißt, selbst die Entwickler von Linux haben noch weitere Herausforderungen zu meistern, um mit der modernen Hardware Schritt zu halten. Nichtsdestotrotz ist es eine große Herausforderung für alle.
Allerdings trifft dies insbesondere Unternehmenssoftware hart, vor allem wenn man an die Optimierung der supply chain denkt, da wir Unmengen an Daten zu verarbeiten haben. Von Anfang an ist das bereits ein ziemlich komplexes Unterfangen. Aus der Sicht der Unternehmenssoftware müssen Sie ein Design verfolgen, das gut mit dem Cache harmoniert, da der Cache lokale Kopien enthält, auf die schneller zugegriffen werden kann und die näher an der CPU liegen.
So funktioniert es: Wenn Sie in Ihrem Hauptspeicher auf ein Byte zugreifen, können Sie in moderner Software nicht einfach nur ein Byte abrufen. Wenn Sie auch nur ein Byte in Ihrem RAM anfordern, kopiert die Hardware tatsächlich 4 Kilobytes – im Grunde die gesamte 4-Kilobyte-Seite. Die zugrunde liegende Annahme ist, dass, sobald Sie ein Byte lesen, das nächste Byte, das Sie anfordern, auch das unmittelbar folgende sein wird. Das ist das Lokalitätsprinzip, was bedeutet, dass, wenn Sie sich an diese Regel halten und Zugriffe erzwingen, die die Lokalität bewahren, der Speicher fast so schnell zu arbeiten scheint wie Ihre CPU.
Allerdings erfordert das eine Abstimmung zwischen den Speicherzugriffen und der Lokalität der Daten. Insbesondere gibt es etliche Programmiersprachen, wie Python, die von Haus aus nicht diese Eigenschaften liefern. Im Gegenteil, sie stellen eine enorme Herausforderung dar, um irgendeinen Grad an Lokalität zu erzielen. Das ist ein gewaltiger Kampf, und letztlich handelt es sich um einen Kampf, bei dem eine Programmiersprache angewandt wird, die um Muster herum designt wurde, die der verfügbaren Hardware völlig entgegenwirken. Dieses Problem wird sich im kommenden Jahrzehnt nicht ändern; es wird nur noch schlimmer.
Folglich möchten Sie aus der Perspektive von Unternehmenssoftware die Lokalität der Daten, aber auch deren Verkleinerung erzwingen. Wenn Sie Ihre Big Data klein machen können, wird es schneller. Das ist zwar nicht sehr intuitiv, aber wenn Sie die Größe der Daten, typischerweise durch Beseitigung von Redundanzen, reduzieren, können Sie Ihr Programm beschleunigen, da Sie viel besser mit dem Cache umgehen. So passen mehr relevante Daten in die niedrigeren Cache-Ebenen, die wesentlich geringere Latenzen aufweisen, wie in dieser Darstellung gezeigt.
Lassen Sie uns schließlich den speziellen Fall von DRAM betrachten. DRAM ist buchstäblich die physische Komponente, die den RAM bildet, den Sie für Ihren Desktop-Arbeitsplatz oder Ihren Server in der Cloud verwenden. DRAM wird auch als Hauptspeicher bezeichnet, der aus DRAM-Chips besteht. Im letzten Jahrzehnt ist der Preis für DRAM kaum gesunken. Wir sind von 5 $ pro Gigabyte auf 3 $ pro Gigabyte in einem Jahrzehnt zurückgegangen. Der Preis von RAM sinkt zwar weiter, jedoch nicht sehr schnell. Er stagniert seit einigen Jahren, und da es in diesem Markt nur drei große Akteure gibt, die DRAM in großem Maßstab herstellen können, gibt es kaum Hoffnung auf unerwartete Entwicklungen in diesem Markt in den kommenden zehn Jahren.
Aber das ist noch nicht einmal das Schlimmste des Problems. Es gibt auch den Stromverbrauch pro Gigabyte. Betrachtet man den Energieverbrauch, stellt sich heraus, dass moderner RAM pro Gigabyte etwas mehr Energie verbraucht als noch vor einem Jahrzehnt. Der Grund ist im Wesentlichen, dass der aktuelle RAM schneller ist, und die gleiche Regel der Leistungsmauer gilt: Erhöhen Sie die Taktfrequenz, steigt der Energieverbrauch erheblich. Übrigens verbraucht RAM beträchtlich viel Energie, weil DRAM im Grunde ein aktives Bauteil ist. Man muss den RAM ständig auffrischen, um den elektrischen Leckagen entgegenzuwirken; schaltet man den RAM aus, gehen alle Daten verloren. Die Zellen müssen kontinuierlich neu geladen werden.
Daher lautet die Schlussfolgerung für Unternehmenssoftware, dass DRAM die eine Komponente ist, die sich nicht weiterentwickelt. Es gibt zahlreiche Bereiche, wie etwa die Verarbeitungsgeschwindigkeit, die sich noch sehr schnell voranbringen; das gilt aber nicht für DRAM – es stagniert förmlich. Berücksichtigt man den Energieverbrauch, der ebenfalls einen erheblichen Teil der Cloud-Computing-Kosten ausmacht, macht der RAM kaum Fortschritte. Deshalb sollten Sie, wenn Sie ein Design wählen, das den Hauptspeicher überbetont – was typischerweise der Fall ist, wenn ein Anbieter sagt: “Oh, wir haben ein In-Memory-Design für Software” – sich diese Schlüsselwörter zu Herzen nehmen.
Immer wenn Sie einen Anbieter hören, der behauptet, ein In-Memory-Design zu haben – was kein besonders überzeugendes Argument ist – teilt er Ihnen mit, dass sein Design vollständig auf die zukünftige Entwicklung von DRAM setzt, von der wir bereits wissen, dass die Kosten nicht sinken werden. Wenn man bedenkt, dass in 10 Jahren Ihre supply chain wahrscheinlich etwa 10-mal mehr Daten zu verarbeiten haben wird, nur weil Unternehmen immer besser darin werden, mehr Daten innerhalb ihrer supply chain zu sammeln und mit ihren Kunden und Lieferanten zusammenzuarbeiten, ist es nicht unvernünftig anzunehmen, dass ein großes Unternehmen mit einer großen supply chain in einem Jahrzehnt 10-mal mehr Daten sammeln wird als heute. Der Preis pro Gigabyte RAM wird jedoch gleich bleiben. Wenn Sie also die Rechnung machen, könnten Ihre Cloud-Computing- oder IT-Kosten im Grunde fast um eine Größenordnung steigen, nur um nahezu dieselbe Leistung zu erbringen, weil Sie mit einer ständig wachsenden Datenmenge klarkommen müssen, die nicht leicht in den Speicher passt. Die wesentliche Erkenntnis ist, dass Sie alle Arten von In-Memory-Designs wirklich vermeiden sollten. Diese Designs sind sehr veraltet, und im Folgenden werden wir sehen, welche Alternativen es gibt.
Schauen wir uns nun die Datenspeicherung an, also die persistente Speicherung von Daten. Im Wesentlichen gibt es zwei weit verbreitete Klassen der Datenspeicherung. Die erste besteht aus Festplattenlaufwerken (HDD) oder rotierenden Scheiben. Die zweite besteht aus Solid-State-Drives (SSD). Das Interessante ist, dass die Latenz bei rotierenden Scheiben schrecklich ist, und wenn man sich dieses Bild anschaut, versteht man leicht warum. Diese Scheiben drehen sich buchstäblich, und wenn Sie auf einen beliebigen Datenpunkt auf der Scheibe zugreifen möchten, müssen Sie im Durchschnitt eine halbe Umdrehung abwarten. Da die Spitzenmodelle der Scheiben mit etwa 10.000 Umdrehungen pro Minute rotieren, bedeutet das, dass eine eingebaute Latenz von drei Millisekunden vorhanden ist, die sich nicht verringern lässt. Es ist buchstäblich die Zeit, die die Scheibe benötigt, um sich zu drehen und den genauen interessierenden Punkt auszulesen. Es handelt sich um einen mechanischen Vorgang, der sich nicht weiter verbessern wird.
HDDs sind hinsichtlich der Latenz schrecklich, haben aber auch ein weiteres Problem, nämlich den Stromverbrauch. Als Faustregel gilt, dass sowohl ein HDD als auch ein SSD etwa drei Watt pro Stunde pro Gerät verbrauchen. Das entspricht typischerweise dem derzeitigen Standard. Wenn die Festplatte jedoch läuft, verbrauchen Sie bereits drei Watt allein, um die Scheibe in Rotation zu halten, selbst wenn Sie nicht aktiv von der Festplatte lesen. Das Erreichen von 10.000 Umdrehungen pro Minute dauert lange, sodass die Scheibe ständig in Bewegung gehalten werden muss, auch wenn Sie sie nur selten nutzen.
Andererseits verbrauchen SSDs beim Zugriff zwar drei Watt, doch wenn Sie nicht auf die Daten zugreifen, verbrauchen sie nahezu gar keine Energie. Sie haben einen Restverbrauch, der allerdings äußerst gering ist – in der Größenordnung von Milliwatt. Das ist sehr interessant, denn Sie können eine Menge SSDs einsetzen; wenn Sie diese nicht verwenden, zahlen Sie nicht für den Strom, den sie verbrauchen. Die gesamte Branche wechselt in den letzten zehn Jahren schrittweise von HDDs zu SSDs.
Um das zu verstehen, können wir uns diese Kurve ansehen. Was wir erkennen, ist, dass der Preis pro Gigabyte sowohl bei HDDs als auch bei SSDs in den letzten Jahren gefallen ist. Allerdings flacht der Preis nun ab. Die Daten sind etwas veraltet, aber in den letzten Jahren gab es keine wesentlichen Veränderungen. Vor zehn Jahren waren SSDs extrem teuer und kosteten 2.400 $ pro Terabyte, während Festplatten nur 60 $ pro Terabyte kosteten. Heutzutage ist der Preis von Festplatten im Wesentlichen auf ein Drittel gesunken – also etwa 20 $ pro Terabyte. Der Preis von SSDs hat sich um mehr als das 25-fache reduziert, und der Trend zu sinkenden SSD-Preisen hält an. SSDs sind aktuell – und wahrscheinlich auch im nächsten Jahrzehnt – die Komponente, die am meisten Fortschritte macht, und das ist sehr interessant.
Übrigens hatte ich erwähnt, dass das Design moderner Rechengeräte (CPU, GPU, TPU) im Wesentlichen zweidimensional mit höchstens 20 Schichten ist. Bei SSDs hingegen wird das Design zunehmend dreidimensional. Die neuesten SSDs besitzen etwa 176 Schichten. Wir nähern uns in etwa 200 Schichten. Da diese Schichten unglaublich dünn sind, ist es nicht unvernünftig anzunehmen, dass wir in Zukunft Geräte mit Tausenden von Schichten und potenziell um Größenordnungen mehr Speicherkapazitäten haben werden. Offensichtlich wird der Knackpunkt darin bestehen, dass Sie nicht ständig auf all diese Daten zugreifen können – wiederum aufgrund von Dark Silicon und Energieverlusten.
Es zeigt sich, dass, wenn man es richtig anstellt, viele Daten nur sehr selten abgerufen werden. SSDs beinhalten ein sehr spezifisches Hardware-Design, das mit zahlreichen Macken einhergeht, wie der Tatsache, dass Sie Bits nur auf 1 schalten können, aber nicht wieder auf 0. Stellen Sie sich vor, Sie haben anfangs ausschließlich Nullen; Sie können eine Null in eine Eins verwandeln, jedoch können Sie diese Eins nicht lokal wieder in eine Null umwandeln. Möchten Sie dies dennoch tun, müssen Sie den gesamten Block zurücksetzen, der bis zu acht Megabyte groß sein kann. Das bedeutet, dass Sie beim Schreiben Bits von Null zu Eins umwandeln können, aber nicht von Eins zu Null. Um Bits von Eins zu Null zu ändern, müssen Sie den gesamten Block leeren und neu schreiben, was zu allerlei Problemen führt, die als Write Amplification bekannt sind.
Im letzten Jahrzehnt haben SSDs intern eine Schicht namens Flash Translation Layer implementiert, die all diese Probleme für Sie abmildern kann. Diese Flash Translation Layers werden mit der Zeit immer besser. Es gibt jedoch noch erhebliches Verbesserungspotenzial, und im Hinblick auf Unternehmenssoftware bedeutet dies, dass Sie Ihr Design wirklich optimieren sollten, um das Beste aus SSDs herauszuholen. SSDs sind bereits eine wesentlich bessere Lösung als DRAM, wenn es um die Speicherung von Daten geht, und wenn Sie clever vorgehen, können Sie in einem Jahrzehnt von Gewinnen in mehreren Größenordnungen profitieren, die durch den Fortschritt der Hardwarebranche erzielt werden – was bei DRAM nicht der Fall ist.
Abschließend wollen wir über Bandbreite sprechen. Bandbreite ist wahrscheinlich das am besten gelöste Problem in der Technik. Selbst wenn Bandbreiten erreicht werden, erzielen wir heute Werte, die absolut verrückt sind. Geschäftlich ist die Telekommunikationsbranche äußerst komplex, und es gibt zahlreiche Probleme, sodass Endverbraucher nicht alle Vorteile des Fortschritts im Bereich der optischen Kommunikation tatsächlich wahrnehmen.
Im Hinblick auf die optische Kommunikation mit Glasfasertransceivern ist der Fortschritt absolut unglaublich. Es ist wahrscheinlich eine dieser Entwicklungen, die sich genauso rasant voranbringen wie CPUs in den 80er oder 90er Jahren. Um Ihnen eine Vorstellung zu geben: Mit Wavelength Division Multiplexing (WDM) oder Space Division Multiplexing (SDM) können wir jetzt buchstäblich ein Zehntel Terabyte an Daten pro Sekunde über ein einziges Glasfaserkabel übertragen. Das ist absolut enorm. Wir nähern uns einem Punkt, an dem ein einziges Kabel genügend Daten transportieren kann, um im Grunde ein ganzes Rechenzentrum zu speisen. Noch beeindruckender ist, dass es der Telekommunikationsbranche gelungen ist, neue Transceiver zu entwickeln, die auf alten Kabeln basieren und diese absolut verrückten Leistungen erbringen. Sie müssen nicht einmal neue Glasfaserkabel in den Straßen verlegen; Sie können buchstäblich das Glasfaserkabel verwenden, das vor einem Jahrzehnt installiert wurde, den neuen Transceiver anschließen und so um mehrere Größenordnungen mehr Bandbreite über dasselbe Kabel erzielen.
Das Interessante daran ist, dass es ein allgemeines Gesetz der optischen Kommunikation gibt: Alle zehn Jahre verringert sich die Distanz, ab der es sinnvoll wird, die elektrische Kommunikation durch optische zu ersetzen. Vor einigen Jahrzehnten, etwa vor zwanzig Jahren, brauchte man ungefähr 100 Meter, damit die optische Kommunikation die elektrische übertraf. Hätten Sie also Distanzen von weniger als 100 Metern, würde man auf Kupfer setzen; bei mehr als 100 Metern würde man auf Glasfaser umsteigen. Heutzutage jedoch, mit der neuesten Generation, gibt es Distanzen, bei denen die Optik bereits bei nur drei Metern gewinnt. Wenn man ein Jahrzehnt vorausblickt, würde es mich nicht überraschen, wenn wir Situationen erleben, in denen optische Kommunikation sogar bei Distanzen von nur einem halben Meter gewinnt. Das bedeutet, dass es mich irgendwann auch nicht überraschen wird, wenn Computer intern optische Leitungen besitzen, einfach weil diese leistungsfähiger sind als elektrische Leitungen.
Aus der Perspektive von Unternehmenssoftware ist dies ebenfalls sehr interessant, denn es bedeutet, dass vorausblickend die Kosten für Bandbreite massiv sinken werden. Dies wird wesentlich von Unternehmen wie Netflix subventioniert, die einen dramatisch hohen Bandbreitenverbrauch haben. Das bedeutet, dass Sie, um Latenzprobleme zu umgehen, etwa riesige Datenmengen vorab in Richtung des Endbenutzers holen und diesen dann mit Daten interagieren lassen können, die näher gebracht wurden und wesentlich kürzere Latenzen aufweisen. Selbst wenn Sie Daten übertragen, die nicht unbedingt benötigt werden, ist es die Latenz, die Ihnen schadet – nicht die Bandbreite. Es ist besser zu sagen: “Ich habe Zweifel, welche Daten benötigt werden; ich kann tausendmal mehr Daten als nötig abrufen, sie näher an den Endnutzer bringen, den Benutzer oder das Programm mit diesen Daten interagieren lassen und so die Round-Trip-Zeit minimieren, wodurch ich in puncto Leistung gewinne.” Dies wirkt sich wiederum tiefgreifend auf die architektonischen Entscheidungen aus, die heute getroffen werden, da sie darüber bestimmen, ob man mit dem Fortschritt dieser Hardwareklasse in einem Jahrzehnt Leistungsgewinne erzielen kann.
Zusammenfassend lässt sich sagen, dass Latenz der entscheidende Kampf unserer Zeit im Bereich Software Engineering ist. Sie beeinflusst maßgeblich alle Leistungsaspekte, die wir haben und haben werden. Leistung ist absolut entscheidend, da sie nicht nur die IT-Kosten steuert, sondern auch die Produktivität der Menschen, die in Ihrer supply chain tätig sind. Letztendlich wird dies auch die Leistung der supply chain selbst bestimmen, denn ohne diese Leistung können Sie nicht einmal ein numerisches Rezept implementieren, das wirklich intelligent ist und fortschrittliche sowie prädiktive Optimierungsereignisse liefert, nach denen wir streben. Insgesamt wird dieser Kampf um bessere Leistung – zumindest im Bereich der Unternehmenssoftware – nicht gewonnen. Neue Systeme können – und sind häufig – langsamer als die alten. Dies ist ein akutes Problem. Eine schlechtere Softwareperformance verursacht Unternehmen enorme Kosten.
Um nur ein Beispiel zu nennen: Es sollte nicht als selbstverständlich gelten, dass bessere Computerhardware auch zu besserer Leistung führt. Einige Leute im Internet haben beschlossen, die Eingabelatenz zu messen – also die Zeit, die nach einem Tastendruck vergeht, bis der entsprechende Buchstabe auf dem Bildschirm erscheint. Beim Apple II im Jahr 1983, der mit einem 1-MHz-Prozessor ausgestattet war, betrug diese Zeit 30 Millisekunden. Im Jahr 2016, mit einem Lenovo X1, einem sehr guten Notebook mit einem 2,6-GHz-Prozessor, betrug die Latenz 110 Millisekunden. Wir haben also Computerhardware, die um mehrere Tausend Mal besser ist, dennoch weist die Latenz fast viermal so hohe Werte auf. Das ist typisch für das, was passiert, wenn man keine mechanische Sympathie hat und nicht auf die vorhandene Computerhardware achtet. Wenn Sie die Computerhardware “provozieren”, zahlen Sie dies mit schlechter Leistung zurück.
Das Problem ist sehr real. Mein Vorschlag ist, wenn Sie beginnen, sich irgendeine Unternehmenssoftware für Ihr Unternehmen anzusehen, egal ob sie Open-Source ist oder nicht, denken Sie an die Elemente der Mechanical Sympathy, die Sie heute gelernt haben. Betrachten Sie die Software und überlegen Sie gründlich, ob sie die tiefgreifenden Trends der Computerhardware aufgreift oder ob sie sie gänzlich ignoriert. Ignoriert sie diese, bedeutet das, dass sich die Leistung im Laufe der Zeit nicht nur nicht verbessert, sondern höchstwahrscheinlich sogar verschlechtert. Die meisten Verbesserungen werden heutzutage durch Spezialisierung statt durch Taktfrequenz erzielt. Wenn Sie diese Autobahn verpassen, wählen Sie einen Weg, der im Laufe der Zeit immer langsamer wird. Vermeiden Sie diese Lösungen, weil sie in der Regel aus frühen, entscheidenden Designentscheidungen resultieren, die nicht rückgängig gemacht werden können. Sie sind damit für immer festgelegt, und es wird Jahr für Jahr nur schlimmer. Denken Sie daran, ein Jahrzehnt vorauszuplanen, wenn Sie diese Perspektiven betrachten.
Schauen wir uns nun die Fragen an. Das war eine ziemlich lange Vorlesung, aber es ist ein herausforderndes Thema.
Frage: Was ist Ihre Meinung zu Quantencomputern und ihrer Nützlichkeit bei der Bewältigung komplexer supply chain Optimierungsprobleme?
Eine sehr interessante Frage. Ich habe mich vor 18 Monaten für die Beta-Version von IBMs Quantencomputer angemeldet, als sie den Zugang zu ihrem Quantencomputer in der Cloud öffneten. Mein Gefühl ist, dass es aufregend ist, denn Experten können all die S-Kurven abflachen sehen, aber nicht erkennen, wie neue Kurven plötzlich aus dem Nichts auftauchen. Quantencomputing ist einer davon. Allerdings glaube ich, dass Quantencomputer sehr harte Herausforderungen in Bezug auf supply chain mit sich bringen. Zunächst, wie bereits gesagt, ist der Kampf unserer Zeit in Bezug auf Unternehmenssoftware die Latenz, und Quantencomputer tun in dieser Hinsicht nichts. Quantencomputer bieten Ihnen potenziell bis zu 10 Größenordnungen an Geschwindigkeitsschub für extrem rechenintensive Probleme. Daher wären Quantencomputer die nächste Stufe jenseits von TPUs, bei denen Sie extrem schnelle Operationen unglaublich zügig durchführen können.
Das ist sehr interessant, aber um ehrlich zu sein, gibt es meines Wissens derzeit nur sehr wenige Unternehmen, die es sogar schaffen, superskalare Anweisungen in ihrer Unternehmenssoftware zu nutzen. Das bedeutet, dass der gesamte Markt einen 10- bis 28-fachen Geschwindigkeitsschub durch superskalare GPUs ungenutzt lässt. Es gibt nur sehr wenige Leute in der supply chain, die das tun; vielleicht Lokad, vielleicht nicht. Bei TPUs denke ich, dass es buchstäblich niemanden gibt. Google macht es umfangreich, aber mir ist niemand bekannt, der jemals TPUs für etwas supply chain-bezogenes verwendet hat. Quantenprozessoren wären die Stufe jenseits von TPUs.
Ich verfolge auf jeden Fall sehr aufmerksam, was mit Quantencomputern geschieht, aber ich glaube, dass dies nicht der Engpass ist, dem wir gegenüberstehen. Es ist aufregend, weil wir das vor etwa 70 Jahren etablierte von-Neumann-Design wieder aufgreifen, aber dies ist nicht der Engpass, mit dem wir oder die supply chain in den nächsten zehn Jahren konfrontiert sein werden. Darüber hinaus ist Ihre Vermutung ebenso gut wie meine. Ja, es könnte potenziell alles verändern oder auch nicht.
Frage: Cloud- und SaaS-Angebote ermöglichen es Organisationen, fixe Kosten zu nutzen und umzuwandeln. Arbeiten die Unternehmen, die solche Dienste anbieten, auch daran, ihre Fixkosten und das damit verbundene Risiko zu reduzieren?
Nun, das kommt darauf an. Wenn ich eine Cloud-Computing-Plattform bin und Ihnen Rechenleistung verkaufe, liegt es dann in meinem Interesse, Ihre Unternehmenssoftware so effizient wie möglich zu gestalten? Nicht wirklich. Ich verkaufe Ihnen virtuelle Maschinen, Gigabytes an Bandbreite und Speicher, also eigentlich das Gegenteil. Mein Interesse besteht darin, sicherzustellen, dass Sie eine Software haben, die so ineffizient wie möglich ist, damit Sie eine verrückte Menge an Ressourcen verbrauchen und pay-as-you-go bezahlen.
Intern werden große Technologieunternehmen wie Microsoft, Amazon und Google unglaublich aggressiv, wenn es um die Optimierung ihrer Rechenressourcen geht. Aber sie sind auch aggressiv, wenn sie an vorderster Front stehen, um die Rechnung zu bezahlen, wenn sie einem Kunden das Mieten einer virtuellen Maschine in Rechnung stellen. Wenn der Kunde eine virtuelle Maschine mietet, die 10-mal größer ist als sie sein sollte, nur weil die von ihm verwendete Unternehmenssoftware extrem ineffizient ist, liegt es nicht in ihrem Interesse, den Fehler des Kunden zu unterbrechen. Das ist für sie in Ordnung; es ist ein gutes Geschäftsmodell. Wenn man bedenkt, dass Systemintegratoren und Cloud-Computing-Plattformen dazu neigen, Hand in Hand als Partner zu arbeiten, wird einem klar, dass diese Gruppen nicht unbedingt Ihr bestes Interesse im Sinn haben. Bei SaaS ist es jedoch etwas anders. Tatsächlich, wenn Sie einem SaaS-Anbieter pro Benutzer zahlen, liegt es im Interesse des Unternehmens – und das ist beispielsweise bei Lokad der Fall. Wir berechnen nicht nach den verbrauchten Rechenressourcen; wir berechnen unseren Kunden in der Regel pauschale monatliche Gebühren. Daher neigen SaaS-Anbieter dazu, bei ihrem eigenen Verbrauch an Rechenressourcen sehr aggressiv zu sein.
Allerdings, Vorsicht, es gibt einen Bias: Wenn Sie ein SaaS-Unternehmen sind, können Sie ziemlich zögerlich sein, etwas zu tun, das für Ihre Kunden viel vorteilhafter wäre, aber für Sie in Bezug auf Hardware deutlich teurer. Es ist nicht alles eitel Sonnenschein. Es gibt eine Art Interessenkonflikt, der alle SaaS-Anbieter betrifft, die im supply chain arbeiten. Zum Beispiel könnten sie in die Neu-Entwicklung all ihrer Systeme investieren, um eine bessere Latenz und schnellere Webseiten zu liefern, aber die Tatsache ist, dass es Ressourcen kostet und ihre Kunden natürlich nicht mehr bezahlen werden, wenn sie das tun.
Das Problem verstärkt sich tendenziell bei Unternehmenssoftware. Warum ist das so? Es liegt daran, dass die Person, die die Software kauft, in der Regel nicht dieselbe Person ist, die sie benutzt. Deshalb ist so viel von dem Unternehmenssystem unglaublich langsam. Die Person, die die Software kauft, leidet nicht so sehr wie ein armer Absatzplaner oder Bestandsmanager, der jeden einzelnen Tag des Jahres mit einem super langsamen System zurechtkommen muss. Es gibt also einen weiteren Aspekt, der spezifisch für den Bereich der Unternehmenssoftware ist. Sie müssen die Situation wirklich analysieren, indem Sie alle Anreize betrachten, die im Spiel sind – und bei Unternehmenssoftware gibt es in der Regel jede Menge widersprüchliche Anreize.
Frage: Wie oft musste Lokad seinen Ansatz aufgrund der beobachteten Hardware-Entwicklungen überdenken? Können Sie, wenn möglich, ein Beispiel nennen, um diesen Inhalt in den Kontext real gelöster Probleme zu stellen?
Lokad, so glaube ich, hat unseren Technologiestack etwa ein halbes Dutzend Mal umfassend neu gestaltet. Allerdings wurde Lokad 2008 gegründet, und wir hatten ein halbes Dutzend größere Neuschreibungen der gesamten Architektur. Es lag nicht daran, dass sich die Software so sehr weiterentwickelt hätte; sie hat sich zwar weiterentwickelt, aber was die meisten unserer Neuschreibungen vorantrieb, war nicht, dass sich die Hardware so stark verbessert hatte. Vielmehr war es so, dass wir ein besseres Verständnis für die Hardware gewonnen hatten. Alles, was ich heute präsentiert habe, war denjenigen, die bereits vor einem Jahrzehnt aufmerksam waren, im Wesentlichen bekannt. Also, Sie sehen, Hardware entwickelt sich zwar weiter, aber sehr langsam, und die meisten Trends sind auch ein Jahrzehnt im Voraus sehr vorhersehbar. Dies ist ein langfristiges Spiel.
Lokad musste massive Neuschreibungen durchführen, was eher widerspiegelt, dass wir allmählich weniger inkompetent wurden. Wir gewannen an Kompetenz und hatten daher ein besseres Verständnis dafür, wie man Hardware einsetzt, anstatt dass die Hardware die Aufgabenstellung verändert hätte. Das war nicht immer der Fall; es gab spezifische Elemente, die für uns wirklich bahnbrechend waren. Das markanteste Beispiel waren SSDs. Wir sind von HDD auf SSD umgestiegen, und das war ein kompletter Wendepunkt in unserer Performance, mit massiven Auswirkungen auf unsere Architektur. In sehr konkreten Beispielen basiert das gesamte Design von Envision, der domänenspezifischen Programmiersprache, die Lokad bereitstellt, auf den Erkenntnissen, die wir auf Hardwareebene gewonnen haben. Es ist nicht nur eine Errungenschaft; es geht darum, alles, woran man denken kann, einfach schneller zu machen.
Sie möchten eine Tabelle mit einer Milliarde Zeilen und 100 Spalten verarbeiten, und Sie möchten dies 100-mal schneller mit denselben Rechenressourcen tun? Ja, das können Sie. Sie möchten in der Lage sein, Joins zwischen sehr großen Tabellen mit minimalen Rechenressourcen durchzuführen? Ja, erneut. Können Sie superkomplexe dashboards haben, bei denen buchstäblich hundert Tabellen dem Endnutzer in weniger als 500 Millisekunden angezeigt werden? Ja, das haben wir erreicht. Dies sind alltägliche Errungenschaften, aber gerade deshalb konnten wir all das erreichen, was es uns ermöglicht, ziemlich ausgefallene prädiktive Optimierungsrezepte in Produktion zu bringen. Wir müssen sicherstellen, dass alle Schritte, die uns dorthin geführt haben, mit sehr hoher Produktivität durchgeführt werden.
Die größte Herausforderung, wenn Sie etwas sehr ausgefallenes für die supply chain in Bezug auf numerische Rezepte tun möchten, ist nicht die Phase “es zum Laufen bringen”. Sie können College-Studenten nehmen und innerhalb weniger Wochen eine Reihe von Prototypen erstellen, die irgendeine Art von supply chain Leistungsverbesserung liefern. Sie nehmen einfach Python und irgendeine zufällige Open-Source-Maschine-Learning-Bibliothek des Tages, und diese Studenten, wenn sie klug und willens sind, werden in wenigen Wochen einen funktionierenden Prototyp erstellen. Allerdings werden Sie das niemals in großem Maßstab in Produktion bringen. Das ist das Problem. Es geht darum, wie man all diese Reifestufen von “richtig machen”, “schnell machen” und “billig machen” durchläuft. Genau hier kommt die Hardware-Affinität wirklich zur Geltung und Ihre Fähigkeit zur Iteration.
Es gibt keine einzelne Errungenschaft. Allerdings erfordert alles, was wir tun – zum Beispiel wenn wir sagen, dass Lokad probabilistic forecasting betreibt – nicht so viel Rechenleistung. Was wirklich Rechenleistung erfordert, ist, sehr umfassende Wahrscheinlichkeitsverteilungen zu verwenden, all diese möglichen Zukünfte zu betrachten und sie mit all den Entscheidungen, die Sie treffen können, zu kombinieren. Auf diese Weise können Sie die besten Optionen mittels finanzieller Optimierung auswählen, was sehr kostspielig wird. Wenn Sie nichts haben, das wirklich optimiert ist, sitzen Sie fest. Die bloße Tatsache, dass Lokad probabilistic forecasting in Produktion einsetzen kann, beweist, dass wir eine umfassende Hardware-Optimierung entlang der gesamten Pipeline für alle unsere Kunden vorgenommen haben. Heutzutage bedienen wir etwa 100 Unternehmen.
Frage: Ist es besser, einen eigenen Server für Unternehmenssoftware (ERP, WMS) zu haben, anstatt Cloud-Dienste zu nutzen, um Latenz zu vermeiden?
Ich würde sagen, heute spielt es keine Rolle, denn die meiste Latenz, die Sie erleben, entsteht innerhalb des Systems. Das ist nicht das Latenzproblem zwischen Ihrem Nutzer und dem ERP. Ja, wenn Sie eine sehr schlechte Latenz haben, könnten etwa 50 Millisekunden zusätzlich entstehen. Offensichtlich möchten Sie, wenn Sie ein ERP haben, nicht, dass es zum Beispiel in Melbourne steht, während Sie in Paris operieren. Sie wollen, dass das Rechenzentrum in der Nähe Ihres Einsatzortes ist. Moderne Cloud-Computing-Plattformen verfügen jedoch über Dutzende von Rechenzentren, sodass es in Bezug auf Latenz kaum einen Unterschied zwischen Inhouse-Hosting und Cloud-Diensten gibt.
In der Regel bedeutet Inhouse-Hosting nicht, dass das ERP auf dem Boden mitten in der Fabrik oder im Lager platziert wird. Stattdessen bedeutet es, dass Sie Ihr ERP in ein Rechenzentrum stellen, in dem Sie Rechenhardware mieten. Ich glaube, dass es aus der Perspektive moderner Cloud-Computing-Plattformen mit Rechenzentren auf der ganzen Welt keinen praktischen Unterschied zwischen Inhouse-Hosting und Cloud-Diensten gibt.
Was wirklich einen Unterschied macht, ist, ob Ihr ERP intern alle Round-Trips minimiert. Beispielsweise ist es meist die Interaktion zwischen der Geschäftslogik und der relationalen Datenbank, die die Leistung eines ERPs stark beeinträchtigt. Wenn Sie Hunderte von Hin- und Her-Interaktionen haben, um eine Webseite darzustellen, wird Ihr ERP furchtbar langsam sein. Daher müssen Sie bei Unternehmenssoftware-Designs darauf achten, dass nicht eine massive Anzahl von Round-Trips entsteht. Das ist eine interne Eigenschaft der Unternehmenssoftware, die Sie betrachten, und es hängt nicht stark davon ab, wo Sie die Software betreiben.
Frage: Glauben Sie, dass wir neue Programmiersprachen benötigen, die das neue Hardware-Design auf Kernniveau aufgreifen und die Funktionen der Hardware-Architektur in vollem Umfang nutzen?
Ja, und ja. Aber um ganz offen zu sein: Ich habe hier einen Interessenkonflikt. Genau das hat Lokad mit Envision getan. Envision entstand aus der Beobachtung, dass es knifflig ist, die volle Rechenleistung moderner Computer auszuschöpfen – etwas, das möglich sein sollte, wenn man die Programmiersprache selbst mit Blick auf Performance entwirft. Man kann sie nahezu übernatürlich machen, und deshalb habe ich in der Vorlesung 1.4 über programming paradigms für supply chain gesagt, dass, wenn man die richtigen Programmierparadigmen wählt – wie Array Programming oder Data Frame Programming – und eine Programmiersprache konstruiert, die diese Konzepte aufgreift, man nahezu umsonst Leistung erhält.
Der Preis, den Sie zahlen, ist, dass Sie nicht so ausdrucksstark sind wie eine Programmiersprache wie Python oder C++, aber wenn Sie bereit sind, eine reduzierte Ausdruckskraft zu akzeptieren und alle für die supply chain relevanten Anwendungsfälle abzudecken, dann können Sie massive Leistungsverbesserungen erzielen. Das ist mein Glaube, und deshalb habe ich auch gesagt, dass beispielsweise objektorientierte Programmierung aus der Perspektive der supply chain Optimierung nichts zum Tisch beiträgt.
Im Gegenteil, dies ist eine Art von Paradigma, das nur der zugrunde liegenden Computerhardware zuwiderläuft. Ich behaupte nicht, dass objektorientierte Programmierung völlig schlecht ist; das meine ich nicht. Ich sage vielmehr, dass es Bereiche im Software Engineering gibt, in denen sie vollkommen sinnvoll ist, jedoch nicht, wenn es um die prädiktive Optimierung von supply chain geht. Also ja, definitiv, wir benötigen Programmiersprachen, die dem wirklich Rechnung tragen.
Ich weiß, dass ich mich oft wiederhole, aber Python wurde im Grunde in den späten 80er Jahren entwickelt, und dabei haben sie vieles verpasst, was über moderne Computer zu wissen war. Sie haben etwas eingebaut, bei dem sie per Design kein Multithreading nutzen können. Sie besitzen diesen globalen Lock, weshalb sie nicht mehrere Kerne verwenden können. Sie können Lokalität nicht ausnutzen. Ihre späte Bindung verkompliziert Speicherzugriffe erheblich. Sie sind sehr variabel, was zu einem hohen Speicherverbrauch führt, der sich nachteilig auf den Cache auswirkt usw.
Das sind genau die Arten von Problemen, bei denen, wenn Sie Python verwenden, Sie in den kommenden Jahrzehnten Bergaufkämpfe erleben werden – und der Kampf wird mit der Zeit nur noch schlimmer. Es wird nicht besser werden.
Die nächste Vorlesung findet in drei Wochen statt, am selben Wochentag und zur gleichen Uhrzeit. Sie wird um 15 Uhr Pariser Zeit am 9. Juni beginnen. Wir werden moderne Algorithmen für supply chain diskutieren, die gewissermaßen das Gegenstück zu modernen Computern für supply chain darstellen. Bis zum nächsten Mal.
