90nm doch schneller?

[Dresdenboy]

Original geschrieben von rkinet
Ist das die Ursache für die schnellerne 90nm ?
Ein schneller angebundener L2 Cache !?

Eine interessante Sache... Der Unterschied beträgt ca. 10%. Denkbar ist, daß dank kleinerem Die die Signallaufzeiten kürzer sind und an irgendeiner (oder zwei) Stelle ein Takt eingespart werden kann.

 

[Treverer]

Original geschrieben von andr_gin
Also die SPEC-Werte sagen doch absolut nichts über die Performance aus. Das ist das reinste Synthetische Zeug.

hmm, man könnte natürlich auch ganz auf benches verzichten - nur ist das wohl etwas irreal, oder

also kann man nur schauen, die verschiedenen benches zu kennen und zu bewerten. und da sind, denke ich, die spec-werte viel besser als vieles andere, was mit recht synthetisch genannt wird, wie z.b. 3dmurks oder sandra-hochrechnungen - denn messungen, wer weiß ob da gemessen wird?

warum ich finde, daß die spec besser sind? wegen der transparenz. und der daher guten vergleichbarkeit der werte. würde ich die programme für die einzelergebnisse besser kennen, dann wäre es auch leichter zu sehen, wo und warum ein cpu zulegt oder verliert. aber genau dieses habe ich mir vorgenommen fürs nächste wochenende, denn beim neuen athlon64 wert, gibt einzelne benches, die 15% zugelegt haben. da wir vermuten, daß es vor allem an den ram-timings liegt, müßte dies nachprüfbar sein an dem, was das programm macht bzw. wie es bei anderen timings in der vergangenheit abgeschnitten hat. und genau so etwas ist doch bei kaum anderen benches möglich, oder?

 

[Seemann]

Original geschrieben von Dresdenboy
Eine interessante Sache... Der Unterschied beträgt ca. 10%. Denkbar ist, daß dank kleinerem Die die Signallaufzeiten kürzer sind und an irgendeiner (oder zwei) Stelle ein Takt eingespart werden kann.

Andererseits, hatte DresdenBoy nicht eine gefixte Error-Liste gepostet, in der ein Bug in Zusammenhang mit dem Speicherzugriff aufgelistet war?

Benutzen die 90nm-Chips eigentlich das CG- oder D0-Stepping?

 

[p4z1f1st]

D0

 

[Dresdenboy]

Original geschrieben von Seemann
Andererseits, hatte DresdenBoy nicht eine gefixte Error-Liste gepostet, in der ein Bug in Zusammenhang mit dem Speicherzugriff aufgelistet war?

Ja, hat er Aber dieser Bug bezog sich auf das Prefetching aus dem DRAM, was sich bei Datensätzen komplett innerhalb des L2 eigentlich nicht auswirken sollte.

 

[Treverer]

Original geschrieben von rkinet

http://techreport.com/reviews/2004q4/athlon64-fx55/index.x?pg=3


Ist das die Ursache für die schnellerne 90nm ?
Ein schneller angebundener L2 Cache !?

ja, sehr gute erklärung, gerade für quake steigerung um 7%

ich denke, jetzt wissen wir es...nur: warum schweigt amd über so etwas? machen sie jetzt einen auf understatement? oder wollen sie intel schonen

 

[Seemann]

Original geschrieben von p4z1f1st
D0

Wenn es tatsächlich ein neues Stepping ist, dann besteht vielleicht eventuell möglicherweise die Chance, dass AMD das mal in den hauseigenen Docs erwähnt.

 

[Treverer]

lol

einer der besten witze des jahres: p4 schlägt athlon64 in ut2004 wenn der software renderer verwendet wird:

http://techreport.com/reviews/2004q4/athlon64-fx55/index.x?pg=6

also, liebe mädels, holt eure 2d-grafikkarten wieder vor, denn

1. reichen dann auch wieder 8mb locker bei top auflösungen

2. habt ihr endlich wieder ein system, bei dem es sich lohnt, einen p4ee zu besitzen


p.s.: na, dieses post paßt aber auch zur entdeckung der langsamkeit


und desweiteren: was für verherrende ergebnisse bei farcry und doom3 für intel. und diese engines werden die nächsten drei jahre die games beherrschen. und nicht solche benches wie 3dmark, wo man genau diese, für intel!, harten wahrheiten NICHT sieht...

 

