Performancediskussion RUSE

[Undertaker]

Split aus: http://www.forum-3dcenter.org/vbulletin/showthread.php?p=8254798



So einfach ist das nicht. Der L3 des i3 ist halbiert, so ursprünglich nicht "vorgesehen". Der Q9550 dagegen ist eine Erweiterung des Kentsfield.

Was meinst du mit nicht vorgesehen? Der Clarkdale ist von vornherein mit 4MB L3 gedacht, bei einem teildeaktivierten Modell wäre dies etwas anderes - und auch dann würde mich ein solch großer Einbruch verwundern. Lynnfield kann mit weniger Cache als Yorkfield weitaus besser performen, dann wird ein in Relation dazu sogar größerer Cache des Clarkdale im Vergleich zu Conroe kaum die Bremse sein.
Hier liegt definitiv nicht die Ursache.

Mir schweben da eher zwei Theorien im Kopf herum, an welche ich zwar nicht so recht glauben mag, aber die zumindest eine Untersuchung wert wären:

1. Speicherlatenz

Der einzige Punkt, in dem Clarkdale wirklich schlecht dasteht, auch verglichen zum Core 2. Das hat schon einige Male Leistung gekostet, in diesem Ausmaß allerdings noch nie.

2. Spezielle Bevorzugung von Core i5/i7?

Wenn hier schon architekturspezifisch optimiert wurde, dann womöglich auch modellspezifisch? Evntl. kommen ja nur i5/i7 Modelle in den Genuß "spezieller Optimierungen". Wäre allerdings genauso merkwürdig.

[y33H@]

Lynnfield hat nicht weniger Cache, bedenke den inklusiven L3. Der Clarkdale ist imo ein runterskalierter Lynnfield und leidet daher an verringerten Cache teils sehr. Ähnlich der Pentium-E-2xxx-Serie.

[S940]

Nein, ich hab auch mal drüber nachgedacht. ;)

1. Der i3 hat 512kb L2 und 4MB L3, der i7 860 1MB L2 und 8MB L3. Der E6600 hat 4MB L2, der Q9550 12MB L2.

-> Wenn der Q9550 gegen den i5 760 untergeht, der E6600 aber nicht gegen den i3 530, ist das keine Cachesache

2. Gleiches Thema bei den Threads, SMT bringt dem i7 860 ganz gut Leistung, dem i3 530 daher wahrscheinlich sogar umso mehr.

Nö, denn Du darfst die Punkte nicht aufdröseln, sonder musst sie im Zusammenhang betrachten.
SMT bringt <in dem speziellen Fall> möglicherweise nur dann was, wenn der Cache groß genug ist. Ist er beim i3 aber nicht ergo -> großes FAIL, da sich die 4 Threads die die Daten gegenseitig aus dem kleinen 256kB L2 bzw. dem 4MB L3 kegeln.
Der i5 760 hat damit kein Problem, der hat a) echte 4Kerne und b) den vollen Cache, dass der Q9550 dann wg. der schlechteren FSB Arch. verliert ist nur logisch. Der E6600 hat dagegen nur 2 Threads, die anscheinend von der Menge her auch noch schön in den 4MB L2 Cache passen.
Bin mir ziemlich sicher, dass SMT dem i3 wg. Cache Trashing in Verbund mit der schlechteren RAM Anbindung das Genick bricht, aber Genaues würden nur Tests bringen.

@y33H:
Ruhig, ruhig, war kein Vorwurf. Ist schon klar, dass ihr in erster Linie mal nur die Standardsettings bencht. Dachte nur, dass Du vielleicht für die Print noch OC Tests gemacht hättest.

3. Der i3 530 hat im Verhältnis zur Rechenleistung mehr reale Speicherbandbreite als der i7 860Was bitte ist "reale" Speicherbandbreite, ist das ne Neuerfindung von Dir ?
Fakt ist: Die Clarkdales haben im Vergleich zu den Nehalems ne grottige RAM Anbindung, les Dir die Tests durch ... 10-12 GB/s BW, im Vergleich dazu hat ein Nehalem (dual channel) um die 17GB/s++. Richtig böse wirds dann, wenn man auch noch die Latenzen vergleicht ...
Also nein, dass ist bei genauerem Hinschauen ganz und gar nicht erklärbar. Am liebsten würde ich es mal auf meinem i5 540M selbst testen...Na dann mach mal, wenn DU eh so ein Maschinchen hast :) Oder gibts keine kostenlose Demo Version ?

ciao

Alex

[y33H@]

Online sind's sogar mehr CPUs als Print ;)

[Undertaker]

Lynnfield hat nicht weniger Cache, bedenke den inklusiven L3. Der Clarkdale ist imo ein runterskalierter Lynnfield und leidet daher an verringerten Cache teils sehr. Ähnlich der Pentium-E-2xxx-Serie.

Sry, aber das ist der völlig falsche Vergleich - man beachte die verschiedenen Kernzahlen. Die Cachegröße pro Kern ist bei Lynnfield und Clarkdale identisch. Conroe hat weniger Cache pro Kern als Yorkfield. Dennoch aber schlägt Lynnfield Yorkfield und Conroe Clarkdale. Das ist nicht mit der Cachemenge zu begründen.

Als Test dafür z.B. einfach mal den Gulftown auf 4 Kerne beschnitten testen. Ich werde versuchen, Werte für meinen 3MB Arrandale zu bekommen. Meine Vorhersage: Gulftown wird bei gleichem Takt und 50% mehr Cache kaum vor Lynnfield/Nehalem liegen. Ein 3MB Clarkdale wird nicht über den üblichen 5-10% hinter dem 4MB Vollausbau liegen.

Nö, denn Du darfst die Punkte nicht aufdröseln, sonder musst sie im Zusammenhang betrachten.
SMT bringt <in dem speziellen Fall> möglicherweise nur dann was, wenn der Cache groß genug ist.

Nö, dass ergibt keinen Sinn. Auf einem Clarkdale ohne SMT laufen doch in der gleichen Anwendung nicht weniger Threads der Anwendung als bei einem Clarkdale mit SMT. Für die Cacheauslastung ist es völlig egal, ob wir das Spiel bei identischer Hardware auf zwei Threads oder 4 Threads pressen.


Was bitte ist "reale" Speicherbandbreite, ist das ne Neuerfindung von Dir ?
Fakt ist: Die Clarkdales haben im Vergleich zu den Nehalems ne grottige RAM Anbindung, les Dir die Tests durch ... 10-12 GB/s BW, im Vergleich dazu hat ein Nehalem um die 17GB/s++. Richtig böse wirds dann, wenn man auch noch die Latenzen vergleicht ...

Davon sprach ich doch. :) Lies nochmal oben nach. Real ist das, was hinten raus kommt - und das ist bei Dual-Channel DDR3-1333 weniger als bei Lynnfield (nicht mit Nehalem vermischen, der hat Triple-Channel DDR3-1066). Vom Verhältnis her hat Clarkdale pro Kern allerdings immernoch mehr Bandbreite - wenn also 10-12GB bei Clarkdale limitieren würden, hätte Lynnfield bei unter 20-24GB/s die gleichen Probleme. Weder hat Lynnfield soviel Bandbreite noch scheint er davon limitiert. :)


Edit: Übrigens noch ein weiterer Punkt gegen die Cachetheorie: Man beachte den Athlon II X4, der mit gerade einmal 2MB summiertem L2 Cache und 4 Kernen zwar nicht berauschend, aber durchaus in einem üblichen Verhältnis zu den Phenom II X4 Modellen performt.

Ich bleibe bei der Vermutung: Entweder es ist irgendein spezifisches Problem mit dem i3 an sich (fehlende Optimierungen wie bei den i5/i7), oder aber das Spiel hängt extrem an der Speicherlatenz - hier steht Clarkdale sehr schlecht da.

[S940]

Dennoch aber schlägt Lynnfield Yorkfield und Conroe Clarkdale. Das ist nicht mit der Cachemenge zu begründen.

Wie bsagt, siehe oben.
Im Fall 1 hat man den üblichen Architekturvorteil, v.a. bei sovielen Threads, die miteinander agieren, wird der FSB zw. den beiden Wolfdale DIEs im Yorkfield qualem - der Nehalem tauscht dagegen über den L3 die Daten - das sind Welten ...
Für Fall 2, siehe oben, das liegt mMn an SMT, das mit 4 Threads die 4 MB Cache zum Überlaufen bringt, sodass der RAM abgefragt werden muss, der aber ausgerechnet beim Clarkdale schlecht angebunden ist.
Als Test dafür z.B. einfach mal den Gulftown auf 4 Kerne beschnitten testen. Ich werde versuchen, Werte für meinen 3MB Arrandale zu bekommen. Meine Vorhersage: Gulftown wird bei gleichem Takt und 50% mehr Cache kaum vor Lynnfield/Nehalem liegen. Ein 3MB Clarkdale wird nicht über den üblichen 5-10% hinter dem 4MB Vollausbau liegen.Teste erstmal den i3 mit und ohne SMT, das wäre einfacher ;-)
Beim Gulftown hast Du wieder das Problem, dass er Triple Channel hat, eventuell macht das auch den Löwenanteil des i7 970 Vorsprungs aus. Ein Vergleich zum Lynnfield wäre da dann etwas schräg. Da müßte man mal erst den i7 970 mit dual channel testen, um das auszuschließen ^^

Apropos:
@y33H:
Wieviel RAM braucht das Spiel ? Könnten die 6GB RAM vielleicht auch schon nen Vorteil bieten ? Naja beim CPU Bench wohl eher nicht, aber ich frag vorsichtshalber mal :)

Edit:
Nö, dass ergibt keinen Sinn. Auf einem Clarkdale ohne SMT laufen doch in der gleichen Anwendung nicht weniger Threads der Anwendung als bei einem Clarkdale mit SMT. Für die Cacheauslastung ist es völlig egal, ob wir das Spiel bei identischer Hardware auf zwei Threads oder 4 Threads pressen.
Hmm wie ? Ohne SMT laufen 2 Game Threads, mit laufen 4 ... was sonst ? Für die Cacheauslastung ist das nur egal, wenn der Cachebedarf der gleiche wäre ...

Edit: Übrigens noch ein weiterer Punkt gegen die Cachetheorie: Man beachte den Athlon II X4, der mit gerade einmal 2MB summiertem L2 Cache und 4 Kernen zwar nicht berauschend, aber durchaus in einem üblichen Verhältnis zu den Phenom II X4 Modellen performt.

