IPC-Vergleich - Yorkfield vs Nehalem in Spielen (Split aus Ivy Bridge) [Archiv]

dargo

2011-08-01, 19:00:29

Bitte verlinkt doch nicht immer diesen Unsinn von CB & Co. Ich krieg immer die Kriese wenn ich diese Links sehe. Erstens muss der Reviewer wissen was er da überhaupt bencht. Und da habe ich selbst heute noch bei 99,xx% der CPU-Tests in Games meine Zweifel wenn ich sehe wie man da ran geht.

Schau dir einfach mal meine beiden Tests mit RE5 an. Einmal mit Yorkfield Q9550 und einmal mit i5-750.
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=6973305&postcount=2

Nimmst du noch den SMT-Vorteil eines i7 ist der Nehalem durchaus in der Lage die Frames eines Yorkfield bei gleicher Taktrate in etwa zu verdoppeln. SMT gehört bei mir ebenso zur höheren IPC weil die CPU besser ausgelastet wird.

Edit:
Ich kann mich immer nur wiederholen - reale Spielszenen haben nichts mit irgendwelchen intergrierten Benchmarks @Timedemos gemeinsam. Die tatsächliche CPU-Last ist Ingame wesentlich höher.

Edit 2:
Zusammengefasst bedeutet das folgendes - beide CPUs im vollständigen CPU-Limit:

Q9550 @2,83Ghz (8,5x 333Mhz FSB, Speicher @333Mhz) = 92,30fps
i5-750 @1,74Ghz (13x 133,8 BCLK, Speicher @535Mhz) = 104,25fps

Hochgerechnet bedeutet dies, dass der i5-750 mit 2,83Ghz 170fps erreichen würde, sprich +84% gegenüber Yorkfield und 2,83Ghz.

WEGA

2011-08-01, 20:44:09

füher war bei CB auch ein Phenom2 schneller als ein i7 ...

y33H@

2011-08-01, 21:00:06

Das hätte ich gerne mal als Link. Ein Phenom II X4 ist nicht schneller als jedweder Core i7 - selbst der 920er ist idR schneller.

dildo4u

2011-08-01, 21:10:21

Das hätte ich gerne mal als Link. Ein Phenom II X4 ist nicht schneller als jedweder Core i7 - selbst der 920er ist idR schneller.
Er meint wohl den berüchtigten Anno Bench bei CB.Über das Gesamte Rating siehts natürlich anders aus.

http://www.computerbase.de/artikel/prozessoren/2010/test-amd-phenom-ii-x6-1100t-black-edition/17/#abschnitt_anno_1404

y33H@

2011-08-01, 21:16:03

CB hat den Anno-Bench mit mehreren Szenen widerlegt und nutzt ihn nicht mehr ;)

dildo4u

2011-08-01, 21:18:00

Jo ihr und hardware.fr kommen da auf andere Ergebnisse.

http://www.hardware.fr/articles/778-13/anno-1404.html

http://www.pcgameshardware.de/aid,813007/Core-i7-990X-im-Test-Intels-neues-Flaggschiff/CPU/Test/

Nightspider

2011-08-01, 22:31:21

Q9550 @2,83Ghz (8,5x 333Mhz FSB, Speicher @333Mhz) = 92,30fps
i5-750 @1,74Ghz (13x 133,8 BCLK, Speicher @535Mhz) = 104,25fps

Hochgerechnet bedeutet dies, dass der i5-750 mit 2,83Ghz 170fps erreichen würde, sprich +84% gegenüber Yorkfield und 2,83Ghz.

Ja toll, in einem einzigen Spiel, das von 6 Kernen profitiert.

Nur weil in einem Gothic 4 Sandy bis zu 36% schneller ist als ein Nehalem bedeutet das nicht, das alle Games auch nur annähernd so stark profitieren.

Andere Games haben teils kaum von Nehalem profitiert. Und wenn SMT nur in der extremen Minderheit der Games überhaupt genutzt wird, kannst du das nicht zur IPC Leistung dazuzählen. Erst recht nicht nur von einem Game.

Genauso ist Sandy teils 35% schneller, teils nur genauso schnell wie ein Nehalem.
Da würde ich sehr vorsichtig sein aber meiner Meinung nach stimmt es nicht im gerinsten, das Nehalem 80-100% mehr Leistung als ein Yorkfield bietet.

Dann wäre AMD schon längst Pleite gewesen. :wink:

dargo

2011-08-01, 22:53:55

Ja toll, in einem einzigen Spiel, das von 6 Kernen profitiert.

:facepalm:

Hast du nur ansatzweise irgendwas von hier verstanden?
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=8863293&postcount=308

Es ist im Prinzip ganz einfach. Nehalem/Lynnfield/Sandy Bridge können sich erst in Games extrem vom Kentsfield/Yorkfield absetzen wenn die Engine mindestens mit 3 Cores perfekt skaliert. Optimalfall ist es wenn die Engine perfekt mit 4 Cores skaliert. Ich habe dir außer RE5 DIRT3 genannt. Dazu kannst du gleich Crysis 2 nehmen. Je besser eine Engine mit mehr als 2 Cores skaliert umso stärker liegt der doppelte Dualcore zurück. Eine ganz einfache und plausible Rechnung wenn man mal die einzelnen Architekturen kennt.

Nightspider

2011-08-01, 23:10:59

:facepalm:

Hast du nur ansatzweise irgendwas von hier verstanden?
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=8863293&postcount=308

Es ist im Prinzip ganz einfach. Nehalem/Lynnfield/Sandy Bridge können sich erst in Games extrem vom Kentsfield/Yorkfield absetzen wenn die Engine mindestens mit 3 Cores perfekt skaliert. Optimalfall ist es wenn die Engine perfekt mit 4 Cores skaliert. Ich habe dir außer RE5 DIRT3 genannt. Dazu kannst du gleich Crysis 2 nehmen. Je besser eine Engine mit mehr als 2 Cores skaliert umso stärker liegt der doppelte Dualcore zurück. Eine ganz einfache und plausible Rechnung wenn man mal die einzelnen Architekturen kennt.

Ich habe alles verstanden was du gesagt hast aber ich schau mir dein alten Post an:

Wie schon y33H@ angeführt hat... wenn man in gpu-limitierten Szenen testet kann nur Blödsinn dabei rauskommen. Die IPC ist bei Nehalem im Vergleich zum Yorkfield in Games (sie müssen natürlich sehr gut mit Quads skalieren) um ~80% höher. Beim gleichen Takt wohlgemerkt. Ein Sandy Bridge kommt da in den Bereich +~100%.

Dirt3 und Crysis 2(nutzt das überhaupt 6Kerne?) nutzen 6 Kerne aber wie stark ist dort der IPC Vorteil der Architektur, SMT bereinigt?

Das wären 3(!!!!!!) Games und du schreibst es so, als wären 80% der Durchschnitt! Selbst SMT bereinigt sind das vielleicht nur 50% mehr Leistung in einer Extremsituation eines Spiel, das stark von der Architektur profitiert. Andere Games können vielleicht kaum darauf anspringen.

Zumal es Games gibt, die einfach kaum am FSB des Yorkfield Dual-DualCores limitieren.

Nimmst du dir ein aktuelles Spiel, das nur 2 Kerne nutzt ist der Vorteil der IPC Leistung vom Nehalem auf einmal nurnoch 30 statt 80% oder wie?

Ich rechne jedenfalls immer mit Durchschnittswerten und solche übertrieben Leistungsschübe, die Intel und AMD manchmal für kleinere Architekturupdates angeben braucht doch keiner.

Glaube hier im Forum herrscht eher die Meinung, das Nehalem +10-15% mehr Leistung zu Yorkfield brachte, SMT bereinigt und diese Angabe ist imho auch korrekt.

Deswegen ist deine Aussage mit dem 80% einfach FALSCH, wenn du sie nicht eingeschränkt äußerst.

Edit:

Deswegen sind die Angaben von Computerbase auch realistischer, als was du da behauptest. Bei +80 oder 100% (Sandy) hätte jeder seine alte CPU so schnell entsorgt, das noch heute eine Knappheit an Nehalem herrschen müsste.
Solche extremsituationen, die du dir da rausgesucht hast, wie in RE5 verzerren nunmal das Bild. Der Durschnitt ist wichtig, das ist überall so.
Und meistens wird das in den Tests bei Computerbase und PCGH auch richtig beschrieben. Ich weiß also nicht, was du so auf Computerbase rumhackst.

dargo

2011-08-02, 07:08:49

Dirt3 und Crysis 2(nutzt das überhaupt 6Kerne?) nutzen 6 Kerne aber wie stark ist dort der IPC Vorteil der Architektur, SMT bereinigt?

Ob beide Spiele 6 Kerne sehr gut auslasten können kann ich dir nicht sagen weil ich einfach keinen Sechskerner für Tests habe. Ich könnte es mir aber gut vorstellen, dass 5 oder 6 Kerne noch paar Prozent bringen weil ein Vierkerner perfekt gegenüber einem Zweikerner skaliert. Noch einen Tick besser als in RE5.

Das wären 3(!!!!!!) Games und du schreibst es so, als wären 80% der Durchschnitt!

Wo habe ich geschrieben es wäre der Durchschnitt? Der Durchschnitt interessiert mich überhaupt nicht. Die wichtigste Voraussetzung ist erstmal, dass die Gameengines perfekt mit 4 Cores und mehr skalieren. Erst dann kann der native Quadcore von Intel zeigen was in ihm steckt, ist doch völlig logisch. Wenn ein Game nur 2 Cores nutzt dann ist natürlich der Vorsprung von einem Nehalem im Vergleich zum Yorkfield nicht so extrem wie wenn die Engine 4 Cores auslastet. Ganz einfach weil der FSB erst bei größer 2 Cores extrem limitiert. Wohl gemerkt in Games und nicht in synthetischen Benchmarks.

Selbst SMT bereinigt sind das vielleicht nur 50% mehr Leistung in einer Extremsituation eines Spiel, das stark von der Architektur profitiert. Andere Games können vielleicht kaum darauf anspringen.

Was heißt hier vielleicht? Weißt du es oder vermutest du es nur? Nochmal... lastet ein Game 4 Cores oder mehr perfekt aus sieht die Kentsfield/Yorkfield Architektur kein Land gegen einen Nehalem/Sandy Bridge.

Zumal es Games gibt, die einfach kaum am FSB des Yorkfield Dual-DualCores limitieren.

Siehe oben...

Nimmst du dir ein aktuelles Spiel, das nur 2 Kerne nutzt ist der Vorteil der IPC Leistung vom Nehalem auf einmal nurnoch 30 statt 80% oder wie?

Richtig, die Werte können natürlich etwas varieren. Sobald ein Game mehr als 2 Cores sehr gut auslasten kann legt der Nehalem enorm zu bzw. der Yorkfield legt nur minimal zu. Das ist einfach in den Architekturen begründet. Der FSB wird bei mehr als 2 Cores immer zum größeren Flaschenhals. Dadurch kann der Yorkfield seine Leistung nicht entfalten.

Ich rechne jedenfalls immer mit Durchschnittswerten und solche übertrieben Leistungsschübe, die Intel und AMD manchmal für kleinere Architekturupdates angeben braucht doch keiner.

Es geht hier um keine Folien von beiden IHVs. Es geht um Fakten, und diese habe ich dir geschildert.

Glaube hier im Forum herrscht eher die Meinung, das Nehalem +10-15% mehr Leistung zu Yorkfield brachte, SMT bereinigt und diese Angabe ist imho auch korrekt.

Die Meinung in Foren bezieht sich immer auf den Benchmarkmüll diverser Reviewer im Netz weil die Leute immer noch nicht verstehen oder verstehen wollen, das man CPUs nicht in GPU-Limits testet.

Deswegen sind die Angaben von Computerbase auch realistischer, als was du da behauptest.
Die Angaben von CB & Co sind Mumpitz, zumindest was Gamebenches angeht. Erstmal muss der Reviewer wissen was er da überhaupt bencht.

Skysnake

2011-08-02, 10:37:54

Mal kurz nen Einwurf, den ich dann auch einfach so stehen lassen will, da ich das Gezanke etwas kindisch finde grad:

Die Meinung in Foren bezieht sich immer auf den Benchmarkmüll diverser Reviewer im Netz weil die Leute immer noch nicht verstehen oder verstehen wollen, das man CPUs nicht in GPU-Limits testet.

Du meinst also das Benches bei 800x600 ohne alles bla blub von am Besten 10 Jahre alten Spielen so richtig tolle Benches sind, um die Leistungsfähigkeit einer CPU zu testen?

Meinst du nicht, dass das geringfügig hirnrissig ist? Man testet jedwede Hardware eigentlich genau in den Aufgabenbereichen die man auch real verwendet, denn alles andere ist fischen im trüben. Wenn man schon irgendwelche allgemeinen Aussagen machen will, dann doch bitte syntetische, bzw. pseudo syntetische Benchmarks die auf Programmen wie Photoshop, CAD oder sonst was aufsetzen.

LinPak ist auch noch ganz nett, sieht man aber auch nirgends leider.

PS: Mit is grad ein F16 im Tiefflug übers Haus gebrettert :ugly: WTF die Dinger sing ganz schon laut :biggrin:

y33H@

2011-08-02, 10:57:55

Man testet jedwede Hardware eigentlich genau in den Aufgabenbereichen die man auch real verwendet, denn alles andere ist fischen im trüben. Sofern man Spiele und CPUs vermisst, sollte es so weit wie möglich weg vom Grafiklimit sein - also u.a. 800x600 oder niedriger, aber mit maximalen Details damit nicht auch CPU-relavantes verringert wird. Das sollte eigentlich jedem klar sein. Die meisten verstehen das aber nicht und fordern Benchmarks in 1080p und freuen sich dann, dass bedingt durchs Grafiklimit ihr alter E8400 "gleichauf" meinem i7-2600K ist. Was natürlich nicht der Fall ist.
Wenn man schon irgendwelche allgemeinen Aussagen machen will, dann doch bitte syntetische, bzw. pseudo syntetische Benchmarks die auf Programmen wie Photoshop, CAD oder sonst was aufsetzen.Spiele kannst du nicht mit synthetischen Programmen testen, da musst du schon das Spiel selbst nehmen ...
Du meinst also das Benches bei 800x600 ohne alles bla blub von am Besten 10 Jahre alten Spielen so richtig tolle Benches sind, um die Leistungsfähigkeit einer CPU zu testen?Von alten Spielen und "ohne alles" (sprich minimale Details)hat dargo nicht gesprochen.

dargo

2011-08-02, 11:23:14

Mal kurz nen Einwurf, den ich dann auch einfach so stehen lassen will, da ich das Gezanke etwas kindisch finde grad:

Du meinst also das Benches bei 800x600 ohne alles bla blub von am Besten 10 Jahre alten Spielen so richtig tolle Benches sind, um die Leistungsfähigkeit einer CPU zu testen?

Meinst du nicht, dass das geringfügig hirnrissig ist?
Oh man... so langsam müsste ich eine dicken Artikel in 3DC zum Thema CPU- und GPU-Limits verfassen. Ansonsten drehe ich mich ständig im Kreis. Viele User verstehen leider die Zusammenhänge nicht.

Nochmal:freak: für dich.

Grundvoraussetzungen für CPU-Tests in Games:
1. Reproduzierbare Savegames und nichts anderes.
2. Vollständige CPU-Limits. Ich gehe hier den etwas einfacheren Weg und wähle die kleinstmögliche Auflösung. Ganz einfach deshalb weil die Chance vollständig im CPU-Limit mit einer Grafikkarte XY zu liegen größer ist als wenn ich 1920x1080 nehme. Der Testaufwand (Zeit) ist somit für mich geringer, der bei Savegames ohnehin schon enorm ist.
3. Immer mit max. Details benchen. Verringert man die Details verringert sich in der Regel auch die CPU-Last.
4. Die Tests müssen mehrmals wiederholt werden um leichte Schwankungen möglichst zu egalisieren. Ich nehme bei meinen Tests den Durchschnitt von 4 Durchläufen.
5. Bei Savegames die Testszene möglichst kurz halten. Ich nehme 5 Sekunden. Bei deutlich längeren Testszenen (manche Reviewer nehmen bis zu 1-2 Minuten, da muss ich immer den Kopf schütteln) läuft man Gefahr viele Sekunden in GPU-Limits zu erfassen was natürlich das Ergebnis verfälscht.
6. Bei Savegames nur die avg.fps verwenden. Min.fps können je nach Game und Testszene deutlich schwanken.

PS: bencht man eine beliebige Testszene (Savegame, keine Timedemo) in einer üblichen 1920x1080 Auflösung samt 4xMSAA/16xAF dann sagt das Ergebnis nichts anderes aus, als dass der Spieler eben mit dem gleichen System wie der Tester und der gleichen Vorgehensweise die selben fps bekommt. Weicht nur die Grafikkarte, die CPU oder die Vorgehensweise vom Spieler im Spiel selber ab ändern sich die jeweiligen Limits und das Ergebnis ist unbrauchbar. CPU- und GPU-Limits wechseln ständig in Games. Das kann sich schlagartig in wenigen Sekunden hin und her ändern.

Botcruscher

2011-08-02, 11:39:57

Die meisten verstehen das aber nicht und fordern Benchmarks in 1080p und freuen sich dann, dass bedingt durchs Grafiklimit ihr alter E8400 "gleichauf" meinem i7-2600K ist. Was natürlich nicht der Fall ist.
Spiele kannst du nicht mit synthetischen Programmen testen, da musst du schon das Spiel selbst nehmen ...

Doch die meisten verstehen sehr wohl. Wenn man die synthetische Leistung vergleichen will sollte man die Spiele aber ganz lassen. Bei Spielen verschiebt sich nämlich die Intention zu dem für was das Spiel da ist: spielen. Und eh du rum nörgelst das die Masse neben den low Resolution auch Spielegrafik sehen will, ich hätte auch noch gerne alles dazwischen. Das wäre super ist aber vom Reviewer leider nicht zu leisten. PS: Verbinden wir das noch mit den Grafikkartenkombinationen und nennen es Leistungsschau. Für Spieler, die wir nun mal sind, wäre das der Hammer.

y33H@

2011-08-02, 11:46:26

Diese "Leistungsschau" gibt's bei PCGH immer mal wieder (vor allem in der Print) - aber wie du schon sagt, kaum zu leisten (weil extrem zeitaufwendig). Daher lieber low res und den Verweis darauf, dass die CPUs im Grafiklimit zusammen rücken, als CPU-Benches, bei denen alle Chips "gleichschnell" sind.
Bei Spielen verschiebt sich nämlich die Intention zu dem für was das Spiel da ist: spielen. Nichtsdestotrotz möchten viele wissen, welche CPU in Spielen schneller ist - ergo low res.

Älteres Beispiel:

http://www.abload.de/thumb/2011-08-02_120039q8kf.png (http://www.abload.de/image.php?img=2011-08-02_120039q8kf.png)

dargo

2011-08-02, 11:49:19

Doch die meisten verstehen sehr wohl. Wenn man die synthetische Leistung vergleichen will sollte man die Spiele aber ganz lassen.
Das Problem bei synthetischen Benchmarks ist, dass sie die Schwächen eines doppelten Dualcores nicht zeigen können. Vereinfacht ausgedrückt - die Aufgaben werden parallel abgearbeitet. Spiele funktionieren ganz anders. Da kommt es sehr oft darauf an, dass ein Thread auf das Ergebnis eines oder mehreren wartet. Und eben hier zeigen sich die Schwächen eines nicht nativen Quadcores.

