News AMD Epyc im SP 7: Nach GPUs streben wohl auch CPUs die Kilowatt-Marke an

[ETI1120]

Das Interessante ist, dass AMD offenbar auch nicht an die thermal power wall geglaubt hat (mit dem von Mitch Alsup beschriebenen K9-Projekt). Hatten die nur FOMO, oder haben beide Firmen an eine Kuehltechnologie geglaubt, die das wegkuehlt.

Robert P. Colwell schreibt, dass es das Erfolgsrezept von Intel war die Frequenz immer höher zu schrauben. Vom Erfolgsrezept verabschiedet man sich meist sehr ungern und deshalb passiert es sehr erfolgreichen Unternehmen immer wieder, dass sie zu spät bemerken, dass sie ein totes Pferd reiten.

Bei AMD war es nach dem GHz Athlon ähnlich, aber um mir eine Meinung zu bilden würde ich gerne mehr lesen.

Intel hatte als Robert P Colwell die Microprozessor Group verlassen hat, AFAIU 3 Design Teams*):

• Oregon, X86 Netburst
• Kalifornien, Itanium
• Israel, letztendlich mit Core erfolgreich

Wie viele Teams AMD hatte weiß ich nicht. Aber Intel konnte letztendlich 2 Fehlschläge locker verkraften weil das 3. Team einen Volltreffer gelandet hat. Bei AMD kam der K10, der jedoch durch den TLB-Bug schwer gehandicapt war.

*) Xscale außen vor gelassen

Ein Problem von Netburst war, dass sie viel mit Replays gemacht haben, das aber nicht in der Simulation erfasst haben (haben wohl gedacht, dass die selten genug sind, sodass sie keine Rolle spielen), und die Replays dann weitere Replays ausgelöst haben, und das den IPC stark beeinträchtigt hat.

Robert P Colwell schreibt den Erfolg des P6 vor allem ihrem selbstgeschrieben Simulator DFA zu. Damit konnte das P6 Team viele Designentscheidungen durchspielen und sich für das erfolgsversprechendste Design entscheiden.

Im Interview sagt er, dass DFA für Williamette nicht mehr der richtige Simulator war und dass der Simulator nun von einem professionellen Softwareentwickler betreut wurde. Das brachte wohl Probleme mit sich.

Robert P. Colwell ist ein Verfechter der Data Driven Culture. Er ist da in der Tradition von Grace Hopper “One accurate measurement is worth a thousand expert opinions.”

 

[Skysnake]

Der Aussage würde ich absolut zustimmen. Selbst Experten verschätzen sich bei gewissen Fragestellungen konstant einfach weil die Realität eben nicht immer zur Erwartungshaltung passt.

 

[ETI1120]

Allerdings muss man auch verstehen was man tatsächlich misst. Robert P. Colwell ist bei der Debatte RISC vs CISC aufgrund der Daten auf der CISC Seite gelandet.

Er hat festgestellt, dass viele Argumente der RISC Fraktion nicht stichhaltig waren.

Es war also kein Zufall dass er nach einem Ausflug in eine letztendlich gescheiterte VLWI Architektur bei Intel gelandet ist und dort maßgeblich mit am P6 gearbeitet hat.

 

[mae]

Bei AMD kam der K10, der jedoch durch den TLB-Bug schwer gehandicapt war.

Bei AMD kam nach K8 (die ersten Opteron und Athlon 64 Generationen) mindestens ein K9 Projekt. Die Beschreibungen von K9 von Mitch Alsup passen nicht zu denen, die ich sonstwo gelesen habe, also waren es vielleicht zwei Projekte, oder eine der Quellen liegt falsch. Jedenfalls wurde K9 offensichtlich nicht zum Produkt.

Stattdessen kam K10, der, wie Andy Glew schrieb, ein aufgewaermter K8 ist. Und laut meinen Messungen ist das tatsaechlich so: Bei Programmen, die kaum ausserhalb der L1-Caches zugreifen, hat K10 praktisch dieselben IPC.

Und K10 hatte anfangs keinen Taktfortschritt im Vergleich zu K8, im Gegenteil. Erst mit dem Phenom II ging dann beim Takt etwas weiter (aber da hatte ich schon einen Wolfdale gekauft).

 

[ETI1120]

Bei AMD kam nach K8 (die ersten Opteron und Athlon 64 Generationen) mindestens ein K9 Projekt. Die Beschreibungen von K9 von Mitch Alsup passen nicht zu denen, die ich sonstwo gelesen habe, also waren es vielleicht zwei Projekte, oder eine der Quellen liegt falsch. Jedenfalls wurde K9 offensichtlich nicht zum Produkt.

K9 war ein Projekt das vor dem Tapeout abgebrochen wurde, so wie es Mitch Alsup darstellt hat. aber AFAIU hat AMD damals die Spuren verwischt, so dass einiges an Verwirrung entstanden ist was K9 den eigentlich war. Erst später ist AMD offener geworden.

Stattdessen kam K10, der, wie Andy Glew schrieb, ein aufgewaermter K8 ist. Und laut meinen Messungen ist das tatsaechlich so: Bei Programmen, die kaum ausserhalb der L1-Caches zugreifen, hat K10 praktisch dieselben IPC.

Und K10 hatte anfangs keinen Taktfortschritt im Vergleich zu K8, im Gegenteil. Erst mit dem Phenom II ging dann beim Takt etwas weiter (aber da hatte ich schon einen Wolfdale gekauft).

Das hatte ich so nicht auf dem Schirm, erklärt aber sehr gut warum AMD in dieser Zeit an Boden verloren hat. Und dann gab es ja noch den Bug, ...

Ich habe gar nicht gewusst wie nah ich den Antworten war

https://x.com/philparkbot/status/1478813774899339264

Auch AMD wusste dass es mit den Frequenzsteigerungen nicht weitergeht, deshalb hat AMD einen 2 Kern K8 gemacht. AFAIU wurde die 2 Core Variante von K8 auch als K9 bezeichnet, ...

