90nm doch schneller?

[i_hasser]

Original geschrieben von Dresdenboy
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)

Ha! - jetzt haben wir ja doch wieder K8 Bezug . War ja eigentlich nur froh, dass ich nach mehreren Tagen endlich den Benchmark so halbwegs auf die Reihe bekommen hab .

Wie man sieht ist CPI_M ähnlich schnell wie CPI_A und CPI_L - obwohl die Multiplikation ja Vector Path ist.

Also ein bisschen Performance kostet es schon, CPI_[x]MM ist ja jeweils ein minimales Stückchen langsamer als CPI_[xy]M (also 2 vs. 1 Multiplikation).
Aber es macht ja praktisch garnix aus.


Und um das jetzt wieder richtig auf das Thema zu lenken - ich hab natürlich auch noch einen K8 neben mir stehen 8).

MG: 440.058, MI: 440.058, MF: 0, CPI_A(zx);
MG: 436.480, MI: 436.480, MF: 0, CPI_L(zx);
MG: 426.088, MI: 426.088, MF: 0, CPI_M(zx);
MG: 40.8889, MI: 40.8889, MF: 0, CPI_D(zx);
MG: 706.409, MI: 706.409, MF: 0, CPI_AL(zx);
MG: 711.087, MI: 711.087, MF: 0, CPI_AM(zx);
MG: 706.409, MI: 706.409, MF: 0, CPI_LM(zx);
MG: 1052.69, MI: 1052.69, MF: 0, CPI_AAL(zx);
MG: 1045.85, MI: 1045.85, MF: 0, CPI_ALL(zx);
MG: 1012.96, MI: 1012.96, MF: 0, CPI_ALM(zx);
MG: 1052.69, MI: 1052.69, MF: 0, CPI_AMM(zx);
MG: 1000.38, MI: 1000.38, MF: 0, CPI_LLM(zx);
MG: 1052.69, MI: 1052.69, MF: 0, CPI_LMM(zx);
MG: 116.458, MI: 116.458, MF: 0, CPI_ALD(zx);
MG: 108.095, MI: 108.095, MF: 0, CPI_AMD(zx);
MG: 108.095, MI: 108.095, MF: 0, CPI_LMD(zx);
MG: 138.280, MI: 138.280, MF: 0, CPI_ALMD(zx);
MG: 144.030, MI: 144.030, MF: 0, CPI_ALLD(zx);
MG: 141.282, MI: 141.282, MF: 0, CPI_AMMD(zx);
MG: 152.955, MI: 152.955, MF: 0, CPI_AALD(zx);
MG: 138.369, MI: 138.369, MF: 0, CPI_AAMD(zx);
MG: 1136.23, MI: 1136.23, MF: 0, CPI_ALLM(zx);
MG: 1090.09, MI: 1090.09, MF: 0, CPI_ALMM(zx);
MG: 1130.25, MI: 1130.25, MF: 0, CPI_AALM(zx);

So, das ist jetzt ein Socket754 K8 auf 1.8GHz.

Interessant ist zB., dass bei CPI_D die Performance verhältnismäßig deutlich besser ist als bei meinem TBred (ein K7 auf 1.8GHz hätte 36.8 haben müssen).

Dann ist der Performanceeinbruch bei ALMM deutlich geringer (liegt wohl daran, dass Multiplikation jetzt kein Vector Path mehr ist) und überhaupt ist die Leistung verhältnismäßig ein gutes Stück höher.

Ich hab mal eine einfache Rechnung gemacht, alle Werte *2.2/1.8 - so sind sie mit denen vom K7 vergleichbar.

MG: 537.849, MF: 0, CPI_A(zx);
MG: 533.476, MF: 0, CPI_L(zx);
MG: 520.774, MF: 0, CPI_M(zx);
MG: 49.9753, MF: 0, CPI_D(zx);
MG: 863.389, MF: 0, CPI_AL(zx);
MG: 869.106, MF: 0, CPI_AM(zx);
MG: 863.388, MF: 0, CPI_LM(zx);
MG: 1286.62, MF: 0, CPI_AAL(zx);
MG: 1278.26, MF: 0, CPI_ALL(zx);
MG: 1238.06, MF: 0, CPI_ALM(zx);
MG: 1286.62, MF: 0, CPI_AMM(zx);
MG: 1222.69, MF: 0, CPI_LLM(zx);
MG: 1286.62, MF: 0, CPI_LMM(zx);
MG: 142.338, MF: 0, CPI_ALD(zx);
MG: 132.116, MF: 0, CPI_AMD(zx);
MG: 132.116, MF: 0, CPI_LMD(zx);
MG: 169.009, MF: 0, CPI_ALMD(zx);
MG: 176.037, MF: 0, CPI_ALLD(zx);
MG: 172.678, MF: 0, CPI_AMMD(zx);
MG: 186.945, MF: 0, CPI_AALD(zx);
MG: 169.118, MF: 0, CPI_AAMD(zx);
MG: 1388.73, MF: 0, CPI_ALLM(zx);
MG: 1332.32, MF: 0, CPI_ALMM(zx);
MG: 1138.75, MF: 0, CPI_AALM(zx);