Ich bleibe bei der Vermutung: Entweder es ist irgendein spezifisches Problem mit dem i3 an sich (fehlende Optimierungen wie bei den i5/i7), oder aber das Spiel hängt extrem an der Speicherlatenz - hier steht Clarkdale sehr schlecht da.
RAM Latenz könnte es auch sein, die spielt dann natürlich ne besonders große Rolle, wenn der L/L32 überläuft ;-)
Beim Propus ist auch noch interessant, dass der ja ne gute RAM Latenz hat, da der L3 fehlt.

Edit2:
Davon sprach ich doch. Lies nochmal oben nach. Real ist das, was hinten raus kommt - und das ist bei Dual-Channel DDR3-1333 weniger als bei Lynnfield (nicht mit Nehalem vermischen, der hat Triple-Channel DDR3-1066). Vom Verhältnis her hat Clarkdale pro Kern allerdings immernoch mehr Bandbreite - wenn also 10-12GB bei Clarkdale limitieren würden, hätte Lynnfield bei unter 20-24GB/s die gleichen Probleme. Weder hat Lynnfield soviel Bandbreite noch scheint er davon limitiert.
Gut wenn Du davon sprachst, i.O. Aber ich frag in Foren da immer gerne nach, da man nie sicher sein kann, was der Diskussionspartner jetzt für "real" hält ;-)
Zum Thema:
Die Bandbreite ist nur wichtig, wenn man sie braucht. Sehr gut möglich, dass bei den 8MB L3 Quads alles im L3 abläuft und die Speicherbandbreite somit total egal wäre. Du kannst nicht einfach die eine Größe (RAM BW) vergleichen, und die andere Größe (L3 Cache) unter den Tisch fallen lassen. Das ist alles miteinander vernetzt, verknüpft und voneinander abhängig ;-)

ciao

Alex

[Undertaker]

Wie bsagt, siehe oben.
Im Fall 1 hat man den üblichen Architekturvorteil, v.a. bei sovielen Threads, die miteinander agieren, wird der FSB zw. den beiden Wolfdale DIEs im Yorkfield qualem - der Nehalem tauscht dagegen über den L3 die Daten - das sind Welten ...

Siehe doch mal mein edit und betrachte den Propus. :) Der hat eine ähnliche Speicherbandbreite wie der Clarkdale, noch weniger Cache bei 4 physischen Kernen, und verliert dennoch nicht mehr Leistung als üblich auf Deneb - das widerlegt eine starke Cacheabhängigkeit von Ruse imho deutlichst.

Der einzige einleuchtende Nachteil wäre die hohe Speicherlatenz.

[y33H@]

@ S940

Nee, RAM-Menge fällt weg.

[Undertaker]

Übrigens, es gibt ja auf Steam eine Demo... Da könnte man doch hier glatt mal einen Benchthread eröffnen, falls sich eine passende Szene findet oder es auch hier einen integrierten Benchmark gibt.

[S940]

Siehe doch mal mein edit und betrachte den Propus. :)
Jo hab ich gemacht, siehe die obigen Edits.
Nochmal ausführlicher:
Der hat eine ähnliche Speicherbandbreite wie der Clarkdale, noch weniger Cache bei 4 physischen Kernen, und verliert dennoch nicht mehr Leistung als üblich auf Deneb - das widerlegt eine starke Cacheabhängigkeit von Ruse imho deutlichst.
Das widerlegt sie nur auf der AMD Architektur. Die Erkenntnis kannst Du jetzt aber nicht einfach auf die Intels übertragen. Da bist Du nur wieder in der Obstabteilung bei Äpfel und Birnen ...

Die L3 Cache Anbindung der AMDs ist lausig, deswegen fragte ich y33H ja nach L3 OC Tests ...
Bei Intel schaut das dagegen ganz anders aus, vergleich mal die Everest L3 Werte zw. Lynnfield und Phenom :freak:

Der einzige einleuchtende Nachteil wäre die hohe Speicherlatenz.Das kann ein Grund sein, aber als einzigen Exklusivgrund sehe ich das nicht an. Sooo toll waren die Core2 CPUs mit FSB doch auch nicht, oder ?

@y33H@:
Thx, alles klar.

Übrigens, es gibt ja auf Steam eine Demo... Da könnte man doch hier glatt mal einen Benchthread eröffnen, falls sich eine passende Szene findet oder es auch hier einen integrierten Benchmark gibt.
Wäre ich dafür ^^

[Undertaker]

Das widerlegt sie nur auf der AMD Architektur. Die Erkenntnis kannst Du jetzt aber nicht einfach auf die Intels übertragen.

Ich denke schon, dass das über entsprechende Vergleiche möglich ist. :) Es gibt einige Beispiele, wo Propus gegenüber Deneb sehr viel stärker zurückliegt - World in Conflict beispielsweise - wo Clarkdale aber dennoch recht gut liegt. Wir können sicher nicht die identische Cachelastigkeit zweier verschiedener Architekturen voraussetzen - wenn wir aber in anderen Situationen auf der einen Architektur eine sehr klare Abhängigkeit erkennen (WiC), können wir durchaus eine gewisse Abschätzung in Bezug auf die hier diskutierte Anwendung treffen. :)

Btw, Demo ist gerade fertig. Ich hoffe ich werde gleich mit Zahlen untermauern können, was ich hier momentan noch spekuliere. :)

[y33H@]

iirc hat die Demo den int. Benchmark nicht drin. Wäre unter "Extras" zu finden.

[S940]

iirc hat die Demo den int. Benchmark nicht drin. Wäre unter "Extras" zu finden.
Mann toll .. wieso den nicht ? Ist doch v.a. bei ner Demo wichtig, dass man weiss, wo sein System einzuordnen ist :( :(

Naja, lassen wir Undertaker mal suchen :)
Ich denke schon, dass das über entsprechende Vergleiche möglich ist. :)
Das geht mMn so gut wie immer schief, wenns mal klappt, dann liegts ganz sicher an was anderem bzw. ist Zufall :)

[Undertaker]

iirc hat die Demo den int. Benchmark nicht drin. Wäre unter "Extras" zu finden.

Leider korrekt. Man kann höchstens den Anfang der Mission mit Fraps benchen... Ich schau mal, ob etwas sinnvolles herauskommt und erstelle gfls. einen Thread im Benchmarkforum. :)

@S940: An Zufälle glaube ich nicht. Dafür war die Vergangenheit bisher zu eindeutig.

[S940]

@S940: An Zufälle glaube ich nicht. Dafür war die Vergangenheit bisher zu eindeutig.
Vergangenheit ? WiC ? Das ist nicht viel ;-)

[Undertaker]

Das war doch nur ein Beispiel. ;) Ganz im Gegenteil, ich kenne keinen einzigen Fall, wo sich eine zwischen Propus und Deneb manifestierte, starke Cachelastigkeit nicht auch bei anderen Architekturen widergespiegelt hätte. Und ich kenne wiederum ebenfalls keinen Fall, wo ein kleinerer oder auch gar fehlender L3 Cache auf einmal die fps mehr als halbiert hätte - in Relation zur Kernskalierung der anderen Probanden sollte der i3 eigentlich bei locker 30-35fps liegen.

Aber nun weg vom theoretischen Geplänkel zu den realen Eindrücken: Zunächst einmal ist der Anfang der Demomission nicht von übermäßiger Action geprägt, allerdings kenne ich auch nicht den Verlauf des Vollversion-Benchmarks. Mit Hilfe CPU-limitierter Settings, hierfür mussten allerdings einige GPU-lastige Details dran glauben, pendelte sich die Framerate auf 125-135fps auf dem X6 (3,5GHz) ein, 80-90fps auf dem i5 540M. OK, kann an der fehlenden Action liegen... Aber jetzt wirds interessant: Auf 2 Kerne beschnitten (weiterhin 3,5GHz) fällt der X6 auf ebenfalls 80-90fps...

Schade, dass ich keinen i3 zur Hand habe... Nicht das man wirklich nur für i5 und i7 Modelle spezielle Optimierungen greifen lässt.

@y33h@:

Stünde bei euch ein i5 661 o.ä. zur Verfügung? Und lässt sich das extrem schlechte Abschneiden des i3 auch bei Szenen im realen Spiel beobachten?

[y33H@]

Bei den ingame-Werten im 2 on 2 schneidet der i3 auch schlecht ab, ja. Ein 655er ist da.

[S940]

Das war doch nur ein Beispiel. ;) Ganz im Gegenteil, ich kenne keinen einzigen Fall, wo sich eine zwischen Propus und Deneb manifestierte, starke Cachelastigkeit nicht auch bei anderen Architekturen widergespiegelt hätte. Und ich kenne wiederum ebenfalls keinen Fall, wo ein kleinerer oder auch gar fehlender L3 Cache auf einmal die fps mehr als halbiert hätte - in Relation zur Kernskalierung der anderen Probanden sollte der i3 eigentlich bei locker 30-35fps liegen.

Naja, Deine "Fälle" kenne ich nicht, ich weiss nur, dass Du sehr gerne zur pauschalen Äpfel-Birnen Logik neigst ;-)
Abgesehen davon, im Konkreten Fall:
Bisher gabs auch noch kein Spiel, dass so dermaßen von vielen Threads und Cache profitierte ;-)

Aber nun weg vom theoretischen Geplänkel zu den realen Eindrücken: Zunächst einmal ist der Anfang der Demomission nicht von übermäßiger Action geprägt, allerdings kenne ich auch nicht den Verlauf des Vollversion-Benchmarks. Mit Hilfe CPU-limitierter Settings, hierfür mussten allerdings einige GPU-lastige Details dran glauben, pendelte sich die Framerate auf 125-135fps auf dem X6 (3,5GHz) ein, 80-90fps auf dem i5 540M. OK, kann an der fehlenden Action liegen... Aber jetzt wirds interessant: Auf 2 Kerne beschnitten (weiterhin 3,5GHz) fällt der X6 auf ebenfalls 80-90fps...
Und was ist nun mit HT On/off ? Oder kannst Du das nicht an/abstellen ?

Schade, dass ich keinen i3 zur Hand habe... Nicht das man wirklich nur für i5 und i7 Modelle spezielle Optimierungen greifen lässt.
Was für "spezielle" Optimierungen sollten das eigentlich sein ? Da bleibt eigentlich nur Cachegröße - so gesehen wären wir eigentlich einer Meinung :freak:

Stünde bei euch ein i5 661 o.ä. zur Verfügung? Und lässt sich das extrem schlechte Abschneiden des i3 auch bei Szenen im realen Spiel beobachten?Hmm, was willst Du jetzt mit dem ? Testen ob AES nen Einfluß macht ? :freak: Oder steh ich gerade auf dem Schlauch ?

[Undertaker]

Naja, Deine "Fälle" kenne ich nicht, ich weiss nur, dass Du sehr gerne zur pauschalen Äpfel-Birnen Logik neigst