Nichtsdestotrotz möchten viele wissen, welche CPU in Spielen schneller ist - ergo low res.

Das Haupt-Verständnisproblem bei den meisten Spielern ist immer noch, dass sie nicht begreifen, dass High-Res nicht automatisch GPU-Limit heißt. Ich habe hier im Forum schon mehrmals Szenen gepostet wo ein vollständiges CPU-Limit sowohl bei 640x480 1xAA/1xAF als auch bei 1920x1080 4xMSAA/16xAF herrschte.

y33H@

2011-08-02, 12:02:30

Solche Szenen oder Spiele sind zugegeben aber selten, vor allem auf CPUs wie einem i7-2600K @ stock.

Skysnake

2011-08-02, 12:40:20

Nur mal so am Rande, was bringt es mir bitte, wenn ich weiß, dass ne CPU in den totalen Grüppeleinstellungen, die ich eh nie verwenden werde 300% schneller ist, dann aber in den Einstellungen, die ICH verwende nur noch 5% schneller ist, aber 100% mehr kostet?

Das ist doch total banane....

Und bzgl. Dual-Dualcores und syntetische/pseudo synthetische Benchmarks... Ich glaub du verstehst nicht den Sinn eines synthetischen Benchmarks.

Wenn du einen Benchmark haben willst, der dir die Leistungsfähigkeit bei Producer-Consumer Aufgaben über mehrere Cores zeigt, dann nimmt auch so einen, und wenn du keinen findest, dann schreib dir halt einen.

Wenn ein Benchmark nicht XY verwendet, ist doch klar, das man über XY keine Aussage treffen kann, da muss man dann einfach einen anderen nehmen. Synthetische Benchmarks nehmen halt oft einen sehr klar umrissenen Teilaspekt einer CPU raus. Da kann man doch dann nicht nen Strick daraus drehen, dass nicht alles erfasst wird :rolleyes:

Dafür gibt es halt ganz viele unterschiedliche Benchmarks, darunter auch einige, die die Gesamtheit eines Systems testen in einer speziellen Konstellation. Cinebench ist da z.B. zu nennen, oder CAD Benchmarks etc etc. Das sind reale Programme, wo man halt spezielle Setups testet und gut ist. Aus EINEM Benchmark kann man eh nie etwas schließen, man muss sich immer die Gesamtheit anschauen und dann entscheiden was wichtig ist und was nicht.

Die ganzen low Res Benchmarks mit Spielen etc. versteh ich daher eben genau nicht. Die bringen einem absolut nichts, weil kein Mensch die Einstellungen auch verwendet.

(Dummer Auto Vergleich inc: Das ist genau so als ob ich ein Auto testen würde und behaupten würde es wäre SUPER toll ist, weil es 320 fährt, aber der erste Gang bis 120 geht und man nicht vom Fleck weg kommt..)

Wenn man die Leistungsfähigkeit von einer CPU wissen will, soll man auch die Programme so verwenden, wie Sie Sinn machen. Das heißt eben auch, dass wenn man nur zocken will und da der 2 Jahre alte Dualcore genau so schnell ist wie der nagel neue Quad, dann ist das halt so und fertig. Deswegen ist die neue CPU ja nicht schlechter...... Sie bringt halt nur in diesen Anwendungen nichts und fertig.

dargo

2011-08-02, 12:43:05

Solche Szenen oder Spiele sind zugegeben aber selten, vor allem auf CPUs wie einem i7-2600K @ stock.
Alles eine Frage der Spiele (ein Spiel wie zb. Shift 2 welches praktisch nur Dualcores auslasten kann und gleichzeitig eine recht hohe CPU-Last aufweist hat viele solcher Szenen), der Szenen, der Settings und der GPUs. Mit der nächsten GPU-Generation verschieben sich mit einem i7-2600K außerdem die Limits schlagartig weiter Richtung CPU. Oder halt jetzt schon mit High-End SLI/CF. An dieser Stelle möchte ich allerdings nochmal erwähnen, dass Limits nicht gleich spielbare fps bedeutet. Das brauche ich dir y33H@ natürlich nicht sagen.

Nur mal so am Rande, was bringt es mir bitte, wenn ich weiß, dass ne CPU in den totalen Grüppeleinstellungen, die ich eh nie verwenden werde 300% schneller ist, dann aber in den Einstellungen, die ICH verwende nur noch 5% schneller ist, aber 100% mehr kostet?

Das ist doch total banane....

Die ganzen low Res Benchmarks mit Spielen etc. versteh ich daher eben genau nicht. Die bringen einem absolut nichts, weil kein Mensch die Einstellungen auch verwendet.

Das Haupt-Verständnisproblem bei den meisten Spielern ist immer noch, dass sie nicht begreifen, dass High-Res nicht automatisch GPU-Limit heißt. Ich habe hier im Forum schon mehrmals Szenen gepostet wo ein vollständiges CPU-Limit sowohl bei 640x480 1xAA/1xAF als auch bei 1920x1080 4xMSAA/16xAF herrschte.
;)

Du hast einfach das Problem die Ergebnisse meiner Benchmarks richtig zu interpretieren und sie auf die Spiele zu übertragen. Ich sags ja... ein entsprechender Artikel zu den Grundkenntnissen und einiges wird gleich klarer.

y33H@

2011-08-02, 12:52:34

Skysnake

2011-08-02, 12:58:35

Nein, du ziehst dir Ergebnisse aus dem Rechner, die möglichst große Leistungsunterschied zeigen sollen, ob diese dann real auch zu finden sind ist dir völlig egal.

Mir dagegen geht es total am aller wertesten vorbei, was das Ding irgendwo leisten könnte oder nicht. Für mich zählt was auf dem Platz rum kommt, und das sind die realen Einstellungen und fertig.

Alles andere ist mal ganz nett um zu sehen, ob noch Luft für die Games der nächsten 1-2 Jahre da ist und gut ist. Mehr aber auch nicht. Zudem steigen die CPU-Anforderungen seit Jahren nur noch sehr sehr langsam an. Kein Vergleich zu dem Anstieg bei den GPUs, wobei selbst dort der Anstieg dramatisch nachgelassen hat. JEtzt mal ganz abgesehen von irgendwelchen Super-Duper-Mega-SSMSSAGLAjblablub-Downsamling-Einstellungen, die mehr oder weniger einfach nur versuchen die Rechenleistung die brach liegt irgendwie halbwegs sinnvoll zu verwenden. Wogegen ich auch nichts einzuwenden habe. Oft sieht man ja noch einen Unterschied, wobei inzwischen es wirklich nur noch marginale Verbesserungen bringt in neuen Games. Nichts was man sofort sieht auf den ersten Blick halt.

Wie gesagt, ich finde nahezu alle synthetischen Benchmarks deutlich besser als Games in low Res blablub um die Leistungsfähigkeit einer CPU einzuschätzen. Es bringt einfach fast nichts und hat wirklich absolut null niente NADA praktischen Nutzen. Nicht mal sonderlich gut verallgemeinern kann man die Sache, da sich die ganzen Engines etc. einfach viel zu stark unterscheiden...

Für Gamer nicht wirklich sinnvoll, da total vorbei an den Anforderungen, und für alle anderen eh total Banane.

EDIT:

Ein E8400 wird in den meisten heutigen Spielen von einem Core i5-2500K böse in die Tonne getreten - in BC2 etwa doppelt so schnell.

Ja und? Es war ein Beispiel nichts anderes, nicht reales, einfach nur eine Veranschaulichung. Ob das real zutrifft war irrelevant.

Dennoch was bringt es, wenn der Fall so ist, was er bei dem Game sicherlich auch sein kann, wenn der Dualcore 60 FPS bringt und der Quad 120. Hab ich davon einen nutzen als User? Also ich nciht, für mich sieht das alles gleich aus.

Wenn ich neu kaufen will, ist das vielleicht ganz interessant und muss eben eingepreist werden, das muss man aber immer.

Unterm Strich geht es aber darum was die CPU real leistet in den Einstellungen die ich verwende. Nicht mehr und nicht weniger. Wenn eine CPU X Z FPS bringt weil die GPU limitiert und CPU Y auch, dann ist das halt so, dann bringt mir die "schnellere" CPU rein gar nichts. Etwas Luft nach oben zu haben ist ja ganz schön und nett, aber nur weil man in irgendwelchen weltfremden Einstellungen 200% mehr Leistung hat, heißt das noch lange nicht, dass ich das dann auch real sehen werde. Das GPU Limit kann ich ja im tagtäglichen Einsatz nicht einfach wegzaubern...

Wie gesagt, hier werden Äpfel mit Birnen verglichen.

Die einen wollen wissen was real bei raus kommt, und die anderen was wäre theoretisch überhaupt möglich und welches Potenzial steckt so grob in dem Ding drin, die ich aber so NIE abrufen werd können.

Für mich ist letzteres total Banane wie gesagt, da es an der Realität völlig vorbei geht. Mich interessiert da eher, wie viele Punkte ich bei BOINC mit den CPUs bekomme und was Sie da verbrauchen.

dargo

2011-08-02, 13:01:55

Wenn man die Leistungsfähigkeit von einer CPU wissen will, soll man auch die Programme so verwenden, wie Sie Sinn machen.

Genau das tue ich. ;)

Das heißt eben auch, dass wenn man nur zocken will und da der 2 Jahre alte Dualcore genau so schnell ist wie der nagel neue Quad, dann ist das halt so und fertig.
Sowas gibt es nicht bei gleicher Architektur und Taktrate. Sollte dies dennoch der Fall sein gibt es nur zwei Möglichkeiten:

1. Das Spiel skaliert nicht über einen Dualcore.
2. Der Reviewer testet im GPU-Limit welches durch oftmals verwendete Timedemos nochmals verstärkt werden.

Schaffe89

2011-08-02, 13:11:24

Die IPC ist bei Nehalem im Vergleich zum Yorkfield in Games (sie müssen natürlich sehr gut mit Quads skalieren) um ~80% höher. Beim gleichen Takt wohlgemerkt. Ein Sandy Bridge kommt da in den Bereich +~100%.

Was soll das hier in diesem Split sein? Rosinenpickerei?
Selbst wenn ein Quadcore gut skaliert sind das bei gleichem Takt niemals 80% in irgend einer Form.
Nehalem vs. Kentsfield/Yorkfield

Bitte verlinkt doch nicht immer diesen Unsinn von CB & Co.

Die benchen auch im absoluten CPU limit, also halte dich zurück, andere Quellen als Unsinn abzustempeln.
Was soll der Quatsch.
Rosinenpickerei kann man sich sparen.
Vergleiche doch mit einem nativen Quadcore alias Phenom II x4, dann sieht man auch den Vorteil des nativen Quadcores beispielsweise in GTA4. Deine 80% sind aber wie oben schon rcihtig erkannt provokanter Unsinn und Rosinen imbesten Alter.

Mir dagegen geht es total am aller wertesten vorbei, was das Ding irgendwo leisten könnte oder nicht. Für mich zählt was auf dem Platz rum kommt, und das sind die realen Einstellungen und fertig.

Ich bin auch dafür CPU´s in absoliten Limits zu testen, um wirklich zu sehen, welche nun am möglichst schnellsten ist.
Man bencht ja auch keine Grafikkarten (wenn möglich) im CPU limit, oder etwa doch?
Klar ist eine Betrachtung auch bei höheren Auflösungen nötig. Die Relationen verschieben sich dort eben sehr stark, da reicht kein Hinweis, dass die Prozessoren etwas "zusammenrücken".

Wenn man wissen will, was das System mit CPU A und GPU B leistet ist es aber kein reiner CPU Tests, sondern eher etwas für die Praxis.

Edit:

SMT/ mehr Kerne/ höher Takt/andere Architektur/ AMD vs. Intel Geht alles mit einem möglichen GPU limit anders um und holt hie und da mehr FPS raus.
Siehe Battlefield Bad Company 980X vs. 2600k, bzw die Benches von CB mit 15% Vorsprung des AMD Systems in Far CRY 2.
Wer nur blind 600x800 bencht, hats genausowenig verstanden.

Skysnake

2011-08-02, 13:16:22

Und was macht das für einen Unterschied, wenn ich mit ner GTX580 oder gar zwei oder drei im GPU Limit hänge? Wird die theoretisch schnellere CPU dadurch besser geeignet fürs zocken?

Also ich meine nicht. Man kann immer nur mit der Software testen, die es real auch gibt, und wenn die halt einfach nicht so viel Leistung braucht, dann ist das halt so. Ein Auto mit 200PS ist auch nicht immer besser als eins mit 80. Für das Omale das eh nur in der Stadt zum einkaufen fährt ist es total Jacke wie Hose, und genau so ist es bei Gamern. Toll das die CPU super toll und so viel besser ist als die andere, etwas davon sehen werden sie aber sehr selten wenn überhaupt. Da stellt sich dann eben auch die Frage nach dem Sinn. Für mich entzieht sich dieser. Sorry, ist aber so.

Fürn Bürorechner macht ne moderne CPU auch keinen Sinn. Ich kann mit meinem "Word" damit auch nicht schneller schreiben als mit ner "lahmen" CPU.

Man muss immer sich überlegen, was man mit dem Test aussagen will. Bei den Tests so wie du sie machst/machen willst, sieht man schon, was möglich wäre ohne GPU-Limit, das man aber nicht weg zaubern kann. Das wars dann aber auch.

Ganz nett zu wissen, mehr aber auch nicht. Wenn ich wirklich schauen will, welche CPU-Architektur wirklich besser ist, dann muss ich schauen wie Sie in Anwendungen performen, die wirklich so viel Leistung brauchen, also Render, Server-Applikationen usw.

Denn es ist nicht immer so, dass die CPU, die in Games etc. super toll performt in diesen weltfremden Einstellungen dann auch in Anwendungen, die wirklich die Leistung der CPU voll ausreizen genau so weit vorne liegen. Da kann sich sogar mal das Blatt wenden, da der Fokus der Anwendung eben wo anders liegt und eine Stärke/Schwäche die vorher nicht zum tragen kam nun voll durch schlägt.

y33H@

2011-08-02, 13:21:47

@ Skysnake

Gut, dann testen wir alle CPUs nur noch in 25x16 mit SGSSAA auf einer GTX 580. Denn das ist meine "reale Einstellung" und da reicht dann sogar ein A64 X2 6000+ :uclap: Umgekehrt testet auch niemand Grafikkarten mit einem Singlecore-Atom und stellt dann fest, dass eine HD 6990 nicht schneller sei als eine HD 5450 ... ich hoffe, du verstehst das.
Wenn ich wirklich schauen will, welche CPU-Architektur wirklich besser ist, dann muss ich schauen wie Sie in Anwendungen performen, die wirklich so viel Leistung brauchen, also Render, Server-Applikationen usw.Und das kann ich auf Spiele übertragen? NEIN!

Skysnake

2011-08-02, 13:24:31

.... Warum hab ich aus so einen Blödsinn gewartet?

Du verstehst schon den Unterschied oder?

Fall 1: Ich ändere etwas, die Leistung steigt an
Fall 2: Ich ändere etwas, die Leistung bleibt also gleich

Äpfel und Birnen und so gell ;)

y33H@

2011-08-02, 13:28:02

Fall 1: Ich baue eine schnellere CPU ein, die Fps steigen (CPU-Limit)
Fall 2: Ich baue eine schnellere CPU ein, die Fps stagnieren (GPU-Limit)

Für CPU-Tests in Spielen benötige ich ersteres.

dargo

2011-08-02, 13:31:31

Schaffe89

2011-08-02, 13:36:32

Und was macht das für einen Unterschied, wenn ich mit ner GTX580 oder gar zwei oder drei im GPU Limit hänge? Wird die theoretisch schnellere CPU dadurch besser geeignet fürs zocken?

Nein, das ist aber nur ein Verständnisproblem.
Und dieses Nein bietet dann genug Spielraum eine schwächere CPU zu verbauen sprich ---> KAufberatung.
Oder man wartet und schaltet die erst überflüssige Leistung mit einer GTX 780 frei. ;-)

Das Haupt-Verständnisproblem bei den meisten Spielern ist immer noch, dass sie nicht begreifen, dass High-Res nicht automatisch GPU-Limit heißt. Ich habe hier im Forum schon mehrmals Szenen gepostet wo ein vollständiges CPU-Limit sowohl bei 640x480 1xAA/1xAF als auch bei 1920x1080 4xMSAA/16xAF herrschte.

Eben, als b Beispiel taugt aktuell wohl gut Star Craft 2 um selbst in hohen Auflösungen noch ein CPU limit zu haben und dann ist Sandy Bridge weit in Front.

dargo

2011-08-02, 13:39:21

Was soll das hier in diesem Split sein? Rosinenpickerei?
Selbst wenn ein Quadcore gut skaliert sind das bei gleichem Takt niemals 80% in irgend einer Form.
Nehalem vs. Kentsfield/Yorkfield

Hast du dir mal meine Tests wenigstens angeschaut und diese auch verstanden?

Die benchen auch im absoluten CPU limit, also halte dich zurück, andere Quellen als Unsinn abzustempeln.
Was soll der Quatsch.

Wenn sie in absoluten CPU-Limits benchen würden würde nicht so ein Blödsinn bei vielen ihrer CPU-Tests in Games rauskommen. Du kannst mir ruhig glauben, ich weiß wovon ich spreche. Ansonsten nenne mir die Tests von CB & Co die im absoluten CPU-Limit liegen.

Ich bin auch dafür CPU´s in absoliten Limits zu testen, um wirklich zu sehen, welche nun am möglichst schnellsten ist.
Man bencht ja auch keine Grafikkarten (wenn möglich) im CPU limit, oder etwa doch?
Klar ist eine Betrachtung auch bei höheren Auflösungen nötig. Die Relationen verschieben sich dort eben sehr stark, da reicht kein Hinweis, dass die Prozessoren etwas "zusammenrücken".

Wenn man wissen will, was das System mit CPU A und GPU B leistet ist es aber kein reiner CPU Tests, sondern eher etwas für die Praxis.

Aha... es freut mich, dass du wenigstens weißt wie man CPUs und GPUs in Games testet.

Schaffe89

2011-08-02, 13:47:07

Wenn sie in absoluten CPU-Limits benchen würden würde nicht so ein Blödsinn bei vielen ihrer CPU-Tests in Games rauskommen. Du kannst mir ruhig glauben, ich weiß wovon ich spreche. Ansonsten nenne mir die Tests von CB & Co die im absoluten CPU-Limit liegen.

Sie testen doch auch im CPU limit. Schon seit 2 Jahren. ? realitätsferne Tests .
Hast du dir mal meine Tests wenigstens angeschaut und diese auch verstanden?

Klar. Du nutzt den FSB Flaschenhals und willst anderen Usern hier 80%+ verkaufen.
Dass das nur absolute Rosinen sind, verschweigst du vehement, oder muss ich den CB ANNO 1404 pro AMD Bench ausm Register ziehen? Da hat die Intel Architektur bei bestimmten Szenarien wohl auch NAchteile. Also lassen wir das am besten. :)

Edit:

Dirt 3 skaliert besonders schlecht mit 4 Theads.

Nightspider

2011-08-02, 14:54:47

Hey wer hat hier unsere Diskussion geentert? :ugly:

Wo waren wir? Ahja:
Dargo ich verstehe deinen Standpunkt vollkommen aber sehe es für 99,9% der Gamer nicht relevant ob Nehalem in EINEM einzigen Spiel bis zu 50% (SMT bereinigt) mehr Leistung bringt. Der Durchschnitt ist eben viel geringer und ich weiß nicht, warum dir der Durchschnitt egal ist.
Bist du so Rosinen-fixiert, wie es auch schon Schaffe89 anspricht?

Die Meinung in Foren bezieht sich immer auf den Benchmarkmüll diverser Reviewer im Netz weil die Leute immer noch nicht verstehen oder verstehen wollen, das man CPUs nicht in GPU-Limits testet.
Mit so einer Aussage wäre ich hier sehr vorsichtig. Du tust so, als würdest du dich über alle Hardware-Tests stellen.
Und das stimmt einfach nicht. Das was PCGH, 3DC und Co. machen sind auch realistische Tests, oft mit einem großen Durchschnitt an Games.

Wenn du so einen Test schreiben würdest, hättest du jedem empfohlen sich einen Nehalem zu kaufen, da der ach so tolle Performance Gewinn ja bei 80% liegt (im Jahre 2015 :rolleyes:).
Und dann hätte dir jeder Leser auf den Tisch gekackt, weil diese Behauptung fast nie zutrifft.
Zumal hier im Forum bestimmt auch der Großteil der techniversierten Leute weiß, das es solche Extremsituationen gibt, wie du sie angibst aber das ist eben für fast alle egal und nicht von Relevanz.

Deswegen gibt eben keiner solche exhorbitanten Werte von +80% (Yorkfield vs. Nehalem) an.

Wo habe ich geschrieben es wäre der Durchschnitt? Der Durchschnitt interessiert mich überhaupt nicht.

Das habe ich doch schon gesagt. Wenn du von einem Leistungssprung von 80% sprichst, von Yorkfield zu Nehalem, komplett ohne dieses Szenario einzugrenzen geht man davon aus, das du vom Durchschnitt sprichst.
Anderfalls hättest du dazuschreiben müssen, das diese in den seltensten Fällen auftritt.
Rosinenpickerei eben.

Und wenn hier im Forum, davon gehe ich zumindest aus, vom Durchschnitt reden ist es schon bisschen sinnlos, wenn dich der Durchschnitt überhaupt nicht interessiert.
Der Durchschnitt wird überall benötigt und auch nur Durchschnitt Angaben machen überhaupt einen Sinn bei einer Kaufempfehlung.

Alles andere kannst du auf Folien packen und an Intel/AMD schicken, die freuen sich über solche Benchmarks.

dargo

2011-08-02, 15:02:25

Sie testen doch auch im CPU limit. Schon seit 2 Jahren. ? realitätsferne Tests.

Ich habe von absoluten CPU-Limits gesprochen, nicht von xx% CPU-Limits. Dass CB immer noch nicht bei allen CPUs in ihren Tests im absoluten CPU-Limit liegt beweist schon alleine dieser Test.
http://www.computerbase.de/artikel/prozessoren/2011/test-intel-sandy-bridge/30/

Und obwohl ich CB so oft kritisiere (das liegt wohl eher daran, dass es eine deutschsprachige Seite ist und hier im Forum immer wieder gerne als Grundlage verlinkt wird, meine Kritik bezieht sich aber generell auf nahezu alle CPU-Tests in Games die es Online zu bestaunen gibt) muss ich sie hier loben. Denn endlich geben sie zumindest wenige Infos wie sie bei den Benchmarks vorgehen (das tut im übrigen die PCGH wesentlich ausführlicher). Das gibt wenigstens schon mal eine ansatzweise vernünftige Diskussiongrundlage. Auch die Testvorgehensweise hat sich im Vergleich zu vor wenigen Jahren in die richtige Richtung entwickelt. Da fehlt nur noch der Feinschliff.

Jetzt zum verlinkten Test... speziell Arcania. Mir reicht nur ein Blick auf die Zahlen um festzustellen, dass die Testszene nicht im vollständigem CPU-Limit liegt. Das verwundert mich auch überhaupt nicht, denn CB bencht hier mit ganzen 80 Sekunden. :freak: Erstens stelle ich die Reproduzierbarkeit bei einer so langen Testszene in Frage und zweitens sieht man an den Ergebnissen wie gesagt, dass viele Sekunden dieser Testszene schon im GPU-Limit liegen.

i7-2600K @2,8Ghz 4C/4T = 100% avg.fps
i7-2600K @3,4Ghz 4C/4T = 114% avg.fps

Zweitere CPU muss mindestens 121% liefern.

Das zieht sich durch fast alle Games durch. Erst bei Civilization V (minimaler Zoom) hatte CB das Glück vollständig im CPU-Limit zu liegen.
http://www.computerbase.de/artikel/prozessoren/2011/test-intel-sandy-bridge/33/

Hier liefert der 3,4Ghz i7-2600K @4C/4T 124% Leistung. Die paar Prozent über 121% könnten mit Messschwankungen zu tun haben. Die Grundlast wird bei so hohen Frames dafür kaum verantwortlich sein.

Klar. Du nutzt den FSB Flaschenhals und willst anderen Usern hier 80%+ verkaufen.

Ich will hier niemandem was verkaufen. Das sind Fakten! Jeder kann es bei sich mit einem Kentsfield/Yorkfield nachbenchen. Ich bin gerne bereit das entsprechende Savegame in RE5 zu liefern.

Dirt 3 skaliert besonders schlecht mit 4 Theads.
Genau. :ulol:
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=6973307&postcount=3

Dargo ich verstehe deinen Standpunkt vollkommen aber sehe es für 99,9% der Gamer nicht relevant ob Nehalem in EINEM einzigen Spiel bis zu 50% (SMT bereinigt) mehr Leistung bringt. Der Durchschnitt ist eben viel geringer und ich weiß nicht, warum dir der Durchschnitt egal ist.

Ich wiederhole mich nochmal - wenn ein Nehalem in einem Spiel wesentlich weniger zulegt als die Angaben die ich gemacht habe dann gibt es dafür nur zwei Gründe:

1. GPU-Limit
2. Spielengine skaliert schlecht mit mehr als 2 Cores.

Punkt zwei habe ich doch schon ausgiebig erläutert. Schau dir doch einfach die Skalierungen der beiden CPUs genauer an.

http://img402.imageshack.us/img402/8649/residentevil5.png

http://img696.imageshack.us/img696/6112/residentevil5i52.png
Der schnellste Quadcore beim Q9550 legt gegenüber dem Dualcore gerade mal um 37% zu. Der schnellste Quadcore beim i5-750 legt um 85% zu. Verstehst du jetzt worauf ich hinaus will? Als ich RE5 getestet habe sind mir erst die extremen Limitierungen der Doppel-Dualcore-Architektur klar geworden. Das war auch ein Grund warum ich schnell zum Lynnfield umgestiegen bin.
RE5 war damals schon ein kleiner Vorgeschmack wie es in Zukunft mit den Skalierungen bei Quadcores in Games aussieht. Dirt 3 und Crysis 2 skalieren sogar noch besser. Als nächstes wird sicherlich BF3 folgen. Das kann ich aber erst genau sagen wenn ich das Game ausgiebig untersucht habe.

Mit so einer Aussage wäre ich hier sehr vorsichtig. Du tust so, als würdest du dich über alle Hardware-Tests stellen.
Und das stimmt einfach nicht. Das was PCGH, 3DC und Co. machen sind auch realistische Tests, oft mit einem großen Durchschnitt an Games.

Ersteinmal muss man sich im klaren sein was will ich überhaupt mit meinen Tests bezwecken? Will ich zeigen wieviel schneller CPU X als CPU Y ist? Will ich zeigen wieviel schneller Grafikkarte X als Grafikkarte Y ist? Oder will ich einfach nur zeigen wie gut spielbar ist Spiel XY in Settings XY mit System XY? Letzteres hilft nur dem der das gleiche System zu Hause stehen hat und die selben Settings verwendet. Und selbst das nur relativ grob weil wie gesagt die Vorgehensweise im Spiel unterschiedlich sein kann.

Skysnake

2011-08-02, 17:38:39

Also allein deine Vorgehensweise von nur 5 Sec. oder so als Referenz zu nehmen ist halt mal bullshit. Dir ist schon klar, dass die Standardabweichung besser wird, wenn man mehr Werte für seine Statistik hat....

Bei so kurzen Scenen 5 Sec! Da kann dir schnell mal das System irgendwo rein scheisen in den Bench. DA wird m Hintergrund was geladen, es gibt diesn oder jenen zusätzlichen Trap. Die Daten fliegen vielleicht aus dem Cache wegen XY etc etc etc etc etc etc.

Sorry, aber so bringt es einfach rein gar nichts mit dir drüber zu diskutieren. Du willst ein gewisses Ergebnis haben, und drehst dir die Sachen so hin, das es stimmt und gut ist.

dargo

2011-08-02, 17:41:27

Bei so kurzen Scenen 5 Sec! Da kann dir schnell mal das System irgendwo rein scheisen in den Bench. DA wird m Hintergrund was geladen, es gibt diesn oder jenen zusätzlichen Trap. Die Daten fliegen vielleicht aus dem Cache wegen XY etc etc etc etc etc etc.

:facepalm:

Kein Kommentar...

Schaffe89

2011-08-02, 17:52:35

Ich habe von absoluten CPU-Limits gesprochen, nicht von xx% CPU-Limits. Dass CB immer noch nicht bei allen CPUs in ihren Tests im absoluten CPU-Limit liegt beweist schon alleine dieser Test.
http://www.computerbase.de/artikel/p...ndy-bridge/30/

Die Spiele sind halt teilweise nicht gut geeignet, man kann auch schlecht bei jedem neuen CPU review den Spieleparcour ändern.
Trotzdem ist das vor allem im Schnitt annähernd ein CPU limit, was den IPC Vorteil und den Vorteil der Sandy´s relativ wahrheitsgemäß zeigt, da fehlt nicht viel, wie auch dort Civilization zeigt.

Der Durschnitssvorsprung entspricht in etwa dem Vorpsung der Intels in Civilization 4, also kann an deiner Kritik nicht sooo viel drann sein.

Genau.

Ich hab vorher schon was im Zusammenang mit Rosinen gesagt.
Der Skalierungstest von PCGH zeigt da was ganz anderes. ;-)
Der zeigt dass erst 6 Kerne im Vergleich zu 4 mit 46% skalieren und 2 Kerne auf 4 mit lausigen 25%.

http://www.pcgameshardware.de/aid,825548/Zum-Release-Dirt-3-im-Technik-Test-Sechs-CPU-Kerne-im-Vorteil-gelungener-DirectX11-Modus/Rennspiel-Sportspiel-Simulation/Test/

Aber ich sehe worauf du hinauswillst.
In Res5 ist die Skalierung der alten FSB Quadcores einfach erbärmlich.
DAs dürften aber eher Ausnahmen sein.

http://www.computerbase.de/artikel/prozessoren/2010/test-amd-phenom-ii-x6-1100t-black-edition/22/#abschnitt_resident_evil_5

Dan dürfte deiner Meinung nach dieser Test auch kein reines CPU limit sein, weil 4 und 6 Kerner kaum skalieren?

IVN

2011-08-02, 18:00:18

Nur mal so am Rande, was bringt es mir bitte, wenn ich weiß, dass ne CPU in den totalen Grüppeleinstellungen, die ich eh nie verwenden werde 300% schneller ist, dann aber in den Einstellungen, die ICH verwende nur noch 5% schneller ist, aber 100% mehr kostet?

Nein, sie ist immer noch viel, viel schneller, nur muss sie aufgrund deiner Lahmen GraKa ideln, und die ander, lahme CPU, nicht, da sie trotz der lahmen GraKa ausgelastet ist.

Und ja, es ist sinnvoll mit Low-Res zu benchen, denn das zeigt wie viel Potential die CPU hat. Ich erinner mich, wie alle behauptet haben, das 6C Phenoms gleich schnell wie Nehalems wären. Und dann kam Starcraft 2 und zeigte wieso es gut ist viel Power pro Kern zu haben.

Twodee

2011-08-02, 18:43:57

Nein, sie ist immer noch viel, viel schneller, nur muss sie aufgrund deiner Lahmen GraKa ideln, und die ander, lahme CPU, nicht, da sie trotz der lahmen GraKa ausgelastet ist.

Und ja, es ist sinnvoll mit Low-Res zu benchen, denn das zeigt wie viel Potential die CPU hat. Ich erinner mich, wie alle behauptet haben, das 6C Phenoms gleich schnell wie Nehalems wären. Und dann kam Starcraft 2 und zeigte wieso es gut ist viel Power pro Kern zu haben.
Naja bei Starcraft 2 wird dann mit einem Its optimized for Intel dagegengeschossen. Nein wenn dann muss da schon ein SLI mit 2xGTX580 in den handelsüblichen Auflösungen herhalten. Erst dann kapieren es die Widersacher, das die eine CPU schneller als die andere ist :rolleyes:

boxleitnerb

2011-08-02, 18:47:51

Naja bei Starcraft 2 wird dann mit einem Its optimized for Intel dagegengeschossen. Nein wenn dann muss da schon ein SLI mit 2xGTX580 in den handelsüblichen Auflösungen herhalten. Erst dann kapieren es die Widersacher, das die eine CPU schneller als die andere ist :rolleyes:

Das wäre im Prinzip eine Möglichkeit, allerdings sprechen etwaige Skalierungsprobleme schon dagegen. Man bringt sich da eine weitere potentielle Fehlerquelle mit rein.

Skysnake

2011-08-02, 18:52:13

Sagt ja auch keiner etwas dagegen. Man sollte solche Benches ja AUCH machen, nur ist es halt in 95% der Fälle irrelevant.

Die dort gezeigten vermeindlichen Unterschiede der CPU bleiben im realen Einsatz halt total auf der Strecke. So etwas ist nice to know, aber das wars auch. Ich kann deswegen nicht sagen, die CPU X ist 100% besser als CPU Y, denn die dort erzielten Werte sind halt fürn Poppes.

Was z.B. wichtig ist, ob die CPU genug power hat in solchen Games wie SC2 oder WOW, die insbesondere WOW halt nur aus 2 Kernen vernünftig profitiert hat. Da seh ichs auch ein, weil man wirklich die entsprechende Anwendung hat. Über hypothetische muss ich nicht diskutieren, wenn die Power absolut verpufft. Vor allem, wenn vermeindliche große Vorteile in diesen unrealistischen Settings auftauchen, die durch einen "Flaschenhals" in der einen Architektur entstehen, die man so aber gar nicht oder nur sehr selten wirklich hat.

Sieht man doch sehr gut an den aktuellen Opterons. Die sollen ja so schlecht sein bla blub, wenn man sich aber mal so die FP-Performance anschaut, die man aus ihnen herauskitzeln kann und dazu den Preis nimmt, dann sind die Dinger wirklich SEHR interessant. Zudem sind die Maschinen ziemliche RAM-Monster wenn man es drauf anlegt.

Das sind halt alles so Sachen. Wirkliche Leistungsvergleiche hat man eigentlich immer mit einem konkreten Problem. Alles andere ist halt nur ne Verallgemeinerung, die heute bei den vielen unterschiedlichen Architekturen und Schwerpunkten/Ansätzen halt kaum noch möglich ist. Es gibt nicht DIE Super CPU. Das war vielleicht mal, wobei eigentlich noch nie aber lassen wir das... Heute aber auf jeden Fall nicht mehr. Im Schnitt ist CPU X natürlich besser als CPU Y, aber es gibt eben auch Ausreißer sowohl nach oben als auch nach unten. Je nachdem wie man seinen "Parcour" wählt kann man sehr stark die Wertungen hin und her schieben. Man muss einfach nur Rosinenpickerrei betreiben, dann wird das schon das Ergebnis geben, das ich will.

boxleitnerb

2011-08-02, 18:59:55

Skysnake

2011-08-02, 19:37:51

Wenns im SLI zum tragen kommt ist ja fein, nur in welchen Settings kommts zum tragen, und wie viel Anteil daran trägt der in die CPU gewanderte PCI-E Controller?

Hier werden einfach sehr einfache Erklärungsmuster abgeliefert, und das wars. Gerade bei CF/SLI kommt aber doch noch das eine oder andere mit dazu.

Ich wehre mich einfach gegen solche Pauschalaussagen wie Sie hier die ganze Zeit getätigt werden aufgrund von Rosinenpickerrei.

Wenn ich schon höre: " Der Durchschnitt interessiert mich nicht" & "5 Sec Benches"

Ja klar, total repräsentativ sowas. Such dir die richtige Szene raus, dann siehts wieder etwas anders aus. Pack noch ein Hintergrundprogramm dazu und schaut dir an, wie die Datenlokalität etc. sich verändert. Grad mit den unterschiedlichen Cachegrößen sollte man da in so einem kleinen Fenster sehr stark das Ergebnis beeinflussen können.

boxleitnerb

2011-08-02, 19:41:55

Kleines Zeitfenster ist nur logisch zum Benchen, sonst läuft die Szene anders ab oder die Lastverteilung im System ändert sich von dem weg, was du testen willst. Es geht nicht anders.

IVN

2011-08-02, 19:45:53

Sagt ja auch keiner etwas dagegen. Man sollte solche Benches ja AUCH machen, nur ist es halt in 95% der Fälle irrelevant.Performance ist nie irrelevant. Auch wenn du in vielen Spielen bei HD-Auflösung und AA/AF, die CPU nicht auslasten wirst können, so ist es gut zu wissen, und das belegen die Low-Res-Benches, das die CPU so stark ist. Man kann die Power, die man kauft, immer noch in Anwendungen oder zukünftigen Spielen nutzen.

Die dort gezeigten vermeindlichen Unterschiede der CPU bleiben im realen Einsatz halt total auf der Strecke. So etwas ist nice to know, aber das wars auch. Ich kann deswegen nicht sagen, die CPU X ist 100% besser als CPU Y, denn die dort erzielten Werte sind halt fürn Poppes. Nein, sind sie nicht. Die CPU mit besseren Werten ist immer noch schneller, nur muss sie auf die GPU warten, wenn man die Auflösung erhöht und AA/AF dazu schaltet.

Du scheinst nicht zu verstehen, was diese Tests genau messen. 640*480 ist das gleiche, wie eine Rennstrecke für Sport-Autos. Es gibt einen Grund wieso jedes Auto-Magazin Ferrari, Porsche und Co, auf einer Rennstrecke testet, wenn sie die maximale Performance dieser Autos erfahren wollen. Niemand wird auf die Idee kommen einen Porsche in der 50er Zone fahren zu lassen, und zum Schluss zu kommen, das er genau so schnell ist, wie der 1,2 Liter Polo.

Was z.B. wichtig ist, ob die CPU genug power hat in solchen Games wie SC2 oder WOW, die insbesondere WOW halt nur aus 2 Kernen vernünftig profitiert hat. Da seh ichs auch ein, weil man wirklich die entsprechende Anwendung hat. Über hypothetische muss ich nicht diskutieren, wenn die Power absolut verpufft. Vor allem, wenn vermeindliche große Vorteile in diesen unrealistischen Settings auftauchen, die durch einen "Flaschenhals" in der einen Architektur entstehen, die man so aber gar nicht oder nur sehr selten wirklich hat.

Ob sie selten sind oder nicht, hängt von den Spielen ab, die man spielt. Versuchs mal mit Strategie-Spielen...

dargo

2011-08-02, 20:32:21

