warum macht amd die cpuform nach?
- Ersteller spacemanneke
- Erstellt am
PS Noch eine Frage - wo würdest du den Alpha in seinem Design einordnen? Also welche Generation? Beachte dabei aber, dass der Alpha als CPU Legende gilt, vor allem was IPC angeht 
@derDUKE
Damit hast du wohl recht - ich mach das aber auch daran fest, dass es seit nunmehr 26 Jahren immer so gelaufen ist - bis auf den in diesem Maßstab gerade erst erschienenen P4. Und desswegen soll sich plötzlich das komplette Konzept in der CPU Entwicklung ändern? Glaub ich net.
Der P4 weicht (und das wird denke ich jeder glauben) vom bisherigen Weg ab. Der K7 hat nicht eine extrem hohe IPC oder sowas, sondern ist nur die logische Weiterführung vom 686er. Der P4 dagegen hat einfach eine verflucht niedrige IPC, und jetzt, wo die physikalischen Grenzen auf einmal etwas enger werden (unerwartete Leckströme bei 90nm) trifft es den P4 am härtesten, weil der diese Grenzen am stärksten strapaziert hat. Es war schon lange abzusehen, dass Silizium nicht mehr ewig das Material aus dem die CPUs sind bleiben kann. Einzige Möglichkeit das zu umgehen ist das Design zu verbessern für eine höhere IPC. Sicher muss man auch auf die Taktrate eingehen (btw. wisst ihr, was AthlonXP und CyrixM2 gemein haben? Beide wurden (u.a.) in 0.18µm gefertigt), aber es kann doch nicht das Hauptzeil sein gerade das zu strapazieren, was man eigenltich hinauszögern will - das Erreichen der physikalischen Grenzen. Ein optimierter 8086 würde zwar sicherlich bis 5GHz und mehr gehen, aber die Leistung wäre alles andere als prikelnd. Und so wird es über kurz oder lang auch dem P4 ergehen.
@derDUKE
Damit hast du wohl recht - ich mach das aber auch daran fest, dass es seit nunmehr 26 Jahren immer so gelaufen ist - bis auf den in diesem Maßstab gerade erst erschienenen P4. Und desswegen soll sich plötzlich das komplette Konzept in der CPU Entwicklung ändern? Glaub ich net.
Der P4 weicht (und das wird denke ich jeder glauben) vom bisherigen Weg ab. Der K7 hat nicht eine extrem hohe IPC oder sowas, sondern ist nur die logische Weiterführung vom 686er. Der P4 dagegen hat einfach eine verflucht niedrige IPC, und jetzt, wo die physikalischen Grenzen auf einmal etwas enger werden (unerwartete Leckströme bei 90nm) trifft es den P4 am härtesten, weil der diese Grenzen am stärksten strapaziert hat. Es war schon lange abzusehen, dass Silizium nicht mehr ewig das Material aus dem die CPUs sind bleiben kann. Einzige Möglichkeit das zu umgehen ist das Design zu verbessern für eine höhere IPC. Sicher muss man auch auf die Taktrate eingehen (btw. wisst ihr, was AthlonXP und CyrixM2 gemein haben? Beide wurden (u.a.) in 0.18µm gefertigt), aber es kann doch nicht das Hauptzeil sein gerade das zu strapazieren, was man eigenltich hinauszögern will - das Erreichen der physikalischen Grenzen. Ein optimierter 8086 würde zwar sicherlich bis 5GHz und mehr gehen, aber die Leistung wäre alles andere als prikelnd. Und so wird es über kurz oder lang auch dem P4 ergehen.
Aaarghhhh
Da zoffen sich ausgerechnet zwei, die erwiesenermassen Ahnung von der Materie haben!!!
Ich denke, da sind zwei Ebenen, die immer wieder durcheinander gemischt werden.
Das eine ist die Meldung per CPU ID-Abfrage "Hallo" HuHu ich kann diese bestimmten Befehle verstehen! Diese Abfrage sagt aber wirklich gahhhr nüx über die Leistungsstärke aus.
Das andere sind Baukastenmerkmale, die zeigen wie moderne Ideen in das Design eingeflossen sind. Der K5 war in der Tat sehr fortschrittlich. Von dem Standpunkt des Designs war der K5 genauso fortschrittlich (CISC zu RISC-Decoder), wie der PentiumPro, der später als PentiumII wiederbelebt wurde.
Der K5 verstand aber weniger Features, was Instruktionen angeht, als ein PentiumPro.
Den Standard zur IA32 definiert aber intel, von daher meldet der P4 "Halloooo ich 786" über die Geschwindigkeit sagt dies nüxxx aus. Der Athlon meldet sich daher auch berechtigt mit "Grrr bin nur ein 686".
Fortschrittlich ist aber beim Athlon die SIMD-Einheit und auch die neuartigere Systemverbindung, es ist eben kein "Bus" mehr.
Der K8 ist da noch fortschrittlicher. Mehrere parallele Systemverbindungen. Eigener Speicherkontroller, NX-Bit ... dennoch meldet sich der K8 auch als 686
so etwas nennt man Understatement 8)
Wie gesagt es handelt sich hier um die x86-Geschichte. Andere CPU Gattungen jucken hier gar nicht... dies wäre ein eigener Artikel, bei dem intel sicherlich eben nicht mit erhobenen Haupt herausgeht (AMD auch nicht).
Siehe auch CISC-RISC oder auch "Crush", Cray, Motorola, DEC`s Alpha, ...
Link IA-32 architecture CPUID http://www.sandpile.org/ia32/cpuid.htm mit nettem Zitat dazu...
http://www.sandpile.org zeigt dies in wunderschöner Weise. Im Kopfteil jeder CPU Beschreibung ist sowohl die CPU-ID Nennung drin, als auch der Fortschrittsgrad nach Designmerkmalen
MFG Bokill
Da zoffen sich ausgerechnet zwei, die erwiesenermassen Ahnung von der Materie haben!!!
Ich denke, da sind zwei Ebenen, die immer wieder durcheinander gemischt werden.
Das eine ist die Meldung per CPU ID-Abfrage "Hallo" HuHu ich kann diese bestimmten Befehle verstehen! Diese Abfrage sagt aber wirklich gahhhr nüx über die Leistungsstärke aus.
Das andere sind Baukastenmerkmale, die zeigen wie moderne Ideen in das Design eingeflossen sind. Der K5 war in der Tat sehr fortschrittlich. Von dem Standpunkt des Designs war der K5 genauso fortschrittlich (CISC zu RISC-Decoder), wie der PentiumPro, der später als PentiumII wiederbelebt wurde.
Der K5 verstand aber weniger Features, was Instruktionen angeht, als ein PentiumPro.
Den Standard zur IA32 definiert aber intel, von daher meldet der P4 "Halloooo ich 786" über die Geschwindigkeit sagt dies nüxxx aus. Der Athlon meldet sich daher auch berechtigt mit "Grrr bin nur ein 686".
Fortschrittlich ist aber beim Athlon die SIMD-Einheit und auch die neuartigere Systemverbindung, es ist eben kein "Bus" mehr.
Der K8 ist da noch fortschrittlicher. Mehrere parallele Systemverbindungen. Eigener Speicherkontroller, NX-Bit ... dennoch meldet sich der K8 auch als 686
so etwas nennt man Understatement 8)Wie gesagt es handelt sich hier um die x86-Geschichte. Andere CPU Gattungen jucken hier gar nicht... dies wäre ein eigener Artikel, bei dem intel sicherlich eben nicht mit erhobenen Haupt herausgeht (AMD auch nicht).
Siehe auch CISC-RISC oder auch "Crush", Cray, Motorola, DEC`s Alpha, ...
Link IA-32 architecture CPUID http://www.sandpile.org/ia32/cpuid.htm mit nettem Zitat dazu...
http://www.sandpile.org zeigt dies in wunderschöner Weise. Im Kopfteil jeder CPU Beschreibung ist sowohl die CPU-ID Nennung drin, als auch der Fortschrittsgrad nach Designmerkmalen
MFG Bokill
Zuletzt bearbeitet:
BlackBirdSR
Commodore Special
Original geschrieben von intel_hasser
Das ist Blödsinn, der K7 hat sehr wohl sehr viele Neuerungen, wenn du meinst da hat sich nix im Vergleich zum P6 oder K6 geändert hast du dir die Architektur nie richtig angesehen!
Das ist wirklich mal was neues (wobei der I-Cache nur in anderer Form realisiert wurde und trotzdem noch vorhanden ist).
Schön, das liegt in der Natur einer Superskalaren Architektur und ist nicht ungewöhnlich.
Und trotzdem bei weitem nicht so schnell.
Sorry, mein Cx486DX2-V80-GP hat auch nur einen x86 Decoder (CISC)... der AMD K5 hat Afaik auch nur einen Decoder. Seit wann ist das Fehlen wichtiger Komponenten (der langsame Decoder ist eine eklatante Schwäche vom P4, das hab ich bisher fast überall gelesen) ein architektonischer Fortschritt
Normalerweise nennt man sowas einfach ein Stück draht... der Sinn der Sache (architektonisch) liegt bei genau 0.0
Hat der K6 und der K7 auch (die Sprungvorhersagen der beiden sind mit die beste die es bei x86 gibt) - der Cyrix M2 hat auch eine verflucht gute Sprungvorhersage die ihrer Zeit vorraus war.
Das ist Schwachsinn, der K7 hat eine FPU brachialster Art, sowas hat es bei x86 noch nie gegeben und auf die Integer Einheit trifft ähnliches zu - bei den anderen "kleineren" Sachen sieht es teilweise ähnlich aus.
Warum ist dann der 486er eben nur ein 486er und kein 786er?
tut mir leid, ich hätte mich echt gerne weiter auf eine DIskussion eingelassen, aber so kommen wir auf keinen grünen Zweig.
Wenn ich dir von Drive Stufen erzähle, und du von Draht sprichst; ich von einer komplett umgebauten ALU, und du sagst, "trotzdem nicht so schnell"
dann kannst du dir vielleicht vorstellen, dass es keinen Spass mehr macht.
Und bevor das nun in ein Scharmützel übergeht, beende ich das.
Ich hab dich nicht überzeugt, aber du mich schon 3x nicht
Man sieht sich
Sorry, aber wenn ich auch so empfindlich wäre hätte ich genau das schon nach diesem Satz gesagt:
Wenn du mal Lust auf Lektüre hast: http://www.azillionmonkeys.com/qed/cpujihad.shtml
Wenn du mal Lust auf Lektüre hast: http://www.azillionmonkeys.com/qed/cpujihad.shtml
BlackBirdSR
Commodore Special
Wie der P6
The Athlon is a long pipelined architecture, and like the P6, does a lot of work to unravel some of the oddball conventions of the x86 instruction architecture in order to feed a powerful RISC-like engine.
Wie P6 aber extrem aufgemotzt:
The K7 has a 72 entry instruction control unit (so that's up to 144 ops, which is significantly more than the P6's 40 entry reorder buffer) in addition to an 18 entry integer reservation station as well as a 36 entry FPU reservation station. Holy cow. The K7 will do an awful lot of scheduling for you, that's for sure.
Wie der P6 aber aufgemotzt
Now, the K7 has two load and one store ports into the D-cache (the P6 core can sustain a throughput of one load and/or store per clock.
Vergleich zum K6
So like its predecessor the K6, the instruction decoders and back ends look fairly well balanced, except that with the K7 we have a significantly wider engine.
Vergleich P6/K6 und K7
AMD's claims are that the K7's algorithm achieves 95% prediction accuracy (similar to the K6.) Given the long pipelined architecture of the K7, using a very accurate predictor seems more necessary than it was on the K6. Like the P6 core, the K7 also loses a decode clock on any taken branch (because it does not use a branch target cache like the K6 does.) However, the high decode bandwidth of the Athlon will typically make this a non issue.
Was ist daran Neu?
So the K7 appears to have the same expected average branch penalty as the K6! That's quite good for a deeply pipelined architecture. Its better than the P6 which has a worse predictor (90% accuracy) and larger miss penalty (13+ clocks).
Statt den P6 nachzumachen, legt man eben eins drauf:
The K7 architecture shows a three-way pipeline (FADD, FMUL, and FSTORE) for the FPU
Und das ist eine Designneuerung die es Wert ist darüber zu sprechen.
K7 lässt SIMD ausschließlich über die FPUs laufen. Zählt man das als Neuerung?
On the surface it appears as though the SIMD capabilities of the Pentium !!!'s full SSE implementation better alleviates register pressure over the K7. However the K7 has the opportunity to pull even with SSE in this area as well by virtue of its use, once again, of memory operands. (The theoretical peak result throughput of SSE and 3DNow! are identical -- each has slight advantages over the other which on balance are a wash.)
Schneller, oder größer, aber wo neuer?
The K7's cache is now 128 KB (2-way, harvard architecture, just like the Alpha 21264.) Ok this is just ridiculous -- the K7 has 4 times the amount of L1 cache as Intel's current offerings. If somebody can give me a good explanation as to why Intel keeps letting itself be a victim to what appears to be a simple design choice for AMD, I'd like to hear it.
The load pipe has increased from 2 cycle latency on the K6 to 3 cycle latency on the K7. This matches up with the P6 which also has a 3 cycle access time to their L1 cache. (But recall that the K7 can perform two loads per clock which is up to twice as fast as the K6 or P6.)
Ich sehe auf Anhieb nichts, dass so radikal anders wäre, es in eine neue Generation zu stopfen, ausser der FPU und dem Bussystem.
Dass die FPU aber nicht zwingend einen Generationswechsel anzeigt, sieht man am K8.
Beim Bus an diversen x86 Konkurrenten.
Im ENdeffekt, sehe ich noch immer nicht, wo der K7 so grundlegende Neuerungen besitzt, die den ganzen Ablauf umkrempeln?
So the K7 appears to have the same expected average branch penalty as the K6! That's quite good for a deeply pipelined architecture. Its better than the P6 which has a worse predictor (90% accuracy) and larger miss penalty (13+ clocks).
Lies mal richtig - "That's quite good for a deeply pipelined architecture" - der K6 hat eine kurze Pipeline, der K7 eine lange. Trotzdem hat es AMD geschafft, dass die branch penalty nicht einbricht, obwohl genau das bei einer längeren Pipeline passieren müsste (siehe P3).
So like its predecessor the K6, the instruction decoders and back ends look fairly well balanced, except that with the K7 we have a significantly wider engine.
"except that with the K7 we have a significantly wider engine." - das ist wohl kein Fortschritt
Es geht nur um die Decoder!
The Athlon starts out with 3 beefy symmetrical direct path x86 decoders that are fed by highly pipelined instruction prefetch and align stages.
Vergleich das mal mit dem einen Decoder vom P4
So indeed 5 ops is the K7's sustained instruction throughput. This is superior to the P6 architecture
Da brauch ich nix sagen, da hat mir der Author die Arbeit schon abgenommen
.
.
.
(ich spar mir hier jetzt vieles, zb. die Sache mit den interen Registern, weil ich eben gerade schon eine halbe Stunde ein Post geschrieben hab und jetzt ehrlich gesagt keine Lust hab das alles rauszusuchen was da steht)
Versus the P6
The K7 is larger faster and better in just about every way.
Das dürfte alles sagen.
------------------------
Worin ich den Schritt vom K7 sehe? Darin, dass der K7 das parallel Ausführen von Befehlen jetzt nicht mehr als lohnenden Nebenverdienst nutzt (wie der P6 - in der Realität hat man selten mehr als 2 Anweisungen die parallel durchlaufen), sondern massiv darauf aufbaut und gerade darauf ausgelegt ist.
Während der P6 darauf setzt Anweisungen möglichst schnell auszuführen und nur geringfügig auf paralleles ausführen setzt, ist der K7 darauf ausgerichtet massiv parallel zu arbeiten.
Und DAS ist neu!
Lies mal richtig - "That's quite good for a deeply pipelined architecture" - der K6 hat eine kurze Pipeline, der K7 eine lange. Trotzdem hat es AMD geschafft, dass die branch penalty nicht einbricht, obwohl genau das bei einer längeren Pipeline passieren müsste (siehe P3).
So like its predecessor the K6, the instruction decoders and back ends look fairly well balanced, except that with the K7 we have a significantly wider engine.
"except that with the K7 we have a significantly wider engine." - das ist wohl kein Fortschritt
Es geht nur um die Decoder!The Athlon starts out with 3 beefy symmetrical direct path x86 decoders that are fed by highly pipelined instruction prefetch and align stages.
Vergleich das mal mit dem einen Decoder vom P4
So indeed 5 ops is the K7's sustained instruction throughput. This is superior to the P6 architecture
Da brauch ich nix sagen, da hat mir der Author die Arbeit schon abgenommen
.
.
.
(ich spar mir hier jetzt vieles, zb. die Sache mit den interen Registern, weil ich eben gerade schon eine halbe Stunde ein Post geschrieben hab und jetzt ehrlich gesagt keine Lust hab das alles rauszusuchen was da steht)
Versus the P6
The K7 is larger faster and better in just about every way.
Das dürfte alles sagen.
------------------------
Worin ich den Schritt vom K7 sehe? Darin, dass der K7 das parallel Ausführen von Befehlen jetzt nicht mehr als lohnenden Nebenverdienst nutzt (wie der P6 - in der Realität hat man selten mehr als 2 Anweisungen die parallel durchlaufen), sondern massiv darauf aufbaut und gerade darauf ausgelegt ist.
Während der P6 darauf setzt Anweisungen möglichst schnell auszuführen und nur geringfügig auf paralleles ausführen setzt, ist der K7 darauf ausgerichtet massiv parallel zu arbeiten.
Und DAS ist neu!
BlackBirdSR
Commodore Special
Original geschrieben von intel_hasser
So the K7 appears to have the same expected average branch penalty as the K6! That's quite good for a deeply pipelined architecture. Its better than the P6 which has a worse predictor (90% accuracy) and larger miss penalty (13+ clocks).
Lies mal richtig - "That's quite good for a deeply pipelined architecture" - der K6 hat eine kurze Pipeline, der K7 eine lange. Trotzdem hat es AMD geschafft, dass die branch penalty nicht einbricht, obwohl genau das bei einer längeren Pipeline passieren müsste (siehe P3).
So like its predecessor the K6, the instruction decoders and back ends look fairly well balanced, except that with the K7 we have a significantly wider engine.
"except that with the K7 we have a significantly wider engine." - das ist wohl kein Fortschritt
The Athlon starts out with 3 beefy symmetrical direct path x86 decoders that are fed by highly pipelined instruction prefetch and align stages.
Vergleich das mal mit dem einen Decoder vom P4
So indeed 5 ops is the K7's sustained instruction throughput. This is superior to the P6 architecture
Da brauch ich nix sagen, da hat mir der Author die Arbeit schon abgenommen
.
.
.
(ich spar mir hier jetzt vieles, zb. die Sache mit den interen Registern, weil ich eben gerade schon eine halbe Stunde ein Post geschrieben hab und jetzt ehrlich gesagt keine Lust hab das alles rauszusuchen was da steht)
Versus the P6
The K7 is larger faster and better in just about every way.
Das dürfte alles sagen.
------------------------
Worin ich den Schritt vom K7 sehe? Darin, dass der K7 das parallel Ausführen von Befehlen jetzt nicht mehr als lohnenden Nebenverdienst nutzt (wie der P6 - in der Realität hat man selten mehr als 2 Anweisungen die parallel durchlaufen), sondern massiv darauf aufbaut und gerade darauf ausgelegt ist.
Während der P6 darauf setzt Anweisungen möglichst schnell auszuführen und nur geringfügig auf paralleles ausführen setzt, ist der K7 darauf ausgerichtet massiv parallel zu arbeiten.
Und DAS ist neu!
dir gehts immernoch um Leistung, um den Vergleich mit dem P4, den du für eine Dreckschleuder hältst, und um besser größer boah ey.
Der K7 arbeitet auch nicht massiv paralleler. Sonst wäre er viel schneller
Tut mir leid, es macht einfach keinen Sinn mit dir darüber weiter zu "kämpfen"
Kannst meinetwegen glauben du hättest gewonnen. Ist mit egal.
Überzeugt hast du mich nicht im Geringsten 8)
Der K7 arbeitet massiv paralleler, weil er eine höhere IPC als der P3 oder der P4 hat. Die IPC gibt genau darüber auskunft wie parallel ein Desing arbeitet (wenn die IPC > 1 ist), früher zu 486er Zeiten gab die IPC an wie schnell eine CPU die einzelnen Befehle ausführen kann (da diese ja noch seriell verarbeitet wurden), heute gibt die IPC an wie parallel eine CPU arbeitet, da die IPC > 1 ist (beim K7 max. 9).
BlackBirdSR
Commodore Special
uznd wieviel in Wirklichkeit?
9 ist ein lächerlicher Wert.
2-3 schon eher das was dem Maximum entspricht.
Ich kenne Werte zwischen 4 und 5 - das ist auch egal, ob nun 2/3 oder 4/5, weil der K7 2 bis 5 Befehle pro Takt ausführt, was heist es werden noch deutlich mehr Befehle parallel ausgeführt (da ein einzelner Befehl ja teilweise deutlich mehr als einen Takt braucht...).
BlackBirdSR
Commodore Special
lass dieses Thema lieber
Wieso
Willst du das etwa anzweifeln? Es ist bisher noch nicht möglich einen Befehl in weniger als einem Takt auszuführen, und viele komplexere Befehle brauchen eben mehrere Takte. Der Durchsatz von mehreren Befehlen pro Takten kommt daher, dass noch mehr Befehle parallel ausgeführt werden, und man in 7 Takten eben zb. 20 Befehle ausgeführt hat.
Das besondere am K7 ist meiner Meinung nach die extreme parallelisierung, die erstmal auch wirklich in den Vordergrund gestellt wird. Dazu gehört Branch Prediction, Out of Order Execution usw. - das ist kein Vergleich zum P6.
Willst du das etwa anzweifeln? Es ist bisher noch nicht möglich einen Befehl in weniger als einem Takt auszuführen, und viele komplexere Befehle brauchen eben mehrere Takte. Der Durchsatz von mehreren Befehlen pro Takten kommt daher, dass noch mehr Befehle parallel ausgeführt werden, und man in 7 Takten eben zb. 20 Befehle ausgeführt hat.
Das besondere am K7 ist meiner Meinung nach die extreme parallelisierung, die erstmal auch wirklich in den Vordergrund gestellt wird. Dazu gehört Branch Prediction, Out of Order Execution usw. - das ist kein Vergleich zum P6.
![mtb][sledgehammer](/data/avatars/m/1/1883.jpg?1596828194){kind=avatar}
mtb][sledgehammer
Grand Admiral Special
Hmm, die theoretischen 9 halte ich doch auch für übertrieben, insbesondere, da die Befehle erst durch den Decoder durchmüssen, und da gehen max 3 x86 Befehle rein und 6 Makro (oder Micro).Ops raus. Dennoch halte auch ich den Athlon in diesm Punkt (massiver Decoder) für fortschrittlicher als der Pentium 4 (kleine Decoder + Trace Cache), dessen Trace Cache im Moment nur 3 µOps pro Takt an Output bringt, also weniger als der athlon. Das kann selbst der höhere Takt nicht kompensieren. Natürlich halte ich auch die Idee des Trace Cache für moderner, doch was bringt ein moderner Ansatz, wenn am Ende die alte Methode doch wirtschaftlicher ist. (Einen Vergleich mit anderer Technolgie spare ich mir lieber, da das mit Sicherheit neuer Zündstoff wäre )
Genauso denke ich über die Hyper Pipeline des Pentium 4. Ist zwar auc ein interessanter Ansatz aber wiederum bringt die Idee im Endeffekt keinen Vorteil.
Im Prinzip halte ich daher beide Konzepte (P7, K7) von dieser Sichtweise aus auf der selben Ebene wie den P6. Den beides sind herstellerspezifische Wege, zu mehr Performance. Wieviel der eine vom anderen übernimmt, muss sich zeigen.
Die HT-Technologie oder eine andere Umsetzung von SMT könnte hingegen für mich ein Argument dafür sein, dass eine CPU eine Stufe weiter ist. Das ist wirklich ein Ansatz der erwiesenermaßen den Durchsatz erheblich steigern kann, und ich bin überzeugt davon, dass auch ein Athlon/opteron damit noch stärker ausgelastet würde.
Eine weitere Sichtweise ist mit Sicherheit die der Befehle: Allerdings könnte man dann schon den PIII dank SSE den 786er nennen und damit den P4 aufgrund SSE2 den 886. Entsprechend wäre der Athlon XP schon 786 und der K8 aufgrund AMD64 schon den 986. Allerdings stellt sich hier wiederum die Frage, welcher SIMD Befehlssatz ist Argument genug für eine neue CPU Generation. MMX war es nicht, 3Dnow! wohl auch nicht, SSE?, SSE2 hätte große Berechtigung, da es die Ablösung von x87 FP erlaubt. x86-64 halte ich aber definitiv für ein großes Argument, eine CPU in eine neue Schublade zu stecken, schließlich war das beim 386er auch ein ausreuchendes Argumeent (oder war damals noch etwas anderes weltbewegendes neues dran?).
Nunja, soviel mal von mir für das erste.
Schade dass D'Espice sich hier noch nicht gemeldet hat. Vielleicht könnte ich heute seinen Standpunkt besser verstehen.
)Genauso denke ich über die Hyper Pipeline des Pentium 4. Ist zwar auc ein interessanter Ansatz aber wiederum bringt die Idee im Endeffekt keinen Vorteil.
Im Prinzip halte ich daher beide Konzepte (P7, K7) von dieser Sichtweise aus auf der selben Ebene wie den P6. Den beides sind herstellerspezifische Wege, zu mehr Performance. Wieviel der eine vom anderen übernimmt, muss sich zeigen.
Die HT-Technologie oder eine andere Umsetzung von SMT könnte hingegen für mich ein Argument dafür sein, dass eine CPU eine Stufe weiter ist. Das ist wirklich ein Ansatz der erwiesenermaßen den Durchsatz erheblich steigern kann, und ich bin überzeugt davon, dass auch ein Athlon/opteron damit noch stärker ausgelastet würde.
Eine weitere Sichtweise ist mit Sicherheit die der Befehle: Allerdings könnte man dann schon den PIII dank SSE den 786er nennen und damit den P4 aufgrund SSE2 den 886. Entsprechend wäre der Athlon XP schon 786 und der K8 aufgrund AMD64 schon den 986. Allerdings stellt sich hier wiederum die Frage, welcher SIMD Befehlssatz ist Argument genug für eine neue CPU Generation. MMX war es nicht, 3Dnow! wohl auch nicht, SSE?, SSE2 hätte große Berechtigung, da es die Ablösung von x87 FP erlaubt. x86-64 halte ich aber definitiv für ein großes Argument, eine CPU in eine neue Schublade zu stecken, schließlich war das beim 386er auch ein ausreuchendes Argumeent (oder war damals noch etwas anderes weltbewegendes neues dran?).
Nunja, soviel mal von mir für das erste.
Schade dass D'Espice sich hier noch nicht gemeldet hat. Vielleicht könnte ich heute seinen Standpunkt besser verstehen.
mtb][sledgehammer
Grand Admiral Special
Bei der Gelegenheit habe ich gerade noch eine Verständnis Frage: Welche Aufgabe haben die AGUs, welche sowohl bei Netburst als auch beim K7 eine enorme Proportion haben (2xdouble pumped bzw 3x normal)? AMD Geht dabei ja in etwa davon aus, dass bis zu 50% aller µOps davon bearbeitet werden müssen.
puh, die AGU war doch für Shift Operationen usw. zuständig, oder? Viele Mathematische Dinge kann man damit sehr gut optimieren -> zb. AX*3=AX<<1+AX, AX*6=AX<<2+AX<<1 usw. - die Multiplikation ist im Vergleich zur Addition auch saulahm.
BlackBirdSR
Commodore Special
Original geschrieben von intel_hasser
Wieso
Willst du das etwa anzweifeln? Es ist bisher noch nicht möglich einen Befehl in weniger als einem Takt auszuführen, und viele komplexere Befehle brauchen eben mehrere Takte. Der Durchsatz von mehreren Befehlen pro Takten kommt daher, dass noch mehr Befehle parallel ausgeführt werden, und man in 7 Takten eben zb. 20 Befehle ausgeführt hat.
Das besondere am K7 ist meiner Meinung nach die extreme parallelisierung, die erstmal auch wirklich in den Vordergrund gestellt wird. Dazu gehört Branch Prediction, Out of Order Execution usw. - das ist kein Vergleich zum P6.
Ja das will ich.... (und Willy/NW führen einige Operationen in 0.5Takten aus)
Für was gibt es Scheduler, Abhängigkeiten, Pipeline Stalls etc?
woher soll der K7 bitte schön 9µOps ausführen?
Wie oft bekommst du einen Code, der ständig ADD/MUL abwechselt?
Wo bekommst du einen Code, der auf Lode/Store verzichtet, welche dem K7 out-of-order Ausführung vermiesen?
Wo bekommst du einen Code, der ständig zwischen FMUL/FADD abwechselt, keine FDiv benutzt?
Der P4 hat nur 6µOps alle 2 Takte. Selbst damit kommt er mehr aus als, auch in SMT Situationen. Wie soll da der K7 bitte 5 Ops pro Takt wirklich ausführen?
Zumal Befehle ja in-order retired werden müssen. Viel Spass dabei.
Zum Glück fassen die Scheduler die ganzen befehle vor den Einheiten.
Der K7 wäre locker doppelt so schnell bei gleichem Takt, glaubt man dir. Und das ist er nicht.
Wenn ich so lese was du schreibst, würde das eher auf einen Vergleich P6 <-> Vektorrrechner zutreffen.
Der P4 hebt sich vom Design nunmal krass von den anderen Beiden ab. Und dafür ist er eben für mich eine Generation weiter.
Egal ob der nun schneller oder langsamer ist, als der Vorgänger.
Du willst einen Pentium60 oder PentiumPro 150 ja auch nicht in die vorherige Generation stecken oder?
Zuletzt bearbeitet:
Der P4 hat afaik eine 2fach getaktete ALU - aber die braucht für Operationen auch einen Takt (ALU Takt).
Ein Befehl kann nicht in weniger als einem Takt ausgeführt werden, das ist theopraktisch einfach unmöglich. Wohl kann man aber 10 Befehle in 5 Takten ausführen.
The K7 has a 72 entry instruction control unit (so that's up to 144 ops, which is significantly more than the P6's 40 entry reorder buffer) in addition to an 18 entry integer reservation station as well as a 36 entry FPU reservation station. Holy cow. The K7 will do an awful lot of scheduling for you, that's for sure.
Die Durchsatzraten sind auf Teilbereiche vom K7 bezogen, dass der komplette Kern keine 9 CISC OPs pro Takt verarbeiten kann ist doch irgendwo klar... bei einer HDD betrachtest du Zugriffszeit und Datenraten auch nicht zusammen, sondern getrennt.
Der K7 nutzt zwar irgendwo altbewährte Techniken, aber ist im Endeffekt doch deutlich anders. Der K5 dagegen ist zb. anders als alle anderen 586er, jedoch trotzdem nur ein 586er - obwohl unten drunter eigentlich doch ein 686er, auch offiziell ist die Architektur die eines 586ers.
Ein Befehl kann nicht in weniger als einem Takt ausgeführt werden, das ist theopraktisch einfach unmöglich. Wohl kann man aber 10 Befehle in 5 Takten ausführen.
The K7 has a 72 entry instruction control unit (so that's up to 144 ops, which is significantly more than the P6's 40 entry reorder buffer) in addition to an 18 entry integer reservation station as well as a 36 entry FPU reservation station. Holy cow. The K7 will do an awful lot of scheduling for you, that's for sure.
Die Durchsatzraten sind auf Teilbereiche vom K7 bezogen, dass der komplette Kern keine 9 CISC OPs pro Takt verarbeiten kann ist doch irgendwo klar... bei einer HDD betrachtest du Zugriffszeit und Datenraten auch nicht zusammen, sondern getrennt.
Der K7 nutzt zwar irgendwo altbewährte Techniken, aber ist im Endeffekt doch deutlich anders. Der K5 dagegen ist zb. anders als alle anderen 586er, jedoch trotzdem nur ein 586er - obwohl unten drunter eigentlich doch ein 686er, auch offiziell ist die Architektur die eines 586ers.
mtb][sledgehammer
Grand Admiral Special
Bei der Durchsatzleistung des Athlon sollte man noch beachten, dass der Athlon keinen optimierten Code bekommt (im Gegensatz zu PIII oder P4). Das heißt die Scheduler und Co sind in der Lage einen nicht optimalen Code so zu verbessern, dass der Athlon bei gleichem Takt mehr Leistung als der PIII und natürlich viel mehr leistung als der P4 bringt.
Insbesondere muss man dabei auch beachten, welches L2 Cache System dem Athlon im Vergleich zum PIII Coppemine zur Verfügung steht. Auf der Seite des Athlon steht ein 64 breiter Datenpfad, beim PIII sind es gigantische 256 Bit. Ein weiteres Merkmal sind die extremen Unterschiede in der Latenz des selben. Ich möchte behaupten, dass ein Athlon XP mit dem Cache eines Coppermine einen deutlicheren Performancevorsprung vor diesem hätte als das tatsächlich der Fall ist.
Wie extrem parallel der Athlon arbeiten kann beweist meiner Ansicht auch die Tatsache, dass AMD beim Sprung zum K8 die Execution Units eigentlich (bis auf SSE2 und x86-64) unangetatstet ließ. Was verbessert wurde ist vor allem die Versorgung mit Befehlen: 128 Bit breiter L2 Cache, integrierter Memory Controller. An dieser Stelle mal der erstbeste Bench den ich finden konnte:
Ersttaunlich finde ich, wie stark der FX hier von der Erhöhung seines Speichertakts von 333 auf 400 MHz profitiert, obwohl er durch seinen großen L2 Cache ja eigentlich nicht so stark vom RAM abhängig sein dürfte.
Worauf ich damit hinaus will, ist, dass der K7 Kern durchaus für den x86 Bereich revolutionäre Superskalarität bietet.
Insbesondere muss man dabei auch beachten, welches L2 Cache System dem Athlon im Vergleich zum PIII Coppemine zur Verfügung steht. Auf der Seite des Athlon steht ein 64 breiter Datenpfad, beim PIII sind es gigantische 256 Bit. Ein weiteres Merkmal sind die extremen Unterschiede in der Latenz des selben. Ich möchte behaupten, dass ein Athlon XP mit dem Cache eines Coppermine einen deutlicheren Performancevorsprung vor diesem hätte als das tatsächlich der Fall ist.
Wie extrem parallel der Athlon arbeiten kann beweist meiner Ansicht auch die Tatsache, dass AMD beim Sprung zum K8 die Execution Units eigentlich (bis auf SSE2 und x86-64) unangetatstet ließ. Was verbessert wurde ist vor allem die Versorgung mit Befehlen: 128 Bit breiter L2 Cache, integrierter Memory Controller. An dieser Stelle mal der erstbeste Bench den ich finden konnte:
Ersttaunlich finde ich, wie stark der FX hier von der Erhöhung seines Speichertakts von 333 auf 400 MHz profitiert, obwohl er durch seinen großen L2 Cache ja eigentlich nicht so stark vom RAM abhängig sein dürfte.
Worauf ich damit hinaus will, ist, dass der K7 Kern durchaus für den x86 Bereich revolutionäre Superskalarität bietet.
was schreibst du da für einen, man verzeihe mir, bockmist?
wo ist den intel voraus?
das 90nm verfahren war bis jetzt ein einziger fehlschlag -> viel zu früh, intel wollte einfach was neues nachschieben ohne "weit genug zu sein"
nur weil ibm etwas kann (90nm, soi), kann intel es eben noch lange nicht.
einziger punkt ist dass erst jetzt eingeführte retention modul auf dem k8 bzw. heatspreader -> aus amds sicht war der verbleib beim sockel a völlig in ordnung
amd steht inzwischen besser da und konnte eigenen innovation begründen (amd64) oder mit begründen (hypertransport), ohne zu risikieren von den "herstellern" also kompliziertes und kostenaufwendiges kleinvieh übersehen zu werden.
man hat ja gesehen was mit 3dnow passiert ist, amd hat es probiert...intel hat einfach sse nacherfunden und 3dnow platt gemacht.
aus heutiger sicht war 3dnow gut und effektiv (die neuen quake3-dlls...na ja, heut zu tage bringen sie auch nicht mehr viel
), aber wirtschaftlich und auf grund der damaligen unwichtigkeit von amd ein einziger finanzieller fehlschlag, wenn man so will.ich erhebe jetzt keinen anspruch auf richtigkeit, aber amd hätte sich zu zeiten des athlon-xp palominio mit einem sockel 754 ähnlichen retention-modul doch einen knieschuss verpasst.
Ach ja, jetzt klingelts wieder
Mit AGU werden (neben Shift Operationen) die meisten Integeroperationen realisiert. Den Befehl kann man nämlich wunderbar für so ziemlich alles mögliche gebrauchen, da er eine Multiplikation und eine Addition beherrscht.
Da gibts solche tollen Dinge wie LEA EAX,[EBX*5+ECX] und damit werden momentan sehr viele unsigned Integer Operationen realisiert -> wichtig.
Der P4 mag das übrigens garnet
Mit AGU werden (neben Shift Operationen) die meisten Integeroperationen realisiert. Den Befehl kann man nämlich wunderbar für so ziemlich alles mögliche gebrauchen, da er eine Multiplikation und eine Addition beherrscht.
Da gibts solche tollen Dinge wie LEA EAX,[EBX*5+ECX] und damit werden momentan sehr viele unsigned Integer Operationen realisiert -> wichtig.
Der P4 mag das übrigens garnet
BlackBirdSR
Commodore Special
Der P4 hat 2! doppelt getaktete FAST-ALUs, von denen jede in 0.5 globalen Taken, ein zugeordnetes µOp bearbeiten kann.
Bezüglich AGUs:
AMD lässt mit neuen Revisionen des K8, viele LEA Befehle zu ADD konvertieren.
Der P4 tut dies ebenso, und somit sind auch die meisten Compiler darauf ausgelegt.
Man spart sich im Fall des K8 damit einen Taktzyklus, und verlegt die Ausführung von der AGU in die ALU.