Das meine ich eher bei dir zu beobachten. ;) Bleiben wir doch beim Thema. Zeig mir doch mal ein Beispiel, Architektur völlig egal, wo eine Halbierung des Caches einen derartigen Performancehit von wohl über 50% verursacht haben soll. Umso unglaubwürdiger wird es, wenn sich sowohl Core 2 als auch K10.5 hier kaum besonders cachelastig präsentieren - und nein, jetzt bitte nicht wieder von Äpfeln und Birnen anfangen. :) Wir wollen mit deren Werten keinen Quervergleich zwischen den Architekturen ziehen, sondern eine Aussage zu dem Spiel an sich treffen.


Bisher gabs auch noch kein Spiel, dass so dermaßen von vielen Threads und Cache profitierte ;-)

Tut es ja auch nicht, dass ist ja gerade der Witz. Rechne mal nach:

E6600, 2,4GHz
E8400, 3,0GHz (+25%), +28% Leistung - sehr unterdurchschnittlich

Die Cachelastigkeit von Ruse scheint mir sowohl was den Core 2, als auch was den K10.5 angeht, eher gering zu sein.


Was für "spezielle" Optimierungen sollten das eigentlich sein ? Da bleibt eigentlich nur Cachegröße - so gesehen wären wir eigentlich einer Meinung

Man kann wohl kaum auf eine bestimmte Cachegröße optimieren, da bist du in der falschen Abstraktionsebene. ;) Nun, wir wissen doch, wie "Optimierungen" in der Vergangenheit schon erfolgten: Über Abfrage von Hersteller oder CPU-Modell. Finde ich hier zwar auch sehr weit hergeholt, aber einen Test wäre es wert - auch um das Ergebnis des i3 gegenzutesten, es kann sich ja immer mal ein Problem einschleichen.

Ansonsten finde ich immernoch das Thema Speicherlatenz am interessantesten. Weil die Frage vorhin kam: Ja, da war der Core 2 sogar besser als der Clarkdale. Ein Bus ist latenztechnisch gar nicht mal schlecht (kein Routing).

SMT teste ich gleich, geht leider am Laptop nur indirekt (keine BIOS-Option, aber per Software-Kern-Deaktivierung sollte das auch klappen).

Edit: Ohne SMT verliert der i5 ~10% Leistung.

Bei den ingame-Werten im 2 on 2 schneidet der i3 auch schlecht ab, ja. Ein 655er ist da.

Der würde mich mal interessieren, nur um sicherzugehen. Ansonsten muss ich wohl warten, bis die Vollversion samt Benchmark draußen ist. Sollte der i5 genauso schlecht abschneiden, kann es in meinen Augen nur am latenzschwachen IMC des Clarkdale liegen.


Ich denke gemeinsam beschließen können wir folgendes: Hier ist irgendetwas sehr merkwürdig. :)

[S940]

Das meine ich eher bei dir zu beobachten.
So hat halt jeder seine Eindrücke .. ;-)
Bleiben wir doch beim Thema.Gerne :)
Zeig mir doch mal ein Beispiel, Architektur völlig egal, wo eine Halbierung des Caches einen derartigen Performancehit von wohl über 50% verursacht haben soll.
Ist das jetzt das Thraed-Thema ?
Muss nachfragen, will ja nicht, dass ein Mod sonst böse wird :D
Falls ja:
So läuft das nicht, Du hast pauschal behauptet dass man oft von AMD -> Intel schließen könne, ich hab das pauschal angezweifelt. Wenn ich Dir jetzt was zeigen soll, müßtest Du erstmal Deine Fälle konkretisieren.

Umso unglaubwürdiger wird es, wenn sich sowohl Core 2 als auch K10.5 hier kaum besonders cachelastig präsentieren - und nein, jetzt bitte nicht wieder von Äpfeln und Birnen anfangen. :)
HMm, siehst Du irgendwo nen Core2 mit weniger als 4MB L2 im Test ? Ich nicht ... von was redest Du ?

Wir wollen mit deren Werten keinen quervergleich zwischen den Architekturen ziehen, sondern eine Aussage zu dem Spiel an sich treffen. Können wir sehr gerne machen, ich hab keine Quervergleiche von AMD -> Intel gemacht, das war jemand anders ;-) Wenn dieser jemand das in Zukunft unterläßt, trauere ich dem nicht nach :)


Bisher gabs auch noch kein Spiel, dass so dermaßen von vielen Threads und Cache profitierte ;-)
Tut es ja auch nicht, dass ist ja gerade der Witz. Rechne mal nach:

E6600, 2,4GHz
E8400, 3,0GHz (+25%), +28% Leistung - sehr unterdurchschnittlich
Ähhh ... willst Du mir jetzt vorrechnen, dass das Spiel *nicht* cachelastig ist, da zwischen ner 2Thread CPU mit 4 und 6 MB Cache nicht viel Unterschied ist ? Das zeigt nur, dass ein Core2 mit 4 MB L2 genügend Cache hat, dir restlichen +3% können auch schon vom höherem FSB des E8xxx kommen.
Die Cachelastigkeit von Ruse scheint mir sowohl was den Core 2, als auch was den K10.5 angeht, eher gering zu sein.
HMmm
Ph2 955 3,2 GHz: 27 / 32,4 fps
X4 635 2,9 Ghz: 21 / 24,8 fps

Mehrtakt: +10%
Min SpeedUp: +28,5%
AVG SpeedUp: +30,6%

Ich sehe da ne deutliche Cachelastigkeit bei den K10s, Du nicht ?
Ist halt ein kleiner Unterschied, ob man zw. 0 und 6 MB oder zw. 4 und 6 MB vergleicht ;-)



Man kann wohl kaum auf eine bestimmte Cachegröße optimieren, da bist du in der falschen Abstraktionsebene. ;)
Nö, da bist Du eher auf dem Holzweg ;-)
Cacheoptimierungen sind durchaus möglich, nachdem Intel da seine Assembler GSG9 Truppe zu Eugen schickte, die es sogar fertig gebracht haben, dass die Engine auf 6 Kerne / 12 Threads skalieren, ist sogar stark davon auszugehen.

Ansonsten finde ich immernoch das Thema Speicherlatenz am interessantesten. Weil die Frage vorhin kam: Ja, da war der Core 2 sogar besser als der Clarkdale. Ein Bus ist latenztechnisch gar nicht mal schlecht (kein Routing).
Hmm ok gut, hätte ich jetzt nicht gedacht, dass Clarkdale selbst gegen die Chipsatz Kontroller abloost. Prinzipiell ist der Aufbau doch der gleiche, der Unterschied ist nur der, dass der Clarkdale IMC mit 2 Ghz Uncore Takt läuft, der Chipsatz aber nur mit 500 Mhz oder was das damals war. Viel Unterschied sollte es auf alle Fälle nicht sein, oder wie schauts mit den absoluten Zahlen aus ?

SMT teste ich gleich, geht leider am Laptop nur indirekt (keine BIOS-Option, aber per Software-Kern-Deaktivierung sollte das auch klappen).Uhh . hab ich jetzt auch Kopfschmerzen bei, da die Hyperthreading Hardware Teile noch aktiviert bleiben. Vielleicht bremst auch da irgendwie was beim Cachezugriff oder es gibts sonst irgendwelche kursiosen Seiteneffekte. Aber nun gut, solange man nix anderes hat - was soll man machen. Für den Fall, dass es nur die Cachegröße ist, sollte es eigentlich ausreichen.

Aber solange Du nicht das gleiche testet wie PCGH sagt das eigentlich auch wieder nix aus. Kann ja sein, dass Deine Szene jetzt problemlos auf dem i3 läuft egal ob mit/ohne SMT :(

Da wären wir nur wieder bei den Äpfel / Birnen, diesmal im Bezug auf unterschiedliche Szenen.

Edit:
Edit: Ohne SMT verliert der i5 ~10% Leistung.
Also ~70-80 fps ? Tja .. damit weiss man nun, dass SMT in der Szene was bringt, wies in PCGHs benchmarkszene aussehen würde weiss man leider nicht :(

Sollte der i5 genauso schlecht abschneiden, kann es in meinen Augen nur am latenzschwachen IMC des Clarkdale liegen.Ähh .. ein I5 655/661 ist auch ein Clarkdale mit der gleichen latenz. Da hatte ich schon oben gefragt, was Du damit testen willst ? Oder willst Du Uncore übertakten ?

Ich denke gemeinsam beschließen können wir folgendes: Hier ist irgendetwas sehr merkwürdig.
Das muss man nicht beschließen, das war von Anfang an klar ;-)

ciao

Alex

[Undertaker]

Ich kürze die Sache jetzt mal ab: Ich glaube, du hast vom Einfluss eines Caches nicht ganz korrekte Vorstellungen: Es gibt nicht "die" Cachegröße, ab deren Erreichen weitere Profite praktisch ausbleiben, bzw. ab deren Unterschreitung die Performance schlagartig zusammenbricht: Ein Cache ist performancebeeinflussend, aber nicht begrenzend/limitierend. Da gab es schon in der Vergangenheit schöne Benchmarks dazu (bei Interesse PN).

Insofern fällt auch die darauf aufbauende Argumentation zusammen. :)

Warten wir doch mal die Full und mit dieser hoffentlich folgende weitere Benchmarks ab. Hier sind wir in der Tat mittlerweile zu weit vom Thema entfernt, da bin ich auch nicht unschuldig. ;)

[S940]

Ich kürze die Sache jetzt mal ab: Ich glaube, du hast vom Einfluss eines Caches nicht ganz korrekte Vorstellungen: Es gibt nicht "die" Cachegröße, ab deren Erreichen weitere Profite praktisch ausbleiben, bzw. ab deren Unterschreitung die Performance schlagartig zusammenbricht: Ein Cache ist performancebeeinflussend, aber nicht begrenzend/limitierend. Da gab es schon in der Vergangenheit schöne Benchmarks dazu (bei Interesse PN).

Ich glaube eher, dass Du keine Ahnung von Cache Optimierung hast, les mal das Intel Opt. Handbuch durch:

Punkt 3.6.10
Locality Enhancement:
(...)
Locality enhancement to the last level cache can be accomplished with sequencing the data access pattern to take advantage of hardware prefetching. This can also take several forms:
(...)
• Optimal tile size and shape selection can further improve temporal data locality by increasing hit rates into the last level cache and reduce memory traffic resulting from the actions of hardware prefetching (see Section 7.6.11, “Hardware Prefetching and Cache Blocking Techniques”)
(...)
User/Source Coding Rule 10. (H impact, H generality) Optimization
techniques such as blocking, loop interchange, loop skewing, and packing are best done by the compiler. Optimize data structures either to fit in one-half of the first-level cache or in the second-level cache; turn on loop optimizations in the compiler to enhance locality for nested loops. Optimizing for one-half of the first-level cache will bring the greatest performance benefit in terms of cycle-cost per data access. If one-half of the first-level cache is too small to be practical, optimize for the second-level cache. Optimizing for a point in between (for example, for the entire first-level cache) will likely not bring a substantial improvement over optimizing for the second-level cache.http://www.intel.com/assets/pdf/manual/248966.pdf