Das ist ein Zitat aus https://ieeexplore.ieee.org/document/9623437 (Hinter Bezahlschranke),

So wie ich den Ausschnitt verstehe, hat es AMD nach dem K8 noch Mal an einem High Frequence design versucht, sind aber am Prozess gescheitert.

@mae Ein Zufallsfund
https://pdfs.semanticscholar.org/6a82/1a3329a60def23235c75b152055c36d40437.pdf

Muss zwischen May 1999 und October 2000 sein, denn in dieser zeit war Fred Pollack Director of Intel's Microprocessor Research Laboratories

auf den ich indirekt über einen Artikel von Phil Park gestolpert bin, denn dort waren zwei Antworten von Robert P. Colwell referenziert. Als ich die weiteren Anworten durchgegangen bin, bin ich auf diesen Foliensatz gestoßen.

Könnte Dich interessieren:
https://www.quora.com/profile/Bob-Colwell-1

 

[mae]

Anhang anzeigen 1659582
Das ist ein Zitat aus https://ieeexplore.ieee.org/document/9623437 (Hinter Bezahlschranke),

Ja, "aggressively pipelined" entspricht dem, was Mitch Alsup beschreibt.

https://pdfs.semanticscholar.org/6a82/1a3329a60def23235c75b152055c36d40437.pdf

Muss zwischen May 1999 und October 2000 sein, denn in dieser zeit war Fred Pollack Director of Intel's Microprocessor Research Laboratories

Micro-32 war am 16.-18.11.1999. Interessant, dass Pollack schon da ueber load-to-store-forwarding ueber renaming sprach, was ich erst bei Zen3 und Tiger Lake (vermutlich auch Ice Lake) gemessen habe, also 20 Jahre spaeter.

 

[ETI1120]

Pat Gelsinger hat bei der ISSCC 2001 eine Variante der Folie von Fred Pollack aufgelegt. Und in seinem Vortrag ebenfalls klar gemacht, dass das GHz Rennen zu Ende geht.

Micro-32 war am 16.-18.11.1999. Interessant, dass Pollack schon da ueber load-to-store-forwarding ueber renaming sprach, was ich erst bei Zen3 und Tiger Lake (vermutlich auch Ice Lake) gemessen habe, also 20 Jahre spaeter.

Manchmal braucht es eben einiges an Zeit, bis ein Konzept umgesetzt werden kann.

Ich finde keine biographische Daten zu Fred Pollack (Er war am Anfang des P6 Projekts der Boss von Robert P. Colwell, erst ist auch auf mindestens einem Patent zu P6 auf dem auc). Fred Pollack hat Intel 2001 verlassen.

Fred Pollack hatte bei Intel eine sehr interessante Laufbahn. iAPX432, i960 und P6. iAPX432 war ja das Paradebeispiel der RISC-Jünger warum CISC zum Untergang verurteilt sei. In seinem Interview mit dem CHM erzählt Robert P. Colwell einiges über iAPX32. er hat seine Doktorarbeit über iAPX432 gemacht.

Eine ganz witzige Passage aus dem Interview von Robert P. Colwell mit dem CHM:

0:30:44 BC: Gordon Bell came to Carnegie Mellon and he gave a talk about his personal
conversion to RISC, because he had switched camps at that point. Prior that he designed the
VAX which is a canonical CISC. In that talk, he told the audience, "of course the 432's a
piece of junk: it's got seven levels of indirection in the addressing path”. I was thinking well,
yeah it does, but in terms of what's wrong with it, that's not even in the top 10 list.
Afterwards I went up to him after the Q&A session was over, and I said "Gordon, you blamed
the seven layers of addressing for something and" I said you know, "I've measured this
machine extensively and they've got a cache that shorts out all seven layers almost all the
time. It makes no difference, you could make it 20 layers and it won't make any difference"
and he said, "no, no, no anyone can see just by looking at it", I said "you can’t tell anything
just by looking at it, that’s the point of the RISC research, you have to measure it, and I've
measured it and my conclusion is not the same as yours." He said "hey the audience got the
point that's all that matters" and I thought wait a second, you can't tell a lie to an audience
and walk away from it. He clearly did not view things the way I did so that was disturbing.
There were a lot of people who drew lessons about the 432s who were just crazy. Their
lessons weren't based on anything but casual observations, on the level of a block diagram
and, yeah there were things wrong but you couldn’t see them from there. I pointed out that if
you're going to design a competitive machine and you're not going to have registers, which
the 432 did not, you'd better have ready access to certain things like constants, you're going
to need 0, you're going to need 1, you're going to need 4 (because you're going to be scaling
pointers so you need to multiply by 4). Well the 432 guys gave you 0 and 1, no 4. So if you
needed any other constant but 0 and 1 you had to open the constants object. Opening a
constants object required the operating system to get involved, and that's why every
procedure call was so nightmarishly slow.

 

[Skysnake]

Interessantes Zitat und wenn so tatsächlich passiert dann ein ziemlicher Fail von Bell.

Btw ne ein Punkt den ich den Leuten auch immer predige bei Code Optimierungen. Messt euren Code und optimiert dann das was viel Zeit kostet und nicht das bei dem ihr denkt das es ein Problem gibt

Roofline Model finde ich zum Beispiel extrem nützlich hierfür.

 

[LencoX2]

Naja, Heute sind wir bei 500-1000 Watt für den High End PC

High End PC geht sparsam wenn man die effizientesten Teile nimmt: Habe hier 7800X3D mit 9070, 32Gb 2TB M.2
Der zieht 150-400W je nach Game und Settings

 

[mae]

Fred Pollack hatte bei Intel eine sehr interessante Laufbahn. iAPX432, i960 und P6. iAPX432 war ja das Paradebeispiel der RISC-Jünger warum CISC zum Untergang verurteilt sei.

Das Paradebeispiel war die VAX, aus mehreren Gruenden:

1) DEC hatte Patterson engagiert, um ihnen beim Microcode fuer die VAX zu helfen. In diesem Projekt kam Patterson zu dem Schluss, dass der komplizierte Befehlssatz der VAX das groesste Problem ist, und begann dann mit dem Forschungsprojekt, das zum Berkeley RISC fuehrte. Patterson kannte sich daher auch gut mit der VAX aus und konnte Beispiele geben.

