Was Prozessoren und die Frequenzwand mit der Cloud zu tun haben

Seit bald 20 Jahren werden die CPU-Kerne für Computer nicht mehr schneller. Trotzdem werden neue Prozessoren verkauft. Und der Trend geht in die Cloud. Wie das zusammenhängt.

Im Economist erschien im September eine Grafik, die mir die Entwicklung der Prozessoren in den Computern in den 5 Jahrzehnten wieder in Erinnerung rief. Da sie hinter einer Paywall steckt, habe ich eine ähnliche Grafik gebaut, die auf denselben frei verfügbaren Daten aufbaut, die auch der Economist genutzt hat:

Es fällt sofort auf, dass die meisten Trendlinien um 2005 herum einen markanten Knick machen, abgesehen von der Transistorzahl, die ungebrochen ca. alle 7 Jahre um den Faktor 10 (eine Y-Skaleneinheit) wachsen. Was ist da passiert?

Eine englische Version der Grafik gibt es hier.

Problem 1: Der Stromverbrauch

Heutige Computerchips bestehen aus Milliarden von Transistoren. Durch jeden einzelnen Transistor fliessen bei jedem Ein- oder Ausschalten Strom, um diese Änderung den nachfolgenden Transistoren mitzuteilen. (Wenn sich nichts ändert, fliesst so gut wie kein Strom. Ja, das funktioniert anders als bei den heimischen Lampen, liegt aber an der Art der eingesetzten Transistoren.)

Daraus ergibt sich auch, dass mehr Schaltvorgänge an einem Transistor auch mehr Stromverbrauch (und damit Abwärme) bedeuten. Je schneller also die Taktfrequenz eines Chips ist, desto mehr Energie verbraucht jeder Transistor. Und wenn die Transistoren sehr eng gepackt sind, dann wird dieser kleine, nur wenige mm² grosse Chip sehr schnell warm und heiss. Energie von einem kleinen Objekt wegzuführen, bevor es zu heiss wird, ist gar nicht so einfach.

Problem 2: Die Lichtgeschwindigkeit

Licht bewegt sich unheimlich schnell, im Vakuum mit rund 300’000 km pro Sekunde. Pro Sekunde also gut 7x um den Erdball oder in etwas über 8 Minuten von der rund 150 Millionen km entfernten Sonne bis zu uns. Oder etwa eine Tausendstelsekunde (Millisekunde, ms) für die knapp 300 km von St. Gallen bis Genf.

Gleich schnell bewegt sich auch ein Funksignal, sei es beim Radiosender oder beim WLAN.

Nur etwa ⅔ so schnell sind aber Signale in Brillengläsern oder Glasfasern (Grund dafür ist der Brechungsindex). D.h. auch wenn man eine Glasfaser querfeldein ohne Umweg zwischen St. Gallen und Genf verlegen würde, das Datenpaket bräuchte in der Glasfaser statt einer neu 1½ ms. (Glasfaser ist für die schnelle Internetanbindung trotzdem besser, da die einzelnen Datenbits viel, viel näher zusammengepackt werden können. Funkverbindungen sind dafür viel flexibler.)

Ein Datenpaket mit einer Anfrage von St. Gallen nach Genf ist also in frühestens 2*1½ ms = 3 ms beantwortet. Aber wir schweifen ab.

Auch in der Kupferleitung sind elektrische Impulse nur etwa 200’000 km/s schnell.

Bei den heute üblichen Taktfrequenzen von rund 2 GHz ist die Zeit zwischen zwei Takten nur ½ Nanosekunde (ns), eine halbe Millionstelsekunde. In dieser Zeit kommt ein elektrischer Impuls maximal 10 cm weit. D.h. ein Chip muss viel kleiner sein als 10 cm, um überhaupt mit 2 GHz getakten werden zu können. (Infolge vieler, z.T. hintereinandergeschalteter Transistoren und verschiedener weiterer elektrisch-physikalischer Komplikationen ist das in der Praxis nochmals weit weniger.)

Chips heute

Unter anderem aus diesen beiden Gründen werden Chips in der Praxis nicht schneller als mit 2 GHz getaktet. Wenn aber die 20 Jahre alten Chips aus 2005 gleich schnell wären wie die heutigen, würde ja niemand neue Chips kaufen.

Mehr statt schneller

Unter anderem deshalb haben die Chiphersteller vor rund 20 Jahren begonnen, zuerst 2, dann 4 und später noch mehr Recheneinheiten («Cores») auf einen Chip zu packen. Mit nur wenig mehr Fertigungskosten konnte so doppelt so viel Leistung verkauft werden.

Exkurs: Wer programmiert sowas?