[p4z1f1st]

Original geschrieben von Seemann
Wenn es tatsächlich ein neues Stepping ist, dann besteht vielleicht eventuell möglicherweise die Chance, dass AMD das mal in den hauseigenen Docs erwähnt.

also, am anfang dachte ich die Frage wäre nicht ernst gemeint, aber so langsam glaub ichs doch

es wird doch überall (auch hier) quasi rausgebrüllt, dass die 90nm mit D0 kommen

 

[rkinet]

Original geschrieben von Treverer
einer der besten witze des jahres: p4 schlägt athlon64 in ut2004 wenn der software renderer verwendet wird:

also, liebe mädels, holt eure 2d-grafikkarten wieder vor, denn

1. reichen dann auch wieder 8mb locker bei top auflösungen
2. habt ihr endlich wieder ein system, bei dem es sich lohnt, einen p4ee zu besitzen


p.s.: na, dieses post paßt aber auch zur entdeckung der langsamkeit

Hey Treverer, die haben halt alles versucht um dem P4-EE wenigstens einen Anstandpunkt zu geben ('For once, the Pentium 4 runs a game faster than the A64')
Im Notfall hätte die bestimmt auch in 320*240 ge-bencht ...

und von wegen gigantischen 8 MB - 1MB Trident-PCI und P4-EE, D A S Dreamteam 2005 ...

Man sollte aber nicht zu sehr lästern, die vielen 'GHz inside' müsen eben böse Kompromisse im Chipdesign hinterlassen.
Bei 'Normale' CPUs (P-M) packt Intel wahrscheinlich kaum mit mehr GHz als AMD auch.

 

[Seemann]

Original geschrieben von rkinet
und von wegen gigantischen 8 MB - 1MB Trident-PCI und P4-EE, D A S Dreamteam 2005...

Hehe, ich hol noch meine Triden 9440er raus, die hatte tatsächlich 1MB on Board - aufrüstbar auf 2 MB. Hehe, da haben moderne CPus schon mehr Cache on Die...

 

[i_hasser]

Och guck dir doch mal die ganzen DOS-Games die nicht EMS/XMS nutzen an.

Die passen samt uns sonders mit dem Betriebssystem in den Cache. Der HDD-Cache (smartdrive, nwcache usw.) passt natürlich auch noch dazu .


Aber dann komm ich mit meinem Cyrix M2 an - dem kann man nämlich explizit sagen, er soll den VGA RAM cachen. Praktisch macht das den Framebufferbetrieb bis zu 10mal so schnell 8).

 

[AnyKey]

Hi

Wie seiht´s aus wird es möglich sein 4 Doppelseitige Ram Module darauf nutzen
zu können und mit 400 MHz 2-2-2-5-1 ansteuern zu können wenn die Ram Module
diese Vorraussetzung erfüllen

Oder hat sich auch bei den 90nm CPU´s nix am Speichercontroller
gebessert

 

[Dresdenboy]

Original geschrieben von AnyKey
Wie seiht´s aus wird es möglich sein 4 Doppelseitige Ram Module darauf nutzen
zu können und mit 400 MHz 2-2-2-5-1 ansteuern zu können wenn die Ram Module
diese Vorraussetzung erfüllen

Oder hat sich auch bei den 90nm CPU´s nix am Speichercontroller
gebessert

Das wird wohl eher nicht so funktionieren, da es die Signalqualität stark negativ beeinflusst. Das liegt aber am DDR-Standard, daß man so eingeschränkt ist (und die Hersteller nichts strengeres einhalten müssen) und nicht am Speichercontroller.

Zwei mögliche Entwicklungen könnten in Zukunft aber helfen (als Upgrade-Variante):
- Man verbessert den Speicherkontroller, denn falls es AXP- oder P4-Boards gibt, die im dual channel Betrieb 4 double sided DIMMs mit DDR400+ ermöglichen, sollte es auch mit dem MCT machbar sein.
- Die Speicherdichte steigt weiter und ermöglicht die gleiche Kapazität bei single sided DIMMs.

 

[i_hasser]

Hab mal schnell eine ziemlich technische Frage - gehört nicht so ganz zum Thema, aber hier sind gerade so viele kompetente Leute unterwegs .