2) Die VAX war schon da und bekannt, als die Berkeley RISC und Stanford MIPS gestartet sind, waehrend iAPX432 erst in diesem Jahr herauskam.

3) Die VAX war erfolgreich, waehrend iAPX432 zwar ambitioniert, aber kommerziell ein Rohrkrepierer war. Wenn man zeigen kann, dass RISC mehrmals so schnell ist wie eine VAX, und dabei viel weniger Entwicklungskosten hat, dann ueberzeugt das. Wenn man das gegenueber iAPX432 zeigt, zuckt jeder nur mit den Schultern.

Die Sache mit dem i960 ist eine Tragoedie. Da hat Intel einen RISC entwickelt, ungefaehr zeitgleich mit dem 386, hat dem aber einen Rucksack mit Ideen vom iAPX432 draufgepackt, weil das ein besonders sicherer Prozessor fuer Nuklearreaktoren und so sein sollte. Dann stieg Siemens aus dem Projekt aus, der PC wurde zum Erfolg (und damit der 386 zum wichtigeren Projekt), und das i960-Projekt hatte keinen Markt mehr. Wenn die den i960 mit einer einfachen MMU gebaut haetten, waeren sie wohl zur gleichen Zeit wie der 386 fertig geworden, oder sogar noch frueher, und waeren damit der erste kommerzielle RISC auf dem Markt gewesen. Damit haetten sie den Workstation-Markt uebernehmen koennen. So hatten sie Verzoegerungen, wohl einerseits durch den Aufwand, die iAPX432-Ideen einzubauen, andererseits durch den Wegfall des Zielmarkts und darauffolgenden Aenderungen der Anforderungen, und so kam der i960 erst 1988 heraus, als MIPS und SPARC schon etabliert waren, und sie kamen ohne MMU heraus (also nicht fuer Workstations geeignet, war aber zu dem Zeitpunkt ohnehin zu spaet).

Bei IBM gab's das Muster, dass bei ambitionierte Projekte (z.B. Stretch) niemand ein Nachfolgeding machen wollten, weil ihnen dann die Kosten des Projekts angerechnet wuerden; stattdessen haben sie die Projekte eingestellt, und dann konnte sich der ganze Konzern kostenfrei daran bedienen (z.B. hat S/360 einiges von Stretch uebernommen). Beim iAPX432 und i960 ist wohl irgendwie dasselbe passiert, aber zum Nachteil des i960.

 

[stefan92x]

High End PC geht sparsam wenn man die effizientesten Teile nimmt: Habe hier 7800X3D mit 9070, 32Gb 2TB M.2
Der zieht 150-400W je nach Game und Settings

Der 7800X3D ist noch oben dabei, aber nicht mehr absolute Spitze (das wäre der 9800X3D, der mehr verbraucht) und auch die 9070 ist eher gehobene Mittelklasse, High End wäre 4090/5090. So ein Rechner kommt dann im Gaming leicht mal über 500 Watt.

@mae @ETI1120 super spannende historische Diskussion die ihr hier führt, ist fast schon verschwendet in diesem News-Thread. Wäre doch mal ein schönes Thema für einen Leserartikel, so ein historischer Deep Dive?

 

[ETI1120]

Interessantes Zitat und wenn so tatsächlich passiert dann ein ziemlicher Fail von Bell.

Er hat dies 2009 geschildert, also ca. 2 Jahrzehnte danach.

Es ging Robert P. Colwell nicht darum Gordon Bell ans Bein zu pinkeln. Er hat IMO diese Annektode als Beispiel dafür gebracht, dass sehr viele Argumente der RISC-Befürworter eben nicht durch ihre Daten abgedeckt waren.

Btw ne ein Punkt den ich den Leuten auch immer predige bei Code Optimierungen. Messt euren Code und optimiert dann das was viel Zeit kostet und nicht das bei dem ihr denkt das es ein Problem gibt

Dafür gibt es die schöne Bezeichnung: "premature optimizations"

Du kennst das 0. Gesetz von Gerald M. Weinberg?*)

Ich finde "premature optimizations" ist eng verwandt mit "Gold Platening", beiden liegen ungeprüfte Annahmen zugrunde.

Ich bin kein Programmierer und auch kein Hardwareexperte, habe aber früher einiges mit erfolgreichen und mit weniger erfolgreichen Softwareprojekten zu tun gehabt. Als Folge hatte vor 20 Jahren Mal beabsichtigt Requirement Engineering zu machen, aber dafür gab es keine Rolle in der Firma. Als Folge dann habe ich mich wieder aus der Softwaregeschichte herausgelöst und bin in mein angestammtes Tätigkeitsfeld zurück.

*) Ich halte es für sehr bezeichnend dass, nur sehr wenige Bücher von Gerald M. Weinberg ins Deutsche übersetzt wurden. Der erste Band von Software Quality Management ist eine dieser Ausnahmen. Er war in der Auslage für Neuanschaffungen in meiner damaligen Lieblings-Bibliothek. Als ich ausstudiert hatte, war es schon aus dem Programm genommen und nur noch gebraucht zu bekommen. Software Quality Management ist für mich immer wieder ein Denkanstoß. Geralds M. Weinberg Marotte war es Gesetzte zu definieren.

Das Paradebeispiel war die VAX, aus mehreren Gruenden:

Das mag sein.

Robert P. Colwell hat sich die iAPX432 aus guten Gründen als Studienobjekt ausgesucht. 20 Mal langsamer zu sein ist eben schon eine Hausnummer. Und das wurde eben nur allzu gerne CISC in die Schuhe geschoben.

https://www.sigmicro.org/media/oralhistories/colwell.pdf Seite 47

Performance Effects of Architectural Complexity in the Intel 432
ROBERT P. COLWELL
Multiflow Computer, Inc.
EDWARD F. GEHRINGER
North Carolina State University
and
E. DOUGLAS JENSEN
Kendall Square Research Corp.
ACM Transactions on Computer Systems, Vol. 6, No. 3, August 1988.