Bis dahin waren sich die meisten Programmierer gewöhnt, dass der Prozessor immer ein Schritt nach dem anderen ausführte. Mit den vielen Cores konnte man aber nur schneller werden, wenn man die Aufgabe in mehrere Teilprobleme zerlegte, die dann (in sogenannten «Threads», Ablauffäden, parallel zueinander ausgeführt wurden.

Wenn die unterschiedlichen Threads auf die gleichen Daten zugreifen (und mindestens einer davon sie auch ändert), müssen sich diese Threads zuerst koordinieren («Synchronisation»). Wenn das vergessen wird, kommt es zu Programmfehlern, -abstürzen oder Sicherheitsproblemen.

Was hat das aber mit der Cloud zu tun?

Ein einzelner Nutzer und die meisten Programme können diese modernen Chips gar nicht mehr alleine auslasten. Deshalb warten sie die grösste Zeit. Das klingt aber nach Verschwendung, also versucht man das auch zu nutzen.

Dadurch kommt man dann automatisch dazu, dass man zuerst verschiedene Applikationen aus demselben Haus darauf laufen lässt. Oder später dann auch darüber nachdenkt, die brachliegende Hardware zu vermieten und auch noch über fremde Applikationen auf der eigenen Hardware nachdenkt. Und schon war die Cloud geboren.

Kristian Köhntopp hat das kürzlich im Fediverse pointiert beschrieben (mit etwas mehr Informatik-Slang als ich verwendet habe; eine etwas entschärfte Variante hat er später hier geschrieben):

• Wir haben zu viele Transistoren pro Chip. Die Hersteller von Chips wissen nicht, was sie damit tun sollen. Du bekommst absurde Features (KI-Inferenz, Dutzende FPUs, bla) in den P-Cores, oder ganze SoC (RAM, NVME-Controller, Grafik und Inferenz-Beschleuniger) in den Consumer Chips wie bei Apple.
• Wir haben daher zu viele Cores pro Socket (E-Cores -> 128-256 Cores pro Socket)
• Als Kunde habe ich dadurch das Problem, daß die Dichte so groß wird, daß ich kein Bare Metal mehr fahren kann, sondern eine Layer zum Kleinschneiden der Scheiße brauche: K8s oder ein Virtualisierer.
• Als Kunde habe ich dadurch ein Blast-Radius-Problem. Wenn Du ein Hobel umfällt, dann nimmt er den ganzen Laden mit.
• Als Kunde will ich mich also mit mehreren Kunden zusammentun und dann nutzt jeder Kunde ein Stück von jedem Rechner, sodaß bei einem umfallenden Hoben alle Kunden ein bischen leiden, aber keiner ganz tot geht. Ich gehe also zu einem Dienstleister und miete da eine VM in passender Zahl und Größe UND brauche keine Hardware-Kundigen mehr.
• Als Anbieter von so etwas kann ich den Rechner veredeln, durch Bla-as-a-Service. Als Kunde brauch ich damit keine Bla-Kundigen mehr, und kann die zusammen mit den Rechner-Hardware-Kundigen in die Hölle schicken.
• Als Kunde von so einem Anbieter habe ich nun reine Entwcikler, die in komplett abstrakten Layers Dinge zusammenstecken, low-code und nahe an Business Problemen. Dadurch habe ich niemanden nirgendwo mehr, der auch nur einen Hauch einer Ahnung hat, was das alles bedeutet, lastmäßig und ob der getriebene Aufwand dem Problem angemessen ist. Ich kann einen weiteren Dienstleister wie Corey Quinn dafür bezahlen mir zu erklaren wie Scheiße ich bin.
• Das Bruttosozialprodukt steigt, weil das ja jetzt alles Exchanges zwischen Firmen sind, statt innerhalb einer Firma.

Kristian Köhntopp im Fediverse, «Cloud und Kosten», 2024-09-30

Zum oben beschriebenen «Blast-Radius»-Problem: Ab 2-3 Rechnern, besser aber 4+, kann man diese übrigens so einrichten, dass bei einem Ausfall des einen seine Kollegen seine Arbeit übernehmen. Wenn es zu mehreren Ausfällen kommt und dadurch sehr knapp wird, gibt es meist irgendwelche Systeme, die nicht so wichtig sind und pausiert werden können. Dazu gehören zum Beispiel Test-Systeme, die zu viel vorgehalten werden.

Mehr zu Prozessoren

Gewisse Sicherheitsprobleme sind dadurch entstanden, dass die Prozessorhersteller die Ausführung von Code auf den Prozessoren möglichst beschleunigen mussten (und gewisse Sicherheitstests dann nicht oder zu spät erfolgen). Wie beispielsweise die ganze Familie von Spectre, Meltdown und ihren unzähligen Nachfahren:

Andere Probleme beruhen aber auf der Tatsache, dass so viele unabhängige Programme von unabhängigen Teams (oder gar unabhängigen Firmen) sich dieselbe Hardware (Prozessor, Speicher, …) teilen.

Oder auch nur ein Programm, welches nicht mit kritischen Daten arbeitet (und deshalb weniger Sicherheitschecks bekommen hat) mit einem anderen Programm auf der gleichen Hardware arbeiten muss.

Weiterführende Literatur

• Kristian Köhntopp: Cloud Cost vs. On-Premises Cost, 2024-09-30.
  Die erste Referenz auf diese Grafik (ok, die allererste war sein Fediverse-Post).
• Christos Kozyrakis, Aman Kansal, Sriram Sankar, Kushagra Vaid: Server Engineering Insights for Large-Scale Online Services (PDF, local copy), IEEE Micro, July/August 2010.
  Die älteste Kopie der ursprünglichen Grafik, den ich finden konnte. Enthält auch Einblicke in die Interaktion zwischen Prozessoren, Rechenzentren und einigen grossen Applikationen wie Hotmail und Bing.
• Karl Rupp: 40 Years of Microprocessor Trend Data, 2015-06-25.
  Die älteste Variante der Grafik, auf der meine beruht. Mit Hintergründen.
• Karl Rupp: 42 Years of Microprocessor Trend Data, 2018-02-15.
  Einige Updates.
• Karl Rupp: Microprocessor Trend Data, GitHub, lebendes Repository (letztes Update: 2022-02-22).
  Die Daten plus die Plotwerkzeuge, zusammen mit den erzeugten Grafiken. Auf dieser Version beruht meine Grafik.