Ich glaub kaum, dass Du benchmarks hast, bei denen unterschiedliche Binaries auf unterschiedliche Cachegrößen optimiert sind ... falls doch, gerne ne PM.

Insofern fällt auch die darauf aufbauende Argumentation zusammen. :)Wenn das, was Du behauptest der Wahrheit entspräche, ja :)

Warten wir doch mal die Full und mit dieser hoffentlich folgende weitere Benchmarks ab. Hier sind wir in der Tat mittlerweile zu weit vom Thema entfernt, da bin ich auch nicht unschuldig. ;)
Jo, lassen wirs, Licht ins Dunkel könnte im Moment nur y33H mit weiteren Tests bringen.

Ansonsten Danke für Deinen Test, besser als nichts, allemal :)

[Undertaker]

Dann sind wir uns ja einig, beide keine Ahnung zu haben. :D Aber ich demonstriere mal das übliche Verhalten verschiedener Cachegrößen:

http://www.pcgameshardware.de/aid,663616/Intel-Core-2-Sieben-CPUs-im-Cache-Test/CPU/Test/?page=5

Wie man erkennt, gibt es keinen abrupten Punkt, an dem auf einmal die Performance total in den Keller geht, vielmehr entsteht ein "fließender" Verlauf. Auf welche Cachegröße soll hier optimiert wurden sein? ;)

[S940]

Ich demonstriere mal das übliche Verhalten verschiedener Cachegrößen:

http://www.pcgameshardware.de/aid,663616/Intel-Core-2-Sieben-CPUs-im-Cache-Test/CPU/Test/?page=5

Wie man erkennt, gibt es keinen abrupten Punkt, an dem auf einmal die Performance total in den Keller geht, vielmehr entsteht ein "fließender" Verlauf. Auf welche Cachegröße soll hier optimiert wurden sein? ;)
Da demonstrierst Du leider nur wieder Mangel an Detailwissen und Deine bekannte Neigung zu vorschnellen Schlußfolgerungen.

Da sinkt nicht nur die Cachegröße, sondern auch die Cacheassoziativität.

Sehr gut möglich, dass der Benchmark mit gleicher Assoziativität bei allen unterschiedlichen Cachegrößen keinen Unteschied zeigen würde :freak:
Abgesehen davon - wer sagt denn, dass das Spiel überhaupt auf Cachegröße optimiert wurde ? War bei Grid ebenfalls die Intel Mannschaft am Coding-Ball ?

Abgesehen davon hast Du diesmal keinen Äpfel-Birnen Vergleich, es sind alles S775 CPUs mit gleicher Infrastruktur - ausdrückliches Lob.

Blöderweise gings beim Clarkdale Thema aber gerade ja um einen Äpfel-Birnen Vergleich, eben wegen des IMCs Unterschied zw. Lynnfield/Nehalem und Clarkdale. Ein Cache Miss ist beim Clarkdale deshalb viel teurer, weswegen es da durchaus zu überproportionalen Einbrüchen kommen kann. Ist ja auch nicht das erste Mal, dass der Kleine so abloost, Starcraft2 war ja auch schon nicht das Gelbe vom Ei. Das Spiel ist bekanntermaßen Cachelastig -> zuviele Misses bei nur 4 MB -> RAM Zugriff -> *bäh*
In dem Fall wären wir wieder auf einer Linie, Du sagst ja selbst, dass es die RAM Latenz sein kann, das sag ich auch, nur vor dem Hintergrund, dass das wg. der Cache Misses besonders wichtig ist ;-)

Was man auch nicht vergessen darf:
Der Cache ist zwar jeweils gleich groß, aber die 4MB eines Core2 haben nur 14-15Takte Latenz, die 4MB L3 der 1156er CPUs dagegen ~30.

Ich spekuliere da jetzt mal,dass Ruse auf den last Level Cache optimiert wurde, sodass der kleine, schnelle L2 nicht viel bringt. Wobei die Optimierungen mit der ganzen Datenobjekten pro Thread erfolgen muss, da müßte man jetzt Internas Wissen, wie die Obj. verwaltet/erzeugt werden, um Genaueres sagen zu können.

ciao

Alex

[mironicus]

Ah... Intel-optimiert! Man hörte ja schon abenteuerliches was z.B. Intel-Compiler machen, wenn ein Nicht-Intel-Prozessor vom Programm erkannt wird... :)

Der Unterschied zwischen i5/i7 zu den Core2Quad ist aber auch schon enorm.

[Undertaker]

@S940:

Das hat nichts mit Optimierungen zu tun: Nochmal, deine Vorstellung bzgl. der Arbeitsweise eines Caches und diesbzgl. Optimierungen halte ich für höchst abenteuerlich ;) Das Performancebild ist für ein Ansprechen auf die Cachemenge absolut atypisch, denn nocheinmal:

"Wie man erkennt, gibt es keinen abrupten Punkt, an dem auf einmal die Performance total in den Keller geht, vielmehr entsteht ein "fließender" Verlauf."

Das gilt übrigens genauso für Starcraft. ;)

Ich ziehe bei RUSE ganz bewusst auch andere Architekturen wie den Propus heran, der sichtlich problemlos mit seinen 2MB L2 + L3 auskommt. Und natürlich können wir hier Quervergleiche ziehen: Ohne das dieser aufeinmal mit übernatürlichen Prefetching-Fähigkeiten brilliert, wird er wohl kaum einen geringeren Cachebedarf als die Core i Architektur zeigen. Ganz anders hingegen, sobald wir über Hauptspeicherzugriffe reden:

http://www.hardwarecanucks.com/forum/hardware-canucks-reviews/31521-intel-core-i3-540-clarkdale-lga1156-processor-review-7.html

Die Latenz ist ein riesen Pferdefuß. Nicht die 4MB L3, gerade bei einem leistungsfähigen Prefetcher.

OT: Ich würde mich übrigens über freundlichere Umgangsformen freuen. Sich gegenseitig die Kompetenz anzuzweifeln hilft uns nicht, die Ursache zu ergründen. ;)

Was spricht denn für dich gegen das Latenzthema?

[y33H@]

@ mironicus

In GTA4 schlägt ein Lynnfield einen Yorkfield bei gleichem Takt auch um über 50% ;)

[S940]

Das hat nichts mit Optimierungen zu tun: Nochmal, deine Vorstellung bzgl. der Arbeitsweise eines Caches und diesbzgl. Optimierungen halte ich für höchst abenteuerlich ;) Das Performancebild ist für ein Ansprechen auf die Cachemenge absolut atypisch, denn nocheinmal:
Sieht dazu oben meinen Link zum Intel Opt. Handbuch.


"Wie man erkennt, gibt es keinen abrupten Punkt, an dem auf einmal die Performance total in den Keller geht, vielmehr entsteht ein "fließender" Verlauf."
Siehe dazu oben meinen Hinweis, dass der Bench Deines Beispieles durchaus nicht auf eine bestimmte Cachegrüße optimiert sein kann.

Ich ziehe bei RUSE ganz bewusst auch andere Architekturen wie den Propus heran, der sichtlich problemlos mit seinen 2MB L2 + L3 auskommt. *kopfweh*
Ich zitiere mich selbst:

Ph2 955 3,2 GHz: 27 / 32,4 fps
X4 635 2,9 Ghz: 21 / 24,8 fps

Mehrtakt: +10%
Min SpeedUp: +28,5%
AVG SpeedUp: +30,6%
Problemlos ?


OT: Ich würde mich übrigens über freundlichere Umgangsformen freuen. Sich gegenseitig die Kompetenz anzuzweifeln hilft uns nicht, die Ursache zu ergründen. ;)Du - ich hab ne Engelsgeduld, aber Du hast eine Sturheit, die selbst mir den Rest gibt. Bestes Beispiel oben. Du schreibst stur von "nochmal, nocheinmal, nochmal", ohne auf meine Links auch nur einzugehen. Hej ich hab Dir einen Auszug aus dem offiziellen Intel Optimierungshandbuch zititiert, indem von Cacheoptimierungen die Rede ist. Darauf gehst Du aber NULL ein, wiederholst stattdessen nur stupide Deinen alten Standpunkt.

Das Selbe in grün mit den Propus <> Phenom2 Vergleich. Du schreibst, der Propus schlägt sich "gut" ohne L3 ich rechne Dir vor, dass da taktbereinigt 20% Unterschied sind, und was ist das Resultat ? Du redest im nächsten Posting wieder vom "problemlosen Abschneiden des Propus im Vergleich zum Ph2 :freak:

Das ist keine Diskussion mit Dir, das ist ein Reden gegen die Wand.

Wenn Du diskutieren willst, dann bemängle sehr gerne die Intel Anweisungen ansich, oder aber spekuliere darüber, wieso sich das Intel Entwickler Team, dass zu Ruse geschickt wurde, sich nicht daran halten sollte. Oder - beim Propos <>Phneom2 Thema - bemängle meine Rechnung, rechne selbst, oder such irgendnen anderen Grund weswegen der Ph2 +20% besser abschneidet. Dagegen hätte wirklich keiner was.

Aber einfach seinen alten Standpunkt zu wiederholen ist ne dreiste Mischung aus Sturheit und Ignoranz. Und ja - da bleibe ich nicht mehr ruhig. Wenn Du Dich da jetzt auch noch beschwerst ist das nur noch das i Tüpfelchen.
Was spricht denn für dich gegen das Latenzthema?
Hab ich ebenfalls schon mal behandelt:
In dem Fall wären wir wieder auf einer Linie, Du sagst ja selbst, dass es die RAM Latenz sein kann, das sag ich auch, nur vor dem Hintergrund, dass das wg. der Cache Misses besonders wichtig ist ;-)

Nochmal im Langformat:
Eigentlich reden wir vom Gleichen. Wenn die Daten zu groß für L2/L2 werden, müssen sie aus dem L3/RAM kommen, und dann hast Du mit dem Latenzthema durchaus recht.

Vermutlich ist das sogar der Grund, wieso der Core2 so gut abscheidet, da sein L2 deutlich schneller ist als der L3 des Clarkdales. Der kleine Vorteil der Core2 bei der RAM Latenz reicht nicht um den Vorsprung eines lausigen C2D mit 500 MHz weniger Takt zu erklären. Vermutlich hat der wegen FSB266 nichtmal ne bessere RAM Latenz.