3) Die VAX war erfolgreich,

Die VAX und ihre Nachfolger wurden vom PC gekillt. Und viele der Ingenieure, die an den RISC Chips von DEC gearbeitet haben, arbeiteten anschließend an CISC Projekten.

Einer von ihnen, Jim Keller, hat in vielen Interviews erklärt, dass die ISA nicht entscheidend ist.
Robert P. Colwell und seine Kollegen waren Mitte der 80iger nicht sehr populär, weil sie folgendes in mehreren Papers dargelegt haben.

• Viele Kernargumente der RISC-befürworten waren entweder nicht stichhaltig waren oder waren falsch.
• Viele Technologien die als RISC propagiert wurden, waren nämlich gar nicht an das Konzept Reduced Instruction Set Architecture gebunden, sondern konnten auch auf CISC angewendet werden.

Mit dieser Überzeugung hat Robert P. Colwell 1990 bei Intel angefangen

Es hat zwar mehr Aufwand bedeutet, aber eben nicht entscheidend mehr Aufwand. Vor allem dann nicht, wenn Intel das zigfache an Prozessoren verkaufen konnte und den besten Prozess hatte.

Aber wenn die Behauptungen wie viel besser RISC als CISC sei, gestimmt hätten, hätte CISC niemals RISC aus den Datacentern verdrängen können.

Es war auch ein Treppenwitz der Geschichte, dass HP die HP Precision Architecture für Itanium in die Tonne getreten hat.

Grotesker ist nur die Geschichte, die Robert P Colwell auf Seite 86 beschreibt, über den Ursprung der Performance Projektionen für Itanium.

Wenn man zeigen kann, dass RISC mehrmals so schnell ist wie eine VAX, und dabei viel weniger Entwicklungskosten hat, dann ueberzeugt das.

Und genau das "wenn man zeigen kann" haben Robert P. Colwell und seine Kollegen von der Carnegie Mellon University massiv in Frage gestellt. Robert P Colwell sagt dass die Befürwortern von RISC A behauptet haben, aber nur A' beweisen konnten. Seite 47

Daraus resultierte seine Dissertation.

Ein follow up Artikel, als er schon bei Multi Flow war.

Peering Through the RISC/CISC An Outline of Research Fog"
Robert P. Colweil , Charles Y. Hitchcock and E. Douglas Jensen
Hi,
Electrical Engineering Department
Computer Science Department
Carnegie-Mellon University
Pittsburgh , PA 15213
Abstract

Instruction Sets and Beyond: Compters, Complexity and Controversy
Robert P. Colwell, Charles Y. Hitchcock III,
E. Douglas Jensen, H. M. Brinkley Sprunt,
and Charles P. Kollar
Carnegie-Mellon University


Ich habe leider nichts besseres zu "Instruction sets and Beyond: ..."

Der letzte Satz setz dem ganzen die Krone auf. Es ist eben das was @Skysnake beschreibt, ineffizienter Code ist nur dann relevant, wenn er häufig ausgeführt wird. Mit sehr speziellen Benchmarks zu zeigen wie überlegen ein neuer Ansatz ist, reicht eben nicht. Wenn der Benchmark nicht repräsentativ für die tatsächliche Workload ist, sind alle aus dem Benchmark abgeleiteten Zahlen irrelevant.

Die Sache mit dem i960 ist eine Tragoedie. Da hat Intel einen RISC entwickelt, ungefaehr zeitgleich mit dem 386, hat dem aber einen Rucksack mit Ideen vom iAPX432 draufgepackt, weil das ein besonders sicherer Prozessor fuer Nuklearreaktoren und so sein sollte.

Einen weiteren RISC-Prozessor hätte niemand gebraucht.

Wenn man Robert P Colwell glaubt, ist die Tragödie dass die bahnbrechende Konzepte der iAPX432 verloren gingen.

0:34:25 BC: Yeah. 10X. And that's why I said you could get it within shouting distance,
because I think somewhere else the RISC folks measured it as being about 1/20th the speed
of a RISC chip and so if you give it a factor 10 you could get within a factor of 2 of the best
and then at that point you could start saying well wait, I'm not as fast as him but look at all
this other cool stuff you get. But if you're 20 times slower there's no cool stuff going to save
you from there. It's kind of a shame, I mean I think that whole aspect of computer
architecture died because the 432 was such a debacle and it didn't need to be, there were
some good ideas in there, they just got lost.

Seite 53

Eines der grotesken Dinge die die iAPX432 versenkt haben ist, dass das Compiler team und die Hardwareentwickler über Kreuz lagen, und dass der Compiler sehr schlechten Code erzeugt hat.

Robert P. Colwell beschreibt es, dass er das Gefühl hat die Entwickler der iAPX432 glaubten auf einer Mission von Gott zu sein. Sie haben sich wie er meint so gut wie keine gedanken über die Performance gemacht. Seite 52

Bei IBM gab's das Muster, dass bei ambitionierte Projekte (z.B. Stretch) niemand ein Nachfolgeding machen wollten, weil ihnen dann die Kosten des Projekts angerechnet wuerden; stattdessen haben sie die Projekte eingestellt, und dann konnte sich der ganze Konzern kostenfrei daran bedienen (z.B. hat S/360 einiges von Stretch uebernommen). Beim iAPX432 und i960 ist wohl irgendwie dasselbe passiert, aber zum Nachteil des i960.

Robert P Colwell et al nennen in "Performance Effects of Architectural Complexity in the Intel 432" folgende Gründe:

1. Keine Optimierung im Ada Compiler
2. Stark limitierte Speicherbandbreite
3. Designers of the 432 made a decision to provide a new, protected context for every procedue call
4. Instructions are bit alligned, so the 432 must almost of necessity decode the various filed of an instruction sequentially.

.

 

[Skysnake]

@ETI1120
sehr spannende Geschichte die ich nicht kenne. Selbst iAPX432 kenne ich nicht. Muss ich mir mal im Detail anschauen.