Ich denk mal der K7 Kern zerlegt ein ADD EAX, EBX genauso (u.A.) in einen Additions-µOP wie zB. MOV EAX, [EBX+0x123].

Angenommen ich überflute den K7 mit Integer- und Floatadditionen. Wieviele kann er da bestenfalls parallel ausführen? Meine damit sowas wie '2 Floatadditionen und nebenbei noch 3 Integeradditionen'. Es geht um den praktischen Durchsatz, nicht das, was nur die Recheneinheiten leisten.


EDIT: Könnte was in der Größenordnung von 3 Integeroperationen parallel mit 5 Floatoperationen hinkommen?

 

[Dresdenboy]

@i_hasser:
> Ich denk mal der K7 Kern zerlegt ein ADD EAX, EBX genauso (u.A.) in einen Additions-µOP wie zB. MOV EAX, [EBX+0x123].

Naja, nicht ganz Es gibt da direkt ADD-µOps.

> Angenommen ich überflute den K7 mit Integer- und Floatadditionen. Wieviele kann er da bestenfalls parallel ausführen? Meine damit sowas wie '2 Floatadditionen und nebenbei noch 3 Integeradditionen'. Es geht um den praktischen Durchsatz, nicht das, was nur die Recheneinheiten leisten.

Peak wären 9 möglich (3 Int-, 3 Address-, 3 FP/SIMD-Ops). Es kommen aber pro Takt nur max. 6 (3 Int/FP/SIMD + 3 Address-Ops) nach und es wird auch max. nur so eine Gruppe (ist oft aber sogar kleiner) pro Takt abgeschlossen (retired, d.h. Register-/Speicher-Schreiboperationen sind abgeschlossen und der Code ist nicht mehr Spekulativ - was von Ergebnissen vorhergehender Sprungbefehle abhängen kann).

> EDIT: Könnte was in der Größenordnung von 3 Integeroperationen parallel mit 5 Floatoperationen hinkommen?

3 Int- plus 3 Adress-Ops (z.B. bei Befehlen wie ADD EAX, [EBX*4+EDI+4740]).

Ein SIMD-Op kann natürlich auch mehrere kleinere Integer-Werte bearbeiten, wobei die dritte FP-Einheit keine Rechnungen durchführen kann, dafür die FMUL-Einheit auch Integer-Additionen - also erreicht man max. 16 1-Byte-Additionen in einem Takt.



@Thread:
Der INQ erzählt etwas Neues zu der schon einmal aufgetauchten Geschichte mit den Peltier-Elementen im/am Chip. Dazu ist jetzt auch das Patent einsehbar. Ich habe mich gleich einmal umgesehen, was da noch so neues aufgetaucht ist - darunter sind auch einige Strained-Si-Patente für FinFets (das wird noch einmal richtig interessant bei <=65nm). Ich glaube, das hier passt auch in den K9/K10-Thread

 

[rkinet]

Peltier-Elemente ...

65 nm
45 nm
vielleicht mal bei 32 nm ...

Also vom Patent bis zur Fertigung vergehen immer viele Jahre.

Bei den ganz kleinen Strukturen der Zukunft erscheint aber die Wärmeabfuhr ein Problem zu werden, selbst wenn die Chips in Summe nur wenige Watt benötigen.

 

[i_hasser]

Original geschrieben von Dresdenboy
@i_hasser:
> Ich denk mal der K7 Kern zerlegt ein ADD EAX, EBX genauso (u.A.) in einen Additions-µOP wie zB. MOV EAX, [EBX+0x123].

Naja, nicht ganz Es gibt da direkt ADD-µOps.

> Angenommen ich überflute den K7 mit Integer- und Floatadditionen. Wieviele kann er da bestenfalls parallel ausführen? Meine damit sowas wie '2 Floatadditionen und nebenbei noch 3 Integeradditionen'. Es geht um den praktischen Durchsatz, nicht das, was nur die Recheneinheiten leisten.

Peak wären 9 möglich (3 Int-, 3 Address-, 3 FP/SIMD-Ops). Es kommen aber pro Takt nur max. 6 (3 Int/FP/SIMD + 3 Address-Ops) nach und es wird auch max. nur so eine Gruppe (ist oft aber sogar kleiner) pro Takt abgeschlossen (retired, d.h. Register-/Speicher-Schreiboperationen sind abgeschlossen und der Code ist nicht mehr Spekulativ - was von Ergebnissen vorhergehender Sprungbefehle abhängen kann).