Wie besagt, war schon mal erwähnt - ne Antwort darauf gabs von Dir da auch nicht, stattdessen fragst Du mich jetzt zum 2ten Mal ... :freak:

Auch für Moderatoren gilt die goldene Regel: Erst lesen dann schreiben. Ein "verstehen" dazwischen wäre ebenfalls nicht verkehrt. Falls das nicht möglich ist - dann nachfragen, wies gemeint war. Hab ich im Falle der "realen" Speicherbandbreite gemacht, da kam ne Antwort von Dir - dann war alles klar.

In diesem Sinne schönen Tag

Alex

[Undertaker]

Mein letzter Versuch, wenn du dann wieder nur mit persönlichen Angriffen kommst, bin ich hier raus. :)

Also: Ich habe bereits mehrfach erwähnt: Das Performancebild ist folgendes, der i3 ist grob um die Hälfte zu langsam. Jetzt setzen betrachten wir uns wieder den Athlon II X4: 20% Performancenachteil zu einem Phenom II sind sehr viel weniger als in vielen anderen Fällen - ich erwähnte beispielsweise WiC, wo Athlon II und Phenom II über 30% im CPU-Limit trennen - und das sogar bei den Dualcoremodellen, wo der Regor-Kern zusätzlich auf den doppelten L2-Cache zurückgreifen kann. Quelle (http://www.computerbase.de/artikel/prozessoren/2009/kurztest-was-bringt-bei-amd-der-l3-cache/2/#abschnitt_test).

Aus diesen Eindrücken ziehe ich den Schluss: RUSE als Spiel erscheint mir nicht sonderlich cachelastig. Das zeigt sich auch an anderer Stellen: Die 12MB L3 von Gulftown bringen takt- und kernzahlbereinigt offensichtlich ziemlich wenig (wenn die Cachehitrate bei 8MB bereits perfekt wäre, würde sie mit 4MB noch lange nicht ins bodenlose fallen), der alte 9950BE hat - im Gegensatz zu anderen und somit offensichtlich cachelastigeren Fällen - einen sehr großen Rückstand auf den L3-losen Athlon II X4 635: ~25% bei 11% Taktnachteil um genau zu sein, in vielen anderen Spielen herrscht hingegen Gleichstand der Leistung pro Takt.

-> Ruse zeigt sich ganz und gar nicht cachelastig. In anderen Szenarien, die z.B. durch eine höhere Differenz zwischen Athlon II und Phenom II auf eine höhere Cachelastigkeit deuten, schlägt sich Clarkdale mal besser, mal schlechter - aber fällt eigentlich nirgends hinter einen Core 2 Duo gleicher Taktrate. Das passt nicht zusammen.

Ohne weitere verwertbare Zahlen ist das Thema damit für mich durch.

[S940]

Mein letzter Versuch, wenn du dann wieder nur mit persönlichen Angriffen kommst, bin ich hier raus. :)
Solange Du nicht mit destruktiven "Nochmal" Triaden mein Nervenkostüm strapazierst, sonder artig und gesittet argumentierst besteht dazu keine Gefahr :)

Also: Ich habe bereits mehrfach erwähnt: Das Performancebild ist folgendes, der i3 ist grob um die Hälfte zu langsam. Jetzt setzen betrachten wir uns wieder den Athlon II X4: 20% Performancenachteil zu einem Phenom II sind sehr viel weniger als in vielen anderen Fällen - ich erwähnte beispielsweise WiC, wo Athlon II und Phenom II über 30% im CPU-Limit trennen - und das sogar bei den Dualcoremodellen, wo der Regor-Kern zusätzlich auf den doppelten L2-Cache zurückgreifen kann. Quelle (http://www.computerbase.de/artikel/prozessoren/2009/kurztest-was-bringt-bei-amd-der-l3-cache/2/#abschnitt_test).
Ok, also Du bezeichnest jetzt 10% SpeedUp-Unterschied bei 2 Spielen als "sehr viel weniger als in vielen anderen Fällen".

Da muss ich leider wieder Kontra geben, so darfst Du nicht verallgemeinern, WiC ist nur ein einziger Fall. Es genügt, aus Deinem verlinkten Test den nächstbesten Test zu nehmen, da sind es dann deutlich weniger. Nimm z.B. FarCry2 ... da sinds nur ein paar Pünktchen. Die Belastbarkeit der Argumentation ist damit sehr, sehr dünn, da Du das "sehr viel weniger" nur auf ein einziges Spiel beziehst. Genauso unsinnig wäre es jetzt einfach nur FC2 herzunehmen, und von einer astronomischen Cacheabhängigkeit zu fabulieren.

Abgesehen davon:schau mal auf die Auflösung:
Ruse: 1680x1050;
WiC 800x600
Da gibts sicherlich schon ein paar kleine GPU Limits. @800x600 wären eventuell sogar bei Ruse Deine +30% drin.

Wenn ich verallgemeinern würde, dann würde ich einen Durchschnittstest mehrer Spiele nehmen. Den gibts sogar bei CB, unter "Performancerating Spiele".
Da sind es 5% Unterschied. Sagen wir mal ein 512kB Prozessor verlöre nochmal 5%, dann sinds immernoch "nur" 10%. Ruses SpeedUp von +20% ist demzufolge zumindest als "überdurchschnittlich" einzuorden - wenn man CBs Spiele Mix als Vergleichsbasis nimmt.

Aus diesen Eindrücken ziehe ich den Schluss: RUSE als Spiel erscheint mir nicht sonderlich cachelastig.
Tja - siehe oben. Als WiC Sicht und ohne Beachtung der Auflösungen kann man das mit etwas Bauchweh gerade noch stehen lassen. Aus FC2/CB-Spiele Rating Sicht und Berücksichtigung der Auflösungen aber ganz sicher nicht.

Da Deiner Argumentation damit die Basis entzogen ist, fällt sie in sich zusammen.:)

Falls Du einen oder gar mehrere Fehler bei meinen Argumenten findest, dann kannst Du den/die gerne posten und mich darauf hinweisen.

Falls Du z.B. konkret Links zu Deinen eingangs erwähnten "vielen anderen Fällen" hast, dann her damit. Belastbarer Input ist immer gut, dünne Pauschalaussagen auf wackligen Fundamenten dagegen nicht.

ciao

Alex

[Undertaker]

Also jetzt wird deine Argumentation aber sehr wackelig: RUSE ist bei 25-30fps der X4 noch "teils GPU-limitiert" - ein 980X liegt bei ~65fps, da sind GPU-Limitierungen bei <30fps Probanden wohl zu vernachlässigen - als Vergleich für den Cache ziehst du aber den Durchschnitt des mehr als CPU-limitierten 1680x1050 CB-Ratings heran? Also komm... Wir reden hier auch ganz und gar nicht von Durchschnittswerten, sondern Ausnahmefällen, die solche Einbrüche verursachen können.

Zunächst wollen wir doch wissen, ob RUSE wirklich, wie von dir behauptet, konkurrenzlos cachelastig ist, dass es zu einem bisher nie dagewesenen Einbrechen des Clarkdale mit immerhin 4MB L3 kommen kann. Ergo: Die ~20% durch den L3 Cache beim K10.5 müssten weit über dem liegen, was wir sonst überhaupt irgendwo finden können - da reicht das WiC Beispiel also eigentlich schon locker aus. Im gleichen Test findest du z.B. auch CoH (26% Differenz), dass reicht für das erste locker - RUSE ist schoneinmal definitiv nicht das cachelastigste Spiel, was wir bisher so hatten. Und dennoch liegt der Clarkdale so schlecht wie sonst nirgends.

Ganz im Gegenteil würde ich mir jetzt eher mal von dir ein paar Fakten wünschen: Selbst wenn 8MB Cache der optimale Fall für das Spiel bzw. genau diese Szene wären, Cache misses praktisch bei null lägen, fällt die hit rate bei Halbierung dieser Größe nicht auf einmal völlig in den Keller. Ob vom theoretischen worst case (50% miss) praktisch vielleicht 80% oder 90% verbleiben - tjo, dass können wir so sicherlich nicht genau sagen. Was wir sagen können: Die misses würden mit weiter sinkender Cachegröße exponentiell steigen, ein Propus mit nur noch 2MB müsste bei identischem Prefetcher also völlig untergehen. Das tut er bei nur 20% Differenz zum Modell mit 6MB L3 definitiv nicht, und gleichwertige Prefetching-Fähigkeiten sind sicherlich auch etwas optimistisch vorausgesetzt.
Jetzt erbitte ich mir mal von dir zwei Beispiele (so viele hab ich mit WiC und CoH auch gerade gebracht ;)), wo eine Cachereduzierung ähnlicher Größenordnung zu einem ähnlichen Leistungseinbruch von ~50% geführt hätte. Dabei kannst du ganz ausdrücklich auch gerne auf den Core 2 zurückgreifen, der durch die sinkende Assoziativität zusätzlich gehandicapt ist - aber selbst da wären mir keine entsprechenden Fälle bekannt.

Wie wäre es denn eigentlich mal mit ein paar Argumenten pro der ganzen Cachetheorie? :) Eigentlich geht es ja darum, eine begründete Aussage aufzustellen, anstatt etwas zu behaupten und andere zur Widerlegung aufzufordern. ;) Bei nur einem einzigen Messwert diskutieren wir hier generell auf einer sehr wackeligen Basis. Die gleiche Szene wie die PCGH konnte ich in der Demo ja leider nicht vergleichen, aber mein dortiges Ergebnis - 3,5GHz Phenom II X2 ~ 2,8GHz Clarkdale (3MB L3!) inkl. SMT - wäre zumindest in einer deutlich glaubhafteren Größenordnung. Clarkdale immernoch vergleichsweise schwach durch den schlechten IMC und den weiter verkleinerten Cache, aber in einem auch im Vergleich zu anderen Spielen sehr viel realistischeren Bereich.

Hat denn vielleicht mittlerweile auch eine andere Seite bereits Benches durchgeführt?

[S940]

Also jetzt wird deine Argumentation aber sehr wackelig: RUSE ist bei 25-30fps der X4 noch "teils GPU-limitiert" - ein 980X liegt bei ~65fps, da sind GPU-Limitierungen bei <30fps Probanden wohl zu vernachlässigen -

Akzeptiert, wenn der 980X 30 fps schneller ist, kanns mit GPU Limits nicht allzuweit her sein. Damit ziehe ich das Argument zurück - es bleiben aber halt noch ein paar ... ;-)

als Vergleich für den Cache ziehst du aber den Durchschnitt des mehr als CPU-limitierten 1680x1050 CB-Ratings heran? Also komm... Wir reden hier auch ganz und gar nicht von Durchschnittswerten, sondern Ausnahmefällen, die solche Einbrüche verursachen können.