irgendwie werde ich aber das Gefühl nicht los, das ich eine ähnliche Story erzählen könnte. Also nicht so 100%, aber wir haben faktisch auch ne Architektur mit speziellen Fähigkeiten effektiv verloren die es möglich gemacht hat gewisse Probleme in Codes zu entdecken und dann zu optimieren.

Da es die aber im Markt nicht mehr gibt gehe ich davon aus, daß gewisse Programmierfehler sich durch die Codewelt fressen, weil gar nicht mehr klar ist, dass das ein Problem ist. Bzw noch schlimmer den meisten wird gar nicht klar sein dass das Problem überhaupt existiert. So was wird nämlich nur in Rechneraechitekturen gemacht wenn überhaupt. Und auch da wird eher nicht gemacht was zu dem Problem konkret führt und wie das dann aussieht.

Und wir reden da dann schnell von Faktoren langsamer.

Vielleicht sollte ich darüber ja ne Dissertation in ein paar Jahren schreiben. Das Problem wird dann bestimmt überall sein weil kein Mensch mehr darauf achtet und zumindest ein mathematisches Schema gepusht wird das Inserent zu diesem Problem führt wenn man nicht explizit etwas dagegen macht.

Du kennst das 0. Gesetz von Gerald M. Weinberg?*)

Sagt mir jetzt aus dem stehgreif leider nichts.

Ich finde "premature optimizations" ist eng verwandt mit "Gold Platening", beiden liegen ungeprüfte Annahmen zugrunde.

Ja man muss aber aufpassen. Das wird auch oft genug so benutzt das man sich über Optimierung gar keine Gedanken macht....

Wenn ich ne 4 Fach geschachtelte for Schleife habe, dann ist das immer kritisch und ich muss mir anschauen wie lang die werden wenn ich nur ein paar Sekunden Ausführungszeit akzeptieren kann. Wird aber nicht immer gemacht und dann mit Preoptimization angefangen zu argumentieren...

Ich will gar nicht wissen wie viel Rotz in Codes stecken. Faktoren schneller würde macht oft nicht wundern.

 

[mae]

Die VAX und ihre Nachfolger wurden vom PC gekillt.

Die VAX wurde von den RISCs gekillt. Die Leute bei DEC haben sich in den spaeten 80ern nicht in erster Linie Sorgen gemacht, dass ihnen die PCs den Markt abgraben, sondern dass ihnen die Sun SPARCs und HP PAs die Verkaeufe vor der Nase wegschnappen, weil die VAX gegen die im Workstation- und Server-Markt von der Performance her nicht bestehen konnte. Das Problem war so draengend, dass sie nicht noch ein Jahr warten konnten, bis ihr eigenes PRISM-Projekt fertig war, sondern auf MIPS und die DecStations gesetzt haben.

Und ja, die Alpha wurde dann vom PC gekillt. Das war schwer zu vermeiden, einfach weil sich ein Marktfuehrer in einem etablierten Markt schwer tut, sich in einem Marktsegment darunter zu etablieren und dort zu bleiben. Selbst wenn man es geschafft hat, wie IBM mit dem IBM PC, hatten sie keine richtige Kontrolle ueber den Markt, und ihre Versuche, diese Kontrolle zu bekommen (PS/2, OS/2) sind fehlgeschlagen, und am Ende sahen sie sich gezwungen, den PC-Teil loszuwerden und haben ihn an Lenovo verkauft. Genauso hat HP sich am Ende in die PC-und-Drucker-Sparte und HPE geteilt.

Wobei sich Dein Szenario schon angedeutet hat, als mir 1986 vor einer Vorlesung eim Kommilitone erzaehlt hat, dass er jetzt einen ganz tollen Rechner hat; ich fragte, ob er eine VAX hat. Er meinte: "Besser: Ich habe einen Compaq Deskpro 386".

Viele Technologien die als RISC propagiert wurden, waren nämlich gar nicht an das Konzept Reduced Instruction Set Architecture gebunden, sondern konnten auch auf CISC angewendet werden.

Sicher. Die ersten RISCs wurden mit Pipelining schnell und kamen 1986 kommerziell heraus. 1985 kam Intel mit dem 386 ohne Pipelining heraus. 1989 kam Intel mit dem 486 mit Pipelining heraus, war aber trotzdem etwas langsamer als die RISCs aus der selben Zeit.

1992 kam Alpha als superskalarer Prozessor mit 200MHz heraus. Im selben Prozess kam NVAX+ mit 91MHz, keiner superskalaren Ausfuehrung und auch sonst weniger Performance pro Zyklus heraus (alleine das Decoding der VAX-Befehle brauchte mehrere Zyklen). 1993 kam der superskalare Pentium mit 60MHz heraus.

1995 kam OoO auf Mikroprozessoren heraus, beinahe zeitgleich der Pentium Pro und HP PA8000. Ich denke, dass mit modernen Techniken (OoO und Microcode cache (erstmals Pentium 4 im Jahr 2000)) auch die VAX von der Performance her konkurrenzfaehig gemacht werde haette koennen, aber bis dahin waeren DEC wohl die meisten Kunden weggelaufen, etweder zu RISC, wegen der davor hoeheren Performance, oder zu PCs, wegen des niedrigeren Preises.

Aber wenn die Behauptungen wie viel besser RISC als CISC sei, gestimmt hätten, hätte CISC niemals RISC aus den Datacentern verdrängen können.

Performance ist nicht alles.

Es war auch ein Treppenwitz der Geschichte, dass HP die HP Precision Architecture für Itanium in die Tonne getreten hat.

HP hat es eigentlich gut gemacht: Frueh auf RISC gesetzt und damit ihre CISC-Architekturen abgeloest. Dann haben sie frueh erkannt, dass sie HPPA nicht alleine wirtschaftlich weiterentwickeln koennen, und haben sich mit Intel zusammengetan, um ihr EPIC-Projekt zu entwickeln. EPIC war halt das falsche Konzept, aber sie haben es auch geschafft, damit umzugehen und den Umschwung auf Xeons fuer ihre grossen Maschinen geschafft.