> EDIT: Könnte was in der Größenordnung von 3 Integeroperationen parallel mit 5 Floatoperationen hinkommen?

3 Int- plus 3 Adress-Ops (z.B. bei Befehlen wie ADD EAX, [EBX*4+EDI+4740]).

Ein SIMD-Op kann natürlich auch mehrere kleinere Integer-Werte bearbeiten, wobei die dritte FP-Einheit keine Rechnungen durchführen kann, dafür die FMUL-Einheit auch Integer-Additionen - also erreicht man max. 16 1-Byte-Additionen in einem Takt.



@Thread:
Der INQ erzählt etwas Neues zu der schon einmal aufgetauchten Geschichte mit den Peltier-Elementen im/am Chip. Dazu ist jetzt auch das Patent einsehbar. Ich habe mich gleich einmal umgesehen, was da noch so neues aufgetaucht ist - darunter sind auch einige Strained-Si-Patente für FinFets (das wird noch einmal richtig interessant bei <=65nm). Ich glaube, das hier passt auch in den K9/K10-Thread

Ok, danke .

 

[i_hasser]

Hab mal noch eine Frage - ist es theoretisch möglich, dass der K7 alle 1.15 Takte eine Integeroperation fertigrechnet?

Also er in sagen wir einer Sekunde bei 2.2GHz 1.9 Milliarden Rechnungen durchführt (wobei davon 1/4 Addition, 1/4 Bitoperationen, 1/4 Multiplikation und 1/4 Division).


Müsste ja eigentlich möglich sein, spielt da auch der Decoder mit?

 

[mtb][sledgehammer]

Wieso 1,15? Theoretish packt der Dekoder pro Takt 3 x86 Befehle (bei Direct Path Decoding), diese werden in insgesamt 3 MacroOps dekodiert, welche aus 1-2 Microops bestehen. Solange es sich nicht um Multiplikationen handelt, müssten die nach meinem Verständnis alle parallel abgearbeitet werden können. Also 3 Befehle pro Takt. Problem ist eben, dass nicht alles Direct path ist, und eventuell doch ein paar mehr Multiplikationen.

 

[i_hasser]

Gut, also ist es möglich. Hatte mich gewundert, weil mir ein Teilbench 1.9 Milliarden Integerops pro Sekunde ausgespuckt hat und mir der Wert etwas hoch vorkam.

 

[mtb][sledgehammer]