Die Spiele sind halt teilweise nicht gut geeignet, man kann auch schlecht bei jedem neuen CPU review den Spieleparcour ändern.
Trotzdem ist das vor allem im Schnitt annähernd ein CPU limit, was den IPC Vorteil und den Vorteil der Sandy´s relativ wahrheitsgemäß zeigt, da fehlt nicht viel, wie auch dort Civilization zeigt.

Wenn aus praktisch möglichen +21% nur +14% durchschlagen dann heißt es nichts anderes als das in der Testszene einige Sekunden vorhanden sind die von der Grafikkarte limitiert werden. Ich fände es nicht schlecht wenn dieser Hinweis vom Reviewer in solchen Tests mal erwähnt würde. Ansonsten siehst du ja wie solche Ergebnisse von den Lesern interpretiert werden. Dann heißt es plötzlich... ja aber im Durchschnitt liegt CPU X nur xx% vor der alten Architektur.

Der Durschnitssvorsprung entspricht in etwa dem Vorpsung der Intels in Civilization 4, also kann an deiner Kritik nicht sooo viel drann sein.

Ich kann dir hierbei nicht folgen.

Ich hab vorher schon was im Zusammenang mit Rosinen gesagt.
Der Skalierungstest von PCGH zeigt da was ganz anderes. ;-)
Der zeigt dass erst 6 Kerne im Vergleich zu 4 mit 46% skalieren und 2 Kerne auf 4 mit lausigen 25%.

http://www.pcgameshardware.de/aid,825548/Zum-Release-Dirt-3-im-Technik-Test-Sechs-CPU-Kerne-im-Vorteil-gelungener-DirectX11-Modus/Rennspiel-Sportspiel-Simulation/Test/

Ich weiß nicht wie oft ich es noch wiederholen muss. Intergrierte Benchmarks haben rein gar nichts mit der tatsächlichen CPU-Last in Games zu tun. Das beweist wieder hervorragend der Test der PCGH in Dirt 3. Und wenn man sich mal die Werte genauer anschaut ergibt da so einiges gar keinen Sinn. Der Vierkerner legt gegenüber dem Zweikerner nur 30% zu. Der Sechskerner gegenüber dem Vierkerner aber 45%? :|

Wo der Wurm bei diesem Test liegt wird dir nur die PCGH sagen können. Da ist garantiert was schief gelaufen.

Aber ich sehe worauf du hinauswillst.
In Res5 ist die Skalierung der alten FSB Quadcores einfach erbärmlich.
DAs dürften aber eher Ausnahmen sein.

Nein, das verstehst du falsch. RE5 ist keine Ausnahme. RE5 ist nur ein gutes Beispiel um zu zeigen was passiert wenn die Spielengine sehr gut mit 4 Cores skaliert. Das selbe Verhalten wirst du in Dirt 3, Crysis 2 und womöglich in BF3 in Verbindung mit doppelten Dualcores sehen. Einen groben Ausblick auf BF 3 sieht man hier (Q9550 vs. i5-760):
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=8864060&postcount=1694

Allerdings würde ich diese Werte nicht auf die goldene Waage legen. Erstens Alpha-Stadium vom Game, zweitens kenne ich die genaue Vorgehensweise vom Tester nicht (da kann man viel falsch machen). Drittens Low-Details und viertens sehen mir die Dualcores zu schwach aus. Liegt eventuell an der Alpha-Version. Wie gesagt... über BF3 reden wir dann wenn das Game final ist.

http://www.computerbase.de/artikel/prozessoren/2010/test-amd-phenom-ii-x6-1100t-black-edition/22/#abschnitt_resident_evil_5

Dan dürfte deiner Meinung nach dieser Test auch kein reines CPU limit sein, weil 4 und 6 Kerner kaum skalieren?
Dieser Test ist insofern wieder unbrauchbar weil schon wieder die beiden intergrierten Benchmarks genommen wurden. Der Grund warum unbrauchbar wurde von mir oben schon genannt.

y33H@

2011-08-02, 20:36:41

Intergrierte Benchmarks haben rein gar nichts mit der tatsächlichen CPU-Last in Games zu tun. Das beweist wieder hervorragend der Test der PCGH in Dirt 3. Im Falle von Dirt 3 schon: Das ist ein ganz normales Rennen, nur das der Wagen, den sonst der Spieler lenkt, von der AI gefahren wird. Viel praxisnäher geht's kaum - außer selbst fahren. Die Werte habe ich mit einer anderen Strecke noch mal getestet, die neueren sind plausibel.

Skysnake

2011-08-02, 20:37:49

Bei höheren Auflösungen etc. kann es aber zu ganz anderen Problemen wie schlechter Designten PCI-E Controller kommen, höhere Latenzen dort, etc etc.

Man kann das einfach nicht 100% vergleichen. Daher machts auch kaum Sinn in meinen Augen. Das einzige ist halt, das man sieht, jo, der ist eigentlich schneller, aber hat +/- x FPS die gleiche Leistung, also reicht das auch noch für später.

Deswegen ist die CPU aber nicht besser geeignet für Games, sondern genau gleich gut. Das irgend wann vielleicht mal was kommt, wo man dann gravierende Unterschiede auftauchen, steht in den Sternen. Wie gesagt, die Anforderungen steigen in letzter Zeit kaum noch im Vergleich zu Hardware-Entwicklung. Was bringt mir aber ne tolle Leistung, wenn dann Sachenwie PCI-E 3.0 etc nötig sind für GPUs.

Für die Zukunft kaufen ist halt immer schwachsinnig. Etwas Luft nach oben ist ok, aber ne CPU wirklich richtig für Spiele in 1-2 Jahren kaufen ist halt schwachsinnig. Da bekommt man die gleiche Leistung fürs halbe Geld.

Ich hoffe du gibst mir recht, das so ne 80-100% Aussage total Banane ist unter den Voraussetzungen, die hier genannt wurden. Die total leichtgläubigen und unwissenden Leute kommen dann nämlich immer mit som Mist wie: Ich hab jetzt nen PII X6/SB2500(k), soll ich auf SB-E/BD wechseln, wenn der kommt, die sind ja viel schneller....

Das kommt nämlich genau von solchen hohlen Aussagen zu Benches. Mit der Realität hat das halt NICHTS zu tun. Man kann nach oben hin abschätzen, wie aussieht, aber ohne reale Anwendung ist das halt alles nur eine Pi mal Daumen Sache, denn die Programme würden nämlich 100% nicht mehr so aussehen, wenn man die Leistung dann brauchen würde in dem Maße.

@boxleitnerb:
Wenn das so ist, sollte man sich entweder ziemlich heftig Gedanken darüber machen, woran das liegt, und man das abstellen kann und auf der anderen Seite eben ob man nicht doch lieber eine andere Szene nimmt oder eben etwas in seinem verhalten ingame ändert.

Zudem kann man die Statistik durch mehr Durchläufe auch verbessern. Es gibt ja nur eine endliche Anzahl an Variationen. Mit vielen Messwerten wird die Varianz besser.

Von nicht automatisierten Eingaben sollte man eh absehen, da diese nie reproduzierbar sind.

Die Gefahr das Ergebnis durch sehr kurze Szenen total zu verfälschen ist auf jeden Fall viel zu groß, als das man so kurze Szenen nehmen dürfte.

Da muss nur das Cacheing etwas anders laufen, da kann die Performance ganz unglücklich nach unten gehen.

Es gibt einfach viel zu viele Einflussfaktoren, als das man so kurze Szenen nehmen dürfte. Wenn muss man zumindest mit so 5-10 anderen komplett anderen Szenen die Ergebnisse validieren. Wenn es da zu nicht konsistenten Ergebnissen kommt, dann kannste die Sache in die Tonne kloppen.

EDIT:

Dargo schon mal was von Cacheingeffekten und Superskalierung gehört? Das kann bei so etwas durchaus passieren. Auch kann die Datenlokalität sich eventuell erhöhen etc etc etc. Es gibt mehr als genug Erklärungen dafür, dass das so sein kann.

dargo

2011-08-02, 20:41:44

Sagt ja auch keiner etwas dagegen. Man sollte solche Benches ja AUCH machen, nur ist es halt in 95% der Fälle irrelevant.

Die dort gezeigten vermeindlichen Unterschiede der CPU bleiben im realen Einsatz halt total auf der Strecke.
Was macht dich hierbei so sicher? Ich habe hier schon mal erwähnt, dass es genug Szenen in Games gibt die sowohl in kleiner als auch großer Auflösung sogar noch im vollständigen CPU-Limit liegen können. Und dafür brauche ich noch nicht mal SLI/CF. Muss ich dir das erst beweisen?

y33H@

2011-08-02, 20:46:23

@ Skysnake

Wirf mal weniger mit Theorie um dich, sondern lass die Praxis sprechen - so wie dargo. Theorie ist schön und gut um zu erklären, warum praktische Werte so oder so aussehen. Aber mit Theorie alleine wirst du keinen einzigen praktischen Beweis führen. Denn:
Mit der Realität hat das halt NICHTS zu tun.

dargo

2011-08-02, 20:47:41

Im Falle von Dirt 3 schon: Das ist ein ganz normales Rennen, nur das der Wagen, den sonst der Spieler lenkt, von der AI gefahren wird. Viel praxisnäher geht's kaum - außer selbst fahren. Die Werte habe ich mit einer anderen Strecke noch mal getestet, die neueren sind plausibel.
Ich glaub das einfach nicht. Denn anders sind meine Skalierungstests in Dirt 3 nicht zu erklären. Oder es limitiert bei der Phenom II Architektur etwas extrem. Kann ich mir aber kaum bei dem nativen Quad/Sixcore vorstellen. Habt ihr den gleichen Test mal mit einem Nehalem/Lynnfield/Sandy Bridge durchgeführt? Ich habe einen Vorschlag wo wir schon mal beim Thema sind. Ich lasse mal den intergrierten Benchmark bei mir laufen. Dann sehen wir mal wie die Skalierung über die Cores bei einem Lynnfield aussieht.

PS: wo kann ich deine neuen Werte sehen?

Skysnake

2011-08-02, 20:50:09

Ja, das zeigst du mir mal bitte, wo du bei realistischen Einstellungen, also 1920*1080, vollen Details uns 4X AA irgendwo die von dir propagierten 80-100% Leistungsunterschied bringen kannst. Sorry, aber das ist echt Hahnebüchen.

Selbst bei Anno mit riesen Stadt etc. glaub ich nicht dran.

Ach so eins muss ich noch dazu sagen. 1vs2 FPS zählen für mich nicht, sondern nur der Bereich 20 FPS+ Da kann das dann nämlich wirklich entscheidend sein. Bei extrem niedrigen FPS Werten sind die Einmaleffekte ja eh höher.

y33H@

2011-08-02, 20:54:24

@ dargo

Ich such's dir morgen raus =)

dargo

2011-08-02, 21:04:12

Ja, das zeigst du mir mal bitte, wo du bei realistischen Einstellungen, also 1920*1080, vollen Details uns 4X AA irgendwo die von dir propagierten 80-100% Leistungsunterschied bringen kannst. Sorry, aber das ist echt Hahnebüchen.

http://www.forum-3dcenter.org/vbulletin/showpost.php?p=8676037&postcount=408
Lass den Post auf dich wirken, überleg ein paar Minuten bevor du antwortest und dann sag mir nochmal Low-Res wäre praxisfremd.

Übrigens - ich habe nirgendwo gesagt, dass jedes Spiel in jeder Situation in 1920x1080 4xAA @max. Details vollständig cpu-limitiert ist, sodass die 80-100% Leistungsunterschied zustande kommen. Du musst schon genau lesen was ich schreibe.

Skysnake

2011-08-02, 21:09:43

Ja mach das mal bitte, kann mir das absolut nicht vorstellen. In einer einzelnen speziellen Szene vielleicht, aber das ist alles andere als Repräsentativ.

EDIT:

Wie verhält sich die Sache denn wenn das Rennen angefangen hat. Sind die Frameraten dann noch immer gleich niedrig? Wenn nein, kanns auch an irgendwelchen anderen Sachen liegen, die extrem Rechenintensiv sind, oder das noch irgendwas geladen wird oder whot ever. Keine Ahnung wie der Start bei dem Spiel genau aussieht.

Das nur 2 Kerne genutzt werden ist natürlich schon mal ziemlich schlecht. Interessant wäre es aber noch, wie das Game auf unterschiedliche Architekturen reagiert. Eventuell ist die Datenlokalität ja extrem beschissen, oder die haben extrem viele OS Traps warum auch immer. Ohne Vergleich zu einer anderen CPU kann ich dazu leider mir keine Meinung bilden. Auf jeden Fall sieht die Sache sehr seltsam aus, wenn die Framerate bei beiden Auflösungen gleich ist. Irgendwas läuft da SEHR komisch.

Kannst du eventuell noch in beiden Auflösungen ein Bild so 30 Sek nach dem Start machen? Bzw. über Afterburner oder so gleich den groben Frameverlauf der ersten 30 Sek. Wäre mal sehr interessant.