Was die Behauptung angeht, dass RISCs den CISCs nur bei kleinen Benchmarks ueberlegen war. Vor dem Pentium Pro waren sie auch bei SPEC CPU deutlich ueberlegen (und SPEC CPU wurde aus Anwendungsbenchmarks zusammengestellt, und hat immer noch einen guten Ruf als Benchmark). Der Pentium Pro brachte dann einen Schock, weil der beim Integer-Teil von SPEC CPU ueberlegen war. Er wurde dann zwar wieder von einem RISC uebertrumpft, aber der grosse Vorsprung der Vergangenheit war weg. Und die zersplitterte RISC-Landschaft konnte wirtschaftlich und/oder organisatorisch die staendige Weiterentwicklung von OoO-CPUs im GHz-Rennen nicht stemmen.

Derweil hat sich ARM da frueh ausgeklinkt, und sich in einem Marktsegment darunter etabliert, und ist erst dann wieder in die Regionen der AMD64-Prozessoren vorgedrungen, als das GHz-Rennen laengst vorbei war. Und da konnten sie ihren Markt mit der lange geuebten Effizienz auch gegen Angriffe von Intel mit dem urspruenglichen Atom und den spaeteren E-Kernen verteidigen.

Einen weiteren RISC-Prozessor hätte niemand gebraucht.

Wenn die mit dem i960 am Anfang drangewesen waeren, waere es nicht "ein weiterer RISC" gewesen.

Wenn man Robert P Colwell glaubt, ist die Tragödie dass die bahnbrechende Konzepte der iAPX432 verloren gingen.

Ist offenbar sein Steckenpferd. Aber, wenn man's vom Ergebnis her sieht, offensichtlich hat niemand Erfolg damit gehabt, Features von iAPX432 in Architekturen einzubauen, und alles was in die Richtung ging (die Segmente des 286, oder die grosse Version von i960), wurde bestenfalls als Hindernis gesehen, das es zu umgehen gilt (286) bzw. was ab 386 voellig ignoriert wurde, oder ging einfach sang- und klanglos unter (grosser i960, noch mehr als i960 sonst). Colwell mag das schade finden, aber damit ist er in einer kleinen Minderheit.

Instructions are bit alligned, so the 432 must almost of necessity decode the various filed of an instruction sequentially.

Wie bei der VAX mit microcode cache zu loesen.

 

[ETI1120]

Sagt mir jetzt aus dem stehgreif leider nichts.

Ich kenne 2 Variationen:

1. Wenn ein Programm nicht korrekt sein muss, kann es beliebig schnell sein.
2. Wenn ein Programm nicht funktionieren muss, kann es jede andere Anforderung erfüllen.

Ja man muss aber aufpassen. Das wird auch oft genug so benutzt das man sich über Optimierung gar keine Gedanken macht....

Ich denke es hat 2 Ebenen.

• Die Architektur der Software muss entsprechend der Performanceanforderungen festgelegt werden. Wenn hier die Performanceanforderungen nicht beachtet werden, ...
• Wenn die Performanceanforderungen nicht erfüllt werden, muss man nachschauen wo die Rechenleistung versickert und verstehen, wo das Problem liegt. Erst dann kann man entscheiden was die richtige Optimierung ist.

Annektode 1
Software wurde auf dem Rechner des Mitarbeiters (Kunde) installiert. Die Software war sehr langsam. Der Mitarbeiter des Kunden hatte einen älteren PC. Empfehlung an den Kunden der Mitarbeiter soll einen schnelleren Rechner bekommen, da das Programm schon ziemlich aufwändige Berechnungen machen muss.
Zwei Wochen später entdeckt ein Programmierer einen Fehler im Code und nach beheben des Fehlers ist das Programm massiv schneller.

Annektode 2
Bei großen Dokumenten benötigt das Programm beinahe 24 h für das prozessieren. Einige Kollegen meinen das liege halt an der neuen Standardprogrammiersprache, die eben viel eben viel langsamer als bisher verwendete Speziallösung sei.

Der Projektleiter hört sich das eine Weile an und bittet dann einen anderen Kollegen, der sich mit der Standardprogrammiersprache sehr gut ausgekannt hat, sich mal den Sourcecode anzuschauen. Dieser findet sofort mehrere Programmierfehler deren Beheben das Prozessieren von großen Doku auf ca 10 Minuten drückt.

Das Problem war, dass der ursprünglich beauftragte Programmierer zwar die Syntax der neuen Programmiersprache verstanden hatte, aber keine Vorstellung davon hatte, wie sich Konstrukte auf die Performance auswirken.

Wenn ich ne 4 Fach geschachtelte for Schleife habe, dann ist das immer kritisch und ich muss mir anschauen wie lang die werden wenn ich nur ein paar Sekunden Ausführungszeit akzeptieren kann. Wird aber nicht immer gemacht und dann mit Preoptimization angefangen zu argumentieren...

Wenn das Programm die Performanceanforderungen nicht erfüllt, dann geht es nicht um pre mature optimizing sondern um bug fixing. Aber häufig hat man eben die Performanceanforderunge nicht scharf formuliert, sich keine Gedanken gemacht wie man sie testet, ...

Ich will gar nicht wissen wie viel Rotz in Codes stecken. Faktoren schneller würde macht oft nicht wundern.

Es hat einen Grund warum viele alte Hasen im Software Engineering das Durchführen von Code Reviews empfehlen.

Der schlecht programmierte Code muss ja nicht von Anfang an unangenehm auffallen. Mit ein bisschen Pech/Glück wird er selten ausgeführt. Es wird dann unter Umständen fatal, wenn dieser Code durch eine Programmänderungen/-erweiterung plötzlich häufiger ausgeführt wird. Und wenn man nur rät wo die Performance verloren geht und kein vernünftiges Profiling macht dauert es eben eine Weile, bis man im Code sucht der bisher "tadellos" funktioniert hat.

 

[ETI1120]