Öhm also ... Mißverständnis ?
Im Test, den Du verlinkt hast gehts ausschließlich um 800x und 1280x, wenn cb dann im selben Test ein "Performancerating Spiele" kalkulieren, dann geh ich davon aus, dass das auf den durchgeführten Test basiert.
Wenns auf komplett anderen 1680er Test basieren würde, wär es doch komplett sinnlos :freak:



Zunächst wollen wir doch wissen, ob RUSE wirklich, wie von dir behauptet, konkurrenzlos cachelastig ist,
Jetzt übertreib mal bitte nicht, von konkurrenzlos cachelasting hab ich nie was geschrieben, ich schrieb oben doch von "überdurchschnittlich".

Im Gegenteil, solche sinnlosen, krassen Pauschalaussagen hab ich sogar ausgeschlossen:
Genauso unsinnig wäre es jetzt einfach nur FC2 herzunehmen, und von einer astronomischen Cacheabhängigkeit zu fabulieren. Da muss ich mich wirklich fragen, wieso Du mir jetzt solche Extrempositionswörter in den Mund legst ... was soll das ? Gib mal bitte eine Erklärung dazu ab - ich hätte es gerne sachlich, Du auch ?

dass es zu einem bisher nie dagewesenen Einbrechen des Clarkdale mit immerhin 4MB L3 kommen kann. Ergo: Die ~20% durch den L3 Cache beim K10.5 müssten weit über dem liegen, was wir sonst überhaupt irgendwo finden können
Müssen sie nicht, denn der K10 hat 4 Kerne. Da fallen die Worker Jobs kleiner aus, d.h. der L3 Cache SpeedUp wird geringer.

Das ist bei stark multi threaded Apps doch immer so:
Pro: Kleinere Datenpakete pro Thread -> kleinere Caches reichen pro Job
Contra: erhöhter Synchronisationsaufwand -> steigender InterCore Traffic

Das ist auch der Grund wieso die C2Q so schlecht abschneiden, zwar haben die 4 Kerne und dicke Caches, aber der InterCore Traffic per FSB macht alles Plus zunichte.

Dem i3 nützt das alles nichts, die 2 oder 4 SMT Work Jobs sind für den L2 viel zu groß, der L3 ist langsamer als der L2 der C2D, und der RAM ist nicht viel besser angebunden.


Selbst wenn 8MB Cache der optimale Fall für das Spiel bzw. genau diese Szene wären, Cache misses praktisch bei null lägen, fällt die hit rate bei Halbierung dieser Größe nicht auf einmal völlig in den Keller.Nö, die Hit Rate im i3 L3 und im C2D L2 sind sicherlich gleich, aber die Zugriffszeit auf L3 und L2 ist halt "etwas" unterschiedlich, das fällt ins Gewicht, *wenn* die L2 Hitrate des i3 unterirdisch ist, was der Fall sein dürfte ...

Bei den Quads mit den 8 MB sind die zerteilten Jobs dagegen so klein, das es wahrscheinlich schon gute HitRaten im kleinen L2 gibt und/oder die Prefetcher kommen besser mit, erst recht dann beim 980X.

Wie wäre es denn eigentlich mal mit ein paar Argumenten pro der ganzen Cachetheorie? :) Eigentlich geht es ja darum, eine begründete Aussage aufzustellen, anstatt etwas zu behaupten und andere zur Widerlegung aufzufordern. ;)
*Zustimm* Aber man sollte dem Gegenüber durchaus Fehler mitteilen ;-)
Bei nur einem einzigen Messwert diskutieren wir hier generell auf einer sehr wackeligen Basis.
Ebenfalls *Zustimm* vielleicht wars ja nur ein kurioser Fehler in der Szene :freak:

Hat denn vielleicht mittlerweile auch eine andere Seite bereits Benches durchgeführt?Nicht das ich wüßte ... hab mich aber auch nicht wirklich umgeschaut.

[Undertaker]

Jetzt übertreib mal bitte nicht, von konkurrenzlos cachelasting hab ich nie was geschrieben, ich schrieb oben doch von "überdurchschnittlich".

Das würde doch aber nicht unsere Werte erklären. Wie bereits gesagt: Es gibt kein mir bekanntes Spiel, in dem der Clarkdale auch nur annähernd so schlecht liegt. Wir müssten, um die Sache auf die Caches zu schieben, also eine geradezu extrem, konkurrenzlos und einmalige Cachelastigkeit haben. Und genau die haben wir eben nicht. Diese überdeutlichen Formulierungen sind dabei mit voller Absicht gewählt - denn auch die Auswirkungen sind ja offensichtlich extrem. :)

Dem i3 nützt das alles nichts, die 2 oder 4 SMT Work Jobs sind für den L2 viel zu groß, der L3 ist langsamer als der L2 der C2D, und der RAM ist nicht viel besser angebunden.

Gleiches Thema wie beim L3: Das passt nicht in das Performancebild. Wenn der L2 hier das Zünglein an der Waage wäre, würde man dies auch bei den nur mit der doppelten Menge ausgestatteten i5/i7 sehen. So gut, wie SMT auf Lynnfield skaliert und i5/i7 auch absolut performen, reichen die 4x256kB auch für 8 Threads mehr als locker aus. Selbst wenn 2x256kB auf dem 4-Thread Clarkdale nicht mehr optimal wären, führt das nicht zu einem solch krassen Performance-Hit - wie gesagt, der i3 530 sollte bei grob der doppelten Framerate liegen. Klar steigen Cache-Misses an, aber das verläuft in einer sehr viel flacheren Kurve - Gegenbeispiele erwünscht, ich fragte bereits letztes Posting danach. Übrigens auch nach den allgemeinen Pro-Argumenten der Cache-Geschichte, bitte mal noch nachreichen. :)

[S940]

Das würde doch aber nicht unsere Werte erklären.
Jetzt hast Du mich wieder abgehängt, welche Werte denn ?
Es stehen nachwievor die +20% im Raum, egal ob die jetzt super viel, fantastisch, fanatisch oder grottig genannt wären, es sind +20%.
Vielleicht wirds deutlicher wenn mans in Taktfrequenz umrechnet, das wären bei 3 GHz +600Mhz. Das ist mMn kein Kleinvieh was man mal einfach schnell unter den Tisch kehren könnte.
Wenn Du das machen willst - ok. Wenn Du auf dem Standpunkt zementiert bleibst, erübrigt sich eine Diskussion.

Wie bereits gesagt: Es gibt kein mir bekanntes Spiel, in dem der Clarkdale auch nur annähernd so schlecht liegt.
Gabs bisher denn ein Spiel, bei dem der Intel 6Kern soooo gut lag ?
Das Spiel ist in jeder Hinsicht ein Novum, alte Denkmuster passen da nicht mehr.

Wir müssten, um die Sache auf die Caches zu schieben, also eine geradezu extrem, konkurrenzlos und einmalige Cachelastigkeit haben. Und genau die haben wir eben nicht.
Doch die gibts, nur nicht da wo Du schaust, nämlich beim Core i3, aber eben nicht beim Phenom2/Propus ;-)

Erklärung - ich kopier mal wieder, bin ich langsam ja schon gewohnt :freak:
Das ist bei stark multi threaded Apps doch immer so:
Pro: Kleinere Datenpakete pro Thread -> kleinere Caches reichen pro Job
Contra: erhöhter Synchronisationsaufwand -> steigender InterCore Traffic


Diese überdeutlichen Formulierungen sind dabei mit voller Absicht gewählt - denn auch die Auswirkungen sind ja offensichtlich extrem. :)
Du kannst - solange es fair und themenbezogen bleibt - gerne formulieren wie Du lustig bist, hier hast Du mir aber das Wort im Mund verdreht:
wie von dir behauptet, konkurrenzlos cachelastig ist,
und das ist weder in Ordnung noch entspricht es gepflegtem Diskussionsstil.


Gleiches Thema wie beim L3: Das passt nicht in das Performancebild. Wenn der L2 hier das Zünglein an der Waage wäre, würde man dies auch bei den nur mit der doppelten Menge ausgestatteten i5/i7 sehen.
Nein, denn der i5/i7 läuft ja mit 4 Threads, d.h. die jeweiligen Work Jobs sind kleiner, da die Arbeit besser aufgeteilt werden kann. Das musst Du bedenken.

So gut, wie SMT auf Lynnfield skaliert und i5/i7 auch absolut performen, reichen die 4x256kB auch für 8 Threads mehr als locker aus.
Jo, so siehts aus.

Selbst wenn 2x256kB auf dem 4-Thread Clarkdale nicht mehr optimal wären, führt das nicht zu einem solch krassen Performance-Hit
Tja tuts aber. Meine Begründung ist eben zuviel L2 Trashing -> steigender L3 und RAM Bedarf.

Klar steigen Cache-Misses an, aber das verläuft in einer sehr viel flacheren Kurve
Bisher - bei den 2-3-4 Thread Geschichten, vielleicht aber jetzt ... *urks*

Gegenbeispiele erwünscht, ich fragte bereits letztes Posting danach. Übrigens auch nach den allgemeinen Pro-Argumenten der Cache-Geschichte, bitte mal noch nachreichen. :)
Tja Gegenfrage:
Welches ultra-multithreaded Spiel gibts/gabs denn bisher ? Da gibts nur ein einziges - und das dann auch nur bei einer bestimmten Szene:
Das legendäre Anno 1404 im CB Test ;D

Zumindest mit y33H war ich mir da schon mal einig, dass das nur am großen L2 Cache der Phenoms liegen kann, dass die AMDs dort besser sind, ansonsten ist bei den modernen Intel CPUs ja wirklich alles besser.

Und zufälligerweise loost da auch der i3 im Vergleich zum alten E8400 um 24-28% ab:
http://www.computerbase.de/artikel/prozessoren/2010/test-intel-core-i5-760/17/

Sicherlich ein Spezialbeispiel, aber mehr Beispiele gibts nicht - einfach deswegen, da es bisher keine großartig mutithreaded Spiele gab - erst recht nicht mit Intel Programmierbeteiligung ;-)

Wie besagt, von alten Denkmustern lösen - the future is fusion - äh multithreaded :biggrin:

Mit alten Spielekamellen kommst Du da nicht weiter.

ciao

Alex

[Undertaker]

Jetzt hast Du mich wieder abgehängt, welche Werte denn ?

Na die extrem schlechten des Clarkdale. ;)

Gabs bisher denn ein Spiel, bei dem der Intel 6Kern soooo gut lag ?

Wir reden doch von Cachelastigkeit, nicht Kernskalierung - ganz andere Baustelle.

Doch die gibts, nur nicht da wo Du schaust, nämlich beim Core i3, aber eben nicht beim Phenom2/Propus