Aufpassen, hier sind noch ein paar neue Kombinationen dabei .

 

[Bokill]

@i_hasser

Dann brauchst du nur noch jemanden der dein Tool noch mit einem 0,09µm Baby füttert ... wäre dann bei erfolgreichem Test, dann wieder eine Meldung beim Inquirer wert ... 8)

MFG Bokill

 

[i_hasser]

Na unterschwellig mach ich damit ja eigentlich Werbung für AMBiX D - der komplette Bench mit allen Detailresultaten wird da nämlich reinwandern. Dazu kommen noch einige Floatwerte und Integer/Float Kombinationen.

Und dann wird man das auch noch alles schön online einsehen und vergleichen können . Man gibt sagen wir über die ausgewählten Benchmarks vor, für welche Anforderungen man das System braucht und bekommt eine Liste der unter diesen Anforderungen schnellsten Systeme präsentiert 8).


Natürlich sind bei AMBiX auch noch andere Benchmarks dabei... ein zB. dauert ein Pipeline Flush des K7 in der Praxis ungefähr 21 Takte.

Ich würd ja gern mal den Wert vom P4 dagegen sehen, dummerweise hab ich so ein System nicht da um zu testen.

 

[Bokill]

@i_hasser

Was du da als subtil hinstellst, das empfinden andere als zärtliches tätscheln mit dem Dampfhammer. Was ich mit meiner Linkitis als Service begreife, empfinden manche als Beleidigung ... nun denn ... hier mal der Link zu i_hassers AMBiX86 Homepage(almost everytime under development)
...

MFG Bokill

 

[i_hasser]

Aber so leid es mir tut, die AMBiX Homepage wird nicht mehr gepflegt - das bezieht sich alles auf AMBiX C, von AMBiX D ist da noch keine Rede.

Wenn der Benchmark selbst fertig ist oder ich mal zwischendurch Lust hab was anderes zu machen setz ich mich an die HP.

Oder (auch eine Überlegung) - ich verpack das alles hübsch in einem Forum. Wäre am einfachsten zu Warten.

 

[mtb][sledgehammer]

Was mich an deinen bench Results ein wenig wundert ist beispielsweise die reine Add oder die reine Logic Performance 500 Mio Ops pro Sekunde. Arbeiten die beiden Tests beide immer auf dem selben Reg oder dem selben Speicherplatz, bzw. kommen da noch Move Operationen oder Sprünge hinzu? Ich meine z.B. ALLM sieht mit knapp 1,5 Mrd deutlich besser aus, wenn auch das noch weit hinter dem theoretisch möglichen Wert von 6 Mrd Ops pro Sekunde bei 2 GHz hinterher hinkt

 

[i_hasser]