Die VAX wurde von den RISCs gekillt. Die Leute bei DEC haben sich in den spaeten 80ern nicht in erster Linie Sorgen gemacht, dass ihnen die PCs den Markt abgraben, sondern dass ihnen die Sun SPARCs und HP PAs die Verkaeufe vor der Nase wegschnappen, weil die VAX gegen die im Workstation- und Server-Markt von der Performance her nicht bestehen konnte.

Das erste Opfer von RISC war die 68K Familie. Die 68k waren zuvor beherrschte Architektur in den Workstations.

Ich denke das Desaster von DEC kann man nicht alleine an der Konkurrenz mit den RISC Workstations festmachen. Die Frage ist, in wie weit DEC verstanden hat, dass sich die Märkte verändern.

Es ist eben das Problem dass erfolgreiche Unternehmen häufig zu spät bemerken, dass sich die Märkte ändern. Und nicht auf die sich veränderten Märkte anzupassen war das Problem.

Und neben dem verschlafen der Marktveränderungen hat sich DEC mit dem CISC vs RISC unsinn dann endgültig ausmanövriert. Das alte Produkt war nicht performant genug und der Hoffnungsträger Alpha hatte keine Software.

Das Problem war so draengend, dass sie nicht noch ein Jahr warten konnten, bis ihr eigenes PRISM-Projekt fertig war, sondern auf MIPS und die DecStations gesetzt haben.

Und warum sind ist DEC nicht bei MIPS geblieben? Es war doch auch so überlegene RISC Chips die sich schnell und effizient entwickeln liesen?

Und ja, die Alpha wurde dann vom PC gekillt. Das war schwer zu vermeiden, einfach weil sich ein Marktfuehrer in einem etablierten Markt schwer tut, sich in einem Marktsegment darunter zu etablieren und dort zu bleiben.

Man kann die Workstation als High End Personal Computer sehen.
Aber bei Server und PC ergibt "darunter" und darüber keinen Sinn.

Selbst wenn man es geschafft hat, wie IBM mit dem IBM PC, hatten sie keine richtige Kontrolle ueber den Markt, und ihre Versuche, diese Kontrolle zu bekommen (PS/2, OS/2) sind fehlgeschlagen, und am Ende sahen sie sich gezwungen, den PC-Teil loszuwerden und haben ihn an Lenovo verkauft.

Der Punkt ist, der IBM PC wurde erfolgreich, weil IBM keine Kontrolle hatte. IBM hat sich eine ganze Weile ganz gut im Markt geschlagen, ist dann aber ins Hintertreffen geraten. Die einzigen die im PC Markt Kontrolle hatten waren Intel und Microsoft.

IBM war nicht bereit zu fighten.

Genauso hat HP sich am Ende in die PC-und-Drucker-Sparte und HPE geteilt

Komischer weise haben Lenovo und Dell keine Probleme Server und PCs anzubieten.

Bei IBM ist auf den Verkauf der PC-Sparte auch den Verkauf der X86-Serversparte erfolgt. wenn man in umkämpften Märkten nicht fightet verliert man. Beim Verlieren war IBM in den letzten 20 Jahren sehr erfolgreich.

Wobei sich Dein Szenario schon angedeutet hat, als mir 1986 vor einer Vorlesung eim Kommilitone erzaehlt hat, dass er jetzt einen ganz tollen Rechner hat; ich fragte, ob er eine VAX hat. Er meinte: "Besser: Ich habe einen Compaq Deskpro 386".

Ich habe 1987 beim Warten vor dem Hörsaal mitbekommen wie ein Kommilitone erzählt hat, er überlege sich einen Atari ST1040 und Atari Laserdrucker als Drucker für seinen Mac zu kaufen. Das fand ich nicht so witzig, da ich mir gerade einen ST1040 gekauft hatte. Diese Episode hat meine Einstellung zum Mac tief geprägt.

Ich war damals ganz ausdücklich im nicht-X86 lager und habe allem entgegengefiebert, was gegen X86 ging. Ich war immer eher jemand, der als interessierter Anwender unterwegs war. Ich hielt damals Motorola für eine gute Firma. Nur langsam habe ich mir eingestanden, dass Motorola keine Ahnung vom CPU-Geschäft hatte.

Sicher. Die ersten RISCs wurden mit Pipelining schnell und kamen 1986 kommerziell heraus. 1985 kam Intel mit dem 386 ohne Pipelining heraus. 1989 kam Intel mit dem 486 mit Pipelining heraus, war aber trotzdem etwas langsamer als die RISCs aus der selben Zeit.

Ein ganz wichtiger Umstand an der ganzen Geschichte ist, dass sich Intel kurz nach der Einführung vom 80386 aus dem DRAM-Markt zurückgezogen hat. Damit konnten die 80386 auf den viel modernen Anlagen der DRAM Fertigung produziert werden. Das brauchte sehr viel mehr Kapazität und eine drastisch bessere Ausbeute.

Damit konnte Intel den explodierenden PC-Markt selbst bedienen. Und damit wurden die anderen Anbieter von X86 für Intel lästig.

IIRC wurde die erste Sun-Workstation mit Sparc für 240 000 DM verkauft.

1992 kam Alpha als superskalarer Prozessor mit 200MHz heraus. Im selben Prozess kam NVAX+ mit 91MHz, keiner superskalaren Ausfuehrung und auch sonst weniger Performance pro Zyklus heraus (alleine das Decoding der VAX-Befehle brauchte mehrere Zyklen). 1993 kam der superskalare Pentium mit 60MHz heraus.

1995 kam OoO auf Mikroprozessoren heraus, beinahe zeitgleich der Pentium Pro und HP PA8000. Ich denke, dass mit modernen Techniken (OoO und Microcode cache (erstmals Pentium 4 im Jahr 2000)) auch die VAX von der Performance her konkurrenzfaehig gemacht werde haette koennen, aber bis dahin waeren DEC wohl die meisten Kunden weggelaufen, etweder zu RISC, wegen der davor hoeheren Performance, oder zu PCs, wegen des niedrigeren Preises.