Du kannst doch nicht den diskutierten Fall mit sich selbst erklären. :freak: Und wenn die Cachelastigkeit bei Ruse auf anderen CPUs - K10.5, Core 2 - geringer ist als in anderen Spielen ist die Begründung, sie übersteigt bei Clarkdale alles bisher dagewesene, nicht schlüssig.

Nein, denn der i5/i7 läuft ja mit 4 Threads, d.h. die jeweiligen Work Jobs sind kleiner, da die Arbeit besser aufgeteilt werden kann. Das musst Du bedenken.

Tja tuts aber. Meine Begründung ist eben zuviel L2 Trashing -> steigender L3 und RAM Bedarf.

Der i7 860 hat doppelt so viele Threads und die doppelten L2 und L3 Menge. Und bitte keine basta-Argumentation "Tja tuts aber": Eine Halbierung der Cachemenge lässt die Missrate je nach Prefetcher und Anwendungsfall um ein paar Prozentpunkte sinken - aber definitiv nicht so krass. Und das hat mit der Threadzahl direkt erstmal nichts zu tun, sondern nur mit der Datenmenge und dem Zugriffsmuster. Wenn das nicht völlig zufällig ist, federt der Prefetcher den Großteil des kleineren Caches ab, die fps sinken um die üblichen Prozentwerte. Z.B. genau das, was bei Deneb->Propus passiert, hier sogar in geringerem Maße als in anderen Fällen.



Welches ultra-multithreaded Spiel gibts/gabs denn bisher ? Da gibts nur ein einziges - und das dann auch nur bei einer bestimmten Szene:
Das legendäre Anno 1404 im CB Test

Warum die CB-Szene? Die ist von den absoluten fps sogar schneller als die von Behardware, die war die anspruchsvollste aller Tests bisher. Anno skalierte allerdings weder bei BH noch bei CB über 6 Kerne.


Und zufälligerweise loost da auch der i3 im Vergleich zum alten E8400 um 24-28% ab:
http://www.computerbase.de/artikel/prozessoren/2010/test-intel-core-i5-760/17/

Ah, jetzt haben wir doch mal ein schönes Beispiel: Schau dir deinen Benchmark mal genauer an, der i5 661 soll 36% schneller sein als der i3 530. Hmm komisch, was? ;) Ist bei dem der L2 jetzt auf einmal kein Problem?

Ich weiß schon, warum ich den Werten hier bisher zweifle, sie passen einfach nicht zusammen - und bei nur einem Wert sind Zweifel durchaus angebracht. Nochmal zusammengefasst:

1. Das Spiel zeigt auf allen getesteten Architekturen keine außergewöhnliche Cachelastigkeit, die einen außergewöhnlichen Einbruch erklären würde.
2. Würde der Clarkdale am Cache völlig verhungern, wären auch z.B. i7 860 oder X4 635 davon betroffen. Das ist definitiv nicht der Fall.
3. Ich starte mal die dritte Nachfrage, was denn Pro der Cachetheorie spricht. Das momentan nix anderes einfällt, lasse ich nicht gelten. ;)

[Der HeinZ]

Undertaker und S940 Ähm .. wieso fragt ihr nicht Intel? Die werden doch am besten wissen, warum der i3 so enorm abstinkt und garkeinen Vorteil gegenüber core 2 hat, oder irre ich mich?
Für mich sind diese Unterschiede schon sehr ungewöhnlich groß, und das spiegelt ja nun wirklich nicht den alltag in der Spielewelt wieder.
Und wenn die Speicher Latenz soooo einen großen Einfluss hätte, dann müßtest du doch bei dem Lynnfield einfach mal die latenzen am Speicher anpacken und nach oben ziehen und den Takt total wegnehmen. Vielleicht gibt es ja noch einen großen Unterschied zwischen den beiden, den ihr nicht seht oder gar sehen könnt....
Gruss Matthias

[Undertaker]

Am besten wäre es ja, wenn y33h@ mal noch den i5 661 auspacken könnte... Das CB in Anno zwischen i3 und i5 auch eine unerklärbar große Differenz gemessen hat (THX S940 für den Link), bestärkt mich darin nur. Mit dem könnten wir gleich zwei Fliegen mit einer Klappe schlagen:

1. Zweiter Messwert eines Clarkdale zur Absicherung eines Messfehlers
2. Mögliche Anomalie zwischen i3/i5 Clarkdale?

Zumindest theoretisch wäre es ja denkbar (nichtsdestotrotz äußerst merkwürdig), dass nur für i5/i7 spezielle Optimierungen aktiviert werden, wenn Intel hier schon höchstpersönlich mit an der Erstellung herumgepfuscht hat. ;)

Das würde auch erklären, warum mein Clarkdale, der übrigens nochmals um 1MB L3 reduziert ist (aber ein i5 ist), ein durchaus passenderes Leistungsbild abliefert.

[Der HeinZ]

Und der Phenom I ?
Rechne ich den auf Athlon64-II X4 19,8/2,6*2,9= 22 Frames, 2 Frames weniger trotz Level 3 Cache.
Rechne ich den auf 965er hoch, 25 Frames. 7 Frames weniger (ist ja in der realität meist noch weniger)
Bis auf den L3 Cache gibt es hier keinen Unterschied. Irre ich mich?
Athlon64-II = kein Cache Level 3
Phenom I = 2 MB
Phenom II = 6 MB
Also ist doch auch hier etwas merkwürdig, okay nicht großartig, aber immerhin sichtbar.
Gruss Matthias

[Undertaker]

Der Phenom I ist schon in ein paar Punkten langsamer als der Phenom II, das geht nicht nur auf den Cache zurück. Man kann aber durchaus relative Vergleiche ziehen: Der Phenom I ist in vielen Spielen pro-MHz etwa ähnlich schnell wie der Athlon II ohne L3. In RUSE allerdings deutlich schlechter, was ebenfalls zeigt, dass es hier keine übermäßige Cachelastigkeit zu geben scheint.

[S940]

Na die extrem schlechten des Clarkdale. ;)
Achso, dann sag das doch. Ich war verwirrt, da Du das im Zusammenhang auf mein Zitat brachtest:
Zitat von S940 http://www.forum-3dcenter.org/vbulletin/images/3dc/insanedruid/buttons/viewpost.gif (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=8259358#post8259358)
Jetzt übertreib mal bitte nicht, von konkurrenzlos cachelasting hab ich nie was geschrieben, ich schrieb oben doch von "überdurchschnittlich".
Was sich wiederum aber auf meine Phenom2 Rechnerei bezog. Von daher war der bezug auf Clarkdale nicht wirklich klar ...


Wir reden doch von Cachelastigkeit, nicht Kernskalierung - ganz andere Baustelle.Aua, Aua, Aua .... nein EBEN nicht. Was versuch ich Dir denn seit 2 Seiten zu erklären ? Liest Dus nicht, kapierst Dus wirklich nicht oder willst Du mich nur ärgern ?
Schon in meinem ersten Posting schrieb ich:
Nö, denn Du darfst die Punkte nicht aufdröseln, sonder musst sie im Zusammenhang betrachten.
SMT bringt <in dem speziellen Fall> möglicherweise nur dann was, wenn der Cache groß genug ist. Ist er beim i3 aber nicht ergo -> großes FAIL, da sich die 4 Threads die die Daten gegenseitig aus dem kleinen 256kB L2 bzw. dem 4MB L3 kegeln.
Der i5 760 hat damit kein Problem, der hat a) echte 4Kerne und b) den vollen Cache, dass der Q9550 dann wg. der schlechteren FSB Arch. verliert ist nur logisch. Der E6600 hat dagegen nur 2 Threads, die anscheinend von der Menge her auch noch schön in den 4MB L2 Cache passen.
Bin mir ziemlich sicher, dass SMT dem i3 wg. Cache Trashing in Verbund mit der schlechteren RAM Anbindung das Genick bricht, aber Genaues würden nur Tests bringen.

Dann der zweite Versuch hier:

Das ist bei stark multi threaded Apps doch immer so:
Pro: Kleinere Datenpakete pro Thread -> kleinere Caches reichen pro Job
Contra: erhöhter Synchronisationsaufwand -> steigender InterCore Traffic

Das ist auch der Grund wieso die C2Q so schlecht abschneiden, zwar haben die 4 Kerne und dicke Caches, aber der InterCore Traffic per FSB macht alles Plus zunichte.

Dem i3 nützt das alles nichts, die 2 oder 4 SMT Work Jobs sind für den L2 viel zu groß, der L3 ist langsamer als der L2 der C2D, und der RAM ist nicht viel besser angebunden.
Jetzt zum Dritten mal, ich hoffe es kommt an:

Wenn Du ein Problem auf mehrere Teile zerlegst, sinkt das Datenaufkommen pro Teil - bitte im nächsten Posting ausdrücklich auf diese Aussage eingehen, akzeptieren, oder mit Begründung ablehnen. Hab ehrlich gesagt keine Lust nochmal 2 Seiten für nichts herumzuschreiben.

Weitere Erklärung: Es macht nen kleinen Unterschied für die jeweilige Cachelast und auch die Prefetcher, ob auf einem einzigen Kern 5 Gegner KIs, die Wasser/Wellen/Wettersimulation und das Rendering läuft, oder ob jede KI bei nem 6Kerner exklusiv einen Privatkern/thread zugewießen bekommt.

Du kannst doch nicht den diskutierten Fall mit sich selbst erklären. :freak: Und wenn die Cachelastigkeit bei Ruse auf anderen CPUs - K10.5, Core 2 - geringer ist als in anderen Spielen ist die Begründung, sie übersteigt bei Clarkdale alles bisher dagewesene, nicht schlüssig.Siehe oben - die Cachelastigkeit pro Kern ändert sich logischerweise, sobald mehr Kerne zur Verfügung stehen, die auch genutzt werden. Beim K10.5 gibts nur Quad Werte - die darfst Du aber nicht mit Dual Werten vergleichen. Hab ich auch schon ein paar mal erwähnt, wurde aber bisher immer erfolgreich ignoriert ... :rolleyes:

Der i7 860 hat doppelt so viele Threads und die doppelten L2 und L3 Menge. Und bitte keine basta-Argumentation "Tja tuts aber": Lol, erstmal - ja der i7 860 hat doppelt soviele Threads, und doppelte L2/L3 Menge - darauf können wir uns einigen :biggrin:
Aber dann gehts wieder los .. was willst Du mit dem "Basta" ??
Eine Basta Argumentation zeichnet sich dadurch aus, dass man *Ohne* Begründung "Basta-mag ich nicht" sagt. Ich dagegen kanns begründen, das ist kein trotziges, Kindergarten "Basta", das ist einfach so. Du mußt es akzeptieren, ob es Dir passt oder nicht. Die Meßwerte sind so wie sie sind. Wenn sowas für Dich "Basta" ist, bin ich der falsche Ansprechpartner, da müßtest Du Dich bei bei y33H@ über die Testwerte beschweren :freak:

Eine Halbierung der Cachemenge lässt die Missrate je nach Prefetcher und Anwendungsfall um ein paar Prozentpunkte sinken - aber definitiv nicht so krass.Schaumal nochmal oben .. bei nur 2 Prefetchern und 4 Threads mit ner Menge an KI, Render und Simulationsjobs, bin ich mir ziemlich sicher, dass die i3 Prefetcher da nicht mehr durchblicken, das ist zu komplex.
Oder ums mit Deinen Worten zu sagen: Ja die Zugriffe sind verdammt zufällig, da in einem Zugriff ne Anforderung der KI1 an Speicherstelle X kommt, als nächstes ne Anforderung der KI1 an Y, dann will ein Renderthread ne Speicherstelle Z haben, dann KI5 wieder nen anderen Brocken ... zusammenhangslos ..

Läuft dagegen nichtsoviel auf einem Kern, dann blickt der Prefetcher da sicherlich noch durch.

Und das hat mit der Threadzahl direkt erstmal nichts zu tun, sondern nur mit der Datenmenge und dem Zugriffsmuster.Da sind wir wieder beim Eingangsargument: Selbstverständlich hat die Datenmenge was mit der Threadanzahl zu tun ... Geh bitte mal darauf ein, oder lehne das Argument mit Begründung ab.

Warum die CB-Szene? Die ist von den absoluten fps sogar schneller als die von Behardware, die war die anspruchsvollste aller Tests bisher. Anno skalierte allerdings weder bei BH noch bei CB über 6 Kerne.
Weil sie anscheinend die Cachelastigste ist .. darum gings doch von Anfang an.

Ah, jetzt haben wir doch mal ein schönes Beispiel: Schau dir deinen Benchmark mal genauer an, der i5 661 soll 36% schneller sein als der i3 530. Hmm komisch, was? ;) Ist bei dem der L2 jetzt auf einmal kein Problem?
Hehehe, ich habe gehofft, dass Dir das auffällt - ist schon ein dicker Unterschied, nicht wahr ?
Bei Anandtech steht die Erklärung:
Intel says that all Clarkdale Core i5s use the same 2.40GHz uncore clock, while the i3s run it at 2.13GHz and the Clarkdale Pentiums run it at 2.0GHz.http://www.anandtech.com/show/2901/2
Inklusive Turbomode taktet der 661 die Kerne ~18% höher als der i3, die restlichen ~18% kommen somit vom höherem L3 Takt - es ist nunmal ne cachelastige Szene ;-)

Ich weiß schon, warum ich den Werten hier bisher zweifle, sie passen einfach nicht zusammen -Solange Du keine Brille aufsetzt, siehst Du natürlich nichts :cool:
und bei nur einem Wert sind Zweifel durchaus angebracht. Das stimmt, absolute Zustimmung .. hab letztens nochmal gegoogelt .. aber ausser BETA Handbüchern für RUSE nix gefunden :(

1. Das Spiel zeigt auf allen getesteten Architekturen keine außergewöhnliche Cachelastigkeit, die einen außergewöhnlichen Einbruch erklären würde.Wie schon gefühlte 10x geschrieben: Da übersiehst Du die Abhängigkeit der Cachelast von der Kern/Threadanzahl.

2. Würde der Clarkdale am Cache völlig verhungern, wären auch z.B. i7 860 oder X4 635 davon betroffen. Das ist definitiv nicht der Fall.Selber Punkt wie oben, auf Quads können die Workerjobs schon ausreichend gut verteilt werden, sodass sich die Daten nicht groß in die Quere kommen.
3. Ich starte mal die dritte Nachfrage, was denn Pro der Cachetheorie spricht. Das momentan nix anderes einfällt, lasse ich nicht gelten. ;)Ich warte schon Seit letzter Seite auf ein Feedback deinerseits zum Kern/Threadanzahl <> Cachelast Zusammenhang. Basta Aussagen wie "ganz andere Baustelle" ohne Begründung lasse ich ebenfalls nicht gelten :D

@Der HeinZ:
Wenn Du nen Kontakt bei Intel hast, der sich für das Problem interssieren würde - gib Bescheid ^^

Schönes WE

Alex

[Undertaker]

Ich denke, das Thema beenden wir hier. Bei solchen Theorien:


Inklusive Turbomode taktet der 661 die Kerne ~18% höher als der i3, die restlichen ~18% kommen somit vom höherem L3 Takt - es ist nunmal ne cachelastige Szene ;-)

Brauchen wir denke ich nicht weiter zu reden. Die Leistungssteigerung kann maximal so groß sein, wie die am stärksten angehobene Taktrate, aber doch nicht summiert. :freak: Du nimmst dir eine Wasserleitung, verdoppelst an jeweils zwei Stellen die Querschnittsfläche und denkst, dass du in irgendeinem Fall die 4-fache Wassermenge durchbekommst - das ist hochgradiger Unfug. ;)

Es kann der Kerntakt limitieren, es kann die Speicher- oder L3-Anbindung limitieren, auch beides zusammen - aber es sind keine unabhängig voneinander arbeitenden Komponenten, deren Leistungsgewinne addiert werden können.

[Der HeinZ]

Der Phenom I ist schon in ein paar Punkten langsamer als der Phenom II, das geht nicht nur auf den Cache zurück. Man kann aber durchaus relative Vergleiche ziehen: Der Phenom I ist in vielen Spielen pro-MHz etwa ähnlich schnell wie der Athlon II ohne L3. In RUSE allerdings deutlich schlechter, was ebenfalls zeigt, dass es hier keine übermäßige Cachelastigkeit zu geben scheint.
Abgesehen von dem Level 3, dem DDR2 only Controller und dem höheren Takt kenne ich keine unterschiede. Beide laufen doch mit HT 2000 und NB auf 2000 bzw. 1800 oder? Die Befehlssätze sind doch auch identisch. Wahrscheinlich werden die Athlon64-II als auch die Phenom 2 Modelle mit DDR3 Speicher betrieben und der Phenom I mit ddr2-800er, das könnte unterschiede erklären. Aufjedenfall ist dieses Spiel mal interessant von den Benchmarks her!
Bin auf Bulldozer gespannt. und ebenfalls fänd ich x2 und Athlon64-II X2 werte interessant, da es die ja jeweils mit 1 mb und 512 KB Cache gibt.
Gruss Matthias

[S940]

Ich denke, das Thema beenden wir hier.
Bin ich dafür, Du hast gerade bewiesen, dass Du wirklich 0 Ahnung hast :)

Noch ne schöne Zeit,

Alex

[Captain Future]

Haben wir eigentlich alle Daten beisammen?
Wie sind denn die Cache-Latenzen von i5, i7 und i3? Die haben sich bei dem PCGH-Test ja ziemlich unterschieden …


Gleiches Thema wie beim L3: Das passt nicht in das Performancebild. Wenn der L2 hier das Zünglein an der Waage wäre, würde man dies auch bei den nur mit der doppelten Menge ausgestatteten i5/i7 sehen. So gut, wie SMT auf Lynnfield skaliert und i5/i7 auch absolut performen, reichen die 4x256kB auch für 8 Threads mehr als locker aus.
Es gibt noch eine andere mögliche Erklärung: die kompletten Caches laufen hinten und vorn über. Das würde das Latenzproblem des i3 durchaus verschärfen und auch den krassen Vorsprung der Sechskerner erklären können, die einfach mehr Bandbreite haben - zusätzlich zu ihrem Mehr an Kernen und Cache.

Ruse bräuchte dafür gar nichtmal so sehr Sechskernoptimiert zu sein, was ich mir aus folgendem Grund auch nicht vorstellen kann: Für Sandy-Bridge plant Intel erstmal nur Vierkerner im Desktop. Die will man sicherlich nicht unnötig schlecht aussehen lassen. Dagegen spräche allerdings die (taktbereinigt) bessere Skalierung von vier auf sechs Kerne bei AMD.

Völlig unberücksichtigt gelassen wurde bisher auch der L1-Cache beim i/A-Vergleich.

[Undertaker]

@S940: Vorsicht, Glashaus unso. Über deine Theorie, dass 18% höherer Takt und eine 13% schnellere L3 Anbindung die Leistung um 36% erhöhen, solltest du nochmal ganz genau nachdenken. ;) Kleiner Tipp: Was passiert, wenn ich eine 20% schnellere CPU mit einer 20% schnelleren Grafikkarte kombiniere? Nein, die fps steigen nicht um 40%, ganz im Gegenteil, sie steigen um maximal 20%. Einzelne Steigerungen darfst du nur zusammenrechnen (und zwar multiplizieren!), wenn sie vollkommen unabhängig(!!!) voneinander die Performance steigern können: Z.B. Kerntakt und Kernzahl.

Das ist bei L3-Geschwindigkeit und Kerntakt nicht der Fall. Der Kerntakt skaliert nur so lange unbeeinflusst, wie (u.a.) die Cacheanbindung nicht zur Bremse wird. Ein höherer L3-Takt skaliert nur so lange, wie (u.a.) die Rechenleistung der CPU nicht limitiert. Wenn wir den Referenztakt um 20% erhöhen und damit den L1, den L2, den L3, den Kerntakt und den Speichertakt um 20% übertakten, wird die Leistung auch nicht um 100% steigen können, sondern maximal um genau 20%. (Grundlast-Beeinflussungen selbstverständlich außen vor).

Meine letzte Erklärung zu dem Thema, weitere werde ich mir bei deinem Ton der letzten Postings sparen.

Dagegen spräche allerdings die (taktbereinigt) bessere Skalierung von vier auf sechs Kerne bei AMD.

Ich tippe mal, dass die 970/980X so langsam ins GPU-Limit rutschen.

Zum Thema Cache: Bandbreite und Latenz des L1, L2 und L3 nehmen sich bei i3-i7 nichts, bei gleicher Taktrate. Bei LGA1156 haben die i5 und i7 allerdings afair 2,4GHz Uncore, die i3 2,13GHz, also ~13% Vorsprung für i5/i7. Das ist sicherlich leistungsbeeinflussend, haut allerdings von der Größenordnung auch nicht wirklich hin.

Abgesehen von dem Level 3, dem DDR2 only Controller und dem höheren Takt kenne ich keine unterschiede. Beide laufen doch mit HT 2000 und NB auf 2000 bzw. 1800 oder?

Es gibt ein paar IPC-Tweaks, die mal mehr, mal weniger durchschlagen:

http://www.firingsquad.com/hardware/amd_phenom_2_940_performance/images/p2.jpg
http://www.firingsquad.com/hardware/amd_phenom_2_940_performance/