Ich sehe im Moment erst, dass du ja die Aufteilung angegeben hast. Kritisch könnte der DIV Befehl werden, da er den Vector Path nutzt (und da weiß ich heute noch nicht 100%ig, in welchem Maße das parallelisiert wird. Da kommts auch drauf an, wieviele Bit dividiert werden. Die anderen drei Sorten kann der Prozessor dagegen direkt parallel verarbeiten, ergo 3 pro Takt. Hast du das programm in ASM geschrieben (mich würde interessieren, welcher DIV Befehl ausgeführt wird.

 

[i_hasser]

Nein, ist C++. Wart mal kurz...

     453:       f7 bd 9c f8 ff ff       idivl  0xfffff89c(%ebp)

Ist der GNU Syntax, also zu 'Intelianisch' 'IDIV [0xFFFFF89C+EBP]'.

Hat sich inzwischen aber erledigt, der GCC hatte ein paar Sachen wegoptimiert die er nicht wegoptimieren sollte.

 

[i_hasser]

Falls mal jemand Lust hat sich den Kopf zu zerbrechen:

MG: 506.482, MI: 506.482, MF: 0, CPI_A(zx);
MG: 501.749, MI: 501.749, MF: 0, CPI_L(zx);
MG: 492.542, MI: 492.542, MF: 0, CPI_M(zx);
MG: 45.0018, MI: 45.0018, MF: 0, CPI_D(zx);
MG: 813.441, MI: 813.441, MF: 0, CPI_AL(zx);
MG: 813.441, MI: 813.441, MF: 0, CPI_AM(zx);
MG: 813.441, MI: 813.441, MF: 0, CPI_LM(zx);
MG: 1150.44, MI: 1150.44, MF: 0, CPI_AAL(zx);
MG: 1175.63, MI: 1175.63, MF: 0, CPI_ALL(zx);
MG: 1118.48, MI: 1118.48, MF: 0, CPI_ALM(zx);
MG: 953.025, MI: 953.025, MF: 0, CPI_AMM(zx);
MG: 1088.25, MI: 1088.25, MF: 0, CPI_LLM(zx);
MG: 964.439, MI: 964.439, MF: 0, CPI_LMM(zx);
MG: 125.928, MI: 125.928, MF: 0, CPI_ALD(zx);
MG: 149.964, MI: 149.964, MF: 0, CPI_ALMD(zx);
MG: 158.955, MI: 158.955, MF: 0, CPI_ALLD(zx);
MG: 147.391, MI: 147.391, MF: 0, CPI_AMMD(zx);
MG: 166.860, MI: 166.860, MF: 0, CPI_AALD(zx);
MG: 150.174, MI: 150.174, MF: 0, CPI_AAMD(zx);
MG: 1234.19, MI: 1234.19, MF: 0, CPI_ALLM(zx);
MG: 994.205, MI: 994.205, MF: 0, CPI_ALMM(zx);
MG: 1227.13, MI: 1227.13, MF: 0, CPI_AALM(zx);.

So sieht momentan der Integer-Benchmark von AMBiX D aus (bzw. sind das die Ergebnisse davon).

Ist recht interessant, wie die Leistung vom K7 bei bestimmten Kombinationen einbricht - kommt eine Division ins Spiel sinkt die Geschwindigkeit ja teilweise erheblich.

Zur Erklärung:

MG steht für Millionen Gesamtoperationen pro Sekunde, MI für Millionen IntegerOP/s und MF für Millionen FloatOP/s - da das der Integerteil ist sind alles Integeroperationen.

CPI_[abcd] steht dafür, was gemessen wurde. A steht für eine Addition, L für eine logische/Bitoperation (hab & genommen), M für eine Multiplikation und D für eine Division.

Gelesen wird das der Reihe nach, CPI_A bedeutet zB. x=x+y - CPI_AM steht für x=x+y*z und CPI_ALMM für x=x+y&z*a*b - entsprechend der mathematischen Regeln wird das dann in einer bestimmten Reihenfolge gerechnet (da ich in die Regeln sowieso kein Vertrauen hab benutze ich sonst immer Klammern wo es geht, nur hier nicht - also ich weis net, wie die Regeln aussehen ).

x, y, z, a und b sind allerdings Array-Elemente - also für jeden Zugriff darauf kommt eine Address Generation dazu (in dem Fall eine einfache Addition, da die Arrayindizies bekannt und konstant sind).
Bei aufeinanderfolgenden Operationen sind alle Variablen anders (-> andere Elemente im Array).

Mitunter sind bei den Werten aber einige Schwankungen dabei.


PS Schwankungen weitetstgehend beseitigt... ach ja, der Themenbezug. Hmm... die Werte sollten so auch für den K8 gelten . CPU lief auf 2.2GHz.

 

[Dresdenboy]

Original geschrieben von i_hasser
PS Schwankungen weitetstgehend beseitigt... ach ja, der Themenbezug. Hmm... die Werte sollten so auch für den K8 gelten . CPU lief auf 2.2GHz.

Jetzt geht's etwas daneben Kennst du noch den Grund, warum die Pipeline nun 12 Stufen hat? Derselbe Grund kann allein benutzt werden, eine Extra-Messung auf K8 zu rechtfertigen, außer GCC hat so gute Arbeit gemacht, daß keine ungünstigen Dekodierungs-Situationen entstehen. Weiterhin sind Muls und Divs 1 oder mehr Takte schneller als beim K7 und die MUL/IMUL-Befehle sind nicht mehr Vector Path sondern Single oder Double Path (dann passt auch mal ein ADD nebenbei mit in die Befehlsgruppe).

Der Vollständigkeit halber noch zwei Links:
In-depth and thorough examination of AMD64 architecture
Aus dessem Anhang:
K7- und K8-Decoder im Vergleich (Auswirkungen der veränderten Fetch- und Decoder-Stufen)