DEC war eben eines der Unternehmen die sich selbst zerlegt haben. Jahrelang ging es nur bergauf. Man hatte ehrgeizige Ziele. Dann hat DEC lange nicht erkannt dass diese Ziele irrelevant waren. Als DEC endlich erkannt hat, dass sich die Märkte ändern, brachte DEC keine neue Strategie mehr zustande.

HP hat es eigentlich gut gemacht: Frueh auf RISC gesetzt und damit ihre CISC-Architekturen abgeloest. Dann haben sie frueh erkannt, dass sie HPPA nicht alleine wirtschaftlich weiterentwickeln koennen,

Durch den Zukauf von Apollo hat HP auch sehr viel Workstation Know How bekommen. HP PA war sehr erfolgreich. Wieso hätte HP ihre Precision Architecture nicht weiterentwickeln können sollen? RISC ist doch so viel einfacher wie CISC zu entwickeln.

Die Achillesverse von HP war die Halbleiterfertigung. Wie bei allen anderen Anbietern von RISC CPUs.

und haben sich mit Intel zusammengetan, um ihr EPIC-Projekt zu entwickeln. EPIC war halt das falsche Konzept, aber sie haben es auch geschafft, damit umzugehen und den Umschwung auf Xeons fuer ihre grossen Maschinen geschafft.

Das ist eine sehr beschönigende Darstellung.

AFAIU war EPIC überhaupt erst der Anlass für HP und Intel zusammenzuarbeiten. Die Kollateralschäden dieser Zusammenarbeit waren bei Intel und HP gewaltig.

HP hat die eigene Chipentwicklung verloren und überlebt in dem sie wie alle anderen Anbieter Intel weitgehend die Margen überlassen haben.

Der Pentium Pro brachte dann einen Schock,

Es war bestenfalls für die Leute ein Schock die die RISC vs CISC Debatte ideologisch geführt haben, und eben nicht bereit waren den Argumenten und Daten zu folgen.

Es ist eben schon witzig, dass Robert P. Colwell, der Häretiker, der nicht das RISC-Glaubenbekenntnis nachgebetet hat, die Chance bekam zu beweisen, dass CISC ISAs viele Konzepte übernehmen konnte die RISC ISAs zugeordnet wurden.

Und die zersplitterte RISC-Landschaft konnte wirtschaftlich und/oder organisatorisch die staendige Weiterentwicklung von OoO-CPUs im GHz-Rennen nicht stemmen.

Es gibt den oft propagierten großen Vorteil von RISC nicht. Und damit treten dann andere Faktoren in den Vordergrund.

Derweil hat sich ARM da frueh ausgeklinkt, und sich in einem Marktsegment darunter etabliert, und ist erst dann wieder in die Regionen der AMD64-Prozessoren vorgedrungen, als das GHz-Rennen laengst vorbei war.

Arm hat sich im Embedded Markt etabliert. bei der Zuordnung von PC und Embedded markt funktioniert "darunter" bzw. "darüber" ebenfalls nicht. es sind eigene Märkte mit anderen Anforderungen.

Der Erfolg von Arm hängt massgeblich am Gechäftsmodell. Arm hat keine Chips verkauft sondern IP und Chipdesigns.

Und da konnten sie ihren Markt mit der lange geuebten Effizienz auch gegen Angriffe von Intel mit dem urspruenglichen Atom und den spaeteren E-Kernen verteidigen.

Alles was Intel unternommen hat war bestenfalls halbherzig. Der überwältigende Erfolg im PC- und später im Servermarkt hat Intel träge werden lassen.

Colwell mag das schade finden, aber damit ist er in einer kleinen Minderheit.

Nur hat er sich tatsächlich mit der iAPX432 beschäftigt und diese intensiv untersucht. Und da neige ich seiner Meinung mehr Beachtung zu schenken, als denen die nur das wiedergeben was ihnen gesagt wurde.

But there was another aspect of
it that combined with the warring camps: what I call the religious attitude. By religious
attitude, I mean the following. The guys who did the 432 started with a really brilliant idea,
that you can use the notions of encapsulation and object orientation in a holistic way across
system boundaries where it had never before been tried. They didn’t invent the ideas, but
man, they went whole hog with them. Everything and I mean everything in a 432 computer
system is an object. Objects have properties, they have rights access, they have certain fixe aspects to them that you have to obey. And if you obey them, everything is great; if you don't,
the system will stop you in your tracks and say "You tried to access something you have no
rights to" right here, at this line of code. It's like if you're trying to debug code, it drags you
right to the line that's offending. In terms of security, we could use that kind of attitude today,
with all the viruses and worms we contend with.
Unfortunately, in our zeal to get away from the 432’s complexity, and because the field as a
whole did not retain the right lessons from the 432, it is constantly being reinvented
nowadays I'm on program review committees for conferences, and there are papers that are
submitted that are proposing ideas to improve security with the same ideas, just different
With the 432, even the hardware, the actual chip, was an object. To the software, it's an
object with certain capabilities. The 432 developers approached everything that way and
yielded a certain beauty in that once you have really adopted that point of view, the overall
system makes sense in a way that no other computer ever did. There are also many problems
with this whole scheme. One is the overhead involved in looking at the world that way. I
don't think it's unmanageable overhead but if you don't pay attention to it, it will become
unmanageable overhead, and so part of the problem with the 432 was these guys just
weren't paying attention to performance.
They thought in some deep sense that they were on a mission from God. They had this great
epiphany and they were going to follow it to the end and surely it wouldn't screw them up.
Well somewhere along the way, they threw away a little bit too much performance, and if
they had been paying attention to that aspect of it, I think that they could have fixed those
pieces, and if they made peace with the compiler guys they could have fixed that part of it
too. They could have actually got within shouting distance of a competitive part. But, as it
was, there were so many mistakes that there was no way to recover from them all.

Seite 51 im Interview

Wie bei der VAX mit microcode cache zu loesen.

So wie ich es verstehe, wurde es bei der iAPX432 eben nicht gelöst.

Ergänzung (26. September 2025)

Performance ist nicht alles.