{"id":15892,"date":"2022-04-28T18:49:59","date_gmt":"2022-04-28T16:49:59","guid":{"rendered":"https:\/\/www.bernd-leitenberger.de\/blog\/?p=15892"},"modified":"2022-04-28T18:49:59","modified_gmt":"2022-04-28T16:49:59","slug":"die-zahl-fuer-heute-2312","status":"publish","type":"post","link":"https:\/\/www.bernd-leitenberger.de\/blog\/2022\/04\/28\/die-zahl-fuer-heute-2312\/","title":{"rendered":"Die Zahl für heute: 23,12"},"content":{"rendered":"
<\/div>\n

<\/path><\/svg><\/i> \"Loading\"<\/p>\n

<\/div>\n

In dem heutigen Blog geht es erneut um die CPU-Entwicklung und ich will mal die einzelnen Faktoren auseinander dividieren, um dann auf die ominöse Zahl 23,12 zu kommen und zuletzt mal begründen, warum ich den 32-Bit-Mikroprozessor für das Optimum halte.
\n\"\"\/
\nFangen wir mal mit dem Nettoergebnis an. Um wie viel ist die Geschwindigkeit eines Computers seit meinem ersten gestiegen? Nun wenn man es genau nimmt, vom ersten (Ti 99\/4a) gibt es kein Benchmark, das heute noch laufen würde, aber es gibt vom Z80 Prozessor der in meinem zweiten Rechner steckte ein Ergebnis des Dhrystone Benchmarks. Der erreichte bei 2,5 MHz 91 Dhrystones<\/a>, skaliert man das auf 4 MHz so sind es 145, in einem Emulator erreichte ein 3,47 MHz Z80 142 Dhrystones. Normiert wird der Benchmark auf die VAX 11\/780 die je nach Literatur bei 1560 bis 1757 liegt. Gängig werden 1757 Dhrystones als 1 Dhyrstone-MIPS zu definiert.
\n<\/p>\n

Das Problem ist natürlich auch das es den Dhrytsone Benchmark nicht gibt. Ich habe eine alte und eine moderne Version mit dem Cbuilder kompiliert und schon hier gibt es werte von 6332 und 9570 VAX-MIPS pro Kern und ein besserer Compiler erreicht dann wiederum mehr VAX-MIPS. Das ist aber die Problematik jedes Benchmarks<\/a>.<\/p>\n

Mein derzeitiger Prozessor (Core i5-4690) erreicht mit allen vier Kernen über 119.000 Dhrystone MIPS. Er ist also fast 1,5 Millionen mal schneller als mein Z80A Rechner. Nun ist mein heutiger Rechner fast acht Jahre alt, wer will kann bei Sisoft das Systeminformationsprogramm Sandra lite herunterladen<\/a> welche die Dhrystones berechnet. Warnung: Das dauert einige Minuten, während denen der PC praktisch unbenutzbar ist.<\/p>\n

Nun wie kommt die Mehrleistung zustande?<\/h3>\n

Also zuerst mal hat die heutige CPU vier Kerne ein Z80A<\/a> natürlich nur einen. Das reduziert dann schon den Vorteil um den Faktor vier auf rund 368.000-fach.<\/p>\n

Der zweite offensichtliche Punkt ist die Taktfrequenz. Die CPU-Kerne der heutigen CPU takten mit 3,5 GHz, der Z80 damals mit 4 MHz wobei er netto sogar nur mit 3,2 MHz lief (Wartezyklen durch gleichzeitigen Zugriff auf den Bildschirmspeicher durch das Gate Array). Der Takt ist also um den Faktor 875 kleiner. Nun schrumpft der Vorteil schon auf den Faktor 420 zusammen. Das gilt allerdings nur, wenn der Zusammenhang Taktsteigerung \u2013 Geschwindigkeitssteigerung linear ist. Für den Dhrytone Benchmark der relativ klein ist \u2013 er muss ja auch von einer Z80 ausgeführt werden können, gilt das. Die Problematik das mehr Takt nicht immer viel mehr Geschwindigkeit bringt, ist aber seit Anfang der Achtziger gegeben. Seitdem ist der Zugriff von Prozessoren immer schneller angestiegen als Speicher Daten liefern können. Schon die Z80 hatte als Abhilfe den Mechanismus des Waitstates, eines Wartetakts. Konnte der Speicher die Daten nicht liefern, so wartete die CPU einen Takt, das war immer noch günstiger als einen kompletten Zyklus (4 Takte) lang zu warten. Wartezyklen schlugen erst richtig bei der 80286 Generation<\/a> zu. Der IBM PC\/AT<\/a> kostete zwar über 15.000 DM, aber die 8 MHz Version hatte schon einen Wartetakt, weil IBM beim Speicher etwas Geld sparte und nicht die schnellsten Chips verbaute. Konkurrenten lieferten Rechner ohne \u201eWaitstate\u201c und warben damit. Mit dem 80386 Prozessor<\/a> wurde das Problem noch größer, der war noch höher getaktet und es zog der Cache ein, Der besteht aus schnellem SRAM, derselben Technologie wie die Register im Prozessor. Allerdings muss ein Cache<\/a> auch verwaltet werden, das addiert Zeitverluste und befindet sich Daten nicht im Cache, so muss auf den langsamen Arbeitsspeicher zugegriffen werden. Dies zeigt sich, wenn man Datenstrukturen immer größer wählt wie in diesem Test<\/a>: Die Latenz ist in L1-Cache vernachlässigbar. Sie steigt im L2-Cache auf rund 3 ns \u2013 klingt nach wenig, sind aber bei 4 GHz Takt schon 12 Takte, beim L3-Cache sind es 14 ns \u2013 56 Takte (Intel Angabe: 53) und beim Hauptspeicher sind es über 90 ns. Bei dem kleinen Dhrystone Benchmark kann man davon ausgehen, dass er komplett im Cache ist, daher auch hier eine starke Beschleunigung, die aber bei anderen Programmen durchaus nicht so sein muss.<\/p>\n

Der zweite große Punkt für eine Geschwindigkeitssteigerung ist die Vergrößerung der Bits die ein Prozessor auf einmal verarbeitet. Der heutige Prozessor ist ein 64 Bit Prozessor, der Z80 war ein 8 Bit Prozessor. Der Nutzen ist offensichtlich bei Berechnungen. Eine Berechnung mit 64 Bit kann der 64-Bit Prozessor in einem Rutsch durchführen, ein 8 Bitter braucht dazu acht Berechnungen die auch mit acht Lade- und Speicheranweisungen gekoppelt sind. Beim Dhrystone Benchmark der mit 32 Bit Zahlen arbeitet sind 8 und 16 Bit Prozessoren performen daher auch relativ schlecht, verglichen mit einem 32 oder gar 64 Bit Prozessor. Doch nicht überall ist der Vorteil sofort offensichtlich. Bei Sprüngen scheint der Vorteil von immer mehr Bits nicht gegeben zu sein. Ebenso bei Textoperationen, die früher immer mit 8 Bit erfolgten, heute mit Unicode mit 16 Bit, weil bei der Sprache C man jedes Zeichen einzeln prüfen muss ob es nicht das Nullzeichen ist, damit wurde das Stringende markiert. Aber \u2013 da ein 64 Bit Prozessor auch 64 Bit auf einmal lädt, kann er bei einem Sprung die Adresse in zwei Zugriffen laden, ein 8 Bitter braucht dafür mindestens drei Zugriffe da eine Adresse 16 Bit breit ist (plus ein Zugriff für den Opcode). Ändert sich an den Anforderungen nichts, so ist der Geschwindigkeitsgewinn nicht so hoch. Ich habe ja mal das Benchmark der ct\u2018 10\/1987<\/a> erwähnt das ich dank der langen Lebenszeit von DOS bis hin zu einem Athlon mit 550 MHz testen konnte. Das skalierte relativ linear hoch. Denn DOS nutzte eben von dem 32 Bit Befehlen nichts.<\/p>\n

Aber mit jeder Generation kommen neue Befehle dazu. Der Z80 konnte 16 Bit Arithmetik nur eingeschränkt durchführen (Addition, Subtraktion, Inkremente, Dekremente), 8 Bit Arithmetik hatte mehr Möglichkeiten, aber konnte auch nicht multiplizieren und dividieren. Das konnten die 16 Bit CPUs. Mit jeder Generation kamen Befehle hinzu, selbst bei RISC-Prozessoren. Solche Befehle können bestimmte Operationen enorm beschleunigen. Mein Paradebeispiel ist der Z80 Befehl LDIR \/ LDDR. Dieser Befehl kopiert einen Speicherblock dessen Adresse im Register HL steht in die Adressen ab Register DE, die Länge wird in Register BC angegeben. Ein Z80 Code dafür würde so aussehen:<\/p>\n

ld<\/b><\/span><\/span> hl<\/span><\/span>,startadresse <\/span><\/span>; Lade Quelladresse in Register HL<\/i><\/span><\/span><\/span><\/p>\n

ld<\/b><\/span><\/span> de<\/span><\/span>,zieladresse <\/span><\/span>; Lade Zieladresse in Register DE<\/i><\/span><\/span><\/span><\/p>\n

ld<\/b><\/span><\/span> bc<\/span><\/span>,laenge <\/span><\/span>; Lade Blocklänge in Register BC<\/i><\/span><\/span><\/span><\/p>\n

ldir<\/b><\/span><\/span><\/span><\/p>\n

Würde man denselben Code, ohne den LDIR Befehl schreiben, so wäre eine ganze Sequenz nötig:<\/p>\n

ld<\/b><\/span><\/span> hl<\/span><\/span>,startadresse<\/span><\/span><\/span><\/p>\n

ld<\/b><\/span><\/span> de<\/span><\/span>,zieladresse<\/span><\/span><\/span><\/p>\n

ld<\/b><\/span><\/span> bc<\/span><\/span>,laenge<\/span><\/span><\/span><\/p>\n

loop: <\/span><\/span>ld<\/b><\/span><\/span> a<\/span><\/span>,(<\/span><\/span>hl<\/span><\/span>) <\/span><\/span>; lade Wert aus Adresse HL ins Register A<\/i><\/span><\/span><\/span><\/p>\n

ld<\/b><\/span><\/span> (<\/span><\/span>de<\/span><\/span>),<\/span><\/span>a<\/span><\/span> ; lade Wert aus Register A in den Speicher der durch DE adressiert wird<\/i><\/span><\/span><\/span><\/p>\n

inc<\/b><\/span><\/span> hl<\/span><\/span> ; erhöhe Quelladresse<\/i><\/span><\/span><\/span><\/p>\n

inc<\/b><\/span><\/span> de<\/span><\/span> ; erhöhe Zieladresse<\/i><\/span><\/span><\/span><\/p>\n

dec<\/b><\/span><\/span> bc<\/span><\/span> ; erniedrige Zähler<\/i><\/span><\/span><\/span><\/p>\n

jp<\/b><\/span><\/span> nz<\/span><\/span>,loop <\/span><\/span>; Springe wenn Zähler nicht Null ist an den Schleifenanfang (loop)<\/i><\/span><\/span><\/span><\/p>\n\n\n\n\n\n\n
<\/th>\nLDIR<\/th>\nCode<\/th>\n<\/tr>\n<\/thead>\n
Länge<\/td>\n2 Bytes<\/td>\n8 Bytes<\/td>\n<\/tr>\n
Ausführungszeit pro Byte<\/td>\n21 Takte<\/td>\n42 Takte<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Es wird \u00be des Codes eingespart. Relevanter ist die Beschleunigung der Ausführung. Bei der Z80 werden für fünf Befehle die Fetches aus dem Arbeitsspeicher und das Dekodieren eingespart. Da der Sprungbefehl noch einen weiteren Fetch erfordert und jeder Fetch\/Decode mindestens 3 Takte erfordert, halbiert sich die Ausführungsdauer.<\/p>\n

Wäre die Z80 CPU fähig, mehrere Instruktionen gleichzeitig auszuführen, wie heute üblich, dann wäre beim LDIR Befehl intern viel parallelisierbar \u2013 das Erhöhen der Adressen wäre direkt nach den Ladebefehlen möglich. Im Prinzip wären die drei Inkrement\/Dekrement Befehle parallel ausführbar. Die Parallelität kann in komplexen Befehlen aber schon intern in dem Microcode genutzt werden, dagegen benötigt man für die obige Schleife eine aufwendige Logik die Abhängigkeiten erkennt. Heutige Prozessoren haben Spezialbefehle für Verschlüsselung und Entschlüsselung die eine noch viel höhere Beschleunigung ermöglichen. Ähnliches findet man bei Vektoroperationen: AVX kann in der neuesten Version AVX512 acht Zahlen in der gleichen Zeit bearbeiten wie mit den normalen Fließkommaoperationen.<\/p>\n

Die nächste Stufe ist die interne Optimierung, dies kann man nicht an Befehlen festmachen, sondern an ihren Ausführungszeiten. Und hier komme ich zu der ominösen Zahl 23,12. Sie gibt an, um wie viel schneller ein Befehl intern ausgeführt wird \u2013 jetzt unabhängig von der Art und Leistungsfähigkeit des Befehls. Beim Z80 brauchte ein Befehl im Instruktionsmix 6,8 Takte. Die schnellsten Befehle brauchten 4 Takte, die langsamsten 23. Durch eine Pipeline kann man die Ausführungszeit auf minimal 1 Takt pro Befehl drücken, das wurde beim Z80 auch gemacht. Der eZ80 hat eine solche Pipeline und ist dreimal schneller als ein Z80 bei gleichem Takt (also 2,2 Takte im Mix). Mehr geht nur durch interne Parallelität<\/a>, sprich man führt mehrere Befehle parallel aus, wie ich dies schon beim obigen Codestück angedeutet habe. Der eZ80 reduziert so die Ausführungszeit des LDIR Befehls auf 8 Takte, nutzt man einen neuen Modus in dem er 16 Bit auf einmal kopiert (anstatt byteweise) so sind es sogar nur 6 Takte.<\/p>\n

So kam ich auch auf die Zahl 23,12. Die Angabe bezieht sich auf die \u201eInstructions per Cycle\u201c IPC also Anweisungen pro Takt. Beim Z0 betrug dieser Wert 1\/6,8. Ähnlich sah es bei8086 aus (1\/7,5), dann wurde es schrittweise besser: 80286: 1\/4,92, 80386: \u00bc, 80486 1\/1,95 und der Pentium erreichte als erster Prozessor die magische Zahl 1.<\/p>\n

Die modernsten Prozessoren der x86 Architektur (Alder Lake \u2013 Core 12.te Generation und Zen 3) erreichen einen IPC von 3,4, daraus ergibt sich eine Beschleunigung des internen Ablaufs in knapp 40 Jahren um den Faktor 23,12. Alles was oberhalb von 1 liegt, ist nur durch interne Parallelität und das Vorziehen von Befehlen möglich. Das ging los im Pentium.<\/p>\n

Der 32 Bit Prozessor als Optimum<\/h3>\n

Zuletzt noch einen Blick, warum ich einen 32 Bit Prozessor für das ideale handele. Die Angabe \u201en Bit\u201c legt fest, wie groß die internen Register sind. Damit wird auch festgelegt, wie viele Bits maximal in einer Operation verarbeitet werden können und wie groß der Adressbereich ist. Bei Intel stieg die Bitbreite schnell von 4 Bit (1971) über 8 Bit (1973) zu 16 Bit (1978) und 32 Bit (1985). Doch dann dauerte es 20 Jahre bis die Architektur auf 64 Bit erweitert wurde. Der Grund war, das vorher der Adressbereich immer um 4 Bits anstieg, was in zwei Chipgenerationen, damals etwa sechs bis sieben Jahren aufgeholt war:<\/p>\n\n\n\n\n\n\n\n\n\n\n
Prozessor<\/th>\nJahr<\/th>\nBitBreite<\/th>\nAdressbits<\/th>\nStandard Speicherchipgröße<\/th>\n<\/tr>\n<\/thead>\n
4004<\/td>\n1971<\/td>\n4<\/td>\n12<\/td>\n1 KBit<\/td>\n<\/tr>\n
8008<\/td>\n1972<\/td>\n8<\/td>\n14<\/td>\n1 kbit<\/td>\n<\/tr>\n
8080<\/td>\n1974<\/td>\n8<\/td>\n16<\/td>\n4 kbit<\/td>\n<\/tr>\n
8086<\/td>\n1978<\/td>\n16<\/td>\n20<\/td>\n64 Kbit<\/td>\n<\/tr>\n
80286<\/td>\n1982<\/td>\n16<\/td>\n24<\/td>\n256 kbit<\/td>\n<\/tr>\n
80386<\/td>\n1985<\/td>\n32<\/td>\n32<\/td>\n256 kbit<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Man brauchte bei Vorstellung der Prozessoren bis zum 80286 immer 128 Chips der aktuellen Generation für den Speichervollausbau Das war viel und angesichts der Preise auch teuer. Beim 80286 stieg dies auf 512 Chips, aber drei Jahre später steigerte der 80286 dies um den Faktor 256, was vier Chipgenerationen entsprach. Erst 2004 war so viel RAM auch bezahlbar und Intel sah die Notwendigkeit, die Bitbreite zu erweitern um mehr RAM zu adressieren. 64 Bit nutzt für die Adressierung übrigens kein Prozessor, es sind zwischen 40 und 48 Bit. 264<\/sup> Speicherzellen belegen selbst wenn man pro Siliziumatom (Durchmesser 210 pm) ein Elektron speichern könnte, und es keine Isolation zwischen ihnen geben würde, knapp einen Quadratmeter Siliziumfläche. Der durch eine größere Breite der Reigster verfügbare Adressraum dürfte die Hauptantriebsfeder für die Erweiterung der internen Architektur gewesen sein.<\/p>\n

Der zweite Grund ist natürlich, dass ein Prozessor maximal so große Zahlen in einem Stück bearbeiten kann wie seine Bitbreite beträgt. Dabei reden wir von Ganzzahlen. Fließkommazahlen mussten frühere Prozessoren per Software verarbeiten bzw. es gab spezialisierte Coprozessoren die dann aber auch Zahlen verarbeiteten die erheblich größer als die Adressbreite des Prozessors war, so z.B. mit dem 8087 Coprozessor bis zu 80 Bit Fließkommazahlen bei einem 16 Bit 8086 Hauptprozessor.<\/p>\n

Ganzzahlen braucht man entweder als Indexe für Schleifen oder Arrays, daneben Koordinaten (z.B. auf dem Bildschirm) oder weil der Datentyp, der verarbeitet wird, eine Ganzzahl ist. Das kann auch ein Zeichen sein, das intern auch nur eine Zahl ist. Es ist logisch, das man je größer der Wertebereich ist, man mit mehr Bits immer mehr Anwendungen abdeckt. Mit einem Byte kommt man als Index für ein Feld oder als Koordinate für den Bildschirm nicht weit. Mit 16 Bit kann man schon viele Anwendungen mehr abdecken und mit 32 Bit kann man wirklich Arrays indizieren, die größer als der adressierbare Arbeitsspeicher sind. Der Zugewinn wird also immer kleiner. Für 64 Bit sprechen nur zwei Aspekte. Das eine ist, das nun Fließkommazahlen und Ganzzahlen gleich groß sind , zumindest beim standardisierten Fließkommatyp \u201elong double\u201c, der meist eingesetzt wird. Das vereinfacht die Befehlsstruktur des Prozessors und den Fetch. Der zweite Vorteil ist ,dass man mit so langen Ganzzahlen auch viele Fließkommarechnungen erschlagen kann indem man eine Festpunktdarstellung einsetzt. Für Währungen gibt es z.B. einen 64 Bit Ganzzahl-Typ mit 15 Vor- und 4 Nachkommastellen.<\/p>\n

Ansonsten hat aber jede Erweiterung der Bitgröße Nachteile. Ein Befehl besteht aus mehreren Teilen. Zum einen einem Bereich der den Befehlstyp angibt, dann folgen Parameter, die dazu gehören. Bei Rechnungen z.B. die Register die beteiligt sind und spätestens, wenn Daten aus dem Speicher geholt und geschrieben werden müssen, oder es Sprünge gibt folgen dann Adressen. Der Code wird so bei längeren Adressen automatisch länger wenn die Bitbreite ansteigt. Bei der Intel Architektur ist 64 Bit Code rund doppelt so groß wie 32 Bit Code, aber nicht schneller. Deshalb rät selbst Microsoft zu der 32 Bit Version von Office.<\/p>\n

Bei einem 32 Bit Prozessor ergibt sich eine sehr elegante Lösung für Befehlsformate, man kommt nämlich mit zwei aus, die dann sogar noch auf geraden 32 Bit Grenzen liegen, dazu später noch etwas. Das wäre das erste Format wenn der Befehl keine Adresse beinhaltet<\/p>\n\n\n\n\n\n
Opcode<\/th>\nRegister1\/Parameter<\/th>\nRegister 2<\/th>\nRegister 3<\/th>\n<\/tr>\n<\/thead>\n
\n

8 Bit<\/p>\n<\/td>\n

\n

8 Bit<\/p>\n<\/td>\n

\n

8 Bit<\/p>\n<\/td>\n

\n

8 Bit<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Ein Opcode von 8 Bit lässt 256 grundlegende Befehle (ohne Varianten) zu. Für mathematische Operationen im 3-Adressschema<\/a> stehen dann je 8 Bit für 256 Register zur Verfügung (wenn man noch Teilbereichsoperationen wie 8 oder 16 Bit unterstützen will, kann man hier in jedem Feld 1 Bit opfern und so 8 weitere Unterscheidungsmöglichkeiten haben bei 128 Registern.<\/p>\n

Es gibt auch befehle mit weniger Parametern wie keinem (NOP \u2013 No Operation) oder EI (Enable Interrupts) oder einem Parameter (bedingte Sprünge, Push\/Pop, Incement\/decrement \u2026) dann sind hier Felder leer.<\/p>\n

Das zweite Format dient dazu Adressen\/Zahlen in die Register zu laden\/speichern:<\/p>\n\n\n\n\n\n
Opcode<\/th>\nRegister1\/Parameter<\/th>\nZahl<\/th>\n<\/tr>\n<\/thead>\n
\n

8 Bit<\/p>\n<\/td>\n

\n

8 Bit<\/p>\n<\/td>\n

\n

48 Bit<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Das ist dann genau 64 Bit lang, also so lang wie zwei 32 Bit Bündel. Wie man sieht hat man sogar 48 Bit zur Verfügung. Bei Nicht-Adressen würde man davon nur 32 Bits benötigen. Die 48 Bits kann man über segmentierte Adressierung nutzen oder die Adressregister sind 48 Bit breit \u2013 solche Architekturen mit unterschiedlich breiten daten- und Adressregistern hatten früher zahlreiche Rechner z.B. alle Rechner von Seymour Cray<\/a>. Aber auch ohne dieses Feature mit nur 32 Bit für Adressen\/Zahlen hat dieses Format am wenigsten \u201eVerschnitt\u201c (mit einem 16 Bit Format gäbe es außer bei Befehlen ohne Parameter gar keinen Verschnitt, aber ein 32 Bit Rechner greift eben 32 Bit weise auf den Arbeitsspeicher zu. Es ist klar, dass der Verschnitt bei einem 64 Bit Zugriff größer ist.<\/p>\n

Natürlich sind auch unterschiedlich lange Befehlsformate denkbar, wie sie bei der x86 Linie<\/a> historisch gewachsen sind. Aber sie haben deutliche Nachteile. Das Dekodieren ist aufwendiger, der Fetch ist nicht vorhersehbar und vor allem bestraft der Prozessor Zugriffe auf Adressen, die nicht auf ganzen Wortgrenzen liegen. Viele Prozessoren erlauben das gar nicht erst, die Systemprogrammiersprache BCPL sieht z.B. Pointer nur auf durch 4 teilbaren Adressen vor. Bei der x86 Architektur geht der Zugriff weil man dort noch 8 und 16 Bit Werte verarbeiten kann, ein Zugriff auf eine Adresse die zwischen zwei 32 oder 64 Bit Worten liegt erfordert aber dann real zwei Zugriffe, bremst also aus.<\/p>\n

Der einzige Nachteil eines 32 Bitters ist eigentlich der auf 4 GByte begrenzte Adressraum, der so heute nicht mehr ausreicht. Aber nur auf den ersten Blick. Zum einen kann man wortweise adressieren, anstatt byteweise, dann sind es schon 16 GByte. Daneben haben wir heute in den Prozessoren mehrere Kerne, jeder kann aber einen getrennten Adressraum haben, anstatt sich einen zu teilen. Das Betriebssystem kann dann in einem gemeinsamen geteilten Bereich sitzen. Bei einem AMD Threadripper<\/a> mit 64 logischen Kernen käme man so auf 1 TByte Speicher und das ist heute noch mehr, als in den meisten Servern steckt. Wenn 1 TByte in einigen Jahren nicht mehr reichen sollten, wette ich hat auch der Prozessor mehr Kerne.<\/p>\n

Daher sehe ich den 32 Bit Prozessor als die Optimallösung an.<\/p>\n","protected":false},"excerpt":{"rendered":"

<\/div>\n

<\/path><\/svg><\/i> \"Loading\"<\/p>\n

<\/div>\n

In dem heutigen Blog geht es erneut um die CPU-Entwicklung und ich will mal die einzelnen Faktoren auseinander dividieren, um dann auf die ominöse Zahl 23,12 zu kommen und zuletzt mal begründen, warum ich den 32-Bit-Mikroprozessor für das Optimum halte. Fangen wir mal mit dem Nettoergebnis an. Um wie viel ist die Geschwindigkeit eines Computers […]<\/p>\n","protected":false},"author":169,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[4],"tags":[1657,3786,4841,3784],"class_list":["post-15892","post","type-post","status-publish","format-standard","hentry","category-computer","tag-benchmark","tag-dhrystone","tag-ipc","tag-mips","entry"],"a3_pvc":{"activated":true,"total_views":3938,"today_views":0},"jetpack_featured_media_url":"","jetpack-related-posts":[{"id":18612,"url":"https:\/\/www.bernd-leitenberger.de\/blog\/2026\/03\/28\/galileos-cds-teil-2\/","url_meta":{"origin":15892,"position":0},"title":"Galileos CDS \u2013 Teil 2","author":"Bernd Leitenberger","date":"28. M\u00e4rz 2026","format":false,"excerpt":"So, heute geht es weiter mit Teil 2 \u00fcber Galileos CDS, dieser Beitrag schlie\u00dft nahtlos an den ersten Beitrag von gestern an, wie man schon an der ersten Textzeile sieht. Nach der Einleitung im ersten Teil geht es heute weiter damit warum der RCA 1802 genutzt wurde und was seine\u2026","rel":"","context":"In "Raumfahrt"","block_context":{"text":"Raumfahrt","link":"https:\/\/www.bernd-leitenberger.de\/blog\/category\/raumfahrt\/"},"img":{"alt_text":"","src":"https:\/\/vg07.met.vgwort.de\/na\/191e4b0728de42829cf656027b84dc82","width":350,"height":200},"classes":[]},{"id":18614,"url":"https:\/\/www.bernd-leitenberger.de\/blog\/2026\/03\/29\/galileos-cds-teil-3\/","url_meta":{"origin":15892,"position":1},"title":"Galileos CDS – Teil 3","author":"Bernd Leitenberger","date":"29. M\u00e4rz 2026","format":false,"excerpt":"So nun zum dritten Teil \u00fcber das prim\u00e4re Computersystem von Galileo, das CDS. Nachdem sich die ersten beiden Teile nur mit dem RCA 1802, warum er gew\u00e4hlt wurde und seiner Architektur befassten geht es heute um das Computersystem selbst. Der Artikel schlie\u00dft so an seine beiden Vorg\u00e4nger gestern und vorgestern\u2026","rel":"","context":"In "Raumfahrt"","block_context":{"text":"Raumfahrt","link":"https:\/\/www.bernd-leitenberger.de\/blog\/category\/raumfahrt\/"},"img":{"alt_text":"","src":"https:\/\/vg07.met.vgwort.de\/na\/6e7f572a246b4ac395de9c260733b707","width":350,"height":200},"classes":[]},{"id":18610,"url":"https:\/\/www.bernd-leitenberger.de\/blog\/2026\/03\/27\/galileos-cds-teil-1\/","url_meta":{"origin":15892,"position":2},"title":"Galileos CDS – Teil 1","author":"Bernd Leitenberger","date":"27. M\u00e4rz 2026","format":false,"excerpt":"Hall\u00f6chen, es wird Zeit das ich mich mal wieder melde. Es gab zwei Gr\u00fcnde, warum ich mich so rar gemacht habe. Das eine ist das es gerade nicht so viel aktuelles gibt, au\u00dfer einem Update zu Artemis, zu dem ich vielleicht noch etwas schreibe. W\u00e4hrend Trump das ganze Programm nach\u2026","rel":"","context":"In "Raumfahrt"","block_context":{"text":"Raumfahrt","link":"https:\/\/www.bernd-leitenberger.de\/blog\/category\/raumfahrt\/"},"img":{"alt_text":"","src":"https:\/\/vg07.met.vgwort.de\/na\/4fb81c7bafbd4d9d88b5695abdb33d29","width":350,"height":200},"classes":[]},{"id":18511,"url":"https:\/\/www.bernd-leitenberger.de\/blog\/2026\/01\/27\/musks-ki-rechenzentren-im-orbit\/","url_meta":{"origin":15892,"position":3},"title":"Musks KI-Rechenzentren im Orbit","author":"Bernd Leitenberger","date":"27. Januar 2026","format":false,"excerpt":"Bei meinem regelm\u00e4\u00dfigen Besuch des Space Reviews stie\u00df ich auf diesen Artikel: SpaceX, orbital data centers, and the journey to Mars. Ich hatte in meiner Nachlese schon erw\u00e4hnt das Elon Musk, nachdem er dies lange verschoben hat nun plant SpaceX an die B\u00f6rse zu bringen. Ich meinte aber, das l\u00e4ge\u2026","rel":"","context":"In "SpaceX"","block_context":{"text":"SpaceX","link":"https:\/\/www.bernd-leitenberger.de\/blog\/category\/raumfahrt\/spacex\/"},"img":{"alt_text":"","src":"https:\/\/vg06.met.vgwort.de\/na\/0ee72da693054bc3b5c3f00214a7e2b3","width":350,"height":200},"classes":[]},{"id":18380,"url":"https:\/\/www.bernd-leitenberger.de\/blog\/2025\/09\/03\/die-glorreichen-10-das-war-mal-weg-pc-hardware\/","url_meta":{"origin":15892,"position":4},"title":"Die glorreichen 10 – Das war mal weg: PC Hardware","author":"Bernd Leitenberger","date":"3. September 2025","format":false,"excerpt":"Ich will heute mal zwei ZDF Info \/ Neo Sendungen verbinden. Die glorreichen 10, die bei mir als Vorlage f\u00fcr einige Blogs dienten und die von mir noch mehr gesch\u00e4tzte Sendung \"Das war mal weg\", wo es um Dinge geht, die fr\u00fcher fast jeder hatte und die heute aus unserem\u2026","rel":"","context":"In "Die Glorreichen 10"","block_context":{"text":"Die Glorreichen 10","link":"https:\/\/www.bernd-leitenberger.de\/blog\/category\/allgemein\/die-glorreichen-10\/"},"img":{"alt_text":"","src":"https:\/\/vg02.met.vgwort.de\/na\/876c61d389304d98aa0332fadd769381","width":350,"height":200},"classes":[]},{"id":18524,"url":"https:\/\/www.bernd-leitenberger.de\/blog\/2026\/02\/06\/elon-musks-ki-rechenzentren-im-orbit-nochmals-nachgerechnet\/","url_meta":{"origin":15892,"position":5},"title":"Elon Musks KI-Rechenzentren im Orbit – nochmals nachgerechnet","author":"Bernd Leitenberger","date":"6. Februar 2026","format":false,"excerpt":"Ich habe mich ja schon mal mit diesem Thema besch\u00e4ftigt, in dem es vor allem um die Kosten und den wirtschaftlichen Unsinn ging - warum sollte ich ein Rechenzentrum in den Orbit bringen, wenn ich es billiger auf der Erde bauen kann und es auch gen\u00fcgend Gegenden gibt in denen\u2026","rel":"","context":"In "Raumfahrt"","block_context":{"text":"Raumfahrt","link":"https:\/\/www.bernd-leitenberger.de\/blog\/category\/raumfahrt\/"},"img":{"alt_text":"","src":"https:\/\/vg06.met.vgwort.de\/na\/78014052fde04012a2be60bd108cd4bb","width":350,"height":200},"classes":[]}],"jetpack_sharing_enabled":true,"amp_enabled":true,"_links":{"self":[{"href":"https:\/\/www.bernd-leitenberger.de\/blog\/wp-json\/wp\/v2\/posts\/15892","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.bernd-leitenberger.de\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.bernd-leitenberger.de\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.bernd-leitenberger.de\/blog\/wp-json\/wp\/v2\/users\/169"}],"replies":[{"embeddable":true,"href":"https:\/\/www.bernd-leitenberger.de\/blog\/wp-json\/wp\/v2\/comments?post=15892"}],"version-history":[{"count":0,"href":"https:\/\/www.bernd-leitenberger.de\/blog\/wp-json\/wp\/v2\/posts\/15892\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.bernd-leitenberger.de\/blog\/wp-json\/wp\/v2\/media?parent=15892"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.bernd-leitenberger.de\/blog\/wp-json\/wp\/v2\/categories?post=15892"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.bernd-leitenberger.de\/blog\/wp-json\/wp\/v2\/tags?post=15892"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}