PS: War das mit dem i5-750`@3,7 GHZ gemacht?

dargo

2011-08-02, 21:16:55

Ja mach das mal bitte, kann mir das absolut nicht vorstellen.
Was soll ich machen und was kannst du dir nicht vorstellen?

Skysnake

2011-08-02, 21:23:21

Dass die Framerate bei der Änderung der Auflösung gleich bleibt. Das ist SEHR außergewöhnlich.

Und was du machen sollst hab ich doch geschrieben, nach 30 Sek nochmals nen Screen machen, oder noch besser den Verlauf mal posten. Aus so nem Einzelbild kann man halt wenig lesen.

Wenn das kommt, weil noch Daten hin und her geschoben werden müssen per blockierendem Transfer, dann ist das halt dumm gelöst, aber halt so.

Könnte man btw. mal testen, wenn man einen 8X Slot statt 16X verwendet. Oder sind die Frameraten IMMER so schlecht?

y33H@

2011-08-02, 21:36:16

Das ist nicht außergewöhnlich. Man nehme CPU-lastiges Spiel und CPU-lastige Szene und gammlige CPU. Et voila.

dargo

2011-08-02, 21:50:19

Dass die Framerate bei der Änderung der Auflösung gleich bleibt. Das ist SEHR außergewöhnlich.

Da ist nichts Außergewöhnliches dran. Nehme ein cpu-lastiges Game welches zusätzlich noch kaum über 2 Cores skaliert (würde Shift 2 mit 4 Cores sehr gut skalieren würde meine Szene u.U. nicht mehr die selben Frames in beiden Settings liefern weil sich das Limit einfach dann mehr Richtung GPU verschieben würde) kommt sowas bei rum. Es mag für dich außerwewöhnlich sein weil du zu sehr auf den Benchmarkschrott im Netz fixiert bist. Nur haben leider diese wenig mit der Realität zu tun.

Und was du machen sollst hab ich doch geschrieben, nach 30 Sek nochmals nen Screen machen, oder noch besser den Verlauf mal posten. Aus so nem Einzelbild kann man halt wenig lesen.

Du musst bedenken, dass ich selbst bei meinen Tests mich nicht bewege. Ich lasse quasi die KI auf mich wirken. Würde ich das nicht tun könnte die Reproduzierbarkeit gefährdet werden weil die KI dann unterschiedlich auf mich reagiert. Bleibe ich also 30 Sekunden stehen ist die KI weg aus meinem Sichtfeld und somit sinkt selbstverständlich auch die CPU-Last. Fahre ich direkt hinter der KI im Feld dicht mit ändert sich an der CPU-Last kaum was.

Edit:
Hier die Werte aus dem intergrierten Benchmark von Dirt 3.

Lynnfield i5-750 @3,61Ghz (20x 180,5 BCLK), Speicher @722Mhz, GTX480 @830/2000Mhz mit 640x480 1xAA/1xAF, max. Details

Quadcore:
erster Durchlauf - min. 93,98fps, avg. 147,24fps
zweiter Durchlauf - min. 107,94fps, avg. 149,85fps

Dualcore:
erster Durchlauf - min. 62,24fps, avg. 86,71fps
zweiter Durchlauf - min. 62,18fps, avg. 89,15fps

Wie man sieht skaliert der Quad beim Lynnfield schon wesentlich besser als der Quad bei der PCGH mit dem Phenom II. Wo der Wurm da lag kann die PCGH nur selbst finden.

Was auch auffällt ist, dass die Skalierung im intergrierten Benchmark dennoch schlechter ist als tatsächlich Ingame. Das ist das was ich immer an solchen Benchmarks kritisiere. Man versucht im Falle von Dirt 3 zwar eine ähnliche CPU-Last zu simulieren, schafft es aber trotzdem nicht an die tatsächliche ranzukommen. Was mir am Benchmark ebenfalls nicht gefällt ist die Reproduzierbarkeit. Man kommt fast immer an anderer Stelle ins Ziel, die KI verhält sich nicht immer gleich. Dadurch kommt es wie man sieht schon zu etwas größeren Schwankungen. Diese werden zwar durch die avgs. relativ gut geglättet, in einem Frameverlauf könnte ich mir aber durchaus vorstellen, dass diese Abweichungen hier und da wesentlich größer sind. Zudem weiß ich noch nicht ob der intergrierte Benchmark im völligen CPU-Limit liegt. Das müsste man erstmal gegentesten.

boxleitnerb

2011-08-02, 21:53:55

Reagiert die KI eigentlich immer gleich, wenn sich der Spieler gleich verhält? Ich hatte kürzlich mal versucht, einfach Maus- bzw. Tastatureingaben aufzunehmen und im Spiel per Makro abzuspielen (mit integriertem Start von fraps), aber das hat nie geklappt. Die Bewegungen, die da rauskamen, waren immer großer Mist und nie das, was ich vorher aufgezeichnet hatte.

Skysnake

2011-08-02, 22:02:48

Nein, du hast da immer einen Rand()-Generator mit drin, damit die KI eben nicht statisch wirkt.

@Dargo, wenn nicht ein unterschiedliches KI-Modell für Autos in Sicht und außerhalb verwendet wird, dann ändert sich nichts.

Falls doch, warte halt, bis Sie alle an dir vorbei fahren. Du kannst dann ja am Frameverlauf sehen, ob Gegner in Sicht oder nicht, etwas ausmachen.

Wie gesagt, aus einem einzelnen Screen kann man keine Rückschlüsse ziehen, da man ja nicht sieht, wo der Flaschenhals wirklich liegt. Da kann ja alles mögliche passieren.

Texturen laden usw usw.

Schade das ich das Game nicht hier habe.

y33H@

2011-08-02, 22:02:59

@ boxleitnerb

Kommt auf's Spiel an. Die Jungs in der PCGH-Szene von "Warhead" machen immer das Gleiche, als Beispiel.

@ Skysnake

Das sagt die Theorie ... praktisch sieht's oft anders aus, weil vieles gespricptet ist.

Schaffe89

2011-08-02, 22:04:04

Nein, das verstehst du falsch. RE5 ist keine Ausnahme. RE5 ist nur ein gutes Beispiel um zu zeigen was passiert wenn die Spielengine sehr gut mit 4 Cores skaliert. Das selbe Verhalten wirst du in Dirt 3, Crysis 2 und womöglich in BF3 in Verbindung mit doppelten Dualcores sehen.

Also wenn die CPU theoretisch 20 % mehr leisten könnte, aber nur 8 %ankommen, heißt das für dich es besteht ein CPU limit?
Heißt also auch im PCGH Dirt 3 Benchmark herrscht teilweise ein CPU limit, weil von 2 ab nicht alles einwandfrei hochskaliert?

Und von diesem Standpunkt aus errechnest du dann in deinen sehr kurzen Sequenzen 80% IPC plus für Nehalem vs. Yorkfield? Ich denke nicht, dass sowas funktioniert, nur in gewissen Szenen, die nicht einfach nur im CPU Limit liegen, sondern einfach gewisse Nachteile ernorm herausstellen, das hat mit CPU-limit an sich aber weniger was zu tun. Es gibt kein absolutes CPU limit.

Ich kann dir hierbei nicht folgen.

Ich kann nicht folgen, warum du mir nicht folgen kannst. Du sagst vieles ist bei CB ist GPU limitiert, du sagst Civilization ist nicht GPU limitiert, der Vorsprung in Civilization von Sandy zu AMD ist aber nicht viel größer(3%) als der Durchschnitt den CB am Ende raus hat, das war doch ganz trivial.
So und warum ist Civilization nun deiner Ansicht nach CPU limitiert?
Da skaliert ja auch alles sehr schlecht, also muss nach deine Theorie irgend eine GPU Limitierung da sein, oder doch nicht?

Damit solche Aussagen treffen kanns, musst du dich vor allem mit dem Detail der Spieleprogrammierung auskennen, am besten selbst noch Prozessorhersteller sein und zugleich wohl bei der Grafikabteilung mitarbeiten bzw.. ein absoluter Guru sein, der solche wirklichen CPU- Limits erzeugen kann, was einen einwandfrei skalierbaren Code in genau dieser Szene vorraussetzt, etc.. etc...

Lass den Post auf dich wirken, überleg ein paar Minuten bevor du antwortest und dann sag mir nochmal Low-Res wäre praxisfremd.

Na wenn da mal nicht etwas anderes limitiert hat. Wie wärs mit I/O oder Festplatte, oder Engine hänger, der die skalarität der CPU einschränkt?
5 Sekunden Benches und kurze Ausschnitte sagen meiner Meinung nach rein gar nichts aus und taugen schon gar nicht für irgendwelche Beweise.
Wie Skysnake weiter oben schon erkannt hat, taugen deine Benches bisher wenig.
Wenn überhaupt brauchen wir Frameverläufe und dann wirst du höchstwahrscheinlich sehen dass deine bisherigen Benchmarks keine absoluten CPU limits sind (denn die gibt es nicht), sondern einfach sehr stark ins CPU limit laufen und aufgrund der Software, der Engine (oder was weiß ich) verschieden reagieren, besonders bei Dirt 3, also alles Szenenabhängig.

Wie man sieht skaliert der Quad beim Lynnfield schon wesentlich besser als der Quad bei der PCGH mit dem Phenom II. Wo der Wurm da lag kann die PCGH nur selbst finden.

Ich schätze mal, dass es keinen Wurm gibt. Spätestens morgen Abend komme ich mit ganz anderen Werten (warts ab), die eine schlechtere Skalierung zeigen, oder irgendwas dazwischen.
Kann natürlich in dem Fall auch an der Architektur der Phenoms hängen. AMD hat ja hier die Finger im Spiel gehabt, damit auch 6 Kerne einwandfrei skalieren.
Was auch auffällt ist, dass die Skalierung im intergrierten Benchmark dennoch schlechter ist als tatsächlich Ingame. Das ist das was ich immer an solchen Benchmarks kritisiere. Man versucht im Falle von Dirt 3 zwar eine ähnliche CPU-Last zu simulieren, schafft es aber trotzdem nicht an die tatsächliche ranzukommen.

Welche Werte stellst du jetzt genau gegenüber?
Ist es im Spiel wirklich anders? Den integrierten Benchmark kann man ja nun kaum ähnlich im Spiel selbst erzeugen.
Wenn im Spiel die Skalierung besser ist, ja dann wo genau?
Ich glaube nicht, dass man das Fazit durch die bisherigen Vergleiche so fällen kann.

Zudem weiß ich noch nicht ob der intergrierte Benchmark im völligen CPU-Limit liegt.

Die 46% Zugewinn durch den 4 und 5. Thread/core sprechen dafür, die knapp 30% durch den 2 und 3 Thread/Core eher dagegen.
Tja, ich würde meinen das Benchen wirklich etwas verzwickt ist.
Zu verzwickt um soviel zu berücksichtigen.

dargo

2011-08-02, 22:09:35

Reagiert die KI eigentlich immer gleich, wenn sich der Spieler gleich verhält?
Ist eine gute Frage die ich dir nicht beantworten kann. Das ist übrigens ein weiterer Grund warum ich mich selbst nicht bewege und die Testdauer nur 5 Sekunden beträgt. Eben um exakte Reproduzierbarkeit zu gewährleisten. Und das zeigen mir auch die einzelnen Durchläufe. Sie weichen kaum von einander ab. Je nach Game und Szene sind die 4 Werte die ich ermittlere sogar nur hinter dem Komma abweichend.

@Dargo, wenn nicht ein unterschiedliches KI-Modell für Autos in Sicht und außerhalb verwendet wird, dann ändert sich nichts.

Falls doch, warte halt, bis Sie alle an dir vorbei fahren. Du kannst dann ja am Frameverlauf sehen, ob Gegner in Sicht oder nicht, etwas ausmachen.

Du machst den Fehler zu glauben die KI würde alleine für CPU-Last sorgen. Geometrie belastet die CPU ebenfalls. Sind alle Autos aus meinem Sichtfeld weg muss demensprechend auch weniger Geometrie berechnet werden.

y33H@

2011-08-02, 22:22:44

AI macht ziemlich wenig Rechenzeit aus, die Geometrie und die Vorarbeit für die Grafikkarte sind da viel bedeutender.

dargo

2011-08-02, 22:31:15

Also wenn die CPU theoretisch 20 % mehr leisten könnte, aber nur 8 %ankommen, heißt das für dich es besteht ein CPU limit?

In diesem Fall limitiert sowohl die CPU als auch die GPU. Wenn aber nur tatsächlich 8% ankommen überwiegt GPU-Limit. Es gibt nicht nur vollständiges CPU-oder GPU-Limit. Die Limits gehen fließend in einander über.

Heißt also auch im PCGH Dirt 3 Benchmark herrscht teilweise ein CPU limit, weil von 2 ab nicht alles einwandfrei hochskaliert?

Im Test der PCGH und Dirt 3 stimmt mit den Skalierungen grundsätzlich was nicht. Sollte die PCGH alles richtig gemacht haben habe ich die Phenom 2 Architektur trotz nativen Quad/Sixcore völlig überschätzt.

Und von diesem Standpunkt aus errechnest du dann in deinen sehr kurzen Sequenzen 80% IPC plus für Sandy vs. Yorkfield? Ich denke nicht, dass sowas funktioniert.

Da hast du was falsch verstanden. Die 84% kommen von meinem Test Q9550 vs. i5-750 in Resident Evil 5, den ich hier schon mal verlinkt habe.

Ich kann nicht folgen, warum du mir nicht folgen kannst. Du sagst vieles ist bei CB ist GPU limitiert, du sagst Civilization ist nicht GPU limitiert, der Vorsprung in Civilization von Sandy zu AMD ist aber nicht viel größer(3%) als der Durschnitt den CB am Ende raus hat, das war doch ganz trivial.
So und warum ist Civilization nun deiner Ansicht nach CPU limitiert?

Hatte ich doch ausführlich erklärt. :confused: Der i7-2600K 4C/4T taktet mit 3,4Ghz gegenüber dem i7-2600K 4C/4T @2,8Ghz 21% höher. In einer vollkommen cpu-limitierten Szene bei ansonsten gleichen Rahmenbedingungen skaliert die CPU immer 1:1 mit. Und somit erreicht sie auch mindestens 21% höhere Frames. Die 24% bei CB können wie gesagt Messschwankungen sein.

Wo siehst du nur 3% zwischen SB und AMD? Gib bitte immer Links an und genaue Angaben zu CPUs sonst verliert man völlig den Überblick.

Damit solche Aussagen treffen kanns, musst du dich vor allem mit dem Detail der Spieleprogrammierung auskennen, am besten selbst noch Prozessorhersteller sein und zugleich wohl bei der Grafikabteilung mitarbeiten bzw.. ein absoluter Guru sein, der solche wirklichen CPU- Limits erzeugen kann, was einen einwandfrei skalierbaren Code in genau dieser Szene vorraussetzt, etc.. etc...

Das ist einfacher als du glaubt wenn man sich etwas mit der Materie und praktischen Tests beschäftigt hat. :)

Na wenn da mal nicht etwas anderes limitiert hat. Wie wärs mit I/O oder Festplatte, oder Engine hänger, der die skalarität der CPU einschränkt?
5 Sekunden Benches und kurze Ausschnitte sagen meiner Meinung nach rein gar nichts aus und taugen schon gar nicht für irgendwelche Beweise.
Doch, sie sagen sehr viel aus und sichern sogar die Reproduzierbarkeit sehr gut.

AI macht ziemlich wenig Rechenzeit aus, die Geometrie und die Vorarbeit für die Grafikkarte sind da viel bedeutender.
Wie die Gewichtungen jetzt genau sind kann ich nicht sagen, die Physik sollte man aber ebenfalls nicht vergessen.

Schaffe89

2011-08-02, 22:35:08

Wo siehst du nur 3% zwischen SB und AMD? Gib bitte immer Links an und genaue Angaben zu CPUs sonst verliert man völlig den Überblick.

Na das 800x600 Performancerating vs. Civilization 4.
Die Abstände von Phenom II zu Sandy sind in etwa gleich, minimale Differenzen. Links sind alle weiter oben schon gepostet worden.
http://www.computerbase.de/artikel/prozessoren/2011/test-intel-sandy-bridge/46/#abschnitt_performancerating

Was für mich heißt, dass das CPU limit bei Computerbase mehr oder weniger relativ gut eingehalten wird.
War deine Kritik an Computerbase und deren 800x600 Benchmarks.
Um den Zusammenhang wiederherzustellen musst du vielleicht 1 oder 2 Seiten zurückblättern.

Doch, sie sagen sehr viel aus und sichern sogar die Reproduzierbarkeit sehr gut.

Nein, nicht im geringsten, das dürfte y33H@ selbst am Besten wissen.

Edit

Da hast du was falsch verstanden. Die 84% kommen von meinem Test Q9550 vs. i5-750 in Resident Evil 5, den ich hier schon mal verlinkt habe.

Da hab ich mich etwas falsch ausgedrückt.

dargo

2011-08-02, 22:37:18

Na das 800x600 Performancerating vs. Civilization 4.
Die Abstände von Phenom II zu Sandy sind in etwa gleich, minimale Differenzen. Links sind alle weiter oben schon gepostet worden.
Ich finde deine Links nicht. :freak: Wo hast du was mit Civilization 4?

Edit:
Achso... du meinst das Performancerating aller Games zusammen? Das ist noch viel schlimmer. Stell dir folgendes Szenario vor - der Reviewer testet 4 Games. CPU 1 ist tatsächlich 30% schneller als CPU 2 (bsw. i5-750 @2,66Ghz vs. i5-750@3,46Ghz).

Game 1:
Reviewer testet im absoluten CPU-Limit und kommt auf +30%.

Game 2:
Reviewer befindet sich im Test teilweise im hohen GPU-Limit und kommt auf +12%

Game 3:
Reviewer ermittelt +8%.

Game 4:
Reviewer emittelt +25%.

Performancerating aller 4 Games beträgt +18,75%. Mit dem Performancerating wird noch mehr geglättet. Dabei unterbietet das Gesamtrating schon mal das Ergebnis vom Game 1 und 4. Und das alles nur weil man teilweise in GPU-Limits getestet hat.

Welche Werte stellst du jetzt genau gegenüber?

Die der PCGH @intergrierter Benchmark:
http://www.pcgameshardware.de/aid,825548/Zum-Release-Dirt-3-im-Technik-Test-Sechs-CPU-Kerne-im-Vorteil-gelungener-DirectX11-Modus/Rennspiel-Sportspiel-Simulation/Test/

versus:
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=6973307&postcount=3

Letzteres ist Ingame. Dabei geht es mir nicht um die tatsächlichen fps sondern um die Skalierungen DC vs. QC.

Ich schätze mal, dass es keinen Wurm gibt. Spätestens morgen Abend komme ich mit ganz anderen Werten (warts ab), die eine schlechtere Skalierung zeigen, oder irgendwas dazwischen.
Kann natürlich in dem Fall auch an der Architektur der Phenoms hängen. AMD hat ja hier die Finger im Spiel gehabt, damit auch 6 Kerne einwandfrei skalieren.

Sowas gibt es nicht und ergibt auch gar keinen Sinn. Wenn ein Spiel mit einem Sixcore so gut zulegt wie laut der PCGH gegenüber dem Quadcore muss der Quad gegenüber einem Dualcore nahezu 100% zulegen. Ich würde hier einfach den "Nachtest" von y33H@ abwarten.

Edit:
Je mehr ich mir die tatsächlichen Frames der PCGH mit dem Phenom 2 1090T anschaue umso mehr bin ich davon überzeugt, dass irgendwo im System der Wurm war.

Phenom 2 1090T @Quadcore = 69,4 avg.fps
i5-750 @3,61Ghz @Quadcore = ~148 avg.fps

Beim gleichen Takt kommt der 1090T auf 78fps. Der i5 wäre somit 90% schneller als der Phenom 2? :| Sowas halte ich schlicht für unmöglich.

Wird nachgetestet.

Ich wiederhole mich nochmal - wenn ein Nehalem in einem Spiel wesentlich weniger zulegt als die Angaben die ich gemacht habe dann gibt es dafür nur zwei Gründe:

1. GPU-Limit
2. Spielengine skaliert schlecht mit mehr als 2 Cores.

Punkt zwei habe ich doch schon ausgiebig erläutert. Schau dir doch einfach die Skalierungen der beiden CPUs genauer an.

http://img402.imageshack.us/img402/8649/residentevil5.png

http://img696.imageshack.us/img696/6112/residentevil5i52.png
Der schnellste Quadcore beim Q9550 legt gegenüber dem Dualcore gerade mal um 37% zu. Der schnellste Quadcore beim i5-750 legt um 85% zu. Verstehst du jetzt worauf ich hinaus will? Als ich RE5 getestet habe sind mir erst die extremen Limitierungen der Doppel-Dualcore-Architektur klar geworden. Das war auch ein Grund warum ich schnell zum Lynnfield umgestiegen bin.

Auf diesen Punkt möchte ich nochmal gezielter eingehen. Mir fällt gerade ein Szenario ein von früher welches gut zum Thema passt. Ich hatte damals als ich den Q9550 noch besaß mit Hilfe vom Taskmanager hohe CPU-Auslastung in Games gesucht um entsprechende Savegames zu finden. Ich kann mich noch sehr gut an eine Szene aus dem Spiel Timeshift erinnern. Man wurde unter anderem von einem Roboter angegriffen. Kurz das Spiel pausiert und auf den Desktop geswitscht um die CPU-Auslastung zu checken. Alle 4 Cores waren praktisch am Anschlag. In erster Linie denk man sich das Spiel bzw. die Szene profitiert sehr gut von 4 Cores. Als ich dann die Frames gemessen habe (DC vs. QC) kam die Ernüchterung. Die gleiche Szene lieferte quasi die selben Frames mit dem Dualcore und dem Quadcore.
Das Problem beim Taskmanager ist nämlich, dass der TM CPU-Last als solche definiert, auch wenn die CPU intern wartet (hier kommt wieder der Flaschenhals FSB vom dopellten Dualcore ins Spiel). Die gleiche Szene später mit dem Lynnfield getestet und die Anzeige vom Taskmanager stimmt plötzlich. Alle 4 Cores lagen bei ~50% Last, sprich Auslastung von max. 2 Cores. Dass die CPU-Last gleichmäßig auf 4 Cores verteilt wurde liegt an Windows.

Was ich damit sagen will - der Taskmananger ist beim doppelten Dualcore kein Indiz für die tatsächlich anliegende CPU-Last, beim Lynnfield kann man sich auf den aber durchaus verlassen.

Captain Future

2011-08-03, 10:26:19

Wo der Wurm bei diesem Test liegt wird dir nur die PCGH sagen können. Da ist garantiert was schief gelaufen.

Muss nicht, kann aber. Soweit ich weiß, nutzt die Ego-Engine 4- oder 8-core-mapper via XML. Ich weiß natürlich nicht, was PCGH da genommen hat.

Mal angenommen, es ist die 8-core XML: Da werden unterschiedliche Prozesse auf einzelne CPU-Kerne verteilt, was ja sinnvoll ist. Sind aber weniger Kerne da als vorgesehen (wie zum Beispiel, wenn nach Installation auf einem 6-kerner via windows-config auf einmal nur noch zwei da sind...), werfen sich die Prozesse beim Kampf um die Kerne gegenseitig aus den Caches. Deswegen kommt Intel ab Core-i-Serie hier auch so gut weg, selbst wenn sie auf zwei Kerne beschränkt werden: deren Cache-Performance ist weit höher als bei AMD.

Anderes Paradebeispiel: Intels Icestorm-Fighter Benchmark.

http://www.forum-3dcenter.org/vbulletin/showpost.php?p=6973307&postcount=3

Dazu noch etwas. Dein Versuch, via BCLK Uncore etc. auszuschließen in allen Ehren, aber gerade bei echten In-Game-Benchmarks rennst du bei den niedrigen Takten da in ein anderes Problem, sobald eine Physik-Engine zum Einsatz kommt. Diese ist i.d.R. deterministisch, das heißt, braucht eine konstante Rechenzeit. Daher skalieren mehr Kerne bei niedrigem Takt i.d.R. besser als mit hohem Takt, weil da der Physik-Einfluss stärker wiegt.

Billiges Beispiel:
Angenommen, du hast pro kern 1 GHz Rechen"leistung" zur Verfügung; die Physik "braucht" (jaja...) 0,5 GHz. Bei einem Einkerner macht das 50 % aus, bei einem Dualcore 25% bei einem 4Kerne nur noch 12,5%.

Edit:
Je mehr ich mir die tatsächlichen Frames der PCGH mit dem Phenom 2 1090T anschaue umso mehr bin ich davon überzeugt, dass irgendwo im System der Wurm war.

Phenom 2 1090T @Quadcore = 69,4 avg.fps
i5-750 @3,61Ghz @Quadcore = ~148 avg.fps

Beim gleichen Takt kommt der 1090T auf 78fps. Der i5 wäre somit 90% schneller als der Phenom 2? Sowas halte ich schlicht für unmöglich.

Woher sind diese Werte nun?

P.S.: Ich sehe, PCGH hat nicht den integrierten Benchmark direkt genommen, sondern ab Start des Rennens gefrapst. Damit sind die (vermutlich nicht sehr cpulastigen) Introsequenzen raus aus der Gleichung. Außerdem ist, beinahe wie vermutet, eine 6core.xml am Start... qed.

dargo

2011-08-03, 11:15:44

Muss nicht, kann aber. Soweit ich weiß, nutzt die Ego-Engine 4- oder 8-core-mapper via XML. Ich weiß natürlich nicht, was PCGH da genommen hat.

Dirt 3 nimmt sich automatisch die entsprechende XML entsprechend der "angemeldeten" Cores in Windows.

Dazu noch etwas. Dein Versuch, via BCLK Uncore etc. auszuschließen in allen Ehren, aber gerade bei echten In-Game-Benchmarks rennst du bei den niedrigen Takten da in ein anderes Problem, sobald eine Physik-Engine zum Einsatz kommt. Diese ist i.d.R. deterministisch, das heißt, braucht eine konstante Rechenzeit. Daher skalieren mehr Kerne bei niedrigem Takt i.d.R. besser als mit hohem Takt, weil da der Physik-Einfluss stärker wiegt.

Ich versuche den Uncore und die Speicherbandbreite nicht auszuschließen. Ich skaliere sie 1:1 mit damit eine möglichst genaue 1:1 Skalierung gewährleistet ist.
Die Hintergünde zur Grundlast sind mir durchaus bekannt. Wir hatten hier im Forum die Einzelheiten dazu schon vor paar Jahren diskutiert. Deshalb teste ich auch wie hoch der Dualcore takten muss um auf die gleichen Frames wie der Quadcore zu kommen. So erkennt man wo noch eine hohe Grundlast herrscht. Außerdem teste ich mit zwei verschiedenen Taktraten. Damit erkennt man auch schon ob man sich bei der langsameren CPU im Bereich der Grundlast befindet.

Woher sind diese Werte nun?

Aus dem intergrierten Benchmark vom Spiel Dirt 3.

P.S.: Ich sehe, PCGH hat nicht den integrierten Benchmark direkt genommen, sondern ab Start des Rennens gefrapst. Damit sind die (vermutlich nicht sehr cpulastigen) Introsequenzen raus aus der Gleichung. Außerdem ist, beinahe wie vermutet, eine 6core.xml am Start... qed.
Hoppala... du hast völlig recht. Ich habe den kleinen aber sehr wichtigen Hinweis völlig übersehen.
Da es aus technischen Gründen derzeit nicht möglich ist, eigene Strecken samt KI als Benchmark via XML-Datei zu erstellen, greifen wir für unsere Benchmarks (vorerst) auf den integrierten Leistungstest mit der verschneiten Strecke "Aspen" samt KI-Gegnern zurück und messen mit Fraps die ersten 30 Sekunden ab dem Start des Rennens.
Ok... bitte meine Werte vom i5-750 oben gleich wieder vergessen. Ich benche später wenn ich zu Hause bin nochmal mit Fraps nach.

Captain Future

2011-08-03, 11:51:41

Dirt 3 nimmt sich automatisch die entsprechende XML entsprechend der "angemeldeten" Cores in Windows.
Wenn man es nicht via schreibgeschützter Ini-Datei o.ä. zu etwas anderem zwingt...

Ich versuche den Uncore und die Speicherbandbreite nicht auszuschließen. Ich skaliere sie 1:1 mit damit eine möglichst genaue 1:1 Skalierung gewährleistet ist.
Ja, das meinte ich, sorry.

Die Hintergünde zur Grundlast sind mir durchaus bekannt. Wir hatten hier im Forum die Einzelheiten dazu schon vor paar Jahren diskutiert. Deshalb teste ich auch wie hoch der Dualcore takten muss um auf die gleichen Frames wie der Quadcore zu kommen. So erkennt man wo noch eine hohe Grundlast herrscht. Außerdem teste ich mit zwei verschiedenen Taktraten. Damit erkennt man auch schon ob man sich bei der langsameren CPU im Bereich der Grundlast befindet.
Der höher taktende Dualcore hat dafür dann aber noch andere Vorteile. Zumindest auf die letzte Prozentstelle würde ich bei der Methode auf jeden Fall nicht mehr schielen. :)

Aus dem intergrierten Benchmark vom Spiel Dirt 3.
Also von dir selbst auf vergleichbare Weise gemessen? Dann ist ja gut.

Ich benche später wenn ich zu Hause bin nochmal mit Fraps nach.
Ich bin gespannt!

dargo

2011-08-03, 12:03:30

Der höher taktende Dualcore hat dafür dann aber noch andere Vorteile. Zumindest auf die letzte Prozentstelle würde ich bei der Methode auf jeden Fall nicht mehr schielen. :)

Welche denn? Der simulierte Dualcore hat im Prinzip den einzigen Vorteil auf den vollen L3 Cache zugreifen zu können. Das ist mir auch bewußt. Ich sage auch nicht, dass meine Vergleiche zu 100% korrekt sind. 97-99% reichen mir schon. :) Optimal wäre es natürlich wenn ich den L3 Cache beim DC halbieren könnte, geht aber leider nicht.

Also von dir selbst auf vergleichbare Weise gemessen?
Genau. Nur wie du richtig erkannt hast sind die Werte nicht vergleichbar da ich den ganzen Benchmark durchlaufen lassen habe und die PCGH nur die ersten 30 Sekunden.

Schaffe89

2011-08-03, 12:09:48

Letzteres ist Ingame. Dabei geht es mir nicht um die tatsächlichen fps sondern um die Skalierungen DC vs. QC.

Ich hab mich bezüglich solcher Zusammenhänge mal mit einem Spieleentwickler unterhalten und der sagte nur ganz banal, dass es sehr viele Parameter gibt, unter anderem diese, welche Captain Future weiter oben anspricht, also stimmen deine Benchmarks mindestens genausowenig wie diese von PCGH, allein deswegen schon, weil du nur 5 sekunden benchst und sich jede Szene unterschiedlich verhält.

Ansonsten, mal danke für die Zeit die du investierst, das hat auch mein Interesse geweckt.

Sowas gibt es nicht und ergibt auch gar keinen Sinn. Wenn ein Spiel mit einem Sixcore so gut zulegt wie laut der PCGH gegenüber dem Quadcore muss der Quad gegenüber einem Dualcore nahezu 100% zulegen.

Klar ergibt das Sinn. Oder weißt du wie die Engine die versch. Lasten auf die CPU verteilt?

6core.xml am Start... qed.

Captain Future

2011-08-03, 12:11:26

Cache - klar. Aber auch innerhalb der Pipeline geht mit höherem Takt alles eben schneller bei seriellen Aufgaben. Aber wenn du dir auch klar darüber bist, dass keine 100% genauen Werte herauskommen (ob nun 97, 99 oder 95 weiß ich natürlich auch nicht), dann ist ja gut.

Wegen deiner beiden Dirt3-Werte: Untereinander sind die dann aber schon vergleichbar.

dargo

2011-08-03, 12:29:08

Ich hab mich bezüglich solcher Zusammenhänge mal mit einem Spieleentwickler unterhalten und der sagte nur ganz banal, dass es sehr viele Parameter gibt, unter anderem diese, welche Captain Future weiter oben anspricht, also stimmen deine Benchmarks mindestens genausowenig wie diese von PCGH, allein deswegen schon, weil du nur 5 sekunden benchst und sich jede Szene unterschiedlich verhält.

Du bist mir immer noch eine Erklärung schuldig warum eine 5 Sekunden lange Testszene (die von mir 4 mal gemessen und davon der Durchschnitt der avgs. genommen wird) nicht aussagekräftig ist, dafür aber eine längere? Zudem kommen bei den einzelnen Messungen praktisch die gleichen Ergebnisse heraus.

Klar ergibt das Sinn. Oder weißt du wie die Engine die versch. Lasten auf die CPU verteilt?
Ich lasse das erstmal offen bis ich die 30 Sekunden von Dirt 3 gemessen habe.

Aber auch innerhalb der Pipeline geht mit höherem Takt alles eben schneller bei seriellen Aufgaben. Aber wenn du dir auch klar darüber bist, dass keine 100% genauen Werte herauskommen (ob nun 97, 99 oder 95 weiß ich natürlich auch nicht), dann ist ja gut.

Ob das so stimmt und inwieweit eine Abweichung vorhanden ist weiß ich nicht. Mehr Einfluss als die "Flaschenhälse" 1:1 mitskalieren zu lassen habe ich nicht. Unter diesem Aspekt ist dann aber der nötige Dualcore um auf die gleichen Frames des Quadcore zu kommen sogar minimal im Vorteil. Das heißt, der Quad skaliert sogar etwas besser als meine Messungen zeigen.

Skysnake

2011-08-03, 12:38:58

Du vergisst aber komplett die Datenlokalität!

Die ist bei einem Quadcore deutlich höher als bei einem fiktiven Dualcore, der den gleichen L3 hat wie der Quadcore, einfach weil es um die Daten im L1/L2 geht. Von denen hast du weniger bei dem fiktiven Dualcore. Damit sinkt die Datenlokalität, und die Bandbreitenanforderung an den L3 explodiert. Ebenso die Anforderung an den L2.

Und solche Sachen wirken sich teils extrem auf die Performance aus. Da kannst du schnell mal einen Faktor 2 verlieren....

y33H@

2011-08-03, 12:49:52

Hast du das mal gebencht oder hast Links dazu?

dargo

2011-08-03, 12:57:29

@Skysnake

Hast du zufällig meinen kleinen Hinweis überlesen?
Deshalb teste ich auch wie hoch der Dualcore takten muss um auf die gleichen Frames wie der Quadcore zu kommen.

Verdoppele ich den Takt vom Dualcore verdoppelt sich auch der Cache-Takt. Außerdem hätte ich gerne eine Quelle für deinen imho völlig aus der Luft gegriffenen Faktor 2.

Captain Future

2011-08-03, 13:44:38

Da reicht's doch schon, wenn du - bei einem CPU ohne L3 - Daten aus dem RAM nachladen musst. Ich hoffe, Xbit erlaubt das hotlinking:
http://www.xbitlabs.com/images/cpu/intel-core-i7/core2-mem.png

Skysnake

2011-08-03, 13:58:24

@Skysnake

Hast du zufällig meinen kleinen Hinweis überlesen?

Verdoppele ich den Takt vom Dualcore verdoppelt sich auch der Cache-Takt. Außerdem hätte ich gerne eine Quelle für deinen imho völlig aus der Luft gegriffenen Faktor 2.

Das ist nicht aus der Luft gegriffen. Schreib dir einfach mal ein Testprogramm, das einmal in eine Cachestufe passt und das andere mal knapp drüber raus geht. Ganz nett sind auch Testprogramme, bei denen du jedes mal die Cacheline neu laden musst. Da bist du schnell bei nem Faktor 10 und mehr. Das sind schlicht Erfahrungswerte, die man halt eingebläut bekommt mit der Zeit und auch teils durch Beispielprogramme in der Uni gezeigt bekommt. Kannst das schon glauben.

Wenn nicht, schau dir einfach mal die Latenzen von verschiedenen Cache-Stufen an, und wie diese arbeiten.

Zudem, was hat der Takt mit der Datenlokalität zu tun?

Bevor ich jetzt groß aushole, weißt du überhaupt was ich damit meine?

dargo

2011-08-03, 14:30:16

Da reicht's doch schon, wenn du - bei einem CPU ohne L3 - Daten aus dem RAM nachladen musst. Ich hoffe, Xbit erlaubt das hotlinking:
http://www.xbitlabs.com/images/cpu/intel-core-i7/core2-mem.png
Findest du nicht, dass ich solche gravierenden Unterschiede merken würde? Ich wiederhole mich gerne nochmal. Die einzelnen Durchläufe weichen bei den Frames kaum voneinander ab.

Edit:
Das gilt auch für dich Skysnake. Wenn du mir schon mit viel Theorie kommst dann mach dir wenigstens die Mühe meine Ergebnisse in der Praxis umzusetzen und sie gegebenfalls in Frage zu stellen. Nur mit Theorie schaffst du das bei mir nämlich nicht.

Captain Future

2011-08-03, 14:35:21

dargo

2011-08-03, 14:42:55

Das mag ja sein, ändert aber nichts an der Tatsache, dass die schnellsten Speicherzugriffe bei mehreren seriellen Aufgaben bei zusätzlichen Kernen einfach öfter stattfinden können eben weil die Speichergröße pro Aufgabe höher ist.

Natürlich haut dir das i.d.R. nicht die komplette Anwendung um Faktor 2 runter. Aber es trägt, wie auf der anderen Seite ein paar Vorteile durch die schnellere serielle Pipeline, nicht gerade dazu bei, hier Architekturen wirklich vergleichen zu können.
Moment mal... wenn ich dich hierbei richtig verstehe macht ein Test im Spiel XY zwischen einem bsw. Yorkfield und einem Lynnfield keinen Sinn weil letzterer zusätzlich einen L3 Cache hat? Oder zwischen einem Dualcore und Quadcore weil letzterer doppelt soviele Kerne hat? Ist es für den Spieler nicht egal wie die jeweilige CPU ihre Leistung entfaltet? Für den zählt doch nur was hinten rauskommt, nämlich die Framerate. Und zwar aus der Kombination CPU, Chipsatz, Mainboard und Arbeitsspeicher. Da spielen Cachegrößen, Kerne, Latenzen etc. für den Spieler doch überhaupt keine Rolle. Nur was hinten an fps rauskommt zählt.

Skysnake

2011-08-03, 14:44:23

Wenn du aber einmal zwei Threads komplett im L2 Cache halten kannst, und das andere mal eben die zwei Threads zusammen nicht mehr in den L2 passen, dann ist der Leistungsverlust sehr deutlich.

Captain Future

2011-08-03, 14:49:10

@dargo:
Nee, aber es macht keinen Sinn, Kerne bei verschiedenen Architekturen künstlich abzuschalten und daraus dann Schlüsse zu ziehen, die auf Werten basieren, welche durch die genannten, anderen Faktoren beeinflusst werden.

Schaffe89

2011-08-03, 14:55:36

Du bist mir immer noch eine Erklärung schuldig warum eine 5 Sekunden lange Testszene

a) Die KI verursacht andere Lastzustände, das Spiel verteilt die Last auf die Threads eventuell bei sekunde 6 oder 7... anders und dann skaliert da eventuell gar nichts mehr so gut.
Ich bin kein Freak, aber um zu wissen, dass 5 sekunden für eine vernünftige Betrachtungsweise, bzw IPC Einschätzung in Spielen nicht ausreichen, bin ich denke ich noch gut genug.
Wenn überhaupt braucht man eine ausgewogene FPS Betrachtung mit höhen und tiefen, aber alles am besten IM CPU limit und dann den Schnitt daraus nehmen, keine 5 sekunden.
DAs kann ein ganz fieser Leistungspeak sein, wenn die Skalierung da so gut ist.

Es gibt mit Sicherheit relativ viele Sequenzen oder Szenen, welche besonders gut skalieren, man nehme mal das PCGH Savegame bei BC2, wo sehr viel Last auf der CPU liegt.
Phenom II Kerne skalieren relativ gut.

Andere benches von anderen Seiten zeigen wieder keine Skalierung der Phenom II Threads 4 und 5, selbst nahezu im CPU limit.

dargo

2011-08-03, 15:24:36

Hier mal die versprochenen Werte vom intergrierten Benchmark in Dirt 3.

Lynnfield i5-750 @3,61Ghz (20x 180,5 BCLK), Speicher @722Mhz, GTX480 @830/2000Mhz mit 640x480 1xAA/1xAF, max. Details

Aufnahmezeit 30 Sekunden vom Start an (ab Bewegung der Fahrzeuge).

Quadcore:
erster Durchlauf - min. 120fps, avg. 146,033fps
zweiter Durchlauf - min. 116fps, avg. 141,300fps

Dualcore:
erster Durchlauf - min. 63fps, avg. 73,833fps
zweiter Durchlauf - min. 63fps, avg. 76,20fps

Phenom 2 1090T bei der PCGH (http://www.pcgameshardware.de/aid,825548/Zum-Release-Dirt-3-im-Technik-Test-Sechs-CPU-Kerne-im-Vorteil-gelungener-DirectX11-Modus/Rennspiel-Sportspiel-Simulation/Test/)

Quadcore:
min. 55fps
avg. 69,4fps

Dualcore:
min. 44fps
avg. 53,3fps

Am Verhältnis Lynnfield zu Phenom 2 ändert sich nicht viel. Sind beim Quad immer noch satte +84% (143,5fps vs. 78fps, der Phenom 2 kommt hochgerechnet mit 3,61Ghz auf 78 avg.fps). Was auffällt - die Skalierung vom Lynnfield zwischen 4 und 2 Cores ist nochmal deutlich besser in den ersten 30 Sekunden vom intergrierten Benchmark als im gesamten Benchmark. Die Skalierungswerte decken sich schon fast mit meinen Ergebnissen über das Savegame. Das heißt also nichts anderes, dass der hintere Teil vom Benchmark schon zum Teil gpu-limitiert ist, zumindest in der Konstellation Lynnfield @3,61Ghz und GTX480 @830/2000Mhz. In den ersten 30 Sekunden nur minimal.

Jetzt stelle ich nochmal die Frage warum der Phenom II von 2 auf 4 Cores so schlecht in diesem Test skaliert? Ich hoffe y33H@ geht darauf gezielter ein. Wir bräuchten die neuen (korrekten?) Werte.

@dargo:
Nee, aber es macht keinen Sinn, Kerne bei verschiedenen Architekturen künstlich abzuschalten und daraus dann Schlüsse zu ziehen, die auf Werten basieren, welche durch die genannten, anderen Faktoren beeinflusst werden.
Wenn ich Vergleiche zwischen Yorkfield und Lynnfield ziehe dann vergleiche ich weder Yorkfield @2 Cores vs. Lynnfield @4 Cores noch Yorkfield @4 Cores vs. Lynnfield @2 Cores. Die Vergleiche beziehen sich immer auf die gleiche Anzahl der Cores.

Skysnake

2011-08-03, 15:34:50

Schon mal an Cache gedacht? :rolleyes:

Intel: Inklusive AMD exklusive im L3

dargo

2011-08-03, 16:00:51

a) Die KI verursacht andere Lastzustände, das Spiel verteilt die Last auf die Threads eventuell bei sekunde 6 oder 7... anders und dann skaliert da eventuell gar nichts mehr so gut.

Ich lese immer wieder eventuell, vielleicht etc. Alles nur Vermutungen. Ich wiederhole mich gerne nochmal - würden die Lastzustände derart stark abweichen, dass es gravierende Unterschiede zwischen den einzelnen Messungen gibt würde ich das an den Ergebnissen sehen. Die KI ist meist gescriptet. Ich hatte aber schon einen Fall (ich glaube DIRT 2 war das), dass die KI, obwohl ich mich nicht vom Fleck gerührt habe, aufeinander nach wenigen Metern etwas anders reagiert hat. In einem Durchlauf fuhren quasi alle schön nach vorne, im nächsten Durchlauf gabs nach wenigen Metern einen Crash. Im zweiten Fall sah man auch einen etwas größeren Unterschied bei den Frames. Beispiel - anstatt 85 avg.fps 81 avg.fps. Die genauen Werte weiß ich nicht mehr. Wenn solche Fälle auftreten wiederhole ich die Tests bis die Werte näher aneinander liegen. So kommt es in seltenen Fällen vor, dass ich bis zu 12 Durchläufen mache (den ersten Durchlauf erfasse ich übrigens nie wegen eventuellen Nachladerucklern, die ich allerdings praktisch nie erlebe, trotzdem gehe ich hierbei auf Nummer sicher) bis ein für mich brauchbares Ergebnis vorhanden ist. Außerdem sehe ich auf dem Bildschirm starke Abweichungen bei der KI wie zb. den genannten Crash.

Ich bin kein Freak, aber um zu wissen, dass 5 sekunden für eine vernünftige Betrachtungsweise, bzw IPC Einschätzung in Spielen nicht ausreichen, bin ich denke ich noch gut genug.
Wenn überhaupt braucht man eine ausgewogene FPS Betrachtung mit höhen und tiefen, aber alles am besten IM CPU limit und dann den Schnitt daraus nehmen, keine 5 sekunden.
DAs kann ein ganz fieser Leistungspeak sein, wenn die Skalierung da so gut ist.

Das beste wäre natürlich mehrere kurze Szenen zu wählen. Ich erkläre dir aber gerne warum ich mich nur auf eine pro Spiel beschränke. Die Arbeit mit Savegames erfordert enorm viel Zeit. Man muss erstmal entsprechende Szenen im Spiel suchen wo viel los ist. Wenn ich einfach nur überspitzt in den Himmel schaue kommt dabei selbstverständlich keine hohe CPU-Last zustande. Dann ziehen immer mehr Entwickler einem einen Strich durch die Rechnung weil sie kein freies Speichern in Spielen anbieten. Da wird es zur Qual eine entsprechende Szene zu finden die auch reproduzierbar ist. Die Spiele die getestet werden müssen zwar nicht komplett durchgespielt, aber zumindest eine gewisse Zeit angespielt werden um entsprechende Savegames zu finden. Wenn du der Meinung bist eine gute Stelle gefunden zu haben musst du nochmal Gegentests anstellen um zu sehen ob du dich überhaupt im absoluten CPU-Limit befindest. Hast du das alles gefunden musst du mindestens mit zwei verschiedenen Taktraten testen und zusätzlich den erforderlichen Takt beim Dualcore finden um mit dem Quad gleichzuziehen damit du eventuelle Auswirkungen der Grundlast sehen kannst.

Versuche das mal mit 2-3 Games und dann 4-5 Stellen und ich garantiere dir du wirst gleich wieder aufgeben. Der Zeitaufwand ist einfach brutal. Du kannst meine Ergebnisse aber auch gerne anders interpretieren. Wenn ich von 80% spreche dann kannst du es gerne als bis zu 80% sehen. Wobei das auch nicht ganz korrekt wäre, denn ich kann dir nicht garantieren, dass meine Szenen absolute Worst Cases sind. Heißt also, in einer anderen Szene könnten u.U. etwas mehr als 80% drin sein.

Es gibt mit Sicherheit relativ viele Sequenzen oder Szenen, welche besonders gut skalieren, man nehme mal das PCGH Savegame bei BC2, wo sehr viel Last auf der CPU liegt.
Phenom II Kerne skalieren relativ gut.

Mit Sequenzen verbinde ich immer Cutscenen. Cutszenen (natürlich in Spielgrafik) eignen sich für solche Tests überhaupt nicht. Das sind stinknormle Timedemos wo ein großer Teil der CPU-Last einfach nicht vorhanden ist. Quasi vorgerechnete Szenen.
Die Szene in BC2 der PCGH habe ich selber bei mir nachgestellt und kann dir versichern, dass sie zum großen Teil noch stark gpu-limitiert ist. Das ist auch die Gefahr in die man sich begibt bei so langen Testszenen.

Schon mal an Cache gedacht? :rolleyes:

Intel: Inklusive AMD exklusive im L3
Beide haben einen shared L3 Cache. Was meinst du genau mit inklusiv und exklusiv?

Aber mal völlig davon abgesehen - was interessiert den Spieler wie bsw. irgendein Cache angebunden ist oder was auch immer? Den Spieler interessiert nur was hinten rauskommt. Stimmen also die Werte in Dirt 3 tatsächlich beim Phenom 2 wie sie bei der PCGH zu finden sind ist die Architektur vom Phenom 2 trotz nativen Quadcore/Sixcore die absolute Katastrophe. Ähnlich katastrophal wie beim doppelten Dualcore von Intel.

Wenn du aber einmal zwei Threads komplett im L2 Cache halten kannst, und das andere mal eben die zwei Threads zusammen nicht mehr in den L2 passen, dann ist der Leistungsverlust sehr deutlich.
Wie oft muss ich dir noch sagen, dass zwischen meinen Messungen es keine deutlichen Leistungsunterschiede gibt? In keinem einzigen Spiel. Und ich habe schon Spiele im hohen zweistelligen Bereich untersucht (seit 5 Jahren). Dir würde wirklich etwas Praxis gut tun anstatt ständig mit Theorie um sich zu werfen.

Naitsabes

2011-08-03, 17:04:29

Beide haben einen shared L3 Cache. Was meinst du genau mit inklusiv und exklusiv?

Inklusiv (INTEL): Die Inhalte des L1 und L2 Caches finden sich ALLE auch im L3
Exklusiv (AMD [bisher, ich kann mir bei BD einen inklusiven L2 und exklusiven L3 vorstellen]): Die Inhalte der Caches sind NICHT doppelt vorhanden -> was im L3 ist, ist NICHT im L2 oder L1 zu finden und was im L1 oder L2 ist, ist auch nicht im L3.

dargo

2011-08-03, 17:06:52

Vielen Dank Naitsabes für die Erklärung. :)

Captain Future

2011-08-03, 17:10:42

Wenn ich Vergleiche zwischen Yorkfield und Lynnfield ziehe dann vergleiche ich weder Yorkfield @2 Cores vs. Lynnfield @4 Cores noch Yorkfield @4 Cores vs. Lynnfield @2 Cores. Die Vergleiche beziehen sich immer auf die gleiche Anzahl der Cores.
Yeeee. Das meine ich nicht. Du kannst halt nicht sagen, wenn Yorkfield von Dual auf Quad mit 30% skaliert, Lynnfield aber mit 45%, dass Yorkfield Crap ist und das alles auf den FSB schieben.

y33H@

2011-08-03, 17:13:06

Bulldozer hat ein "mostly inclusive"-Design bei L1/L2:

The AMD Family 15h processor has one shared L2 cache per compute unit. This full-speed on-die L2 cache is mostly inclusive relative to the L1 cache. The L2 is a write-through cache. Every time a store is performed in a core, that address is written into both the L1 data cache of the core the store belongs to and the L2 cache (which is shared between the two cores).

[...]

The L3 cache is considered a non-inclusive victim cache architecture optimized for multi-core AMD processors. Only L2 evictions cause allocations into the L3 cache. Requests that hit in the L3 cache can either leave the data in the L3 cache—if it is likely the data is being accessed by multiple cores—or remove the data from the L3 cache (and place it solely in the L1 cache, creating space for other L2 victim/copy-backs), if it is likely the data is only being accessed by a single core.

http://support.amd.com/us/Processor_TechDocs/47414.pdf

dargo

2011-08-03, 17:19:18

Yeeee. Das meine ich nicht. Du kannst halt nicht sagen, wenn Yorkfield von Dual auf Quad mit 30% skaliert, Lynnfield aber mit 45%, dass Yorkfield Crap ist und das alles auf den FSB schieben.
Genau das belegt doch mein Gegentest mit 2,21Ghz. Den kennst du vermutlich noch nicht.
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=7713240&postcount=253

Im Prinzip limitiert stark die Kombination aus FSB und Speicherbandbreite. Wie die Gewichtungen tatsächlich sind lasse ich offen. Ich vermute, dass der FSB stärker limitiert.

Edit:
Eine Erhöhung um 41% des FSB-Taktes und der Speicherbandbreite bei ansonsten gleichem CPU-Takt resultiert in 30% höheren Frames beim Quadcore. Ich nenne sowas einen riesen Flaschenhals.

Edit: 2
Eigentlich ist hier die Gewichtung bei den Limitierungen durchaus erkennbar. Sorry, habs auf den ersten Blick nicht sofort gesehen. Sind ja immerhin schon fast 2 Jahre her.
Im dritten Edit erhöhe ich nur den FSB um 20%, die Speicherbandbreite bleibt identisch. 20% höherer FSB resultiert beim Quad in 10% höheren Frames. Dh. hier limitiert sowohl der FSB als auch die Speicherbandbreite ungefähr im gleichen Maße. Wohlgemerkt bei einem 6-er CPU-Multi. Der Q9550 hat original einen 8,5-er CPU-Multi. Heißt, mit orginalen CPU-Multi wirken sich die beiden Flaschenhälse noch stärker aus.

Skysnake

2011-08-03, 18:07:22

Damit ist gemeint, dass Intel ab der Core i Serie den Inhalt des L1 und L2 Caches im L3 vorhält. Du hast also weniger L3 effektiv zur Verfügung als angegeben. Wenn du aber z.b. Kerne deaktivierst, dann steigt der nutzbare L3 wieder an (sollte zumindest so sein, wie ich die Sache verstanden habe. Genaues kann dir aber wohl nur Intel dazu sagen)

Bei AMD werden beim Phenom I/II die Daten des L1 und L2 nicht im L3 vorgehalten. WEnn du also Kerne deaktivierst/weniger hast, dann sinkt sofort deine Datenlokalität ab.

Da Caches aber transparent für den Programmierer sind, kann man nie sagen, wann jetzt wo wie was gecached wird. Kurze Szenen sind daher auch unbrauchbar, da man eben GENAU die Szene erwischen kann, in der CPU A die Daten schon im Cache hat, und optimal arbeitet CPU B aber grad alles unglücklicherweise ausgelagert hat und nachladen muss. Ein paar Sekunden später kann es aber wieder genau anders rum aussehen.

Captain Future

2011-08-03, 18:39:21

Naja, solange die Fps wie dargo sagt, reproduzierbar sind, dürfte das wohl passen. Denn selbst eine 50-cycle penalty, um eine Cacheline aus dem Speicher zufüllen ist prozentual auf 5 Sekunden nur ein verschwindend geringer Teil.

dargo,
Dein Link beinhaltet aber auch einen Link zu PCGH. Dort sind die Skalierungen zwischen E6600/Q6600 und E8400/Q9650 jedenfalls sehr widersprüchlich. Bei dir kann auch mit reinspielen, dass du unterhalb des FSB-Strap von 266 benchst und darüber dann einmal synchron und einmal asynchron - gerade bei FSB-Flaschenhälsen ist das ein wichtiger Faktor.

dargo

2011-08-03, 19:06:38

Naja, solange die Fps wie dargo sagt, reproduzierbar sind, dürfte das wohl passen. Denn selbst eine 50-cycle penalty, um eine Cacheline aus dem Speicher zufüllen ist prozentual auf 5 Sekunden nur ein verschwindend geringer Teil.

So ist es. Zumal ich gesagt habe, dass meine Werte zwischen DC und QC beim Lynnfield nicht exakt 100% passen können weil eben der DC dann den vollen L3 Cache zur Verfügung hat. Es ist schon paradox von Skysnake lesen zu müssen meine Testmethode wäre unbrauchbar weil ich eine Genauigkeit von 9x% liefern kann und keine 100%, gleichzeitig war das aber gestern noch sein Standpunkt. :ugly:
Nur mal so am Rande, was bringt es mir bitte, wenn ich weiß, dass ne CPU in den totalen Grüppeleinstellungen, die ich eh nie verwenden werde 300% schneller ist, dann aber in den Einstellungen, die ICH verwende nur noch 5% schneller ist, aber 100% mehr kostet?

Das ist doch total banane....
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=8864477&postcount=26

In den meisten Benchmarks im Netz werden CPU-Tests mit riesen großen GPU-Limits ertränkt und hier will er mit mir über die möglichen einstelligen Prozentabweichungen diskutieren. :crazy:

dargo,
Dein Link beinhaltet aber auch einen Link zu PCGH. Dort sind die Skalierungen zwischen E6600/Q6600 und E8400/Q9650 jedenfalls sehr widersprüchlich.

Inwiefern bitte?

Bei dir kann auch mit reinspielen, dass du unterhalb des FSB-Strap von 266 benchst und darüber dann einmal synchron und einmal asynchron - gerade bei FSB-Flaschenhälsen ist das ein wichtiger Faktor.
Ich musste das tun. Der Q9550 taktet mit 8,5x 333Mhz. Um eine 1:1 Skalierung zwischen CPU-Takt und den Flaschenhälsen möglichst zu gewährleisten bin ich mit dem Takt dementsprechend 1:1 runtergegangen. 2833Mhz auf 2210Mhz ergeben 78%, 333Mhz FSB auf 260Mhz FSB sind ebenfalls 78%. Das gleiche passierte bei der Speicherbandbreite. Eine asynchrone Taktung vom FSB und Speicher war beim P45 kein Problem. Man konnte eh nicht mit weniger als 1:1 takten, sprich 333Mhz FSB = mindestens 333Mhz Speichertakt. Es gingt nur über die Speicherteiler höher. Was keinesfalls gebremst hat, ganz im Gegenteil. Weiterhin musste ich mit dem Takt runter weil Resident Evil 5 leider einen 120fps Limiter intergriert hat. Ich musste also ein gutes Stück mit dem Takt beim hohen FSB und niedrigen CPU-Multi runter damit die max.fps auf keinen Fall an die 120fps Grenze kommen. Was natürlich die Ergebnisse verfälschen würde.

Skysnake

2011-08-03, 19:24:27

Naja, solange die Fps wie dargo sagt, reproduzierbar sind, dürfte das wohl passen. Denn selbst eine 50-cycle penalty, um eine Cacheline aus dem Speicher zufüllen ist prozentual auf 5 Sekunden nur ein verschwindend geringer Teil.

Nicht zwingend. Du weißt ja nicht, wie die Thread abgearbeitet werden.

Kleines vereinfachtes BSP: 2 Cores mit jeweils 4 Cachelines. Workingset ist 3 Cachelines groß. Auf 2 Cores läuft das ohne Probleme ohne einen Nachlader in den Cache.

Bei nur noch einen Core, brauchst du 6 Cachelines. Du lädst nun bei jedem Thread wechsel, die ja all ~10-100ms wenn ich es richtig im Kopf habe, passieren, 2 neue Cachelines nach, und so wies der IT-Gott will, sind das natürlich die Cachelines, die man gleich in der ersten Operation brauch.

Mit so etwas kann man ein System sehr schön ausbremsen und bekommt in die eine Richtung eine absolut geile Skalierung, auf der anderen Seite, wenn nicht alles mit dran hängt beim OC, dann hat man fast keine Skalierung.

@Dargo:
DU/Ihr sagt, es wären 9x% Zuverlässigkeit der Aussage zwischen den CPUs. Es wird aber nur eine sehr kurze Sequenz genommen, und man kann das Verhalten in den Caches eben nicht sehen. Dass die Messwerte stabiel sind, sagt gar nichts über irgendwelche Probleme mit der größe des Workingsets aus. Hier wird mit absolut einfachen und primitiven Sachen versucht Aussagen zu treffen, über einen unbekannten Code, mit unbekannter genauer Funktionsweise der Software im Zusammenhang mit der Hardware. Da dann zu sagen, die "Probleme" liegen hier ran oder dort ran ist bei so etwas absolut nicht gegeben. Vor allem wenn man Rosinenpickere macht, indem man nur sehr kurze Sequenzen nimmt, und auch gerade so Sachen wie nach dem Laden eines Savegames etc. Das sind eh kritische Bereiche, wo unglaublich viele unterschiedliche Sachen ablaufen.

dargo

2011-08-03, 19:47:48

@Dargo:
DU/Ihr sagt, es wären 9x% Zuverlässigkeit der Aussage zwischen den CPUs. Es wird aber nur eine sehr kurze Sequenz genommen, und man kann das Verhalten in den Caches eben nicht sehen. Dass die Messwerte stabiel sind, sagt gar nichts über irgendwelche Probleme mit der größe des Workingsets aus. Hier wird mit absolut einfachen und primitiven Sachen versucht Aussagen zu treffen, über einen unbekannten Code, mit unbekannter genauer Funktionsweise der Software im Zusammenhang mit der Hardware. Da dann zu sagen, die "Probleme" liegen hier ran oder dort ran ist bei so etwas absolut nicht gegeben. Vor allem wenn man Rosinenpickere macht, indem man nur sehr kurze Sequenzen nimmt, und auch gerade so Sachen wie nach dem Laden eines Savegames etc. Das sind eh kritische Bereiche, wo unglaublich viele unterschiedliche Sachen ablaufen.
Wie kommst du eigentlich darauf, dass ich direkt nach dem Laden wenn ich das Bild zu Gesicht bekomme die Benchtaste betätige? In allen Games suche ich mir erstmal einen Anhaltspunkt aus nach dem Laden damit exakte Reproduzierbarkeit gewährleistet ist. Das sieht in einem Rennspiel folgendermaßen aus. Strecke wird geladen. Du siehst die Startaufstellung die nicht selten erstmal vorgestellt wird durch bsw. einen Abspann. Sobald du in deiner Perspektive die Startaufstellung siehst kommt erstmal eine Ampel für ca. 2-3 Sekunden bis das Rennen losgeht. Die Benchtaste wird erst betätigt wenn das tatsächliche Rennen auch losgeht. Stelle die Szenen einfach nach und messe wieviel Zeit nach dem Laden vom Savegame tatsächlich verstrichen wird bis die Benchszene erstmal anfängt.

Edit:
Und nochwas... ich habe hier schon mal gesagt, dass ich den ersten Durchlauf nach dem Laden überhaupt nicht erfasse. Erst ab dem zweiten Durchlauf fange ich an zu messen. Beim ersten Laden wird das komplette Savegame geladen. Danach gehts über "Esc" und Neustart direkt ohne Verzögerung ins gleiche Savegame, ohne alles komplett neu laden zu müssen.

dargo

2011-08-03, 20:47:09

Mit der Erlaubnis von y33H@ (vielen Dank nochmal) möchte ich hiermit nochmal Bezug zu diesem Test nehmen.
http://www.pcgameshardware.de/aid,825548/Zum-Release-Dirt-3-im-Technik-Test-Sechs-CPU-Kerne-im-Vorteil-gelungener-DirectX11-Modus/Rennspiel-Sportspiel-Simulation/Test/

y33H@ hat mir über PN einen neuen Test in Dirt 3 mit dem Phenom 2 X6 zukommen lassen. Es handelt sich hierbei allerdings um ein Savegame und nicht ebenfalls um den intergrierten Benchmark, allerdings um eine andere Strecke.

Testsystem - Phenom 2 @3,2Ghz, GTX580, Win7 x64 SP1, FW 275.33
40370

Hier sehen die Skalierungen gleich viel besser und auch plausibel aus. Dass der X4 keine 100% gegenüber dem X2 zulegt könnte am leicht herrschenden GPU-Limit schon liegen. Die CPU taktet immerhin mit 3,2Ghz.

Wie ich schon y33H@ über PN geschrieben habe vermute ich beim Test der PCGH einen Fehler beim Test mit dem Quadcore. Womöglich hat sich das Game tatsächlich die falsche XML geschnappt was zu völlig falschen Ergebissen geführt hat. Die Skalierung bei der PCGH vom TC vs. DC deckt sich mit meinem Test. (http://www.forum-3dcenter.org/vbulletin/showpost.php?p=6973307&postcount=3) Auch bei mir legt der Triplecore nur sehr wenig zu.

y33H@

2011-08-03, 20:56:56

Es handelt es sich hierbei um den integrierten Benchmark - allerdings auf der Strecke "Smelter" und Fraps @ 30 Sekunden inklusive AI (und ohne Vorspann). Das How-2 geht evtl. die Tage online ...

dargo

2011-08-03, 20:59:13

Es handelt es sich hierbei um den integrierten Benchmark - allerdings auf der Strecke "Smelter" und Fraps @ 30 Sekunden inklusive AI (und ohne Vorspann). Das How-2 geht evtl. die Tage online ...
Achso... dann habe ich dich falsch verstanden. X-D

y33H@

2011-08-03, 21:01:07

Wie gesagt, ob du selbst fährst oder deine Karre von der AI gelenkt wird, ist (Fps-technisch) egal. Die landet immer auf dem letzten Platz :ulol:

Schaffe89

2011-08-04, 09:09:00

Dass der X4 keine 100% gegenüber dem X2 zulegt könnte am leicht herrschenden GPU-Limit schon liegen. Die CPU taktet immerhin mit 3,2Ghz.

DAs müsste man mit einem schnelleren CPU alias Sandy Bridge @ 4 ghz nachtesten, wo da das GPU limit liegt.
Ich Zweifel mal arg daran, dass hier ein teilweises GPU limit vorliegt.
Obwohl, vielleicht bremst ja die Tesselation und ein GPU Limit liegt teilweise vor.
Könnte das jemand mit nem flotten System und ner GTX580 nachtesten?:)

dargo

2011-08-04, 09:52:39

DAs müsste man mit einem schnelleren CPU alias Sandy Bridge @ 4 ghz nachtesten, wo da das GPU limit liegt.
Ich Zweifel mal arg daran, dass hier ein teilweises GPU limit vorliegt.
Obwohl, vielleicht bremst ja die Tesselation und ein GPU Limit liegt teilweise vor.
Könnte das jemand mit nem flotten System und ner GTX580 nachtesten?:)
Dafür brauchst du kein anderes System. Einfach die Grafikkarte bsw. um 20% übertakten oder untertakten und schauen was mit den Frames passiert. Ich werde heute die gleiche Strecke mit dem i5-750 @3,2Ghz testen. Hab zwar nur eine GTX480. Die läuft allerdings mit 830/2000Mhz. Müsste also in etwa gleich schnell wie die GTX580 @Stock sein. Wenn ich nicht im leichten GPU-Limit liege ist das beim Phenom 2 @3,2Ghz erst recht nicht der Fall.

Edit:

@Schaffe89
Ich habe für dich einen kleinen Test mit dem intergrierten Benchmark von Dirt 3 angefertigt. Zwei Durchläufe mit je 30 Sekunden.

i5-750 @3,2Ghz, GTX480 @830/2000Mhz, DDR3-1280 640x480 1xAA/1xAF, max. Details
40376

In beiden Fällen hat sich an der Konfiguration nichts verändert! Wie man sieht sind die Abweichungen bis Sekunde 11 quasi vernachläßigbar. Ab Sekunde 12 gehen die großen Abweichungen los. Das ist das Problem vom intergrierten Benchmark in Dirt 3. Die einzelnen Durchläufe laufen unterschiedlich ab. Im Diagramm sind Abweichungen bis zu 40%! erkennbar. Hierbei zu prüfen ob man sich im vollständigen CPU-Limit befindet ist nahezu unmöglich. Bis zur elften Sekunde bleiben die Frames ziemlich stabil weil das Fahrerfeld dicht zusammenbleibt und der Straßenverlauf relativ gerade verläuft so, dass ich alle Fahrer noch im Blickfeld habe. Danach hat man nichts mehr unter Kontrolle.

Jetzt habe ich einen Durchlauf mit verringerter Grafikkartenleistung gestartet.

i5-750 @3,2Ghz, GTX480 @700/1848Mhz, DDR3-1280 640x480 1xAA/1xAF, max. Details
40379

Hier erkennt man sehr gut, dass die ersten 11 Sekunden sich tatsächlich in meiner Konstellation vollkommen im CPU-Limit befinden. Danach kann man nur noch wild raten. Vergleiche ich die grüne Linie mit der blauen oder eher mit der rot/braunen? Oder gar mit keiner von beiden? Alles wäre hier aufgrund der unterschiedlichen Verhaltensweise vom Benchmark denkbar. Würde ich bsw. mit der blauen Linie vergleichen achte dann mal speziell bsw. auf die Sekunde 14 --> 129 vs. 108fps. Das sind 19% Unterschied. Wenn du dir mal anschaust in welchem Ausmaß ich die Taktraten der Grafikkarte verändert habe ist das praktisch in Sekunde 14 ein vollständiges GPU-Limit. Mir würde allerdings nicht im Traum einfallen hier ab der zwölften Sekunde irgendwelche Vergleiche zu ziehen, aus den genannten Gründen.

Jetzt schau dir mal was die Angaben der avgs. aus den Frameverlaufdaten machen.

1. Durchlauf mit 830/2000Mhz --> avg.fps = 119,433
2. Durchlauf mit 830/2000Mhz --> avg.fps = 114,200
1. Durchlauf mit 700/1848Mhz --> avg.fps = 114,767

Bei der schnelleren Grafikkarte weichen die avgs. ~5% voneinander ab obwohl im Frameverlauf Stellen zu finden sind die deutlich stärker abweichen mit bis zu 40%! Die avgs. zwischen dem ersten Durchgang der schnelleren Grafikkarte und dem der langsameren weichen um ~4% ab obwohl im Frameverlauf Stellen zu finden sind mit deutlich stärkeren Abweichungen von bis zu 30%. Ganz übel wirds wenn man mal den zweiten Durchlauf @830Mhz mit dem ersten @700Mhz vergleicht. Laut avgs. kein Unterschied, beim Frameverlauf... X-D

Hier sieht man sehr schön die Problematik längerer Testszenen ohne detailierte Frameverläufe.

Zusammenfassend eignet sich der intergrierte Benchmark von Dirt 3 absolut nicht um reproduzierbare Vergleiche zwischen den CPUs anzustellen. Außer man beschränkt sich tatsächlich nur auf max. die ersten 11 Sekunden. Und diese Zeitangabe bezieht sich ausschließlich auf die Strecke "Smelter". Bei anderen Strecken bzw. Schauplätzen kann das wieder ganz anders aussehen.

PCGH_Carsten

2011-08-05, 09:18:19

dargo

2011-08-05, 11:01:56

„Die verbesserte Grafik fordert ihren Tribut: Smelter 9 läuft mit fast 30 Prozent weniger Fps als Malaysia (PCGH-Dirt 2-Strecke), bleibt in Full-HD jedoch selbst auf einer Geforce GTX 460 spielbar. Erwähnenswert ist die vorbildliche CPU-Skalierung von Dirt 3: In 640 x 480 ohne AA/AF erreicht unser Testsystem rund 190 Fps – mit einer GTX 580 @ 950 MHz. Das Delikate: Nicht die CPU bremst …”

edit: Bevor jetzt Klagen kommen: Dirt 3 ist für unseren Grafik-Parcours - inklusive DX11, MSAA und AF - vorgesehen. In den verwendeten Einstellungen erreicht eine GTX 580 höchstens knapp 80 Fps, ist vom CPU-Limit also meilenweit entfernt.
Wobei man hier natürlich erwähnen muss, dass ihr mit einem Geschoss i7-2600K @4,5Ghz getestet habt. Das ist in einem Spiel wie DIRT 3 welches hervorragend einen Quadcore auslastet eine unheimlich extreme CPU-Leistung.

Und Carsten verstehe mich bitte nicht falsch - die Aussage "In den verwendeten Einstellungen erreicht eine GTX 580 höchstens knapp 80 Fps, ist vom CPU-Limit also meilenweit entfernt." ist oder besser gesagt muss so nicht ganz korrekt sein. In einer 30 Sekunden langen Testszene ohne Frameverlauf kann man diese Aussage zwar auf die avgs. beziehen, wie das aber tatsächlich in jeder Sekunde dieser Testszene aussieht sieht man nicht. Wie aussagekräftig avgs. in einer langen Testszene sind habe ich oben schon verdeutlicht. Außerdem würde mich interessieren ob ihr den intergrierten Benchmark mit anderer Strecke oder ein reines Savegame verwendet habt? Aus dem Text kann ich das nicht eindeutig bestimmen.

PS: ich habe heute angefangen einen entsprechenden Artikel zu der ganzen Benchproblematik in Games zu schreiben. Ich hoffe, dass ich damit in den nächsten Tagen fertig werde. Denn, diese Diskussionen zum Thema fangen jedes Jahr vom Neuen an und nerven mich langsam. :)

PCGH_Carsten

2011-08-05, 11:37:40

Wir testen prinzipiell praxisnah - also genau das, was du in deinen Architekturvergleichen explizit nicht machen willst, mal ganz wertfrei. Daher ist für eine längere Messsequenz ein Abstand von mindestens 137% von unserer niedrigsten Benchmarkauflösung bis zu dem Wert, den wir für die CPU in niedriger Auflösung und ohne AA/AF gemessen haben, schon eine praxisrelevante Grundlage, um das CPU-Limit als maßgeblich beeinflussenden Faktor auszuschließen.

Natürlich wirkt sich die CPU-Limit in einzelnen Szenen, in einzelnen Bildern und sogar innerhalb einzelner Frames unterschiedlich aus. Diese, für den Gamer meist irrelevante, Betrachtung ist aber auch nicht unser Anspruch bei einem Grafikkarten-Benchmark.

Wir verwenden den integrierten Benchmark auf der Strecke Smelter-9, messen aber mit Fraps 30 Sekunden ab ca. Start-/Zieltordurchfahrt. Genauer: wenn der Schatten des Gerüsts das eigene Auto berührt; das erlaubt eine genauere Koordination und präziseres Auslösen. Das How-To kommt bestimmt die Tage auch online…

dargo

2011-08-05, 12:16:36

Wir testen prinzipiell praxisnah - also genau das, was du in deinen Architekturvergleichen explizit nicht machen willst, mal ganz wertfrei.

Ist völlig legitim, ihr verfolgt auch ein ganz anderes Ziel als ich. Bei euch gehts mehr Richtung Kaufberatung. Was bei einem Printmagazin aus Sicht der Spieler auch Sinn macht. Ich sehe bei diesem "praxisnah" aber einzelne Defizite auf die ich hier erstmal nicht eingehen möchte da das den Rahmen sprengen würde. Ich werde darauf in meinem Artikel gezielter eingehen.

Daher ist für eine längere Messsequenz ein Abstand von mindestens 137% von unserer niedrigsten Benchmarkauflösung bis zu dem Wert, den wir für die CPU in niedriger Auflösung und ohne AA/AF gemessen haben, schon eine praxisrelevante Grundlage, um das CPU-Limit als maßgeblich beeinflussenden Faktor auszuschließen.

Könntest du das mir bitte genauer erklären? Ich kann dir hier nicht ganz folgen.

Natürlich wirkt sich die CPU-Limit in einzelnen Szenen, in einzelnen Bildern und sogar innerhalb einzelner Frames unterschiedlich aus. Diese, für den Gamer meist irrelevante, Betrachtung ist aber auch nicht unser Anspruch bei einem Grafikkarten-Benchmark.

Ok... innerhalb eines einzelnen Frames halte ich es schon etwas für übertrieben. Zumal mir keine Möglichkeit bekannt ist soetwas zu erfassen. Fraps misst afaik mindestens jede Sekunde. Innerhalb einer Szene halte ich allerdings für sehr wichtig. Man stelle sich eine Szene vor wo die Frames mehrere Sekunden unter die "magische" grenze von 30fps fallen. Ob diese Sekunden nun einzeln auftreten oder in einem Bündel sei erstmal dahingestellt. Die "flüssige" Spielbarkeit beeinflußt dieses Verhalten sehr wohl. Die avgs. sind aber leider nicht in der Lage diese Spielbarkeit in einer längeren Szene darzustellen. Je länger die Szene umso mehr wird geglättet. Die avgs. können zb. 40fps in einer Szene betragen welche wie gesagt mehrere Abschnitte enthalten die unter 30fps rutschen. Auch auf dieses Problem werde ich im Artikel mit Beispielen (ich hoffe ich finde recht schnell welche) näher drauf eingehen.

Wir verwenden den integrierten Benchmark auf der Strecke Smelter-9, messen aber mit Fraps 30 Sekunden ab ca. Start-/Zieltordurchfahrt. Genauer: wenn der Schatten des Gerüsts das eigene Auto berührt; das erlaubt eine genauere Koordination und präziseres Auslösen.
Vielen Dank für die ausführliche Erklärung. Damit kann ich schon mal mit meinem System genau nachbenchen. Hiermit nochmal ein großes Lob von mir an euch für die zahlreichen Infos zu euren Benchmarks.

Eine kritische Frage habe ich aber dennoch in diesem Zusammenhang - wenn ihr den intergrierten Benchmark mit ganzen 30 Sekunden in Anspruch nehmt wie siehst du die Aussagefähigkeit unter dem Aspekt den ich oben dazu geschrieben habe (unterschiedliches Verhalten, ergo starke Abweichnungen zwischen einzelnen Durchläufen)? Dabei würde mich deine Antwort nicht als Redakteur sondern vielmehr als Privatperson interessieren. Gerne auch über PN.

Hellstaff

2011-08-08, 19:52:24

Weiß jemand, wie ein (übertakteter) Yorkfield in Dirt 3 skaliert? Habe leider nur X4 und SB benchmarks zu Gesicht bekommen.

dargo

2011-08-08, 20:22:39

Weiß jemand, wie ein (übertakteter) Yorkfield in Dirt 3 skaliert? Habe leider nur X4 und SB benchmarks zu Gesicht bekommen.
Wie soll er schon skalieren? Wie jede andere CPU bei OC auch. In einer vollständig cpu-limitierten Szene 1:1 mit, solange du den FSB und den Speicher ebenfalls 1:1 hochtaktest.

Schaffe89

2011-08-09, 14:31:19

Zusammenfassend eignet sich der intergrierte Benchmark von Dirt 3 absolut nicht um reproduzierbare Vergleiche zwischen den CPUs anzustellen

Das sehe ich trotz deines sehr schönen Vergleich anders.
Die KI reagiert in diesem Benchmark nie exakt gleich. Völlig klar dass deswegen im Frameverlauf andere Lastzustände früher oder später eintreten können, deswegen auch die Zickzackmuster.

Wie man an deinen Benchmark sieht, unterscheiden sich die Durschnittswerte kaum. (warum also nicht geeignet, weil irgendwo evtl. minimales GPU Limit) hm..
Deine Benchmarks zeigen auch fast kein GPU Limit, sondern einfach nur Schwankungen aufgrund der unterschiedlich reagierenden KI, das muss kein zweingendes GPU limit sein.

"In den verwendeten Einstellungen erreicht eine GTX 580 höchstens knapp 80 Fps, ist vom CPU-Limit also meilenweit entfernt." ist oder besser gesagt muss so nicht ganz korrekt sein. In einer 30 Sekunden langen Testszene ohne Frameverlauf kann man diese Aussage zwar auf die avgs. beziehen, wie das aber tatsächlich in jeder Sekunde dieser Testszene aussieht sieht man nicht.

Genau diese Aussage könnte man auch auf deine Interpretation der Ergebnisse weiter oben ummünzen. ;-)

Cool wäre, wenn du den gesamten Benchmark nommal mit übertakteter CPU ~4 ghz durchlaufen lässt (mit Frameverläufe) bzw, die relevanten Sekunden (wo deiner MEinung nach starke GPU Limits auftreten einmal mit 550 mhz/650/750/850Mhz)

Dann könnte man dazu bessere Aussagen treffen, das sieht man ja schon alleine an deinem Frameverlauf mit weniger GPU Takt.
Die FPS müssten doch stellenweise mindestens niedriger sein als zuvor, sind sie aber niemals. --> Das ist alles ein Wurstsalat mit sich anders verhaltender KI, CPU-Limits, teilweise minimale GPU Limits.
Da Ordnung reinzubringen, wird sich eventuell vielleicht auch gar nicht rentieren.

Insofern stimme ich jedenfalls zu, dass die ersten 11 Sekunden wohl für nen IPC Vergleich am besten sind, allerdings darf man dolche untersch. Lastzustände, bzw Zickzackkurs später auch nicht ununtersucht lassen. Eventuell zeichnen sich für System A/B oder CPU A/B je nach Anbeindung und Architektur wieder vorteile ab.

Deswegen find ich solche IPC Rosinen-vergleiche im absoluten CPU Limit gar nicht so interessant. Lieber kleine Auflösung, fette Grafikkarte, hohe CPU Last, wenig Frames (wie in Star Craft 2).
Aber keine KAufberatung. Kaufberatung macht man eher so @1680x1050 mit 4xMSAA, die PCGH befindet sich da eher in der Richtung die du verschlägst, also realistische ca 50% mehr Spiele IPC als der Phenom II.

dargo

2011-08-09, 14:57:22

Das sehe ich trotz deines sehr schönen Vergleich anders.
Die KI reagiert in diesem Benchmark nie exakt gleich. Völlig klar dass deswegen im Frameverlauf andere Lastzustände früher oder später eintreten können, deswegen auch die Zickzackmuster.

Und wo siehst du jetzt den Widerspruch?
Wie man sieht sind die Abweichungen bis Sekunde 11 quasi vernachläßigbar. Ab Sekunde 12 gehen die großen Abweichungen los.
Hier erkennt man sehr gut, dass die ersten 11 Sekunden sich tatsächlich in meiner Konstellation vollkommen im CPU-Limit befinden. Danach kann man nur noch wild raten.
Die Lastzustände können sich sowohl bei der CPU als auch GPU ändern. Stelle dir folgende Szene in sagen wir mal der zwanzigsten Sekunde vor - im ersten Durchlauf hast du vor dir 5 Fahrzeuge, im zweiten nur noch eins. Im ersten Fall ist sowohl die CPU-Last als auch GPU-Last bei ansonsten gleichem Bildinhalt höher. Erstens hast du mehr KI vor dir, zweitens mehr Geometrie. Die Details der Fahrzeuge beanspruchen aber auch die Grafikkarte. Wie die Gewichtungen hier sind ist wieder ein anderes Thema und ohne Gegentests (vorausgesetzt es ist eine 100%-ige Reproduzierbarkeit gegeben, die es im DIRT 3 Benchmark nicht gibt) nicht zu bestimmen.

Wie man an deinen Benchmark sieht, unterscheiden sich die Durschnittswerte kaum. (warum also nicht geeignet, weil irgendwo evtl. minimales GPU Limit) hm..

Das ist genau das riesen Problem der avgs. über einen längeren Zeitrahmen. Gedulde dich noch ein wenig, meinen Artikel werde ich voraussichtlich bis Wochenende fertig haben. Dann sollte vieles gleich klarer erscheinen.

Deine Benchmarks zeigen auch fast kein GPU Limit, sondern einfach nur Schwankungen aufgrund der unterschiedlich reagierenden KI, das muss kein zweingendes GPU limit sein.

Woran erkennst du, dass sich einzelne Sekunden nicht im leichten GPU-Limit befinden wenn die Reproduzierbarkeit schon ab der zwölften Sekunde nicht mehr gegeben ist?

Cool wäre, wenn du den gesamten Benchmark nommal mit übertakteter CPU ~4 ghz durchlaufen lässt (mit Frameverläufe) bzw, die relevanten Sekunden (wo deiner MEinung nach starke GPU Limits auftreten einmal mit 550 mhz/650/750/850Mhz)

Dann könnte man dazu bessere Aussagen treffen, das sieht man ja schon alleine an deinem Frameverlauf mit weniger GPU Takt.
Die FPS müssten doch stellenweise mindestens niedriger sein als zuvor, sind sie aber niemals. --> Das ist alles ein Wurstsalat mit sich anders verhaltender KI, CPU-Limits, teilweise minimale GPU Limits.Da Ordnung reinzubringen, wird sich eventuell vielleicht auch gar nicht rentieren.
Das versuche ich dir die ganze Zeit zu erklären. :freak: Wie gesagt, wenn der Artikel Online ist (meine Tests habe ich bereits fertig, fehlt nur noch Feinschliff beim Text) können wir im entsprechenden Thread gezielter drauf eingehen.