 Gut, dann hallo und herzlich willkommen zum Tag 3 der GPN und es ist ein sehr großer Anrang gewesen, deshalb möchte ich eigentlich jetzt dem Publikum, was jetzt hier schon seit fünf Minuten rum sitzt und wartet, nicht den Vortrag noch weiter nach hinten schieben. Deshalb willkommen zu der Shipshow oder How Not to Build a CPU und mit einem hoffentlich tobenen Applaus. Willkommen Peter. Danke sehr. Ich habe es vorhin schon mal erwähnt. Folien voll drüber gucken ist klug, erstmal Nachnamen gelegt, gehört sich so, Obseck und so, gabs Talks auf dem Chaos. Wir reden über Früher und was man früher alles gemacht hat. Weiß jemand was das ist? Das ist ein Computer, den man gebaut hat, um deutsche Nazi Verschuldung zu knacken. Und nein, es ist nicht die Enigma. Das ist der Colossus, den die Briten auch gebaut haben, um eine andere deutsche Verschuldungsmaschine zu knacken, ein bisschen einfacher war. Aber dieses Ding lässt sich tatsächlich als Computer bezeichnen, weil die Enigma ist basically die Enigma-Tagmaschine, The Warm ist basically ganz viele Röhren. Das Ding kann rechnen. Also man muss rumstecken, um es zu programmieren, aber es ist ein Rechner, aber halt zum Passwort knacken. Wahrscheinlich auch die erste Implementierung eines Stringalgorithmus und Hardware. Bis hier ist auch eine schöne Maschine, drei Jahre jünger oder so. Eniak, da sind die Leute auf eine ganz tolle Idee gekommen, wie rechnet man richtig so von 0 bis 9, dann kommt eine 10 und dann die Maschine ist Dezimal. Dinge, die man auf jeden Fall unbedingt tun sollte. Dezimalrechnen, es gibt schon einen Grund. Für Menschen gilt es nicht, aber CPUs sollten schon wie näher sein. Irgendjemand hat ihr jeder von euch schon mal was davon gehört. Dezimalrechnen weird. Genau, aber wenn ihr jetzt hofft, dass ich über so alte Maschinen weiterrehe, der Schortlein in die Röhre. Dieses hier ist ein schönes Gerät aus den Computern gebaut, im 20 Millionen Nanometer Prozess. Oder gut zwei Zentimeter für Leute, die das nicht so spontan im Kopf umberechnen können. Ja, früher hat man, heute muss man die Transistor mit der Lupe suchen. Also da kann man wahrscheinlich einfach die Lupe mit dem Transistor suchen oder, naja, gut, Transistor und sind auch zum Junge dafür, die sind zugegenermaßen wahrscheinlich entwickelt worden, als dieses Ding da auf den Markt gekommen ist. Genau, also Elektroneröhren sind irgendwie sehr coole Geräte, weil man kann damit super schön allerloge Schaltung regeln und man kann den Strom steuern, abhängig von der Spannung, damit kann man rechnen, weil offensichtlich Strom an und Strom aus, gibt irgendwie Strom an und Strom aus Signal und dann hat man irgendwie Schaltungen, die kann man bauen und es ist super cool, weil die Dinger rechnen mit Lichtgeschwindigkeit oder beinahe und dadurch, dass die analog sind, kann man da richtig schön durch die Gegend schieben, also sowas wie, ich nehme ein kleineres Spannungslevel als nur ein größeres Spannungslevel als eins und dann kann ich dazwischen depolieren, dann muss ich die mal an und ausschalten, weil das braucht ganz schön lange, komplett aus und komplett anzuschalten, aber nicht einfach nur ein bisschen dazwischen Wankl, wenn ich Analogtechnik habe, super cool, super schnell. Polem ist nur, also ja gut von zwei Zentimeter kriegt man vielleicht noch auf einen halben Zentimeter Durchmesser runter, aber danach sind wir dann auf. Insofern eher nicht so und insofern gucken wir zwar an, was in der Zwischenzeit passiert ist, bis wir anfangen, uns mit Dingen zu beschäftigen, wo man tatsächlich von CPU Architektur reden kann und nicht von, naja, warum stürzt unser Rechner nach vier Stunden ab, also klar, meine Software darf noch vier Stunden crashen, weil die habe ich geschrieben, aber das liegt an meiner Software und nicht an der Hardware drunter und ihr wisst alle, dass der Begriff Bug irgendwie darum kommt, dass man in so einer Maschine irgendwann mal ein Cava gefunden hat, na, Backhanding, quite verbatimli, wie auch immer. Dieses hier ist, man sieht es vielleicht, da oben steht ein wo kleinen IBM, ein System 360, das ist ein Mainframe. Mainframes sind voll toll, da kann man einen ganzen Computer pro Unternehmen verkaufen, ihr wisst gar nicht, wie viele Unternehmens auf der Welt gibt, da kann man keine Ahnung, tausend Rechner im Jahr verkaufen, ist das nicht mindblowing, das ist ein richtiger Markt und in den 60ern hatte IBM, das den Markt doch bestens vollständig und die haben damit damals schon Milliarden Dollar gerechnet gemacht, weil sie jedem Unternehmen ein oder manchmal haben sie sogar schafft zwei Mainframes pro Unternehmen zu verkaufen, richtig krass. Aber dann wurden die Rechner weiter miniaturisiert, das hier ist ein Minicomputer oder eigentlich das CPU-Bord aus einem Minicomputer, weil der Unterschied zwischen Mainframe und Minicomputer ist, dass ein Mainframe den gesamten Raum füllt und Minicomputer nur ein Rack. Das ist eine PDP-11 oder das Comput-Bord daraus und das ist dann die nächste Minitorisierungstufe, bis wir irgendwann zu diesem Gerät herkommen, dem allseits bekannten Ur-Ober von diesem Laptop, einem Intel Z8080. Also ein, sorry, ein Intel 8080, Z80 ist das, was passiert, wenn Intel nicht schnell genug Neu features drauf wird und andere Firmen deswegen teure Prozessoren verkaufen können, die viel mehr können. Warum habe ich jetzt gerade diese drei Prozessoren ausgewählt und nicht irgendwie den ersten richtigen Integrated Processor, den Intel 4004? Das ist ganz einfach. Alle diese drei Rechner kommen mehr oder weniger direkt noch heute vor. Auch Intel 8080 kommen immer noch irgendwo als Mikrocontroller in irgendwelchen Industrieanlagen vor. Also euer ICE hat ziemlich sicher einige davon verbaut. Die PDP-11 habe ich festgestellt, hat von der Digital Equipment Corporation oder deren Rechtsrechtsrechtsnachfolger Teilsupport bis 2050. Warum? Die steuert ab Tunkhoff weg in den USA. Und Mainframes, die sind über Jahre und Jahre und Jahre und Jahre weitergerechnet worden. Und das, was man heute als Open Power kennt, ist so der super hippe, schnelle, agile, ur, ur, ur Enkel von so einem Mainframe. Wie weit man gekommen ist. Aber damit überlegen wir uns jetzt erst mal noch, wie definitiv eigentlich Performance, weil wir wollen ja schnell werden und dann mal feststellen, ob das gar nicht so gut ist, wie wir das gemacht haben. Zuerst einmal, was ist eigentlich ein Benchmark? Herzlich willkommen bei MacFee. Ja, ich habe es leider nicht probiert, aber das ist noch so mein Ziel genug Leute zu finden, dass sich eine MacFee-Whiskey-Bestellung lohnt. Der geheime Hintergrund dieses Talks. Genau, ne, wir teilen Benchmarks jetzt irgendwie mal richtig auf. Wir haben erst mal so ein paar Zahlen, die man vergleichen kann. Da ist ganz toll. Welche CPU tagtet wie schnell? Super, höhere Nummer besser. Wir kommen da gleich noch mal zu, was passiert, wenn man das zu Ende denkt. Wir haben da auch noch die schöne Abkürzung MIPS, Million Instructions per Second, weil je mehr Instruktion wir rechnen, desto schnell das wäre, voll offensichtlich. Und wir haben das gleich auch noch für Floating Point, das nennt sich dann Floating Point Operations per Second, oder Flops. Ganz schön auf Flop, diese Sache. Und es gibt noch die Abkürzung IPC Instructions per Clock, weil offensichtlich, wenn ich potakt mehr mache, bin ich ja schneller. Well, ne, jetzt haben wir da die erste Kategorie. Warum die ersten Kategorien aufgeteilt sind, kommen wir gleich zu. Naja, diese Kategorie zwei sind, wir gucken uns keinen nackten Daten an, die unser Prozessorhersteller veröffentlicht, sondern wir testen das tatsächlich, testen gut, weil dann haben wir belastbare Zahlen. Machen wir zum Beispiel Tattic Benchmarks wie diesen hier, falls das hier mal jemand gesehen hat. Das ist jetzt kein CPU, sondern GPU Benchmark, aber hey, cool, bunte Bilder, ne? Man möchte bunte Bilder in seinem Talk haben. Ja, es gibt noch das zweite, ein Kernel, das hat nichts mit Linux zu tun, sondern es ist ein kleiner Programmteil, so eine Matrix-Bondifikation. Und da gibt es Toy Programs. Ich fand die Unterscheidungen im Buch, wo ich das hergeklaut habe, sehr schön. Der Unterschied zwischen einem Kernel und einem Toy Program ist, dass ein Kernel tatsächlich Teil, ein sehr kleiner Teil, aber ein Teil einer echten Anwendung ist. Ein Toy Program würde niemand schreiben. Das Beispiel, was die Autoren nutzen, ist Bubblesort. Juhu! Habt ihr schon mal einen produktiven Bubblesort eingesetzt? Den egal, was ihr tut, schlechteren Sortieralgorithmus. Genau und Kategorie 3 sind dann irgendwelche Benchmark-Suits. So der ganz bekannte Name ist dafür Spec. Das steht für Special Interest Group für irgendwas. Genau und die Kategorien lassen nicht aufteilen in Really Bad, Less Bad und okayisch. Hat schon mal jemand von der Bibliothek LibQuantum gehört? Ja, das ist, wenn man einen Compiler über Jahre so optimiert, dass er diesen einen Benchmark komplett von vorne bis hinten durch Konstanten falten kann, weshalb Intel Prozessoren irgendwie 50 Mal schneller sind, wenn man sie mit diesem Compiler übersetzt als alle anderen, weil alle anderen rechnen tatsächlich und bei Intel braucht er eine Compilvorgang-Drehtage. Genau, also auch irgendwie schwierig. Genau, aber deswegen Really Bad sind natürlich diese Zahlen, weil oh Wunder, zwei verschiedene CPUs, die zwei verschiedene Instruktionssätze haben, da kann man schlecht vergleichen und der eine Prozess ist ein schneller Takt, aber der andere hat mehr IPC. Schwierig, kommen wir noch zu. Auf die Art und Weise hat AMD das erste Mal gegen Intel gewonnen. Ja und offensichtlich Less Bad, ein Programm, das nur falls Benchmark geschrieben wird, da gucken sich Leute an, hey, guck mal, da ist ein Benchmark und Optimieren da drauf. Unygen Heaven ist nicht umsonst ausgewählt. Das war großer Skandal mit Tessellation irgendwann so 2011 rum, weil Nvidia in ganz viel Wert auf Tessellation gelegt hat, nur um hinreichend schnell gegen AMD zu gewinnen, die das nicht so gut konnten, obwohl das nirgendwo sonst genutzt wurde. Genau, erste Überlegung, wie werden wir schnell? Genau, wir überschauen uns jetzt mal an, wie so ein Transistor funktioniert. Genau, wir haben so ein Transistor, der besteht irgendwie aus zwei Teilen, also ein CMOS Transistor, weil, wenn ihr euch für Digitaltechnik interessiert, gehört eine Vorlesung dazu, ich möchte das nicht hier nochmal, ich brauche das nicht hier noch mal zu copypasten, aber ganz grob, wir haben einen Anfang, ein Ende und dazwischen haben wir eine Nichtleitende, das teilen Silizium, aber eine Kondensatorplatte darunter und offensichtlich, Ladungen ziehen sich an oder stoßen sich gegenseitig ab, das bedeutet je nachdem, wie ich Kondensator lade, kann ich in diese Silizien darüber Ladungen reinschieben oder nicht. Und wenn da aber Ladungen irgendwie drin sind, dann kann ich eine leitende Brücke bauen dazwischen und damit habe ich einen Leiter gebaut, den ich an und ausschalten kann, deswegen heißt Silizium auch ein Halbleiter, weil ich kann den leitend oder unleitend machen je nachdem ich gescheibe. Für alle anwesend Elektrotechnik-Poffs, ich entschuldige mich sehr für diese Erklärung. Genau, und jetzt kommen wir auf der zweiten wichtigen Erklärung, die diesen ganzen Forderung überhaupt erst sinnvoll macht, nämlich Moos Law. Wir haben unsere Transistor an und es gab dann die Beobachtung, die irgendwie als Law übersetzt hat, weil warum nicht. Wenn wir ein bisschen warten, wenn unsere Transistor ein kleiner und kleiner und kleiner kleiner und kleiner und wenn wir die kleiner und kleiner und kleiner machen, dann werden unsere Kondensatorplatten kleiner, das bedeutet, wir müssen weniger Ladung nutzen, das bedeutet, es fließt weniger Strom. Transistor, das bedeutet, wir können mit gleich viel Strom mehr Transistor schalten und wir können aus anderen Gründen dabei noch höher takten. Richtig nice. Genau, und wir haben aus dem unseren Transistor noch Platz für Zeug, was dumm herum ist. Also, offensichtlich könnten wir einfach eine zweiten Korder neben kleben, aber aus Gründen darf ich jetzt hier nicht besonders stark eingehen möchte, außer dass das extrem painful ist, möchte mal eigentlich gucken, erst mal einen Kern schnell zu machen, als mehrere Kerne zu benutzen. Genau. Und jetzt stellen wir fest, schneller takten funktioniert gut und dass dieses Bild so gruselig abgestillt ist, liegt nicht daran, dass ich keinen Gip bedienen kann und ausschließlich, dass das gutes Vorschadowing hier auf dem Rest des Abschnitts ist. Bestimmt. Hust, hust. Also, ihr seht hier auf der linken Seite der logerinische Skala und Takte gehen linear hoch, logarithmisch. Also, voll toll pro zehn Jahre irgendwie fast zehn, eine Verzehnfachung des Taktes, voll toll, bis zum Jahr 2004. Ja, genau. And then it didn't. Herzlich willkommen bei Intel, weil, wie gesagt, warum ist immer die richtige Frage. Intel war so, wenn wir mehr Takt haben, dann haben wir mehr Takt und dann können wir mehr Dinge tun und dann sind wir schneller. Juhu. Was braucht man für mehr Takt? Irgendwann sind unsere verschiedenen Teile von den CPUs zu weit auseinander und dann packen wir dazwischen Pipeline-Stages und schieben uns ein Teil nach und nach durch die CPU. Ihr seht hier dieses schöne Bild und ich mache jetzt eine kurze Übersetzung aus Pixelmills von Anantec für GPU-Besucherwesen. Genau, weil das oben darüber, wie man vielleicht erkennen kann, ist eine 10-Stage Pipeline aus dem Vorgänger. Darunter war dann eine 20-Stage Pipeline aus der ersten Pension 4 Generation. Die Nachfolge Generation hatte dann über 31. Intel war da nicht so genau, wie viel es tatsächlich ist, sondern mindestens 31. Genau. Und wir haben da ganz viele Pipeline-Stages und dann haben wir sowas Tolles, wie Drive-Cycles. Ein Drive-Cycle ist eine Pipeline-Stage, nichts anderes tut, als das Signal zu nehmen und zu verstärken, dass ich es danach noch habe. Und ihr merkt, dass euer Prozess auch an Takt-Limits knackt, wenn ihr anfängt für eure Operationsverstärker, die nur dafür lassen, dass ihr euer Signal auch versteht, ganze Takt-Cycle einzubringen. Herzlich willkommen bei Intel. Genau. Und Intel war da ganz, ganz, ganz toll. Sie haben nämlich als Sie das Ding vorgestellt haben, so 2002 gesagt. Genau, 2002 haben Sie gesagt. Bis 2005 kriegen wir 10 Gigahertz. 10 Gigahertz. Jetzt habe ich eine Mattaaufgabe an euch. Seid ihr da mal, dass 3,8 größer als 10 ist? Nein. Gut. Nein, 3,8 ist kleiner als 10. Genau. Also, Intel ist da volle Katte in den Limit gelaufen. Und das hat effektiv zwei Gründe. Genau. Also, ich erst... komisch. Ich war das etwa vorstellt euch gerade eben. Ja, also einmal kurz erklären, warum das Ganze irgendwie kaputt geht. Wir haben da zwei Effekte. Zum einen haben wir das Problem, dass Takt in dritter Potent, also dass der Stromverbrauch in dritter Potent oder die Energieverbrauch eigentlich, in dritter Potent vom Takt abhängt. Es liegt einfach daran, da je schneller wir takten, wir haben unsere Kondensatoren, Gintakt entladen und laden wir die. Das bedeutet, wir haben pro Takt Strom, soweit so einfach. Das Problem ist, aber wir müssen unsere Elektronen im wahrsten des Worten in den Hintern treten, damit sie das schnell genug machen. Und die Art und Weise, wie wir das machen, ist, indem wir die Spannung hoch drehen. Und Spannung mal Strom gibt Leistung und damit Wärme. Problem ist nur, dass das nicht linear ist, sondern wir brauchen für mehr Takt, quadratisch mehr Spannungen, haben wir plötzlich so etwas Tolles. Taktverdopptung ist eine Verachtfahrung vom Stromverbrauch. Jetzt betreiben wir unsere CPUs immer ganz tief in dieser Kurve. Das bedeutet, eine Kleinigkeit verhöhnen ist immer noch sehr linear, aber das gibt da basically irgendeine Kurve und knacken und dann ist eine Wand. Das ist die Taktwand, die hat Intel dann auch kennengelernt. Genau. Das zweite, was wir da hatten, ist das sogenannte Denarscaling, weil ich habe vorher erklärt, halb so großer Transistor macht halb so viel Kondensator, heißt halb so viel Strom. Das stimmt für den dynamischen Fall, ist für das Laden und Entladen. Wie kleiner unser Transistor wird, desto näher kommen die Dinge aneinander. Und das bedeutet, Elektronen haben die dumme Anbewohner zu tunneln, weil Elektronen sind genauso ortsfest wie ich und sind dann so, guck mal, ich kann rüber. Und dann fangen die an, wild durch die Gegend zu liegen, zu tunnen und plötzlich habe ich meinen Stadioschrom verbraucht, kann ich dann plötzlich nicht mehr ignorieren. Genau. Und deswegen sorgt irgendwie mehr Takt für viel mehr Strom und außerdem meinen Prozessor immer kleiner machen, leider nicht mehr dafür, dass ich einfach mehr Takt machen kann. Genau. Und das führt dann dazu, dass wir nicht selbst Rechner-CPUs haben, sondern selbst Kochner-CPUs. Ja. Genau. An dieser Stelle muss ich einmal kurz eine kleine Fangirl-Aktion einführen. Habt ihr auch euer Favorite Paper of All Time? Ich musste kurz nur brechen, weil das Mikrofon ist abgehauen und da sehr viel Andrang war, würde ich dem Streames ungen verhauen. Ja, fixe mich mal gerade kurz. Wann ist das abgehauen? Okay. So, dann gehen wir einfach mal gerade kurz zurück. Ja. Ah, sehr schön. Danke sehr. Genau, wir waren bei den selbstkochenden Schaltkreisen und jetzt, wie gesagt, Favorite Paper of All Time ist Dark Silicon useful, Elvis Operator, harnessing the Four Horsemen of the Coming Dark Silicon Colonel Cochlips. Hier Link. Also wenn ihr eins aus diesem Paper mitnehmt, aus diesem Vortag mit dem so rum, es gibt Paper, in denen jemand ernsthaft die Kapitel Überschrift genutzt hat, Deus Ex Machina Horsemen. Also ja, das Paper musste ich ja einfach rein. Genau. Hier und weil über Prozessoren Artunipfum und Vertakten so schön war, machen wir das einfach nochmal. Herzlich willkommen bei AMD Bulldozer. Genau. Also jetzt müssen wir uns überlegen, während der Intel Pentium vier Tage gab es zwei Sachen. Erstens, AMD hat tatsächlich gegen Intel basically allein dadurch gewonnen, dass sie ihre Prozessoren hat mit mehr IPC. Intel und AMD kann man wenigstens mit Instruktion vergleichen, bei 86 und das zweite, was wir halt hatten, ist, aber AMD hat es halt geschafft bei ungefähr 30 Prozent weniger Takt und wir wissen 30 Prozent weniger Takt ist irgendwie so die Hälfte vom Schrummverbrauch, weil dritte Potenz mehr zu leisten als Intel und hat ist dann sogar so weit gegangen, dass sie Prozessoren verkauft haben, an denen nicht der Takt dran stand, sondern eine virtuellen Vergleichsnummer, von denen sie nie zugegeben haben, dass es Intel Takt ist, basically. Und dann hat man einen mit 2,2 Gigahertz Artlon 3300 kaufen können, der einen Pentium 4 bei 3,5 Gigahertz geschlagen hat. Weil so schön. Und dieser Firma kommt sechs Jahre später auf die Idee, das gleiche auch noch mal zu machen. Jetzt muss man dafür ein bisschen Hintergrund kennen. AMD ist so eine dauerpläte Firma gewesen bis so vor fünf Jahren. Dann haben sie irgendwie was sehr Kluges getan. AMD hat die letzten fünf Jahre hat hat davor hauptsächlich überlegt, weil sie irgendwann mal einen kleinen Abend Grafikkarten herstellen, als IT übernommen haben und Play Stations 4 verkaufen konnten. Aber genau die Überlegung ist AMD ist dauerpläte. Aber wenn man für Web Server und andere Anwendungen braucht man nicht viel Takt und auch nicht viel Leistung, man braucht einfach viele Kerne, weil je mehr man parallel machen kann, desto besser. Also nehmen wir einen kleinen Kern, kleine Kerne takten gut, weil wege kurz und kleben davon einfach ganz, ganz, ganz viele auf unser Stück Sedition. Und wenn wir jetzt dabei sind, nehmen wir diesen ganzen wieder verzeugt, dass wir gerade für die Server entwickelt haben, nicht genug Geld, um eine zweite Architektur zu entwickeln. Aber wir haben uns einen kleinen Kerne takten gut, also wenn wir das Ding in den Desktop machen, nehmen wir auf den Takt und machen den hier. Genau. Und das heißt für Server hatten sie eine Architektur mit vielen kleinen Kernen. Das hat auch sehr gut funktioniert. Also die dazugehörige Architektur heißt Optoron und in bestimmten Server Benchmarks haben die Intel im Grund und Boden gerechnet, aber leider nicht im Desktop. Und Werbung wird im Desktop gemacht. Das bedeutet, alle Leute waren der Meinung Buddha, sei es langsam, obwohl sie für sehr viel Anwendungsfeld tatsächlich sehr sinnvoll waren. Genau, das Ergebnis war, dass die Dinger beliebig hoch getaktet sind und beliebig viel Sturmverbraucht haben. Auf der anderen Seite hält eine Bulldozer CPU. Bis heute, wenn ich mich rechtern, sind den Weltrekord für den höchsten Takt. Da hat jemand dieses Ding basically in Füßchen Stickdorf getaucht oder den Takt hoch gedreht. Aber es gibt CPUs, die mit über 8 GHz takten. Also Intel war gar nicht so weit auf. Nur leider der Konkurrent, aber naja, was wir übermachen. Genau. Die Folge ist heute. AMD war fast pleite und hat wie gesagt nur überlebt, weil sie PlayStation und Xbox verkaufen konnten. Und es gibt jetzt heute Ryzen und die erste Ryzen Generation am Vergleich zur letzten Bulldozer Generation einfach mal so eben bei 50 Prozent mehr Instruktionen pro Takt. Und ihr könnt euch vorstellen, eine 50 Prozent mehr Leistung, weil so hoch hat Bulldozer im Endeffekt auch nicht getaktet, ist halt einfach absurd. Und dann hatten außerdem die vergleichsweise 10 Kerne nochmal. Also ich hatte einen 8 Kernen Bulldozer gegen einen 8 Kernen Ryzen, der 50 Prozent mehr pro Takt leistet und außerdem noch 2 Threads pro CPU ausrechnen kann. Er war dann einfach nicht fair. Aber das ist auch der Hintergrund, weshalb AMD heute nicht mehr die Firma ist, die vor fünf Jahren dauerhaft bei zwei Euro Börsenkurs und gehen sie morgen pleite oder überleben sie bis übermorgen sind. Genau. Damit haben wir jetzt unseren Takt teilabgekommen. Jetzt machen wir uns die nächsten 20 Minuten über eine Konzept lustig. Aber das ist schön. That's a gift that keeps on giving. Genau. Wir haben festgestellt, mehr Takt ist böse. Kluge Idee. Wir machen mehr pro Takt. Genau. Und jetzt überlegen wir uns der erste coole Schritt dafür ist Pipelining. Der zweite Vorteil an Pipelins ist, außer dass wir unseren Prozess auch höher takten. Wir können natürlich in jeder Pipelinschritt einen Befehl haben. Das hat sich auch Intel gedacht, weil wenn die ihren 3,8 Gigahertz Poster da haben, dann können sie 3,8 mal 10 hoch 9 Instruktionen pro Sekunde ausführen. Voll gut. Genau. Wir gucken uns jetzt hier an, warum das nicht ganz so gut funktioniert. Es gibt ja die DLX Pipeline. Das ist entstanden aus dem Paper und den 80ern. Für euch für Kontext für die nächsten 20 Minuten. DLX steht für Deluxe. Da waren Leute sehr stolz auf diese Idee. Die zu der Verteilung der entsprechenden Autoren, die sind heute alle davon weg. Genau. Und die DLX Pipeline besteht aus 5 Stages. Fetch, also wir holen uns das Ganze. Decode, was ist denn das eigentlich? Execute, wir rechnen. Memory ist, wir lesen aus Memory und schreiben Memory. Das ist für große Teile unseres Prozesses basically warten. Und dann kommt der Endeffekt Writeback. Also wir nehmen unsere Daten und schieben sie zurück ins Registerfile. Also wir haben unsere Registerfile und da stehen unsere Daten drin. Genau. Und das ist so das, was wir basically tun. 5 Stages heißt, wir können fünf Dinge parallel machen. Wir können das Ding fünfmal so hoch takten. Also virtuell fünfmal so hoch takten, obwohl wir den CPU takt, der ja für unseren Sturmverbrauch relevant ist, gleich halten können. Also viel mehr Leistung pro takt, voll gut. Und damit kommen wir jetzt auf die Frage, warum geht es eigentlich kaputt? Deswegen, was wäre ein CPU Talk ohne Assembly? Herzlich willkommen bei meinem Zeuge Assembler. Wir nehmen eine ganz einfache Schleife. Wir gehen dahin und addieren zwei Vektoren aufeinander. Also Vektor 1 plus Vektor 2 gleich Vektor 3 komponentenweise. Und jetzt haben wir hier so ein Assembler, der lädt erst mal den ersten Wert. Er lädt den zweiten Wert. Dann addieren wir auf das erste Register, den wir gerade geladen haben, vier bei drauf, bei next integer. Dann addieren wir, dann rechnen wir den zweiten Wert aus, schreiben unseren Wert weg, addieren den dritten Pointer und sind glücklich. Und das sieht dann im Endeffekt so aus. Wir haben schön unsere Pipeline und ihr seht die einzelnen Farben. Einen der schwersten Teilen in diesem Talk war tatsächlich um farbigen Regenbogen zu finden. Genau. Aber dem aufmerksamen Beobachter innen ist vielleicht aufgefallen, dass da eine Branche Instruktion fehlt. Also dieses Vorloobgedöns. Jetzt fragen wir uns, wo ist denn die eigentlich? Die steht da nicht, dass ich daran, dass ich geschlappert habe. Die steht an vorletzter Stelle. Und jetzt überlegt ihr euch vielleicht, die letzte Instruktion ist die wichtig. Die wollen wir noch ausführen. Naja, der findige Zip EU-Ingenieur sagt euch aber. Kein Problem. Die ist eh schon gefetzt. Die schieben wir einfach unser D-Code durch und ignorieren, dass sie nie da gewesen ist. Unser Branche führt einfach die nächsten Zunach mit aus und wir sind alle glücklich. Und dann können wir unsere coole Pipeline machen, die super schnell ist und dann können wir da einfach ganz viel cooles Zeug tun. Und das nennt sich ein Branche Lateload. Ist das eine gute Idee? Well, naja, man verlässt sich darauf, dass der Compiler das richtig reordern kann. Ich meine, ich gehe noch mal hier zurück. Ich habe gesehen, ich habe das sehr ausführlich ineinander verschachtet, damit wir den Branche nach hinten hingeschrieben. Well, genau. Nein, nicht besonders gut, der Compiler fängt an, nopzzusperren. Genau. Und jetzt gehen wir noch mal zurück zu den miesen Foreshadowing, dass ich gerade mein Assembly hatte. Weil wir haben da noch so ein zweites Problem. Wir hatten dieses Writeback. Das passiert zwei Instruktionen nachdem wir Exekuted haben. Sehr am Anfang vom Taktas gehört, das geht sich gerade auf, aber trotzdem. Und wir verleisten uns wieder darauf, dass der Compiler das bestimmt optimieren kann und dieses händisch reordering, was ich in meiner Saison gemacht habe, tut und überlegen uns, kann die Compiler das? Es ist immer schön, seine Slides reusing zu können. Genau. Damit bin ich sehr viel schneller, als ich gedacht habe. Ups. Ihr habt gleich ganz viel Zeit für Q&A und ich habe gleich ganz viel Zeit aus den Nähkästen zu plaudern. Das finde ich gut. Wir müssen noch mal kurz eine zweite Sache einführen, um uns über die Deluxe Pipe noch ein bisschen mehr lustig zu machen. Wir haben hier Instruktionen, eine einfache Addition. Vier Additionen. Jetzt kommen wir erstmal dazu, warum ist einfach Instruktionen und Clockzellen doof? Wenn wir jetzt eine hypothetische ISA hätten, die einfach eine Operation hat, die vier Instruktionen auf einmal dienen kann, die kann diese Operation offensichtlich in einem Takt machen. Aber der naive Compiler tut eher das hier. Er dient die ersten zwei, er dient den dritten drauf, er dient den vierten drauf. Und dann haben wir in drei Takten diese Zahn auf 60 er dient. Schön. Ihr kennt vielleicht dieses Divine Conquer, das ist keine Compiler auch, dann passiert das hier. Wir haben immer noch drei Instruktionen, aber wir können zwei davon parallel rechnen, wenn wir denn parallel rechnen können. Und damit haben wir im zweifel zwei Takt diese Adition gemacht. Instruction Level Parallelism, also die Möglichkeit, irgendwie verschiedene Instruktionen, die nicht direkt voneinander abhängen zu rechnen, ist viel, viel, viel, viel dreiter als das. Also das geht so weit, dass euer Prozessor auf die D kommt. Warte mal, wir haben ja eine Schleifentration, aber die nächste Schleifentration hat gar nicht von meiner diesmaligen Schleifentration ab. Die nutzt zwar die gleichen Register und alles, aber das sind andere Memory Zellen und das kann ich einfach parallel machen. Voll cool. Aber ihr seht jetzt hier ein sehr einfaches Beispiel dafür, wie man Instruction Level Parallelism hinbekommen kann. So, und das wollen wir natürlich ausnutzen. Und die Firma MIPS, wer von euch weiß, wofür MIPS steht, nur so Interesse. Also, juh, sind immerhin zwei Menschen. Microarchitecture without inter, inter, inter, Gott im Himmel, interlock Pipeline Stages. Was wir machen, oder was wir nicht machen wollen, ist interlocking. Genau, wir haben unsere Five Stage Pipeline und wir möchten natürlich jetzt nicht, dass unsere verschiedenen States miteinander interagieren müssen, weil das kostet uns Hardware und das kostet uns Hardware und die Leute in Zweifel immer, wir müssen die Takten. Wir hatten es schon mal, weil mehr, ja. Und außerdem haben wir noch das Problem, dass wir im Zweifel irgendwie unsere CPU tatsächlich ganz anhalten können. Das heißt, so, halt, stop. Ich kann nicht mehr. Und was sich die MIPS Menschen überlegt haben, wenn wir das alles nicht machen, dann können wir ja viel schneller rechnen und wir haben ja unsere Compiler, wir hatten schon ein paar Mal, dass Compiler sehr gut sind oder erst recht in den 80ern waren die Compiler sehr gut. Die können das ja alles optimieren. Das ist ein Common Trow, Compiler können das schon. Wir kommen nachher bei den sonstigen, interessanten Ideen, die die Menschen so hatten noch mal da drauf. Genau, also, wir haben diese Sachen, aber jetzt überlegen wir uns mal, wir haben Memory. Wir haben unser Memory und das hängt an einem Cache. Jetzt haben wir zwei Möglichkeiten. Die Daten sind im Cache und die Daten sind nicht im Cache. Und wie ihr alle wisst, sind die Caches dafür da, dass ihr möglichst schnell takten könnt. Nein, sorry, dass ihr gewisse Daten schnell anfragen könnt und andere Daten, die im Speichersten, der taktet nicht so schnell und der ist weit weg, dann einfach entsprechend wartet. Jetzt habt ihr aber dieses Read in eurem Memory, der Grund, weshalb weit weg nach Memory ist, ist, dass man das Read dann direkt laden kann. Wenn euer Cache hinterher kommt, müsst ihr sowieso die CPU anhalten, weil da geht's schlichtig, die Daten sind nicht da, da kann man nicht rechnen. Und auch kein Compiler kann wissen, ob euer Memory-Zugriff irgendwas zwischen einem takt und literally 20.000 drüber braucht. Also, Speicherzugriffe sind beliebig langsam. Genau. Und aus diesem Grund brauchen wir Stalls sowieso. Und das zweite, was wir natürlich haben, Compiler sind schlecht und diese Einheiten, was wir jetzt natürlich machen können, wir können es einer Einheit bauen, die sich einfach merkt, dieses Register wird im nächsten Takt auf diesen Wert gesetzt. Wir können es einfach im drauf folgenden Takt stark direkt das Register-Pfeil zu fragen. Erst diese Einheit fragen und dann hat das Register-Pfeil, das sind sich eine Forwarding-Unit. Und dann können wir alle diese ganzen Sachen hier halt wegoptimieren. Richtig gut. Also, wir haben jetzt gerade diskutiert, Forwarding macht den Compiler viel einfacher. Stalls brauchen wir sowieso. Jetzt haben wir unsere tolle Architektur, die offensichtlich benannt wurde, um sich mit einem schlechten Benchmark-Namen zu schmücken. Und der Name ist nicht einmal richtig. Na, das ist schon ein bisschen bitter. Schon ein bisschen peinlich. Aber ja, und wir hatten jetzt gerade hier irgendwie noch dieses Out of Order eingeschränkt. Das ist natürlich überhaupt kein foreshadowing. Weil wir natürlich jetzt das Problem haben, dass unsere Pipeline, wir haben ja gerade diese gesamten Instruktion, die nacheinander ausgeführt werden müssen. Wenn wir jetzt aber Ding-Out-of-Order rechnen, müssen wir uns eigentlich alle diese Sachen auch wiederhalten. Weil natürlich entzweifeln wissen wir viel früher, als unsere Rechnungen fertig sind, dass wir branchen wollen. Aber um die Semantik vom Programm zu behalten, wir müssen die nächste Institution ausführen. Das ist richtig, richtig doof. Das bedeutet, diese Pipeline nicht nur, dass sie den Copilot schwerer macht und gar nicht so viel Hardware spart, sowieso andere Hardware, die uns gar nicht sparen kann. Well, sie machen es doch sogar dafür, dass wir nachher nicht mal schnelle Prozessoren bauen können. Gleich. Ich habe leider, ob ihr mitgestellt habt, ich schluss mir der Technik. Fasst das? Schwierig. Technik und so, ne? Wir sind hier auf einer Hacker-Konferenz, da kann keiner Technik. Genau. Und jetzt habe ich hier noch so ein paar andere Sachen. Das ist eine schöne Folie. Jetzt kann ich einfach mal fünf Minuten auf einer Folie erzählen. Genau. Also, wir hatten es grad schon für Nobs. Nobs sind offensichtlich doof, weil die nehmen uns einen Platz in der Pipeline weg. Aber Nobs sind noch alles anderen Gründen doof, weil wir wollen unsere Instruktion natürlich cashen, weil dem würden wir schneller, weil dann können wir höher takten, weil cashes helfen uns bei takten. Problem an der Sache ist, dass wir bei Nobs irgendwie in das Problem laufen, dass die natürlich dann auch in unserem Cash liegen. Aber eine Nob tut nichts. Das bedeutet, wir verspenden sehr wertvollen Platz in unserem Instruktion Cash für, well, nichts. Das sind das Wortes. Nob steht für No Operation. Juhu. Bei Out of Order, erstens haben wir gerade gelernt, wir müssen all diese Sachen nachbauen. Das zweite Problem, was wir daran haben mit den Nobs, ist natürlich, dass wir die dann noch irgendwie speziell behandeln müssen, weil was ich bei Out of Order ganz grob mache, ist, dass die CPU-Weiß diese Instruktion hängt von jener Instruktion ab und so ein Dependency-Tree mitführt. Und mein Nob hängt von nichts ab und hat keine Abhängigkeiten und da muss ich mich aktiv darum kümmern, diesen Nobs irgendwie zu behandeln oder ich muss, oder die müllen mir meine Cues voll, das will ich auch nicht. Also Nobs sind doof. Genau. Also generell in Nobs doof und das zweite sind Precise in exceptions. Das ist etwas, das ist sehr, sehr unoffensichtlich, was da passieren kann. Aber stellt euch vor, ihr bekommt von außen einen Deviceinterrupt rein. Und jetzt muss die CPU in das Betriebssystem springen und dann irgendwie dieses Deviceinterrupt handeln und dann zurück in den User-Space. Euer User-Space-Prozess, eure CPU-Pipeline, hat jetzt natürlich das Problem, dass wenn sie interruptet wird, läuft das Ganze, genau, wenn wir interruptet werden, müssen wir jetzt natürlich diese gesamten Dependencies wieder fixen und wir müssen uns ein Zeichen für den Befehl 1 drauf merken, welchen Wert der gesehen hat, weil wir haben ja für Register potenziell bis zu 2 Werte, nämlich einen, der in der Pipeline steckt und einen, der im Registerfall steckt und wir müssen beide Wissen mehr unterbrechen wollen. Und aus diesem Grund hat man sich überlegt, genau so wie das generelle Motto von dieser Deluxe Pipeline, naja, wir ignorieren diese Probleme einfach und das, was exceptions können zum einen von außen kommen, also Interrupts von außen, oder wir können Exception haben, zum Beispiel auf illegales Memory zugegriffen haben, was zum Beispiel rausgeswoppt wurde. Und dann geht unser Triebsystem halt hin und sagt, ja, meine Dwegen, wir swappen das wieder rein. Dafür müsst ihr aber wissen, welche Instruktion das eigentlich war und welche Instruction-Pointer und welche Register und alles. Damit wir natürlich das Programm in der richtigen Stelle mit den richtigen Werten weiterlaufen lassen können. Das nennt sich eine Precise-Exception, dass man das machen kann. Nach dem Motto der Deluxe Pipeline, wir ignorieren das einfach und sagen unsere Precise-Exception imprecise. Heißt, wir garantieren nicht, dass die richtigen Registerwerte rückkommen. Für jeden, der sich gruselt bei, wir garantieren nicht, dass die richtigen Registerwerte zurückkommen. Willkommen im Club. Genau. Schwierig. Also man kann das alles nachbauen, aber die einfachste Art und Weise, Precise-Exception zu bekommen, ist einfach die CPU zu stallen und damit sind wir wieder ganz am Anfang. Also TLDR, wir stallen so ein Ding. Ja, jetzt haben wir uns genug über Architekturen lustig gemacht, die heute keiner benutzt. Wer von euch hat schon mal was von Solaris gehört und Spark? Ah, schön. Die Spark hat sehr viel ähnliche Sachen. Also basically alle Architekturen, die in den 90ern neu entwickelt wurden oder Ende der 80er oder 90er, haben diese Idee drin, weil es war halt zu einem bestimmten Zeitpunkt, wo die Prozessoren nicht so schnell getaktet haben, aber wo fünf Pipestations schon was gebracht haben, das waren so fünf Jahre, da habe ich alle gedacht, voll die tolle Idee. Überlegen machen wir uns über eine andere Architektur lustig, eine Szene-Architektur, anders als die anderen beiden genannt, die heute auch noch relativ viel im Einsatz ist. Arm. Wer von euch kennt die Firma Acorn noch? Oh, schön. Keiner aus meiner Generation. Schade. Bitte. Genau. Also Arm ist entwickelt worden, ganz böse gesagt, um eine Fernsehsendung zu machen und für den Rest guckt euch bitte irgendwelche tollen YouTube-Videos an. Aber das Schöne an Arm ist, das ist eine Risk-Architektur mit 16 Registern. Darauf sind 13 January Purpose und dann gibt es noch Stack-Pointer, Return-Adress-Pointer und den Program-Counter oder Instruction-Pointer oder wie auch immer man das Ding benennen möchte. Das ist ein normales Register und ich kann einfach R15 adressieren. Das macht diesen schönen Code legal. Ich nehme einen Art, adiere einen Random-Zahl auf ein Random-Register und jumpe. Aber es wird noch besser, weil man hat immer festgestellt Small Instruction-Sets, also wenn ich statt 32 mit 16 Bitten zu tun nutze, dann brauche ich weniger Platz in meinem Instruction-Cache Flash-Memory für mein Mikro-Controller und weniger E-Prom und alles. Also kam irgendwann Anfang der 2000er mal diverse Mikro-Controller-Firben zu Arm und waren so, hey, könnt ihr nicht ein bisschen kleiner bauen und so ein Instruction-Satz zufügen und dann war Arm so, ja, super. Ja klar, können wir machen. Dann haben sie Arm Thumb entwickelt. Polymer waren Arm Thumb 1 war, sie haben nur 16-Bit und keine 2-Bit Instruction. Aber das bedeutet, man muss viel wenig, mehr Flexibilität haben als mit 16. Und da kann man dann mehr reinkodieren, also zu dem Zweifel schneller. Aber aus den Gründen hatte man nur eine 16-Bit und eine 2-Bit-Achtatur und ein CPU, der mir das eine oder das andere unterstützt. Dann haben sie nochmal das Ganze ein bisschen neu gemacht mit Arm Thumb wie 2 und dann konnte man ein CPU bauen, die kann beides. Jetzt muss ich der CPU her sagen, ich muss irgendwie zwischen den beiden Modi umschalten. Und zwischen den beiden Modi umschalten, das war aber auch dafür ein Bit, damit man das Instruktionssatz kann. Das ist das least significant Bit in unserem Instruction-Pointer. Wollt ihr schon mal eine Instruction haben, die eine Betriebsmodus eures Prozesses umschaltet? Genau. Ich überlege mal gerade kurz, drei wichtige Architekturen, X86 lustig gemacht, Arm lustig gemacht. Das RISC-5 ist ein bisschen schwierig, weil zum einen ist RISC-5 irgendwie so 20 Jahre jünger als der Rest. Und zum anderen ist das Problem ein RISC-5. RISC-5 für euch als Kontext, einer der Hauptentwickler dieser Deluxe-Pipeline hängt jetzt auch wieder ein RISC-5 mit drin. Und in den Beschreibungspapern zur RISC-5 steht ein sehr langer Abschnitt, warum sie keine Brown-Serieslots haben. Also Menschen können aus Federn lernen und es ist sehr schön, alles was ich bis jetzt gezeigt habe, was ich vor ihnen heute in der Meinung sind, würden wir nicht mehr so machen. Also es ist einfach schön, wenn man sich über Leute lustig machen kann, die ihre Fehler eingesehen haben. Genau. Deswegen jetzt noch zu ein bisschen Abschluss. Wo ist meine Folie hin? Okay. Willkommen bei Foliegeschrieb, aber man scheint nicht neu gebaut oder ähnlich mit Schwachsinn. Wie ihr gesehen habt, weil er glaubt nicht mir, glaubt dem, was der Mensch an links zusammengesammelt hat, weil euch indirekt bescheißen ist viel cooler, als euch direkt zu bescheißen. Genau. Wir haben jetzt noch gut 20 Minuten Zeit, wenn ich das richtig sehe. Ich erzähle euch noch ein bisschen was von meiner letzten Slide und dann habt ihr gerne noch einiges in Zeit für Fragen. Genau. Mein letztes Slide, ihr seht sie da, warum machen Menschen solche Entscheidungen? Wir haben jetzt viele technische Gründe angeschaut. Überlegungen, warum man technische Entscheidungen trifft. Ich hoffe, ich habe auch ein bisschen erklärt, warum man darauf ursprünglich gekommen ist und dann auch, warum es gescheitert ist. Aber es gibt noch ein paar andere coole Gründe, warum Leute interessante Entscheidungen nehmen. Ein ganz wichtiger Grund, warum Leute interessante Entscheidungen in CPU-Design machen, sind Patente. Weil CPU-Firmen haben natürlich auch wieder dieses tolle Ding. Also kommen dann andere Menschen hin, lesen die Patentschrift sehr genau und sehr ausführlich, damit sie sich dann haltestopp. Eine wichtige Sache, warum ihr keine MIPS-CPU bauen könnt, obwohl das ein sehr einfacher Instruktionssatz ist, ist, weil für einen ganz bestimmten Teil von euren Instruktionssätzen, nämlich für bestimmte Load-Operationen und Store-Operationen gibt es ein ganz bestimmtes Patent für eine ganz bestimmte Art und Weise das zu handeln. Und was deswegen andere Leute machen, ist einfach Ja, ok, dann machen wir das halt nicht und wenn diese Institutionen wir sehen, dann treppen wir ins Betriebssystem und dann lassen wir das machen, weil das ist ja ein Code und wer ja alle wisst, es gibt keine Software-Patente. Software-Patente. Genau das. Der Stream kann das gar nicht sehen, das beruptet kommt nicht sehr beeindruckt von meiner Aussage. Genau, also das ist nur das erste. Da gibt es z.B. eine schöne Firma namens Transmeta so um 2.000 rum, die sind auf die tolle Idee gekommen. X86 CPUs bauen ist schwierig, weil da Verklarungen sind und AMD zusammen. Aber wenn wir eine andere CPU bauen und wir schreiben unseren Prozess einfach so, dass wir damit sehr schnell eine Software-Immolation bauen können, dann können wir richtig cooles Zeug machen und Transmeta war tatsächlich sehr cool, die haben es geschafft, zwischenzeitlich die energieeffizientesten X86-Kompatibel-Systeme zu haben, nicht CPUs, Systeme. Das Problem war, das waren Mobile-Prozessionen, die haben irgendwie so ein Drittel von dem Takt gehabt, von dem was interparallel hatte und die haben sich leider nicht durchgesetzt, weil die Überlegung mit Software-Immolation ist generell eine sehr übliche Sache und eine sehr schöne Sache. Auch Apple mit Rosetta und Rosetta 2 hatte das Problem, wenn Sie von einer Ihrer Architektur auf eine andere umbauen, eurer M1-Chip hat extra Hardware drin, damit bestimmte Load- und Store-Aparation mal wieder, wie auf X86 oder zumindest bestimmte Seiteneffekte da sind. Das hat was damit zu tun, was passiert, wenn 2 Threads gleichzeitig auf Speicher zugreifen und X86 ist da viel strenger als Arm, aber wenn man Arm schnell emulieren kann, haben die Arm-CPUs von Apple extra einen Modus in diesen X86-Modus nachzubauen, damit man gute Emulation bauen kann. Aber das ist alles wieder, das ist keine X86-CPU, das ist ja nur dieses eine Verhalten, was man den Endprozessor zufällig anschalten kann. Gut. Die zweite Sache ist, der Compiler wird schon fixen, wir hatten jetzt ein paar Mal, wie gut es funktioniert, wenn der Compiler schon fixt. Ich habe vorhin gemeint, die richtige Frage immer, warum Intel? AMD hat heute Epic mit Y auf dem Markt. Es gab ganz früher mal die Extremity Parallel Integrated Circuits Epic. Da hat Intel viel Aufwand reingesteckt, damit gut X86-Code emulieren zu können. Und sie waren da sehr stolz drauf. Das einzige Problem war, das war so Ende der 90er, sie hatten da auf einem Mikroprozessor-Forum, haben sie das vorgestellt, guck mal, wir können jetzt tolle X86-Code emulieren. Und die haben diese tolle 64-Bit-Instruktionssatz für das 200-Bit-Kündig X86 jetzt ab und alle gehen auf 64-Bit und 200-Bit kann man emulieren. Am Tag nach der Präsentation kam eine relevante Firma namens AMD auf die Idee, ihre 64-Bit-Erweite für X86 vorzustellen und zu sagen, warum Code auf einer anderen Maschine emulieren, wenn der auf unserer Maschine mit voller Geschwindigkeit rechnen könnte. Intel, die vorher sehr secretive Faden mit ihren Folien haben, wie man das so liest, basically noch in der Stunde nach dieser Präsentation ihre Folien geliegt, damit Leute wenigstens ein bisschen in ihren Vortrag reden. Ja, well, genau. Und das letzte ist, was auch ab und zu probiert, hey, das ging nach einer guten Idee. Es gibt einen Grund, warum man heute sehr viel Zeit da reinsteckt, Prozessoren, vor man sie baut, mal zu emulieren und es durchzutesten und so weiter. Damit habe ich jetzt euch hoffentlich ein bisschen ein Überblick gegeben, warum wir nicht mehr in den 80ern sind und vielen Dank für eure Aufmerksamkeit. Dann schon mal von meiner Seite aus. Vielen Dank für den Vortrag. War sehr humoristisch und spannend. Dann würde ich erst mal das Publikum geben, was wir dazu haben. Wir haben jetzt noch so 15 Minuten Zeit dafür. Sehr leere Gesichter. Dann fange ich einfach mit einer Frage an. Und zwar hast du ja sehr viel über Benchmarks geredet und dass die verwendet werden von CPU-Herstellern, um sozusagen ihre CPU besser zu machen. Wie siehst du das, sind die Benchmarks irgendwie aussagefähig für das, was man sonst so auf CPUs tut oder ist das eher so einen schönen Rechnen? Nee, das Ziel von einem Benchmark-Suite vor allem ist, dass es auch sehr viel ausagekräftig zu sein. Also, was die Spec-Menschen machen, ist, die gucken sich im Open-Source-Bereich, weil alles andere ist schwierig. Nach ganz viel Zeug um, was sehr viele Menschen nutzen, also traditionell immer dabei ist, ein GCC, der die Aufgabe bekommt, ein GCC zu compilen. Und wir suchen jetzt ganz viel Zeug, was möglichst aussagekräftig ist, möglichst viele Menschen nutzen. Und außerdem LibQuantum zum Beispiel, das ist jetzt so ein berühmtes Beispiel, dann alles, wo man sich vertan hat mit, das lässt sich nicht Workaround und hacken. Rausfliegt, wenn man neues Zeug nehmen kann, damit man immer schön vorne mit dabei spielt. Das sind Benchmark-Sweets, die auch nicht nur ein Benchmark sind, sondern mehr als einer, sehr viel schöner als einer. Aber generell hat man immer das Problem, dass man natürlich den einen Quotesten möchte. Und wenn ihr jetzt ein Laptop kaufen wollt, damit nur kompilieren, dann ist eigentlich das, was man immer machen möchte, Testet eure CPU mit eurem Workload. Das ist schwierig, wenn man die CPU noch nicht hat, deswegen hat man Benchmark-Sweets, aber deswegen war das okayisch und nicht gut. Andere Fragen, da hinten gibt es eine Frage am besten laut Sagen und dann wiederhole ich sie. Die Frage war, wie sich die CPUs weiterentwickeln, vor allem im Hinblick auf Apple, die jetzt ja eine sehr große Entscheidung getroffen haben, da etwas zu verändern. Ich zitiere jetzt einen gewissen Jim Keller, der gilt gemeiner als einer der CPU-Götter, in Anführungszeichen. ISA Don't Matter. Weil der Hintergrund ISA ist Don't Matter so rum. Weil effektiv so eine moderne CPU, ich habe Out of Order ganz kurz angesprochen, was man heute macht, ist, wir nehmen unseren ISA, übersetzen die in der CPU ISA, die der CPU besser passt und dann macht die CPU das, was sie tut. Und ob das jetzt Apple ist, Apple hat einen riesen Vorteil, die haben so dermaßen viel Geld, dass sie bei einer taiwanischen Firma TSMC immer die allerteuersten und neuesten Prozesse kaufen können. Das bedeutet, was das Denad Scaling sagt, wir kriegen nicht mehr mehr Takt, aber kleinere Prozessoren brauchen immer noch viel weniger Strom. Das bedeutet, die kaufen einfach sich teuer ein, kleine Prozessoren um zu verbauen und können dann entsprechend extrem energie- spare Laptops bauen, weil das deren andernungsfall ist. Aber generell ist die CPU-Welt heute relativ homogen. Ich habe vorhin Ryzen von AMD angesprochen. Es gibt noch eine CPU namens Optoron 1100. Das ist ein Ryzen-Kern mit dem Arm-Fronten. Da ist die gleiche CPU dahinter, aber die versteht Arm-Pestatik 86. So weit geht das schon mit den ISAs. Das heißt, das ist nicht mehr wirklich relevant. Deswegen wird meiner Meinung nach das Ganze nicht entschieden anhand von technischen Sachen, sondern von regulatorischen und Community-Geschichten. RISC-5 ist irgendwie die Zenz-Fight. Das bedeutet für alle Menschen, die komplett neuen Code schreiben müssen und neue CPUs bauen. Also Kontrollern, Festplatten, irgendwelche Mikrocontroller und so weiter. Alle die werden auf RISC-5 wechseln, weil das einfach billiger ist, wenn man nicht 20 Cent pro CPU an den Arm zahlen muss. Wenn man die Legacy-Software aus den 70er und 60er noch betreiben muss, dann kaufen die Leute weiterhin IBM-Mainframes. Weil die Software ist da und einen Atomkraftwerk neu zu lizenzieren weil von der PDP-11 auf eine moderne Maschine wechselt. Das kann sich keiner leisten. Da ist es literally billiger, die Firma PDP-Deck zu kaufen. Das ist nicht passiert. Genau. Aus dem Grund, das ist eine Community-Sache und RISC-5, Arm und X86 werden ausbetten. X86 wird nicht zeitnah sterben und ich glaube nicht, dass Arm den großen Wurf machen wird im Server-Bereich, weil die so spät dran sind, dass RISC-5, das wieder billiger ist, die noch überholen kann. Die Sache ist, dass sich Arm nicht erfolgreich früh und X86-Mark cannibalisiert hat, um da reinzukommen und die Leute, die jetzt neu anfangen, da gibt es zum Beispiel die Firma Tenztorrent, die RISC-5-Card entwickelt und baut damit Server-CPUs, weil da ist viel Geld. Das ist noch so ein bisschen das Battle. Arm ist von diesen drei großen Architekturen, RISC-5, Arm und X86, wahrscheinlich die, die am wenigsten im High-Performs-Bereich umgehen wird. Das wird nach und nach mit ein bisschen Arm-Tickets in den nächsten 2, 3 Jahren und dann auch von X86 langsam auf RISC-5 übergehen. Dann die nächste Frage. Die Frage war, wie weit noch RISC-5-CPUs für Desktop-Anwendungen weitwechselnd sozusagen? 2023 ist der Jahr auf der Linux Desktop. Es ist halt einfach wieder so ein Fall von Legacy-Software und Menschen wollen Powerpoint benutzen und nicht coole CPUs befürchte ich. Es gibt RISC-5-CPUs zu kaufen, also es gibt ein kleines Tech Tips Video, wo sie eine Sci-Fi-Risk-5-CPU koppeln und darauf dann hier Wolfenstein spielen oder hier Doom, weil geht halt und man die gleiche Firma Sci-Fi, weil mir Intel für Ende des Jahres auch weitere Prozesseur angeguckt und bei mir im Büro liegen auf dem Schreibtisch rum Borts mit RISC-5-CPU und einer Grafikkarte. Das ist auch ein Bord direkt. Das ist alles irgendwie da, aber der Markt wird wieder nicht aus technischen sondern aus anderen Sachen geschwunden und die Leute wollen Powerpoint benutzen. Ich befürchte, du wirst noch auf mindestens 10 Jahre das eher als Special Case Hardware kaufen können. Andere Fragen. Gut, dann hätte ich noch eine, du hast AI als Anwendung angesprochen, ich weiß, es ist immer so eine Sache, AI ist wichtig und was auch immer. Wie siehst du das in Hinsicht auf CPUs und Acceleratoren, wo ist da die Balance Richtung auch AI mit einer sehr speziellen Workload Art sozusagen? Lass mich meine Antwort in zwei Worten zusammenfassen. Pur Nvidia. Weil, ihr wisst es vielleicht, momentan sind Grafikkarten so der Bereich, wo man die Acceleratoren für AI Sachen nutzt. Aber im AI-Bereich du hast es gerade schon angesprochen, sind es sehr Special Case Hardware und da lohnt es sich einfach sehr schnell Special Hardware zu bauen und da gibt es von Google schon die TPUs das Schiff für Chancel Processing Unit die irgendwie fancy Zeug machen können und im gleichen Maße wird das auch halt weitergehen. Jedes Handy, was in den letzten drei Jahren verkauft wurde hat irgendwelche Beschleuniger für Interference da drin, also den Teil, wo man nicht trainiert sondern nur noch neueren als Herzwerk anwendet und da ist halt auch einfach auch das Training wird mehr und mehr Special Case und so eine Nvidia GPU ist einfach viel zu teuer und braucht viel zu viel Strom dass ich nicht glaube, dass das da weitergeht sondern das wird in die großen Hyperscaler wenn die Ryan Hardware bauen weil es sich lohnt und für alle anderen die nutzen halt die Grafikkarten die noch übrig bleiben. CPUs sind da irrelevant. Andere Fragen aus dem Plenum würde ich vielleicht noch anschließen an die Frage gerade wird es weiterhin getrennte Hardware bleiben? Also in den Hinblick auch von dem was AMD gemacht hat, die ja wirklich bewusst das Ganze in verschiedene Dice aufteilen wo ist da die Balance? Okay, das ist ein bisschen eine spannende Frage dass ich ehrlich gesagt so 100% sicher bin ich mir nicht meine Hauptgegenfrage wäre so ein bisschen was ist eigentlich meine CPU weil du hast es gerade schon angesprochen ist meine CPU nur der eine Kern ich habe jetzt hier viel über Kerne geredet und über das Ganze zwischen dem Kern und dem eigentlichen Anwendung das sind noch so dermaßen viele Schritte und da kann man das drüber sehen also irgendwelche speziellen Chips die ich direkt auf meinen gleichen mit meiner CPU zusammen auf der gleichen Partie eine Verkaufe werde garantiert kommen und das gibt es auch schon Grafikkarten und CPUs auf dem gleichen Diall also ein Stück Silizium gibt es schon dieses Paper was ich vorhin zitiert habe mit der is Dark Silicon useful redet viel darüber dass man nicht mehr so hoch takten kann und deswegen einfach ganz viel Silizium übrig hat den man besser zum kühlen braucht und um Hotspots anzukriegen da kann man auch was Sinnvolles reinmachen also ja wir werden mehr und mehr Acceleratoren auf unseren Systemen sehen einfach weil wir entweder Silizium kaufen um es nicht zu benutzen oder Silizium kaufen um es zu benutzen auf der anderen Seite ist das halt auch so eine Sache dass natürlich dann auch die Frage ist womit kann ich Geld verdienen mit einem Trainingzeug das lohnt sich für den normalen Anwender nicht in Filens haben wir schon und auch sonst Grafikk, Medienbeschleuniger also wir werden vollgewischen werden mit Beschleunigern aber wo die genau sind ob die auf dem gleichen Di sind ob die auf dem gleichen CPU sind ob die auf dem gleichen Motherboard sind oder ob sie in der Cloud sind alles ein bisschen fragwürdig das wird sich der Markt noch entscheiden der Markt also liebe FDP das ist alles gemacht mit Begleitung ich glaube bei Ihnen versucht man es auch dass man versucht die mit verschiedenen CPU-Kernen zusammen auf einen Line zu machen ich habe ein paar kleine Kerne die nicht so performant sind aber dafür Energieeffizienter und größere Kerne für wenn ich mehr Rechenleistung baue damit schiebe ich auch wieder Komplexität an Richtung Betriebssystems scheduler funktioniert das oder glaubst du es ist da zu durchsetzen oder wird es auch mit den Kernen in so einem Fall Vorleger werden dann werden die niemals so richtig weiß ich zu wissen ja also die Frage war kurz zusammengefasst wenn ich jetzt verschiedene starke CPUs auf meinen Kern mache um Energie zu sparen Energie zu sparen kann ich dann irgendwie dann verschiebe ich auch wieder Komplexität an nicht die CPU verschieben ist schwierig sag mal erstens, gerade im Smartphone-Bereich ist das schon hartwegs üblich aber da ist es auch nicht so dass man keine Benchmarks geben möchte da ist der Benchmark die Akkulaufzeit dann ist man 0,5% langsamer im Desktop-Bereich wo Leute ganz hässliche Videospiele Benchmarks machen die absoluter Tänzkritisch sind ist das ein bisschen schwieriger und als Innenlauf zutunzeitig mies auf die Füße gefallen und hat im Desktop solche schönen Sachen wie also wenn du ansatzweise der Meinung bist dass das irgendwie ein Spiel sein könnte dann reagier bitte frühzeitig und ohne da sieht man das auch in den Benchmarks wie kaputt das gehen kann, wenn das verschieden ist in allen Fällen ist da mittlerweile viel Hardware Unterstützung dabei also Performance-Count oder ähnliches wo die CPU einem sagt, hey, ich habe das und das gemessen und wahrscheinlich ist es besser, das auf den anderen kennenzulassen und hier zu lassen also da ist viel Hardware-Softverkode sein im Spiel um genau dieses Problem zu machen aber ja Komplexität in Software ist immer schwierig und das braucht immer ein paar Jahre und es wird ziemlich weit und ich gehe davon aus dass es auch im Desktop-Bereich kommen wird vor allem bei Batterielaufzeit und Energiesparen so dermaßen wichtig ist dass man dafür auch einfach 3, 4, 5% Performance auch mal gibt weil das Betriebssystem langsam ist weil wenn der Laptop doppelt so lange ohne Batterie klarkommt da ist halt einfach 3% weniger Performance nicht relevant Gut, noch andere Fragen aus dem Plenum eine Frage hätten wir glaube ich noch Zeit wenn es nicht erfahrt ist mir fällt jetzt aktuell auch akut nichts mehr ein dann vielen Dank für den Vortrag und auch für die Möglichkeit so viele Fragen zu stellen und dann würde ich sagen noch ein Abschlussverbrauchs für dich