Original geschrieben von mtb][sledgehammer
Was mich an deinen bench Results ein wenig wundert ist beispielsweise die reine Add oder die reine Logic Performance 500 Mio Ops pro Sekunde. Arbeiten die beiden Tests beide immer auf dem selben Reg oder dem selben Speicherplatz, bzw. kommen da noch Move Operationen oder Sprünge hinzu? Ich meine z.B. ALLM sieht mit knapp 1,5 Mrd deutlich besser aus, wenn auch das noch weit hinter dem theoretisch möglichen Wert von 6 Mrd Ops pro Sekunde bei 2 GHz hinterher hinkt

Ja, na das ist schon ein Praxisnaher Bench. Hab ich doch oben schon geschrieben, eine AG (Address Generation - in dem Fall eine einfache Addition) pro Operation.

Ich schätze mal, dass die geringe Leistung bei CPI_A daher kommt, dass der Wert direkt nach der Rechnung eben wieder in den Cache geschrieben werden muss (die Rechen-arrays sind insgesammt 8kB groß, passen also bequem in den Cache).

Mal sehen, werd wahrscheinlich noch ein CPI_AAAA dazumachen. Das dürfte deutlich mehr Leistung bringen, weil der Wert erst nach 4 Rechnungen wieder zurückgeschrieben wird.

Sprünge sind praktisch nicht dabei - theoretisch wird alle 16, 32, 48 oder 64 OPs gesprungen, aber das kann man so ziemlich vernachlässigen.

 

[Treverer]

ich möchte, rückkehrend zum thema , noch auf etwas hinweisen, was ich noch nirgends las: daß die 90nm cpus ein wenig schneller sind als ihre 130nm pendants, ist ein feines argument dafür, daß der jetzige athlon64 4000+ sein pr zu recht trägt die alten ratings können ja auch um 1% angepaßt werden, also zb. auf 3535

 

[MCT_K]

Original geschrieben von i_hasser

Natürlich sind bei AMBiX auch noch andere Benchmarks dabei... ein zB. dauert ein Pipeline Flush des K7 in der Praxis ungefähr 21 Takte.

Ich würd ja gern mal den Wert vom P4 dagegen sehen, dummerweise hab ich so ein System nicht da um zu testen.

Gibt es für diesen Bench einen extra Schalter? bzw. Wo kann man das Anzeigen lassen?

Ich hätte eine P4 Northwood & Prescott zu Verfügung und mich würde dies auch sehr interessieren.

 

[i_hasser]

Hast du ein rennendes Linux? Die momentanen AMBiX Versionen sind alle für Linux, um das Crosscompiling auf andere Plattformen mach ich mir später Gedanken.

 

[MCT_K]

ja, kein Problem...

der testrechner läuft sogar ständig unter linux, weil es ein kleiner samba-server ist...

 

[andr_gin]

Original geschrieben von Treverer
ich möchte, rückkehrend zum thema , noch auf etwas hinweisen, was ich noch nirgends las: daß die 90nm cpus ein wenig schneller sind als ihre 130nm pendants, ist ein feines argument dafür, daß der jetzige athlon64 4000+ sein pr zu recht trägt die alten ratings können ja auch um 1% angepaßt werden, also zb. auf 3535

Verstehe ich nicht ganz. Erstens ist es nicht 1%, sondern ca. 3% und zweitens ist der 4000+ in 130nm gefertigt und der einzige Unterschied ist das MB Cache statt den 512KB. Das sind ziemlich genau die 200+, die er mehr hat.

 

[Treverer]

Original geschrieben von andr_gin
Verstehe ich nicht ganz. Erstens ist es nicht 1%, sondern ca. 3% und zweitens ist der 4000+ in 130nm gefertigt und der einzige Unterschied ist das MB Cache statt den 512KB. Das sind ziemlich genau die 200+, die er mehr hat.

na, dann werde ich es mal erklären, damit auch du mich verstehst

meine aussage bezog sich auf gemachte einwände, das rating sei zu hoch gewählt. klar, weiß ich auch, daß der jetzige(!) athlon64 4000+ in 130nm gefertigt wird. aber das bleibt ja nicht so, nicht wahr? wenn amd weiß - und das können wir wohl vorraussetzen - das die folgenden cpus in 90nm aus welchen gründen auch immer eine höhere rechenleistung bieten, dann ist doch auch klar, daß sie ihr rating anpassen. zumindest für die dann kommenden prozessoren. wäre die steigerung groß genug, dann, so denke ich, würden sie es auch für die bereits bekannten ratings machen, was natürlich wiederum das durcheinander steigern würde. aber, ich denke, dies wäre amd herzlich egal - es geht eben immer noch darum, aus möglichst wenig realem takt (=technischer und finanzieller aufwand) möglichst hohe (rating-)zahlen zu generieren (beweis: semperon). was "deine" 1% betreffen: erstens war meine rechnung ja nur ein (rechen-)beispiel und zweitens willst du doch wohl nicht ernsthaft jetzt darauf bestehen, daß es nicht nur 1% seien, sondern sogar 3%? wissen wir doch alle, daß dies von der anwendung abhängt, oder?

und noch eine nebenbemerkung: die verbesserung des l2-cache minimiert die realen(!) unterschiede zwischen dual-channel und single-channel erneut. d.h. aber nichts anderes, als daß die rating-differenzen zwischen den beiden modellen noch weniger berechtigt bzw. übertrieben sind. schließlich betrugen die leistungsunterschiede zwischen dual- und single-channel immer nur runde 2,7865%

edit1:
hm, auf klo läßt sich echt nachdenken. und nun denke ich, daß meine letzte behauptung nicht stimmt. wenn der l2-cache die datenzugriffe aufs ram minimieren würde, z.b. weil er größer wird, dann stimmt es. aber wenn er nur schneller wird, dann minimiert er die zugriffe gar nicht, sondern im gegenteil: die cpu braucht eher neue daten, muß also wohl im durchschnitt auch noch häufiger aufs ram zugreifen. die folge ist also eine größere anstatt eine kleinere abhhängigkeit vom ram - dual-channel bringt dann aber natürlich mehr als single-channel. die rating unterschiede zwischen den modellen mit single oder dual-channel also berechtigter, da auch die leistungsunterschiede größer werden...top, paßt ja einfach alles

 

[andr_gin]

Das Rating von AMD ist ja sowieso Daumen mal Pi. Ein 3200+ mit 2,2Ghz und 512KB ist z.B. deutlich schneller, als ein 3200+ mit 2Ghz und 1MB. Außerdem ist der Vorteil von DC vom CPU-Takt abhängig. Bei 1,8Ghz z.B. reicht SC DDR400 noch aus, während bei 2,6Ghz die SC DDR400 schon viel zu wenig sind. Ich würde sagen gerade beim 4000+ stimmt das Rating genau.

 

[Treverer]

Original geschrieben von andr_gin
Ich würde sagen gerade beim 4000+ stimmt das Rating genau.

genau? nö, pi mal daumen

 

[andr_gin]

Naja ich meine im Vergleich zum 3800+. Es ist auch das Problem für AMD, auf was sie sich beziehen sollen. Soll es der P4 sein, dann gibt es das Problem, dass hier ja auch etwas getan wird z.B. FSB, Cache etc. Eine Möglichkeit wäre sich auf eine gewisse CPU zu beziehen z.B. den Thunderbird, aber auch hier gibt es grobe Probleme nämlich, wenn Dinge wie Speicherbandbreite ins Spiel kommen. Einen Thunderbird mit SDRAMkönnte man auch mit 10Ghz takten und er würde nicht an die Leistung eines FX herankommen, weil einfach der RAM so stark limitiert. Eine andere Möglichkeit wäre die CPUs nach der wirklichen Leistungsfähigkeit zu beurteilen und nicht zu sagen "das wäre ein Thunderbird mit so und soviel Ghz", sondern sich prozentuell darauf beziehen. Hier kommen aber wieder neue Probleme dazu z.B. bei Spielen wo sich u.U. nicht genau feststellen lässt, um wieviel diese und jene CPU schneller ist, weil auch Dinge wie z.B. die Grafikkarte limitieren, die mit der CPU nichts oder nur indirekt etwas zu tun haben (z.B. gibt es noch keine A64-Chipsätze auf dem Markt, die PCI-Express unterstützen).

Das Rating von AMD hinkt nicht beim 4000+, sondern viel mehr in der Kategorie 3000+ bis 3400+. Hier schlägt nämlich AMD für 200Mhz mehr Takt auch 200+ Rating drauf, was ein großer Fehler ist, weil man das nicht so rechnen kann. Prozentuell würde es schon eher stimmen (halt auch nur grob). Man sollte es am Besten so aufteilen:

Sockel754:
A64 2700+ (512KB/1,6Ghz/SC/130nm): 2400+
A64 2800+ (512KB/1,8Ghz/SC/130nm): 2700+
A64 3000+ (1MB /1,8Ghz/SC/130nm): 2900+
A64 3000+ (512KB/2,0Ghz/SC/130nm): 3000+
A64 3200+ (1MB /2,0Ghz/SC/130nm): 3200+
A64 3200+ (512KB/2,2Ghz/SC/130nm): 3300+
A64 3400+ (1MB /2,2Ghz/SC/130nm): 3500+
A64 3400+ (512KB/2,4Ghz/SC/130nm): 3600+
A64 3700+ (1MB /2,4Ghz/SC/130nm): 3800+

Sockel939:
A64 3000+ (512KB/1,8Ghz/DC/90nm ): 3000+
A64 3200+ (512KB/2,0Ghz/DC/90nm ): 3350+
A64 3500+ (512KB/2,2Ghz/DC/130nm): 3600+
A64 3500+ (512KB/2,2Ghz/DC/90nm ): 3700+
A64 3800+ (512KB/2,4Ghz/DC/130nm): 3950+
A64 3800+ (512KB/2,4Ghz/DC/90nm ): 4050+
A64 4000+ (1MB /2,4Ghz/DC/130nm): 4100+
A64 4000+ (1MB /2,4Ghz/DC/90nm ): 4200+
FX-55 (1MB /2,6Ghz/DC/130nm): 4450+
FX-55 (1MB /2,6Ghz/DC/90nm ): 4550+

Da ist das Rating an den Athlon64 3000+ mit 512KB,2Ghz und SC angepasst. Das ist natürlich auch nicht 100% richtig, weil ich einige kleinere Effekte nicht mitberücksichtigt habe z.B. dass eine CPU mit 1MB pro 200Mhz mehr Leistung gewinnt, als eine mit nur 512KB, aber mit der Auflösung von 50+ würde das sowieso nicht auffallen und so würde auf jeden Fall schon näher an die Realität herankommen.