Kern-Skalierung in Games (Dualcore vs. Triplecore vs. Quadcore)

[dargo]

Da ich endlich einen Quad habe kann es mit den Tests losgehen. Ich möchte mit diesem Thread zeigen wie gut Games mit mehr als 2 Kernen skalieren. Dazu ist erstmal sehr wichtig ein 100%-iges CPU-Limit zu schaffen. Es nützt nichts wenn die Grafikkarte höhere Frameraten verhindert. Außerdem ist es besonders wichtig mit Savegames zu arbeiten, Timedemos erzeugen eine viel geringere CPU-Last und haben nichts mit der tatsächlichen CPU-Last in Games gemeinsam. Ich habe mich für folgende Taktraten entschieden:

1. 1470Mhz (7x 210Mhz FSB), Speichertakt 252Mhz
2. 2002Mhz (7x 286Mhz FSB), Speichertakt 343Mhz

Wie man sieht liegt der Speicherteiler immer bei 2.40 oder anders ausgedrückt FSB/DRAM-Verhältnis liegt bei 5:6.

Einige werden sich fragen warum so "krumme" Taktraten? Nun, da ist ein kleines System hinter. Da ich auch die CPU-Skalierung zeigen möchte ist es wichtig, dass der CPU-Takt nur über den FSB erhöht wird. Ändere ich den CPU-Takt über den CPU-Multi ändert sich auch das Verhätnis zwischen Bandbreite/FSB und CPU-Takt. Und eben dieses Verhältnis sollte gleich bleiben.

Testsystem:
Gigabyte GA-EP45-DS3
Yorkfield Q9550
Gigabyte GTX 260 @621/1404/1107Mhz
6GB DDR2 Speicher
Vista 64 SP1/SP2 mit aktuellen Updates / Windows 7 Beta (je nach Game)


Benchmarks:

Colin Mcrae: DIRT - Disziplin: CORR, Strecke 'Chula Vista A (USA)' mit 10 Fahrzeugen und maximalen Details
http://img395.imageshack.us/img395/179/dirt1nt5.png

Alarm für Cobra 11: Burning Wheels - Strecke 'Um alle Ecken' mit 8 Fahrzeugen und maximalen Details
http://img530.imageshack.us/img530/6028/cobra111sj1.png
Bemerkung: den Test vom Dualcore den man benötigt um auf die gleichen Frames wie beim 1.47Ghz Quadcore zu kommen habe ich ausgelassen da Cobra 11 eine reine Zweikern-Anwendung ist.

Crysis DX9 - Savegame 'Onslaught' mit maximalen Details inkl. Mster Config 3.01
http://img23.imageshack.us/img23/5040/crysis1.png

Need for Speed: ProStreet - Eingangsrennen mit 8 Fahrzeugen und maximalen Details
http://img266.imageshack.us/img266/4742/nfsps1ao8.png

Race Driver: GRID - Strecke 'San Francisco' mit 12 Fahrzeugen und maximalen Details
http://img201.imageshack.us/img201/817/grid1fe4.png

Farcry 2 DX10 - Savegame 'Akt1 - 8%' mit maximalen Details
http://img206.imageshack.us/img206/671/farcry2vf6.png

Test Drive Unlimited - Strecke 'Inseltour' mit 8 Fahrzeugen und maximalen Details
http://img18.imageshack.us/img18/6480/tdu.png

Need for Speed: Undercover - Rundkurs 'Ocean & Wilson' mit 8 Fahrzeugen und maximalen Details
http://img2.imageshack.us/img2/130/nfsundercoverneu.png

Ghostbusters - Savegame 'Öffentliche Bibliothek' mit maximalen Details
http://img411.imageshack.us/img411/3498/ghostbusters.png

Need for Speed: Shift - Strecke 'Willow Springs GP' mit 16 Fahrzeugen und maximalen Details
http://img33.imageshack.us/img33/3125/nfsshift.png

[dargo]

Ich habe mich entschieden das Testsetup etwas zu ändern. Testsystem bleibt weiterhin unverändert, die Taktraten der CPU sehen nun aber folgendermaßen aus:

1. 1768Mhz (8,5x 208Mhz FSB), Speichertakt 208Mhz
2. 2210Mhz (8,5x 260Mhz FSB), Speichertakt 260Mhz
3. 2833Mhz (8,5x 333Mhz FSB), Speichertakt 333Mhz

Alle drei CPU-Settings werden jeweils als Quadcore/Triplecore und Dualcore getestet. Zusätzlich wird die CPU mit zwei Kernen so weit übertaktet bis sie die Framerate vom Quadcore @1768 und 2210Mhz erreicht. Der CPU-Takt wird ausschließlich über den FSB skaliert. Sollte es bei einem CPU-Setting zu anfänglichen GPU-Limits kommen wird dies von mir explizit gekennzeichnet.


Benchmarks:

Call of Duty: Modern Warfare 2 - Savegame AKT I 'Teamspieler' mit maximalen Details
http://img707.imageshack.us/img707/2493/cod62.png

Colin McRae: DIRT 2 - Strecke 'breed raid' in Marokko mit 8 Fahrzeugen und maximalen Details
http://img193.imageshack.us/img193/6209/dirt22.png

Resident Evil 5 DX9 - Savegame Kapitel 1 'Die öffentliche Versammlung' mit maximalen Details
http://img402.imageshack.us/img402/8649/residentevil5.png

Edit:
Endlich ist die neue Kombination da - i5 Quad samt GTX470. Das Testsystem sieht also folgendermaßen aus:

ASUS P7P55D
i5-750
8GB DDR3-1600
GTX 470 @720/1440/838Mhz
Windows 7 x64

Für weitere Tests habe ich mich für folgende Taktraten entschieden:
1. 1574Mhz (14x 112,4), Speichertakt 450Mhz
2. 2332Mhz (14x 166,6), Speichertakt 666Mhz
3. die nötige Taktrate beim Dualcore um das Ergebnis vom 1574Mhz Quadcore zu erzielen.

Skaliert wird über den BCLK um eine 1:1 Skalierung zu gewährleisten. Die Speicherbandbreite, der QPI-/ und Uncore-Takt skalieren somit 1:1 mit. Eine einzige kleine Einschränkung gibts aber - da mein Mainboard nicht mit < 112 BCLK bootet bin ich gezwungen diesen BCLK-Wert zu nutzen. Auf der anderen Seite ist bei einem BCLK von 208 Schluß. Sprich, ich kann bei perfekter Quadcore-Skalierung nicht immer beim CPU-Multi von 14 bleiben. 112*2 bedeutet 224 BCLK, was wie gesagt mein Mainboard nicht schafft. In diesem Fall muss ich auf den 15-er CPU-Multi zurückgreifen damit ich mit der CPU-Taktrate weiter nach oben komme. Bei einem anderen CPU-Multi ist eine 100%-ige Skalierung nicht mehr gewährleistet. Da es sich aber nur um einen CPU-Multi handelt dürfte die Abweichung sehr gering sein.

Sollte ich also den 15-er CPU-Multi brauchen werde ich dies als Bemerkung beim jeweiligen Spiel erwähnen.

Benchmarks:

Resident Evil 5 DX9 - Savegame Kapitel 1 'Die öffentliche Versammlung' mit maximalen Details
http://img696.imageshack.us/img696/6112/residentevil5i52.png

Bemerkung: wie man unschwer erkennen kann habe ich hier andere Taktraten benutzt. Der Grund ist der 120fps Framelimiter in RE5. Um drunter zu bleiben habe ich hierbei folgende Taktraten benutzt:

1. 1461Mhz (13x 112,4), Speichertakt 450Mhz
2. 1739Mhz (13x 133,8), Speichertakt 535Mhz

GRID - Strecke 'San Francisco' mit 12 Fahrzeugen und maximalen Details
http://img37.imageshack.us/img37/1624/gridi52.png

Test Drive Unlimited - Strecke 'Inseltour' mit 8 Fahrzeugen und maximalen Details
http://img530.imageshack.us/img530/2241/tdui5.png

Colin McRae: DIRT 2 - Strecke 'breed raid' in Marokko mit 8 Fahrzeugen und maximalen Details
http://img716.imageshack.us/img716/9310/dirt2i5.png

Farcry 2 DX10 - Savegame 'Akt1 - 8%' mit maximalen Details
http://img707.imageshack.us/img707/3254/farcry2i5.png

Need for Speed: Shift - Strecke 'Willow Springs GP' mit 16 Fahrzeugen und maximalen Details
http://img84.imageshack.us/img84/6870/nfsshifti5.png

Call of Duty: Modern Warfare 2 - Savegame AKT I 'Teamspieler' mit maximalen Details
http://img51.imageshack.us/img51/1713/cod6i5.png

Mass Effect 2 - Savegame 'Omega-Handelsdistrikt' mit maximalen Details ohne Filmkörnung
http://img576.imageshack.us/img576/3286/me2p.png

Bemerkung: beim 2843Mhz DC wurde 15-er CPU-Multi benutzt.

Need for Speed: Hot Pursuit - Event 'Eagle Crest', Strecke 'Blacklisted - Hot Pursuit' mit 6 Fahrzeugen und maximalen Details.
http://img267.imageshack.us/img267/8552/nfshp.png

Bemerkung: das Spiel ist auf 60fps limitiert wodurch ich andere Taktraten nutzen musste:

1. 1349Mhz (12x 112,4), Speichertakt 450Mhz
2. 1999Mhz (12x 166,6), Speichertakt 666Mhz

Shift 2 Unleashed - Strecke 'Miami Bayfront Park Loop' bei Nacht mit 16 Fahrzeugen und maximalen Details
http://s7.directupload.net/images/110409/cmjsaali.png

Crysis 2 - Savegame 'Masken runter' mit sehr hohen Details
http://s1.directupload.net/images/110411/2lwrkju7.png

Bemerkung - diesmal nicht mit maximalen Details sondern "nur" mit sehr hohen da bei max. Details die Grafikkarte schon etwas limitiert. Außerdem habe ich mich bei der schnelleren CPU für 1872Mhz (14x 133,7) entschieden da die Grafikkarte bei 2332Mhz (14x 166,6) mit sehr hohen Details noch minimal limitiert. Erst unterhalb von ca. 180fps limitiert in dieser Szene zu 100% die CPU. Die 1574Mhz (14x112,4) sind wie bei anderen Tests geblieben. Bei den 3210Mhz musste ich den CPU-Multi von 14 auf 16 erhöhen, sprich 16x 200,6.

[dargo]

Testsystem:
ASUS P7P55D
i5-750 (Lynnfield)
8GB DDR3-1600 9-9-9-24
GTX 470 @700/1400/838Mhz
Windows 7 x64 SP1

Folgende CPU-Taktraten werden verwendet:
1. 1574Mhz (14x 112,4), DDR3-900
2. 2332Mhz (14x 166,6), DDR3-1333
3. die nötige Taktrate beim Dualcore um das Ergebnis vom 1574Mhz Quadcore zu erzielen.

Skaliert wird nur über den BCLK um eine 1:1 Skalierung zu gewährleisten. Die Speicherbandbreite, der QPI-/ und Uncore-Takt skalieren somit 1:1 mit.

Wichtiger Hinweis: Aufgrund von Mainboardlimitierungen beim BCLK bin ich gezwungen mindestens einen BCLK von 112 und maximal 218 zu nehmen. Dh., es kann also vorkommen, dass ich den Dualcore nicht hoch genug takten kann (maximal möglicher Takt 3052Mhz mit einem 14-er CPU-Muti, 218-er BCLK und DDR3-1744) damit er auf die gleichen Frames kommt wie der kleine Quadcore. In diesem Fall muss man sich den nötigen Takt beim Dualcore hochrechnen. Ich werde in solchen Fällen eine kleine Bemerkung beim jeweiligen Spiel beifügen. Einen höheren CPU-Multi zu nehmen macht keinen Sinn da damit wie gesagt keine 1:1 Skalierung mehr möglich ist und das Ergebnis je nach Größe der Abweichung beim CPU-Multi zu starken Verfälschungen führen kann.


Benchmarks:

DIRT 3 - Disziplin 'Landrush', Schauplatz 'Aspen', Strecke 'Eagle Hill Rise' mit 8 Fahrzeugen und maximalen Details
http://s1.directupload.net/images/110531/lai2v4si.png

Bemerkung: wie man sieht kann ich den Dualcore nicht hoch genug takten um die ~70fps zu erreichen. Hochgerechnet müsste der DC mit ca. 3316Mhz takten um die gleichen Frames wie der 1574Mhz QC zu liefern.

Da ich jetzt eine etwas schnellere Grafikkarte besitze habe ich mich dazu entschlossen nicht nur die Taktfrequenz der CPU sondern auch den CPU-Multi anzuheben. Somit sind die erzielten Frames besser auf einen i5-750 übertragbar als mit einem CPU-Multi von 14 oder gar 12. Ich nehme diesmal für weitere Tests den CPU-Multi 18. Am liebsten würde ich den originalen 20-er CPU-Multi verwenden, damit wären aber einerseits eventuell die Taktraten bei dem einen oder anderen Game für ein vollständiges CPU-Limit etwas zu hoch. Anderseits limitiert mich beim OC die CPU. Da ich max. einen BCLK von 216 verwenden kann wäre der maximal mögliche CPU-Takt 4320Mhz (20x 216). Ich schaffe aber "nur" ~3,9Ghz @Dualcore mit einer moderaten Vcore. Das neue System sieht also folgendermaßen aus.

Testsystem:
ASUS P7P55D
i5-750 (Lynnfield)
8GB DDR3-1600 9-9-9-24
Zotac GTX 480 AMP! @830/1660/2000Mhz
Windows 7 x64 SP1

Folgende CPU-Taktraten werden verwendet:
1. 2057Mhz (18x 114,3), DDR3-914
2. 2672Mhz (18x 148,4), DDR3-1188
3. die nötige Taktrate beim Dualcore um das Ergebnis vom 2057Mhz Quadcore zu erzielen (max. 3888Mhz CPU-Takt mit 216 BCLK und DDR3-1728).

Skaliert wird nur über den BCLK um eine 1:1 Skalierung zu gewährleisten. Die Speicherbandbreite, der QPI-/ und Uncore-Takt skalieren somit 1:1 mit.

Wichtiger Hinweis: Aufgrund von Mainboardlimitierungen beim BCLK bin ich gezwungen mindestens einen BCLK von 114 und maximal 216 zu nehmen. Dh., es kann also vorkommen, dass ich den Dualcore nicht hoch genug takten kann damit er auf die gleichen Frames kommt wie der kleine Quadcore. In diesem Fall muss man sich den nötigen Takt beim Dualcore hochrechnen. Ich werde in solchen Fällen eine kleine Bemerkung beim jeweiligen Spiel beifügen. Einen höheren CPU-Multi zu nehmen macht keinen Sinn da damit wie gesagt keine 1:1 Skalierung mehr möglich ist und das Ergebnis je nach Größe der Abweichung beim CPU-Multi zu starken Verfälschungen führen kann.


Benchmarks:

Battlefield: Bad Company 2 - Savegame 'ZERO DARK THIRTY' mit maximalen Details @DX11
http://s7.directupload.net/images/110905/5d2xaewb.png

Bemerkung: auch diesmal lässt sich der Dualcore bei weitem nicht so hoch takten damit er den 2057Mhz Quadcore einholen kann. Hochgerechnet müsste der Dualcore mit wahnsinnigen 5130Mhz takten.

Battlefield 3 - Savegame 'Operation Swordbreaker' mit maximalen Details @DX11
http://s14.directupload.net/images/120406/iffsyvq2.png

Bemerkung: der Dualcore lässt sich nicht ganz auf den Punkt takten damit er den 2057Mhz Quadcore einholt. Hochgerechnet müsste er mit 3961Mhz takten.

Need for Speed: The Run - Savegame 'Nationalpark' mit maximalen Details
http://s7.directupload.net/images/120407/287khcfo.png

Bemerkung: auch hier lässt sich der Dualcore bei weitem nicht so hoch takten damit er den kleinen Quadcore einholt. Hochgerechnet müsste er mit 4696Mhz takten. Bei diesem Spiel ausnahmsweise mit Ingame-AA weil es sich nicht abschalten lässt.

Project Cars - Strecke 'Anhalt GP' mit 36 Fahrzeugen und maximalen Details
http://s1.directupload.net/images/120507/9k74jq22.png

Bemerkung: Ausnahmsweise in 1280x720 weil kleinere Auflösungen nur im Fenstermodus laufen.

Testsystem:
ASUS P7P55D
i5-750 (Lynnfield)
8GB DDR3-1600 9-9-9-24
Sapphire HD7970 @1050/1500Mhz
Windows 7 x64 SP1

Folgende CPU-Taktraten werden verwendet:
1. 2675Mhz (20x 133,74), DDR3-1070
2. die nötige Taktrate beim Dualcore um das Ergebnis vom 2675Mhz Quadcore zu erzielen (max. 4013Mhz CPU-Takt mit 200,66 BCLK und DDR3-1606).

PS: auf eine zweite Taktrate verzichte ich diesmal um den Testaufwand zu reduzieren.

Benchmarks:

Crysis 3 - Savegame 'Willkommen im Dschungel' mit maximalen Details
http://s14.directupload.net/images/130629/dkm2ibtg.png

Bemerkung: der Dualcore lässt sich nicht weit genug hochtakten. Hochgerechnet müsste er mit 6084Mhz takten. Praktisch wird man irgendwo bei 5xxxMhz landen da bei so tiefen Frames die Grundlast schon einen relativ großen Einfluss hat. Man sieht schon, dass der DC mit 4013Mhz vs. 2675Mhz bei 50% mehr Takt 69% höhere Frames liefert.

[dargo]

Wie man unschwer erkennen kann scheint DIRT Schwierigkeiten mit 3 Kernen zu haben. Obs jetzt an der Engine oder DIRT selbst liegt kann ich allerdings nicht sagen.

[Sorkalm]

Wie man unschwer erkennen kann scheint DIRT Schwierigkeiten mit 3 Kernen zu haben. Obs jetzt an der Engine oder DIRT selbst liegt kann ich allerdings nicht sagen.

Ein Gegentest mit einem Phenom oder Nehalem (vielleicht findet sich ja jemand, dem du mal dein Savegame gibst), ob es da dieses Phänomen auch gibt, wäre sicher interessant. So als grobe Einschätzung dürfte das "über zwei PCs" gehen.

[dargo]

Ein Gegentest mit einem Phenom oder Nehalem (vielleicht findet sich ja jemand, dem du mal dein Savegame gibst), ob es da dieses Phänomen auch gibt, wäre sicher interessant. So als grobe Einschätzung dürfte das "über zwei PCs" gehen.
Kann ich gerne machen. Einfach PN an mich. :)

[Gast]

seltsam dass Quadcore mit höherem takt mehr bring.

[dargo]

seltsam dass Quadcore mit höherem takt mehr bring.
:confused:

2Ghz QC + ~26% gegenüber 2Ghz DC
1,45Ghz QC + ~28% gegenüber 1,45Ghz DC

Es ist eigendlich anders herum. Wobei man das schon fast als Messtoleranz ansehen kann. :)

[K4mPFwUr$t]

@dargo
deinen willen eine vergleichsmöglichkeit zwischen SC/DC/TC/QC zu schaffen in allen ehren.
aber im endeffekt hat man von diesem vergleich nur wenig wenn man auflösungen fährt wo nur die CPU limitiert.

hier beim vergleich sind das vieleicht mal 13FPS zwischen DC und QC, wie schaut es dann erst bei auflösung mit 1280x1024 und mehr aus?

dann wäre die sache mit den AVG FPS, die benches würden mehr aussagen wenn es min, avg und max FPS gäbe.

des weiteren wäre vieleicht auch ein vergleich zwischen ~2000Mhz und ~3000Mhz angebracht, um zu sehen wie sehr das spiel vom OC profitiert.

allerdings muss man berücksichtigen das du nicht soviel ressourcen hast wie z.b. eine seite ala CB.de.

[Gast]

:confused:

2Ghz QC + ~26% gegenüber 2Ghz DC
1,45Ghz QC + ~28% gegenüber 1,45Ghz DC

Es ist eigendlich anders herum. Wobei man das schon fast als Messtoleranz ansehen kann. :)

oh, hab mich im diagramm verschaut und die 1,8 GHz bei den 1,4GHz-versionen eingeordnet ;)

[Gast]

@dargo
deinen willen eine vergleichsmöglichkeit zwischen SC/DC/TC/QC zu schaffen in allen ehren.
aber im endeffekt hat man von diesem vergleich nur wenig wenn man auflösungen fährt wo nur die CPU limitiert.

stimmt, die aussagekraft der benches für die realität sind verdammt gering, im prinzip sind die benchmarks arg theoretisch.


dann wäre die sache mit den AVG FPS, die benches würden mehr aussagen wenn es min, avg und max FPS gäbe.

nein, min und max haben praktisch null aussagekraft, da sie nur einen extrem kleinen testzeitraum betrachten.

es geht ja auch nicht darum die spielbarkeit zu beurteilen sondern den relativen unterschied diverser konstellationen festzustellen und das wird genauer je mehr messwerte man hat, also je länger die getestete szene ist. das herauspicken eines einzelnen messwertes hat null aussagekraft.

[dargo]

@dargo
deinen willen eine vergleichsmöglichkeit zwischen SC/DC/TC/QC zu schaffen in allen ehren.
aber im endeffekt hat man von diesem vergleich nur wenig wenn man auflösungen fährt wo nur die CPU limitiert.

Nicht wenn man verstanden hat worum es in diesem Thread geht. :)


hier beim vergleich sind das vieleicht mal 13FPS zwischen DC und QC, wie schaut es dann erst bei auflösung mit 1280x1024 und mehr aus?

Mich interessieren keine Frames in dem Sinne obs spielbar ist oder nicht. Es geht hier ausschließlich um Kern-Skalierung in Games. Oder anders ausgedrückt - wie gut skaliert die Engine vom Game XY mit mehr als zwei Kernen.


dann wäre die sache mit den AVG FPS, die benches würden mehr aussagen wenn es min, avg und max FPS gäbe.

Ich hatte schon mehrfach erklärt warum min.fps für Savegames weniger geeignet sind und möchte mich nicht wiederholen.


des weiteren wäre vieleicht auch ein vergleich zwischen ~2000Mhz und ~3000Mhz angebracht, um zu sehen wie sehr das spiel vom OC profitiert.

Das brauche ich nicht testen, das weiß ich auch so. Mindestens +50% mehr Frames solange die Graka nicht limitiert.

[Lu-Tze]

Mal so als genereller Vorschlag: Wie wäre es eigentlich mit nem FPS-Histogramm? Oder zumindest mal anderen statistischen Werten wie "FPS-Median" und "FPS-Standardabweichung"? Ich glaube, die hätten schon ein wenig Aussagekraft... Auch eine "95%-Untergrenze" wäre sinnvoll, also der FPS-Wert, überhalb dem sich die FPS für 95% der Zeit befinden, und unterhalb für 5%.

[LordDeath]

Ich finde, dass man die Spieleleistung von CPUs nur mit praxistauglichen Settings durchführen sollte. Wer spielt, muss darauf achten, dass man möglichst grafiklimiterend unterwegs ist. Ist die CPU schnell, kann man diese Leistung nicht anderweitig nutzen, ist die Grafikkarte zu schnell, aktiviert man höhere AA+AF Stufen. Und in solchen Situationen ist die Leistung gefragt. Da sieht man dann, dass z.B. die min-FPS bei neuen CPUs stellenweise höher liegen.

Aber solche theoretische Tests braucht man nicht wirklich. Da kannst du auch den CPU Test von 3D Mark nehmen und uns zeigen, wie viel Leistung die extra Cores bringen. Das sind Messergebnisse die für nichts stehen.

[Gast]

Mal so als genereller Vorschlag: Wie wäre es eigentlich mit nem FPS-Histogramm? Oder zumindest mal anderen statistischen Werten wie "FPS-Median" und "FPS-Standardabweichung"?

für was der aufwand?

es geht um reine geschwindigkeitsvergleiche, dafür sind AVG-FPS perfekt geeignet.

es geht nicht um spielbarkeit, was in diesen settings auch komplett absurd wäre, da so niemand spielt.

[K4mPFwUr$t]

nur was bringt dann einem das wissen mit den theoretischen settings?

wenn man CPU limitierung und praxissettings verbinden kann wäre das ganz gut, nur findet man wenig spiele die eine sehr hohe CPU belastung mit sich bringen. das neuste beispiel davon wäre ja GTA4, wo man QC (oder besser gesagt 3threads laut div. taskmanager bildern) einen nutzen gegenüber DC hat.

[Gast]

@LordDeath + @K4mPFwUr$t

In diesem Thread geht es ausschließlich um die Skalierung von Mehrkern CPUs bei Spielen! Um dies zu untersuchen braucht man ein reines CPU-Limit! Unter einem teilweisen oder gar vollständigen GPU-Limit wären die Tests sinnlos. Es würde ja auch niemand auf die Idee kommen, heutige High-End-Grafikkarten auf einer Pentium 60Mhz zu testen! ;)

[LovesuckZ]

Wird hier auch berücksichtigt, dass nVidia schon QuadCore Optimierungen im Treiber hat? Es wäre besser die Tests ohne diese Optimierungen zu fahren, da es ansonsten zu einem verfälschten Ergebnis kommt.

@LordDeath + @K4mPFwUr$t

In diesem Thread geht es ausschließlich um die Skalierung von Mehrkern CPUs bei Spielen! Um dies zu untersuchen braucht man ein reines CPU-Limit! Unter einem teilweisen oder gar vollständigen GPU-Limit wären die Tests sinnlos. Es würde ja auch niemand auf die Idee kommen, heutige High-End-Grafikkarten auf einer Pentium 60Mhz zu testen! ;)

Inwieweit ist dieses Wissen von Bedeutung? Ich teste doch auch nicht die Skalierung von Grafikkarteneinstellung anhand der Codierungsgeschwindigkeit eines Films...

[dargo]

Wird hier auch berücksichtigt, dass nVidia schon QuadCore Optimierungen im Treiber hat?
Die Threadoptimierung im Grafiktreiber steht bei alles Tests auf "auto".

[Gast]

Inwieweit ist dieses Wissen von Bedeutung? Ich teste doch auch nicht die Skalierung von Grafikkarteneinstellung anhand der Codierungsgeschwindigkeit eines Films...

Na um Grafikkarten bei Spielen zu vergleichen brauchts nunmal ne CPU, die die ganzen "Vorberechnungen" an die Grafikkarte liefert. Ist nun diese CPU nichtmal in der Lage die schwächste Karte in diesem GPU-Vergleichstest mit Daten ausreichend schnell zu beliefern, scheinen alle Karten gleichschnell -> Test ist wertlos!

Genauso ist bei reinen CPU-Tests. Hier darf die GPU einfach nicht limitieren. Am besten wäre, wenn man die GPU quasi auskoppeln könnte, also die CPU immer mit voller Leistung "ins Leere" rechnen könnte. Da dies wohl nicht so einfach möglich ist, muss man eben die Auflösung so weit wie möglich runterdrehen um aus dem GPU-Limit heraus zu kommen. Wenn das auch noch nicht reicht, muss man auf niedrigerem CPU-Takt niveau vergleichen.

@dargo

Super, dass Dein neuer Quad jetzt läuft. Warte gespannt auf weitere Tests! :)

[pest]

vielleicht kannst du mir die Frage ja nochmal konkret beantworten dargo
warum du Takt/Bandbreite-Verhältnis gleich lässt?

[BlackBirdSR]

Würden alle hier, die dargo wegen 640x480 kritisieren, auch die Wissenschaftler am LNC kritisieren, weil sie theoretische Grundlagenforschung betreiben?

Es gibt Leute die sich eben für die Theorie interessieren und denen die Praxis erstmal egal ist, solange man den Background nicht kennt. Anstelle dargo hier was vorzuwerfen, sollte man sein Hirn anschalten und die theoretischen Informationen in die Praxis umsetzen!!!

Vielleicht hat ja einer von euch Lust dargos Informationen für den alltäglichen Spielgebrauch umzusetzen, um dann ein Gesamtbild zu erzeugen? Aber vorsicht: Wer denkt, dass in 1680x1050 4xAA die CPU nicht mehr limitiert, der irrt sich gewaltig. Es gibt genügend solcher Situationen, und die erfasst man eben am besten so, wie es dargo macht.

[Gast]

Wird hier auch berücksichtigt, dass nVidia schon QuadCore Optimierungen im Treiber hat? Es wäre besser die Tests ohne diese Optimierungen zu fahren, da es ansonsten zu einem verfälschten Ergebnis kommt.

wieso? es sollten ja auch multicorevorteile durch den grafiktreiber gezeigt werden.

[Gast]

Da dies wohl nicht so einfach möglich ist,

möglich ist es schon, der grafiktreiber müsste einfach alle renderbefehle verwerfen.

mit 3dAnalyze kann man das beispielsweise auch machen.

[dargo]

vielleicht kannst du mir die Frage ja nochmal konkret beantworten dargo
warum du Takt/Bandbreite-Verhältnis gleich lässt?
Stelle dir mal eine Autobahn vor mit zwei Staus. In beiden Staus hast du 100 Fahrzeuge, du stehst ganz hinten. Die erste Strecke wird von 3 auf 2 Fahrbahnen reduziert. Die zweite von 3 auf 1 Fahrbahn. Wo kommst du schneller voran wenn sich alle an das Reißverschlussverfahren halten? Jetzt übertrage das mal auf die CPU. Die Fahrbahnen sind der FSB, eben das Nadelöhr.

Man könnte es auch anders sagen - in beiden Staus geht es von 3 auf 2 Spuren. Im ersten Staus hast du 50 Fahrzeuge, im zweiten 100. In beiden Fällen stehst du ganz hinten. Wo kommst du schneller voran?

[K4mPFwUr$t]

@dargo
der gedankengang ist richtig, nur ist das je nach eingesetzter software unterschied.
besonders im serverbereich gibt es da teils unterschiede, die eine lösung braucht fast ausschließlich CPU power, da macht sich mehr RAM takt nur begrenzt bemerkt.
das ganze kann man auch für den RAM ummünzen.
aber das spiel ja hier keine rolle ;)

ich frag mich nur ob man direkt unterschiedliche engines mit unterschiedlichen spielen vergleichen kann. die grundskalierung dürfte gleich sein, aber angenommen spiel a hat doppelt soviele bots die eine gute KI haben und angenommen spiel b ist ein cod was ja nur eine hand voll scripte braucht um die NPCs ins spiel zu integrieren.

hier müsste sich ja eindeutig die CPU skalierung zu gunsten vom spiel a fallen?

[pest]

Man könnte es auch anders sagen - in beiden Staus geht es von 3 auf 2 Spuren. Im ersten Staus hast du 50 Fahrzeuge, im zweiten 100. In beiden Fällen stehst du ganz hinten. Wo kommst du schneller voran?

versteh' ich nicht, kannst du es so erklären das es ohne Autos auskommt
es müsste doch ein Satz reichen, um deutlich zu machen, wozu das gut sein soll

btw. gehe ich davon aus das bei nem QC und 200Mhz der FSB enorm
limitiert, schließlich kommunizieren die beiden CPUs untereinander auch über den FSB.

[dargo]

@K4mPFwUr$t
Deinen letzten Post kann ich nicht nachvollziehen. Ich ändere doch nicht nur den FSB sondern gleichzeitg im gleichen Verhältnis die Speicherbandbreite und CPU-Takt.

[AffenJack]

Wenn der FSB bei 200mhz enorm limitiert, limitiert er aber genauso bei 333mhz.
Durch das gleiche Verhältnis wie bei höherem Takt nimmst du das Limit mit zu niedrigeren taktraten, denn die Rechenleistung fällt doch in gleichem Maße wie der FSB.
Würdest du den FSB gleichbehalten würdest du das Bild verfälschen, weil du den FSB als limitierenden Faktor ausschaltest.

[blackbox]

Würden alle hier, die dargo wegen 640x480 kritisieren, auch die Wissenschaftler am LNC kritisieren, weil sie theoretische Grundlagenforschung betreiben?

Es gibt Leute die sich eben für die Theorie interessieren und denen die Praxis erstmal egal ist, solange man den Background nicht kennt. Anstelle dargo hier was vorzuwerfen, sollte man sein Hirn anschalten und die theoretischen Informationen in die Praxis umsetzen!!!

Vielleicht hat ja einer von euch Lust dargos Informationen für den alltäglichen Spielgebrauch umzusetzen, um dann ein Gesamtbild zu erzeugen? Aber vorsicht: Wer denkt, dass in 1680x1050 4xAA die CPU nicht mehr limitiert, der irrt sich gewaltig. Es gibt genügend solcher Situationen, und die erfasst man eben am besten so, wie es dargo macht.

Der Fehler ist, dass man die Ergebnisse überinterpretiert.
Was Dargo macht, ist vollkommen in Ordnung. Aber eben nur für die Einstellungen, die Dargo fährt. Das selbe gilt auch für alle anderen Artikel, die sich mit dem Thema auseinandersetzen. Daher ist auch der Titel von Anfang an schon falsch gewählt: Kern-Skalierung in Games. Das suggeriert eine praxisnahe Untersuchung vom Einfluss der Kerne auf Spiele.
Man kann und darf die Ergebnisse (und insbesondere das Fazit!) nicht zu sehr verallgemeinern, was aber leider viel zu oft gemacht wird. Und dann werden plötzlich diese Ergebnisse völlig überbewertet.
Diese Erkenntnisse sind nett zu wissen, haben aber, was die meisten zu Recht bemängeln, für sie keine Praxisrelevanz. Und da du den Vergleich mit dem LNC gebracht hast, dafür dürfte sich ebenfalls nur ein Bruchteil interessieren, weil eben dieses LNC keinen Nutzen bringt für den Durchschnittsbürger. Und außerdem ist man in der Wissenschaft viel vorsichtiger, was die Interpretation der Ergebnisse angeht.

[AnarchX]

@AffenJack
Wobei man dann aber auch noch die Cache-Größe proportional zur Rechenleistung senken müsste, schliesslich ist das auch ein entscheidenter Faktor bei der IO-Performance.

Aber das geht dann doch zu weit. So ist der Versuchsaufbau schon ziemlich gut gewählt.

[dargo]

versteh' ich nicht, kannst du es so erklären das es ohne Autos auskommt
es müsste doch ein Satz reichen, um deutlich zu machen, wozu das gut sein soll

Lese dir es nochmal gründlich durch. Anders kann ich es dir auch nicht erklären. :)


btw. gehe ich davon aus das bei nem QC und 200Mhz der FSB enorm
limitiert, schließlich kommunizieren die beiden CPUs untereinander auch über den FSB.
Q9550 = 2833Mhz mit 333Mhz FSB

Ich nehme 1449Mhz mit einem FSB von 207Mhz. Das Nadelör ist beim Standardtakt des Q9550 sogar größer. Rechner einfach nach.

@Blackbox
Aber vorsicht: Wer denkt, dass in 1680x1050 4xAA die CPU nicht mehr limitiert, der irrt sich gewaltig. Es gibt genügend solcher Situationen, und die erfasst man eben am besten so, wie es dargo macht.
Ich möchte nochmal besonders auf diesen Satz hinweisen.

[Gast]

Es gibt Leute die sich eben für die Theorie interessieren und denen die Praxis erstmal egal ist, solange man den Background nicht kennt. Anstelle dargo hier was vorzuwerfen, sollte man sein Hirn anschalten und die theoretischen Informationen in die Praxis umsetzen!!!

stimmt, wenn man mal kapiert hat, dass die aussagekraft der tests maximal so groß wie die eines 3dmark-scores ist sind sie eigentlich ganz interessant ;)

[dargo]

@AffenJack
Wobei man dann aber auch noch die Cache-Größe proportional zur Rechenleistung senken müsste, schliesslich ist das auch ein entscheidenter Faktor bei der IO-Performance.

Aber das geht dann doch zu weit. So ist der Versuchsaufbau schon ziemlich gut gewählt.
AnarchX, ich habe kein SLI sonst würde ich ja den Standardtakt nehmen. Das werde ich auch tun sobald es schnellere Single-GPU Grafikkarten gibt und ich der Meinung bin es ist eine Neue fällig. Mit einer GPU-Power von 2x GTX260/280 kann ich locker den Q9550 für die Tests mit 2833Mhz betreiben. :)

[blackbox]

Aber vorsicht: Wer denkt, dass in 1680x1050 4xAA die CPU nicht mehr limitiert, der irrt sich gewaltig. Es gibt genügend solcher Situationen, und die erfasst man eben am besten so, wie es dargo macht.

Der Satz ist vollkommen unlogisch.
Ich hoffe, ihr kommt selbst darauf, warum.

Außerdem steckt in dem Satz genau der Fehler, den ich im vorigen Beitrag beschrieben habe.

[dargo]

Der Satz ist vollkommen unlogisch.
Ich hoffe, ihr kommt selbst darauf, warum.
Ich möchte dir nicht zunahe treten aber scheinbar hast du dich mit CPU-Leistung in Games sehr wenig beschäftigt. Die "Verblendung" diverser Benchmarks im Netz mit Timedemos scheint gewirkt zu haben.

[blackbox]

Ich möchte dir nicht zunahe treten aber scheinbar hast du dich mit CPU-Leistung in Games sehr wenig beschäftigt. Die "Verblendung" diverser Benchmarks im Netz mit Timedemos scheint gewirkt zu haben.

Dann hast du nicht verstanden, worauf ich hinweisen wollte.

Warum sollte man ein anderes Setting auswählen, um ein Ergebnis zu erreichen? Warum benutzt man nicht das ursprüngliche Setting?

[dargo]

Warum sollte man ein anderes Setting auswählen, um ein Ergebnis zu erreichen? Warum benutzt man nicht das ursprüngliche Setting?
Weil beim ursprünglichen Setting die Grafikkarte zwischen 0 und 100% (100% eher unwahrscheinlich) limitieren kann, nicht muss. Außerdem bringt mein Setting den meisten gar nichts weil sie in völlig anderen Settings und Hardwarekostellationen spielen.

Im Grunde genommen steht alles schon hier drin:
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=326362

Es wurde schon alles wesentliche dort besprochen. Zugegeben, der Thread ist etwas dick geworden.

[Gast]

Würden alle hier, die dargo wegen 640x480 kritisieren, auch die Wissenschaftler am LNC kritisieren, weil sie theoretische Grundlagenforschung betreiben?

Es gibt einen gewaltigen Unterschied: Grundlagenforschung führt sehr oft zu Ergebnissen die dann in die Praxis umgesetzt werden und verbessern so etwas.

Die Ergebnisse eines Foremmitgliedes verändern...mit Verlaub...garnichts. ;-)

[Gast]

Und ein realitätsfremdes setting hilft mir persönlich genauso viel oder wenig, wie das Wissen das ein Formel 1 Bolide ab einer bestimmten Geschwindigkeit an der Decke fahren könnte.

;-)

[blackbox]

Ich kritisiere nicht deine Mühen, auch nicht die Zahlen, die deine Tests hervorbringen. Ich finde es sogar gut, dass du es macht.

Ich warne nur davor, die Ergebnisse zu sehr zu bewerten. Denn in dem Moment, wo du das tust (und das wurde von anderer Seite leider schon getan), machst du dich angreifbar.

Es ist zwar lobenswert, einen Versuchsaufbau so weit zu verändern, um eine Vergleichbarkeit zu erreichen (was letztendlich ja auch der Anspruch sein sollte), aber der ist hier bei der Thematik in meinen Augen kaum möglich. Dafür sind zu viele Parameter im Spiel. Oder als Lösung: man muss eben mehr Einstellungen fahren, was zu einem unverhältnismäßig großen Aufwand führen würde. Das ist nur schwer möglich. Daher gilt hier dieselbe Aussage: Keine Über- und Fehl-Interpretation der Ergebnisse.

[pest]

Lese dir es nochmal gründlich durch. Anders kann ich es dir auch nicht erklären. :)


ja sry das ich zu dumm bin und deine Autoanalogie nicht checke :rolleyes:
du könntest auch einfach technische Begriffe benutzen



Ich nehme 1449Mhz mit einem FSB von 207Mhz. Das Nadelör ist beim Standardtakt des Q9550 sogar größer. Rechner einfach nach.


so einfach wie du das siehst ist es m.M. nach nicht

woher willst du wissen wie stark der FSB limitiert
woher weißt du das man den FSB "einfach linear runterrechnen" muss
Sättigungspunkte für verfügbare Bandbreite (bei QC vs. DC) mal aussen vor gelassen

[dargo]

@Blackbox
Wer wie die Ergebnisse interpretiert ist jedem selbst überlassen. Wer nur ansatzweise das Thema verstanden hat wird es zu schätzen wissen. Wem das alles egal ist... gut, ist sein gutes recht. :)

[Schimi1983]

mach die tests weiter... mich interessiert es ;-)
for allem der einbruch im dem TC

[Sk_Antilles]

Kommen da jetzt noch ein paar andere Benchmarks oder war es das jetzt?
Weil ein Spiel sagt ja so gut wie nichts aus. Ist recht interessant, aber besser ist es, wenn man eine größere Auswahl an Spielen hätte um einen gewissen Trend zu erkennen.
Ob das sich das in der Praxis bemerkbar macht steht dann auf einen anderen Blatt. Laßt doch Dargo seine Tests machen und diese kann man dann interpretieren. Wir wissen doch ALLE, dass die gewählte Auflösung nicht Praxisrelevant ist. Wir wissen, dass wenn man absolut GPU limitiert bencht, dass das Ergebnis auch nicht gerade sehr aussagekräftig sein wird.
Außerdem kann ich nach dem ersten Test in meiner Illusion leben, dass mein QuadCore echt was bringen könnte, wenn ;D.. Ihr wisst schon :D
Ich glaube einige diskutieren hier um des diskutieren Willens.

[Superheld]

dargo mach ruhig weiter, hast du schon GTA4 ? :smile:

[dargo]

Kommen da jetzt noch ein paar andere Benchmarks oder war es das jetzt?

Die Platzhalter sind nicht nur aus Spaß da. ;)

dargo mach ruhig weiter, hast du schon GTA4 ? :smile:
Noch nicht.

Edit:
Kann man in GTA IV überhaupt frei speichern?

Edit2:
Alarm für Cobra 11: Burning Wheels hinzugefügt. Habe diesmal wohl das Worst Case schlechthin gefunden was die CPU-Last angeht. Cobra 11 ist aber eine reine Zweikern-Anwendung.
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=6973301&postcount=1

PS: ich habe mich bei der kleinsten Taktrate für 1470Mhz entschieden da mir mein Board mit 1449Mhz einen Strich durch die Rechnung ziehen will. Mal werden 207Mhz FSB übernommen, mal sind es 208Mhz (oder besser gesagt 207,6Mhz). Diesmal sinds 210Mhz die auch jedes Mal exakt stimmen (habe es mehrfach geprüft). Den DIRT-Bench habe ich natürlich mit der neuen Taktrate wiederholt.

[Crazy_Chris]

In der Praxis haben diese Messungen leider keinen Wert da sie Realitätsfern sind. :(

[BlackBirdSR]

In der Praxis haben diese Messungen leider keinen Wert da sie Realitätsfern sind. :(

Mach weiter so dargo. Ich finde diese Ergebnisse sehr interessant und mir macht es irgendwie gar keine Probeme sie in die Praxis umzusetzen.
Bin mal gespannt auf die nächsten!

Hab auch schon die ein oder andere Idee wegen dem TC. Aber lass mal weiter benchmarks abwarten.

[Schimi1983]

und schonwieder ist nen TC so komisch... hmmm

[K4mPFwUr$t]

@dargo
hast du was an RTS da?
mich würde intressieren wie sich dort eine CPU großartig bemerkbar macht, am liebsten wäre mir coh.

[dargo]

und schonwieder ist nen TC so komisch... hmmm
Bis jetzt nur bei DIRT. Die Frage ist nur ob es genauso in dem Ausmaß mit einem Phenom X3 passiert? Teste gerade Crysis.

@dargo
hast du was an RTS da?

Nee, leider nicht. Ist nicht mein Genre. Ich könnte eventuell eine Demo testen, glaube aber kaum, dass man in Demos speichern/frei speichern kann.

[K4mPFwUr$t]

bei der vCoH demo kann man jedenfalls den benchmark benutzen, die frage ist allerdings in wie fern wirk sich dieser bench auf die CPU belastung aus.

[dargo]

bei der vCoH demo kann man jedenfalls den benchmark benutzen, die frage ist allerdings in wie fern wirk sich dieser bench auf die CPU belastung aus.
Keine Timedemos! :nono:

[BlackBirdSR]

bei der vCoH demo kann man jedenfalls den benchmark benutzen, die frage ist allerdings in wie fern wirk sich dieser bench auf die CPU belastung aus.

Ich sag mal so:
Beim CoH ohne Addon wurde der integrierte Benchmark mit 1.2GHz Dual-Core K8 zum Fiasko.
Eine 4 Spieler Map gegen 3 AI-Spieler habe ich damit aber ohne jegliche Performanceeinbußen gespielt...

[_DrillSarge]I[]

Keine Timedemos! :nono:
ich könnte mal ut3 benchen, weil das (mit) am besten skaliert. aber dort kann man nur reproduzierbare ergebnisse mit dem flythrough zeugs bekommen.
gibts da einen anderen weg?

[dargo]

I[;6974670']ich könnte mal ut3 benchen, weil das (mit) am besten skaliert. aber dort kann man nur reproduzierbare ergebnisse mit dem flythrough zeugs bekommen.
gibts da einen anderen weg?
Afaik kann man in UT3 gar nicht erst speichern. Von daher wäre ein Test mit besagtem Game sinnlos da man nur auf Timedemos ausweichen kann.

[K4mPFwUr$t]

@BlackBirdSR
wenn man mit verschiedenen mods spielt, kann man da so ziemlich jede CPU in die knie bekommen.
bei normalen gefechten ohne mods gehts noch.

@dargo
die AI in CoH verhält sich in den ersten minuten meist recht simultan.
also wäre es möglich mit savegames zu arbeiten (die afaik in der demo ging, die demo war ledeglich auf USA und eine 2p map beschränkt).

[InsaneDruid]

Dann würde sich die opposing Fronts demo (http://www.4players.de/4players.php/download_info/PC-CDROM/Download/46636.html) anbieten, da sie eher an der aktuellen coh engine dran ist als die alte coh demo. 2 SP missionen sind vorhanden, savegames funktionieren.

[pest]

ich bin immernoch der meinung das die tests nicht mal vor dem synthetischen hintergrund sinn machen.

[BlackBirdSR]

ich bin immernoch der meinung das die tests nicht mal vor dem synthetischen hintergrund sinn machen.

Gelesen und akzeptiert und die Meinung sei dir gelassen. Aber dann lass dargo nun auch weiter seine Arbeit machen. Fair ist Fair.

@UT3 Flyby:
Keine Chance. Ohne User-Input, Particle-System, KI und Physik kann man gleich wieder 3dmark2001 benchen.

[dargo]

@UT3 Flyby:
Keine Chance. Ohne User-Input, Particle-System, KI und Physik kann man gleich wieder 3dmark2001 benchen.
So könnte man es auch ausdrücken. X-D

Crysis ist fertig, siehe erster Post. :)

ich bin immernoch der meinung das die tests nicht mal vor dem synthetischen hintergrund sinn machen.
Ich habe es zur Kenntnis genommen.

[Madkiller]

Diese Erkenntnisse sind nett zu wissen, haben aber, was die meisten zu Recht bemängeln, für sie keine Praxisrelevanz.
Jap, die Praxisrelevanz. Praxisrelevanz in Reviews die auch eine korrekte Aussage für den Einzelnen trifft, gibt es nicht. Das ist nur eine Illusion.
Klar, es kann sein, daß bei einem Review sich zufällig sehr viele Faktoren überschneiden. Aber wer hat schon das selbe System, spielt - ich meine benched - die selben Spiele auf die selbe Art und Weise mit den selben Prioritäten (Settings, fps, etc)? Genau, fast niemand.

Aber nur dann wäre so ein Review auch für jemanden aussagekräftig.
Denn selbst wenn jemand exakt das selbe System hat, das selbe Spiel mit den gleichen Settings spielt, selbst dann fordert jede Situation in dem Spiel GraKa und CPU anders. So kann ne GPU-Limitierung in dem Review schnell zu ner CPU-Limitierung in den kritischen Szenen wenn man selber spielt werden.

Die Einzige Möglichkeit um anhand von Reviews zu wissen, was wieviel für einen bringt ist das alles aufzuteilen.
Indem man aufgezeigt bekommt, zuwas die CPU zu leisten in der Lage ist (mit klar CPU-limitierten Settings, wie dargo es macht) und natürlich in nem eigenen Durchlauf was die GPU zu leisten in der Lage ist (natürlich in ner praxisüblichen Auflösunge, FSAA, AF, etc.)

Wenn man ne richtige Antwort haben will, muß man sich das durch selber Denken zusammen setzen. Ne fertige Antwort die auch zutrifft gibt es nicht - auch wenn es viele nicht wahr haben wollen.

[pest]

Ich habe es zur Kenntnis genommen.

ich finde es einfach schade, das du mir nicht technisch begründen willst/kannst?
warum du so einen Wert auf das gleiche (theoretische)Bandbreitenverhältnis legst?

Hast du den tRD Wert dem entsprechenden FSB angepasst?

[Crazy_Chris]

Aber nur dann wäre so ein Review auch für jemanden aussagekräftig.
Denn selbst wenn jemand exakt das selbe System hat, das selbe Spiel mit den gleichen Settings spielt, selbst dann fordert jede Situation in dem Spiel GraKa und CPU anders. So kann ne GPU-Limitierung in dem Review schnell zu ner CPU-Limitierung in den kritischen Szenen wenn man selber spielt werden.


Klar gibt es keine 100 Prozentige Vergleichbarkeit aber was er macht ist ja ein zusätzliche Verfälschung der in der Praxis vorhanden Verhältnisse. Klar kann das mal ganz interessant sein aber irgendeinen echten Nutzen kann man daraus nicht ziehen. :|
Finde das es im Grunde verschwendete Zeit ist. :redface: Aber wenns spaß macht warum nicht. Bin ja selber auch gerne mal am Tüfteln.

[CrazyIvan]

Seit wann wird im 3DC-Forum infrage gestellt, dass man CPUs mit CPU-limitierten Versuchsaufbauten und GPUs mit GPU-limitierten testet? o0

[Crazy_Chris]

Seit wann wird im 3DC-Forum infrage gestellt, dass man CPUs mit CPU-limitierten Versuchsaufbauten und GPUs mit GPU-limitierten testet? o0

Es geht wohl vielmehr und die Sache mit dem konstanten FSB/DRAM-Verhältnis welches zwar gut gemeint aber praktisch irrelevant ist. :wink:

[Madkiller]

ich finde es einfach schade, das du mir nicht technisch begründen willst/kannst?

Hier wirds (deine Frage, aber auch manch anderes) deutlich
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=337813
warum du so einen Wert auf das gleiche (theoretische)Bandbreitenverhältnis legst?

Weil er so praktisch immer die selbe Pro-MHz-Leistung hat.
So kann er ableiten, wie gut ein Spiel mit steigender CPU-Leistung skaliert.

Seit wann wird im 3DC-Forum infrage gestellt, dass man CPUs mit CPU-limitierten Versuchsaufbauten und GPUs mit GPU-limitierten testet? o0
thx

[Lyka]

gibts auch vielleich was zu Oblivion? :D

[K4mPFwUr$t]

oblivion könnte man mit verschiedenen grasdichten und grassichtweiten probieren, da gras so gut wie nur auf die CPU belastung sich auswirkt.

[pest]

Hier wirds (deine Frage, aber auch manch anderes) deutlich
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=337813


ähm was soll da stehen?...was ich nicht schon weiß?


Weil er so praktisch immer die selbe Pro-MHz-Leistung hat.


na eben nicht, weil der Einfluss des FSB nicht linear ist.

[dargo]

NfS: ProStreet ist fertig.
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=6973301&postcount=1

Dritter Core skaliert sehr gut mit. Der vierte Core bringt nur einen sehr geringen Framezuwachs.

@BlackBirdSR
Hast du schon eine Erklärung oder Vermutung warum der TC in DIRT so einbricht? In anderen Games kann ich dieses Verhalten bis jetzt nicht feststellen.

[AffenJack]

Skaliert sehr gut mit ist untertrieben, er wird fast zu 100% ausgenutzt. Hätte ich bei Prostreet auf keinen fall erwartet.

[pest]

wie soll man die Ergebnisse eigentlich richtig interpretieren
wenn ein 48.6% höher getakteter DC 56.3% mehr Frames liefert? :ugly:

aber schon witzig, da stellt man naive Fragen, und wird sofort für dumm verkauft
es zeigt am Ende aber nur, wie wenig Plan hier manche von dem haben, wovon sie so reden

man ich muss diesem Thread fernbleiben :(

[Armaq]

wie soll man die Ergebnisse eigentlich richtig interpretieren
wenn ein 48.6% höher getakteter DC 56.3% mehr Frames liefert? :ugly:

aber schon witzig, da stellt man naive Fragen, und wird sofort für dumm verkauft
es zeigt am Ende aber nur, wie wenig Plan hier manche von dem haben, wovon sie so reden

man ich muss diesem Thread fernbleiben :(
Was genau ist dein Problem? Er will doch nur eine Sache abbilden und limitiert sich selbst auf genau diese. Wo liegt die Ursache für deine Kritik?

Edit: Ich breche es auf einen Satz. Dargo könnte seinen Tag damit verbringen unter 1680x1050 4xAA 16xAFprobieren eine Stelle zu finden, die vollständig durch die CPU limitiert ist, stattdessen nimmt er gleich ein Setting, das durch die CPU gebremst wird und spart sich den Kram.

[blackbox]

Wenn man ne richtige Antwort haben will, muß man sich das durch selber Denken zusammen setzen. Ne fertige Antwort die auch zutrifft gibt es nicht - auch wenn es viele nicht wahr haben wollen.

Damit machst du es dir zu einfach. Man kann nicht einfach etwas dahin klatschen und die Zahlen für sich sprechen lassen.
Schließlich geht es hier darum, Erkenntnisse zu gewinnen.

Dann stelle ich jetzt zwei ganz einfache Fragen:
1. Was soll hier gezeigt werden? (in dem Sinne: was soll bewiesen oder belegt werden?)
2. Was zeigen uns diese Werte? Was sagen sie aus?

[Gast]

wie soll man die Ergebnisse eigentlich richtig interpretieren
wenn ein 48.6% höher getakteter DC 56.3% mehr Frames liefert? :ugly(

Ganz einfach. Sowas tritt auf, wenn irgendwas in der Engine bei einer bestimmten Aktualisierungsrate gekappt wird. Es könnten z.B. die Aktualisierungsrate von Spiegelungen auf dem Blech eines Autos auf max. 20fps limitiert werden. Wenn dann die FPS auf über 20 steigen bleibt plötzlich mehr Leistung für den "Rest" über. So kann eine CPU die um Faktor 2x schneller ist, auf einmal die 3-4fache FPS liefern!

Hier sehe ich auch ein Problem bei den niedrigen Taktraten von Dargos Tests. Aber leider gibt es für das Problem momentan wohl keine Lösung, solange man die GPU nicht auskoppeln kann. :(

Außerdem haben ja nicht alle Spiele solche "Limitierungen" für irgendwelche Berechnungen. Man müsste nur irgendwie herausfinden, bei welchen Spielen sowas auftritt.

Bis dahin einfach erstmal ordentlich weiter testen Dargo! :cool:

[Madkiller]

ähm was soll da stehen?...was ich nicht schon weiß?
Entschuldige bitte. Aber nach diesem Beitrag hier bin ich davon ausgegangen, daß dir eben vieles in diesem Bereich nicht klar ist:
ich bin immernoch der meinung das die tests nicht mal vor dem synthetischen hintergrund sinn machen.
(außer natürlich du benutzt das "synthetischen" hier nur als unfundierte Provokation - was ich dir aber nicht unterstellen will)

na eben nicht, weil der Einfluss des FSB nicht linear ist.
Exakt. Und gerade deswegen achtet er ja darauf, daß das Verhältniss von CPU-Takt zu FSB/RAM-Takt/Latenz praktisch (es gibt Timings die ggf angepasst werden müßten/könnten, deren Einfluß ist aber minimal) gleich bleibt. Um eben den Einfluß von einem anderen FSB/RAM-Takt/Latenz-Verhältniss auszuschließen/minimieren.

aber schon witzig, da stellt man naive Fragen, und wird sofort für dumm verkauft
es zeigt am Ende aber nur, wie wenig Plan hier manche von dem haben, wovon sie so reden

man ich muss diesem Thread fernbleiben :(
... oder du bist einfach ein wenig mehr offen für (dich) neue Themen/Erkenntnisse.

Ädit:
Eins evtl noch:
btw. gehe ich davon aus das bei nem QC und 200Mhz der FSB enorm
limitiert, schließlich kommunizieren die beiden CPUs untereinander auch über den FSB.
Deinem "enorm limitiert" entnehme ich jetzt mal, daß du es für möglich hältst, daß der FSB derart limitierten würde, daß z.B. eine Erhöhung des FSB von 10% auch nahezu 10% mehr CPU-Leistung bringen würde.
Solche Situationen gibt es aber in der Praxis nicht. Im Schnitt würde ich mal sagen, daß meist etwa nur 1/5el des höheren FSB/RAM-Takt in mehr CPU-Leistung verwandelt werden kann. Oder anders: Ein anderer FSB wirkt sich nur überschaubar auf die Pro-MHz-Leistung der CPU aus.

[Stormscud]

@ Dargo:
also wenn du mir erklärst wie dein Benchmark läuft kann ich Burning Wheels mit 3 Kernen mal nachprüfen wie die bei mir laufen, also im Gegensatz zu 2 und 1 Kern.
Um Kerne "abzuschalten" musste man doch was in die Boot.ini schreiben, oder?

P.S.: andere Spiele gehen natürlich auch, nur heute nicht mehr, muss morgen die 30min Powerpoint für Prozessdatenverarbeitung machen. Im Übrigen: schöne Arbeit, die du da leistest.

[dargo]

@Stormscud
Gerne. Die Vorgehensweise klären wir bitte über PN, das Ergebnis natürlich bitte hier posten. :)

[Madkiller]

Damit machst du es dir zu einfach. Man kann nicht einfach etwas dahin klatschen und die Zahlen für sich sprechen lassen.
Schließlich geht es hier darum, Erkenntnisse zu gewinnen.
Inwiefern einfach? Ich sagte doch, wann die Werte von dargo auch eine Praxisrelevanz haben.
Und seine Tests können genau das aussagen, wofür diese Tests gedacht sind, und natürlich kann man daraus Erkenntnisse erzielen.



Dann stelle ich jetzt zwei ganz einfache Fragen:
1. Was soll hier gezeigt werden? (in dem Sinne: was soll bewiesen oder belegt werden?)
2. Was zeigen uns diese Werte? Was sagen sie aus?
Na um wieviel die fps bei CPU-limitierten Szenen steigen.

[pest]

Außerdem haben ja nicht alle Spiele solche "Limitierungen" für irgendwelche Berechnungen. Man müsste nur irgendwie herausfinden, bei welchen Spielen sowas auftritt.


das tritt aber offensichtlich bei ziemlich vielen Spielen auf , die dargo getestet hat
und reduziert für mich die Wahrscheinlichkeit für korrekte Annahmen


1470Mhz vs. 2002Mhz (+36.2%)

DIRT: +46%
Cobra11: +39%
Crysis: +41%
ProStreet:+41%




Exakt. Und gerade deswegen achtet er ja darauf, daß das Verhältniss von CPU-Takt zu FSB/RAM-Takt/Latenz praktisch (es gibt Timings die ggf angepasst werden müßten/könnten, deren Einfluß ist aber minimal) gleich bleibt. Um eben den Einfluß von einem anderen FSB/RAM-Takt/Latenz-Verhältniss auszuschließen/minimieren.


du hast nicht verstanden was ein nicht-linearer Einfluss ist, ein Verhältniss ist linearer Natur.
Und es gibt Parameter die einen sehr starken Einfluss auf die Ramperformance haben (wie schon erwähnt z.B. tRD), das sollte man für solche Tests nicht auf "auto" lassen



Deinem "enorm limitiert" entnehme ich jetzt mal, daß du es für möglich hältst, daß der FSB derart limitierten würde, daß z.B. eine Erhöhung des FSB von 10% auch nahezu 10% mehr CPU-Leistung bringen würde.
Solche Situationen gibt es aber in der Praxis nicht. Im Schnitt würde ich mal sagen, daß meist etwa nur 1/5el des höheren FSB/RAM-Takt in mehr CPU-Leistung verwandelt werden kann. Oder anders: Ein anderer FSB wirkt sich nur überschaubar auf die Pro-MHz-Leistung der CPU aus.

das ist eine Annahme, die es zu belegen gilt. Die ist aber bei DC/QC verschieden und eben auch enorm von der Anwendung abhängig.
Bei 640x480@Low schlägt die verfügbare Bandbreite/Ramtakt/Latenz sehr stark durch.

Was genau ist dein Problem? Er will doch nur eine Sache abbilden

entweder richtig oder garnicht.


Dann stelle ich jetzt zwei ganz einfache Fragen:
1. Was soll hier gezeigt werden? (in dem Sinne: was soll bewiesen oder belegt werden?)
2. Was zeigen uns diese Werte? Was sagen sie aus?

das würde mich auch interessieren.

[Madkiller]

das tritt aber offensichtlich bei ziemlich vielen Spielen auf , die dargo getestet hat
und reduziert für mich die Wahrscheinlichkeit für korrekte Annahmen


1470Mhz vs. 2002Mhz (+36.2%)

DIRT: +46%
Cobra11: +39%
Crysis: +41%
ProStreet:+41%


Es gibt viele Dinge die pauschal CPU-Last verursacht.
Nur mal ein prinzipielles Beispiel:
Das OS muß im Hintergrund zumindest am Leben erhalten werden. Ich sag jetzt mal, das kostet 100MHz. Physik muß immer berechnet werden, ungeachtet wie hoch die fps. Kostet 200MHz. Bei der KI das Selbe. Macht sagen wir nochmal 200MHz.
In diesem Beispiel würden also 500MHz pauschal verwendet werden, und könnten nicht dafür verwendet werden mehr fps an die GraKa zu senden, daß die daraus Bilder errechnet. Wenn man also die 500MHz von den 1470MHz und den 2002MHz abzieht, kommt man auf:
970MHz vs. 1502MHz (+54,8%)
Damit ist alles im grünen Bereich.
[edit: sry, für das durcheinander, wenn man einmal was ändert...]


du hast nicht verstanden was ein nicht-linearer Einfluss ist, ein Verhältniss ist linearer Natur.

Bist du eigentlich an einer konstruktiven Diskussion interessiert?
Hier wirfst du mir vor, daß ich was nicht verstanden hätte. Obwohl das nur haltbar wäre, wenn ich das ohne Einschränkungen geschrieben hatte, auf die du aber jetzt eingehst:

Und es gibt Parameter die einen sehr starken Einfluss auf die Ramperformance haben (wie schon erwähnt z.B. tRD), das sollte man für solche Tests nicht auf "auto" lassen
Also was jetzt? Habe ich es nicht verstanden, oder sehen wir den Einfluß der RAM-Performance nur anders gewichtet?


das ist eine Annahme, die es zu belegen gilt. Die ist aber bei DC/QC verschieden und eben auch enorm von der Anwendung abhängig.

Ich sprach von ner groben Richtlinie. Wie soll man das belegen? Da könnte ich hunderte Beispiele aufzeigen, die das untermauern, und du könntest die immer noch als nichtig ansehen, weil nicht vorhanden Bereiche dir wichtig sind.


Bei 640x480@Low schlägt die verfügbare Bandbreite/Ramtakt/Latenz sehr stark durch.
das ist eine Annahme, die es zu belegen gilt.
Außerdem bleibt selbst wenn so manche Optionen auf Auto sein sollten, das grundlegende Verhältniss von CPU-Takt zu Latenz gleich oder zumindest sehr ähnlich. Wo sollen die großen Unterschiede her kommen?

entweder richtig oder garnicht.
So kann man es auch sehen. Wenn nur zu 90% und nicht zu 100% dann lieber garnicht.
Wenn man es so sieht, wird bald garnichts mehr gemacht.

das würde mich auch interessieren.
Was ist an meiner Antwort nicht klar?

Einerseits beschwerste dich, daß man auf deine "naiven" Anfragen nicht ausreichend eingehen würde, auf der anderen Seite setzte mit deinen Antworten noch einen drauf.

[Armaq]

Pest, dann mach du dir doch die Arbeit und finde unter 1680x1050 die Stellen in den Spielen die limitieren.

Ich finde es frech, dass hier Arbeit niedergeredet wird, die einen offensichtlichen Anspruch hat und sich selbst auch nicht mehr als dies zugesteht. Was Dargo macht ergibt Sinn, denn er hat sein Gebiet auch genau eingekreist.

Sein Test zeigt zB auf, wann ich mir einen X3 oder einen X4 Phenom aus Spielsicht kaufen sollte. Er zeigt nicht auf, ob ein 3000 Mhz X3 genau so gut ist wie ein 2250 Mhz X4.

[dargo]

Skaliert sehr gut mit ist untertrieben, er wird fast zu 100% ausgenutzt. Hätte ich bei Prostreet auf keinen fall erwartet.
Im Prinzip hast du recht. Viel mehr kann man vom dritten Core wirklich nicht erwarten. Fairerweise sollte man aber hier erwähnen, dass EA mit dem Patch 1.1 einen 30fps Framelimiter eingebaut haben. Umso ärgerlicher da ich im besagten Rennen welches ich fürs Benchen genommen habe mit 3,55Ghz CPU-Takt nicht unter 65fps mit 1680x1050 4xMSAA/16xAF komme. Im Durchschnitt um die ~75fps.

[pest]

Pest, dann mach du dir doch die Arbeit und finde unter 1680x1050 die Stellen in den Spielen die limitieren.


darum gehts doch garnicht, ich mache hier auch Nichts nieder.
Ich weiß nicht woher diese Selbstüberzeugung herkommt, man kann sich doch kritischen Fragen stellen, das erweitert den Horizont.

Es gibt viele Dinge die pauschal CPU-Last verursacht.
Nur mal ein prinzipielles Beispiel:
Das OS muß im Hintergrund zumindest am Leben erhalten werden. Ich sag jetzt mal, das kostet 100MHz. Physik muß immer berechnet werden, ungeachtet wie hoch die fps. Kostet 200MHz. Bei der KI das Selbe. Macht sagen wir nochmal 200MHz.
In diesem Beispiel würden also 100MHz pauschal verwendet werden, und könnten nicht dafür verwendet werden mehr fps an die GraKa zu senden, daß die daraus Bilder errechnet. Wenn man also die 500MHz von den 1470MHz und den 2002MHz abzieht, kommt man auf:
970MHz vs. 1502MHz (+54,8%)
Damit ist alles im grünen Bereich.


das ist mir zu simplifizierend und die Werte sind total aus der Luft gegriffen.
KI u. Physik sind ausserdem Teil des Spiels.



Also was jetzt? Habe ich es nicht verstanden, oder sehen wir den Einfluß der RAM-Performance nur anders gewichtet?


wenn ich schreibe "nicht-linear" und du antwortest "genau, deswegen bleibt das Verhältnis gleich" heißt das für mich, das du es nicht verstanden hast,
oder ich mich nicht richtig ausgedrückt habe. Natürlich ändert sich dadurch die Gewichtung in Abhängigkeit vom gewählten FSB.

Linear ist eine Gerade und das macht "ihr" hier, ihr rechnet munter hin und her
mit linearen Verhältnissen. Ich bin aber der Meinung das man das nicht machen kann.



Außerdem bleibt selbst wenn so manche Optionen auf Auto sein sollten, das grundlegende Verhältniss von CPU-Takt zu Latenz gleich oder zumindest sehr ähnlich. Wo sollen die großen Unterschiede her kommen?


Hast du es schonmal getestet?
Ich schon, das kann bis zu 5-10% ausmachen, wenn man die Parameter nicht anpasst. (das würde auch gut zu den Ergebnissen passen ;))
Vor allem da die meisten modernen Boards ihre Parameterbereiche für FSBs >= 333Mhz optimiert haben.


So kann man es auch sehen. Wenn nur zu 90% und nicht zu 100% dann lieber garnicht.
Wenn man es so sieht, wird bald garnichts mehr gemacht.


jmd. der nur die Diagramme sieht wird entsprechende Schlussfolgerungen ziehen, die eben nicht wirklich der Realität der Testumgebung entsprechen.
Das sollte man doch verhindern/klären.


Was ist an meiner Antwort nicht klar?


deine Antwort spiegelt nicht den realen Sachverhalt wieder.


Einerseits beschwerste dich, daß man auf deine "naiven" Anfragen nicht ausreichend eingehen würde, auf der anderen Seite setzte mit deinen Antworten noch einen drauf.

wie meinen? Ich bin nur an einer exakten Def. der Testannahmen interessiert.
Aber vielleicht ist das auch zuviel für ein Hardware-Forum.

[Armaq]

Was Madkiller erläutert hat, hat mir auch schon jmd. aus der Branche im 4-Augengespräch erläutert. Grundlast und FPS sind halt nicht vollständig verknüpft. Hab ich erst auch nicht geglaubt, aber er weiß es definitiv besser als ich.(programmiert u.a. für den DS uvm.)

[dargo]

das ist mir zu simplifizierend und die Werte sind total aus der Luft gegriffen.
KI u. Physik sind ausserdem Teil des Spiels.

Die Werte waren nur ein Beispiel, das ist doch offensichtlich. Jedes Game hat eine andere "Grundlast".


Hast du es schonmal getestet?
Ich schon, das kann bis zu 5-10% ausmachen, wenn man die Parameter nicht anpasst.
5-10% in was?

Er zeigt nicht auf, ob ein 3000 Mhz X3 genau so gut ist wie ein 2250 Mhz X4.
Eigendlich kannst du das aus den Tests ableiten, ja. :)

[Armaq]

Die Werte waren nur ein Beispiel, das ist doch offensichtlich. Jedes Game hat eine andere "Grundlast".


5-10% in was?


Eigendlich kannst du das aus den Tests ableiten, ja. :)
Nur bedingt.
GTA 4 zB performt auf einem 4Ghz DualCore wohl so ruckelig, weil es mehr Threads ausgibt, die zeitgleich laufen müssten und natürlich "im Schedule hängen". Daher würde ich diesen Vergleich nicht direkt ableiten. Wohl aber ob es ein 2000 Mhz X3 oder X4 sein soll. :)

[dargo]

Nur bedingt.
GTA 4 zB performt auf einem 4Ghz DualCore wohl so ruckelig, weil es mehr Threads ausgibt, die zeitgleich laufen müssten und natürlich "im Schedule hängen". Daher würde ich diesen Vergleich nicht direkt ableiten. Wohl aber ob es ein 2000 Mhz X3 oder X4 sein soll. :)
So meinte ich es nicht. Wenn du dir NfS: ProStreet genauer anschaust dann siehst du, dass der vierte Core im Vergleich zum TC kaum was bringt. Würde der vierte Core ~33% besser skalieren als der TC könnte ein 2250Mhz X4 mit einem 3Ghz X3 gleichauf liegen.

[Armaq]

So meinte ich es nicht. Wenn du dir NfS: ProStreet genauer anschaust dann siehst du, dass der vierte Core im Vergleich zum TC kaum was bringt. Würde der vierte Core ~33% besser skalieren als der TC könnte ein 2250Mhz X4 mit einem 3Ghz X3 gleichauf liegen.
Ja, könnte. Das mein ich ja damit. Der X3 stellt hier sozusagen die sinnvolle Grenze dar, wenn man nur NFSPS zockt.

[Madkiller]

wie meinen? Ich bin nur an einer exakten Def. der Testannahmen interessiert.
Aber vielleicht ist das auch zuviel für ein Hardware-Forum.
Was erwartest du hier eigentlich? Wir sind hier im Forum alle nur Laien. Du dagegen zweifelst alles mögliche an (dein gutes Recht) und wenn dir jemand nur ne 99%ig richtige/nachvollziebare Antwort gibt, tuste die als Falsch ab, weils keine 100% sind?


das ist mir zu simplifizierend
simplifiziert = falsch? Siehe oben.

und die Werte sind total aus der Luft gegriffen.
Ja natürlich. Habe es ja auch so gekennzeichnet.
Evtl solltest du hier argumentieren, warum dir was nicht passt. Und mir natürlich meinen Denkfehler aufzeigen.

KI u. Physik sind ausserdem Teil des Spiels.
Jap, und weil man das nicht aufteilen kann, gibt es ja Multi-Threading-Optimierungen in Spiele, oder?

wenn ich schreibe "nicht-linear" und du antwortest "genau, deswegen bleibt das Verhältnis gleich" heißt das für mich, das du es nicht verstanden hast,
... oder du könntest den ersten Teilsatz in Kontext mit dem zweiten Teilsatz setzen. Und natürlich versuchen zu verstehen was ich sagen will.

Linear ist eine Gerade und das macht "ihr" hier, ihr rechnet munter hin und her
mit linearen Verhältnissen. Ich bin aber der Meinung das man das nicht machen kann.
Ne, "wir" versuchen hier nur der Linearität möglichst nah zu kommen. Was für dich nicht ausreichend ist.
Kann dargo die tRD mit seinem Board überhaupt einstellen?

Hast du es schonmal getestet?
Nö. Aber ich habe bei Spielen mal die CL+tRCD+tRP+tRAS mal verändert, und bin da nur auf wenige Prozent gekommen. Und das sollten die entscheidensten RAM-Settings sein.

Ich schon, das kann bis zu 5-10% ausmachen, wenn man die Parameter nicht anpasst.
Wo? Sandra? :ugly:

jmd. der nur die Diagramme sieht wird entsprechende Schlussfolgerungen ziehen, die eben nicht wirklich der Realität der Testumgebung entsprechen.
Abweichungen von wenigen Prozent sind für dich bedenklich? Ansichtssache.

deine Antwort spiegelt nicht den realen Sachverhalt wieder.
Argumente bitte.

[blackbox]

Inwiefern einfach? Ich sagte doch, wann die Werte von dargo auch eine Praxisrelevanz haben.
Und seine Tests können genau das aussagen, wofür diese Tests gedacht sind, und natürlich kann man daraus Erkenntnisse erzielen.

Welche Erkenntnisse? Ganz ehrlich, ich sehe Werte, die ich aufgrund schwerer Bedenken nicht interpretieren kann.

Na um wieviel die fps bei CPU-limitierten Szenen steigen.

Gut, dann erkläre mir, was es bedeutet, wann eine Szene CPU-limitiert ist.
Gibts da eine Definition? Wurde das jemals geklärt?

Bitte nicht falsch verstehen, die Arbeit, die Dargo macht, finde ich nachwievor gut. Allerdings sollte das alles handwerklich astrein sein. Natürlich kann und soll es nicht wissenschaftlichen Ansprüchen genügen, aber um Erkenntnisse zu gewinnen, sollte alles nachvollziehbar sein.

[Madkiller]

Bist du dir über die Grundlagen von dem Link den ich schon mal gepostet habe im Klaren?
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=337813
Da steht IMO nämlich alles, was deine Punkte beantworten kann. :)

Entscheidend ist das hier (ist in dem Link aber natürlich besser umschrieben):
Limitiert die CPU bei 15fps unter 800x600 und die GraKa ist selbst unter 1600x1200 mit 4xFSAA noch in der Lage, mehr als die 15fps zu produzieren, wird auch unter dieser hohen Auflösung noch die CPU mit 15fps limitieren.

[blackbox]

Nein, das meine ich nicht. Das ist mir auch nicht fundiert genug.

Wie man an der Diskussion am FSB erkennen kann, gibt es hier Unklarheiten.
Daher noch mal die Frage. Woher nehmt ihr die Erkenntnis, dass eine Szene CPU-limitiert ist?
Eine ganz simple Frage. Nur weil in geringen Auflösungen die Grafikkarte vermeintlich keine Rolle mehr spielt? Oder nur weil die FPS steigt? Ist die FPS-Zahl ein guter Indikator? Oder der einzige Indikator?

Ich will hier an den Grundlagen rütteln, auf die eure Tests bauen. Nichts weiter.

[_DrillSarge]I[]

wenn das hier "fertig" ist, könnte man auch mal auf die kernskalierung phenom vs c2q eingehen.

[Armaq]

Welche Erkenntnisse? Ganz ehrlich, ich sehe Werte, die ich aufgrund schwerer Bedenken nicht interpretieren kann.



Gut, dann erkläre mir, was es bedeutet, wann eine Szene CPU-limitiert ist.
Gibts da eine Definition? Wurde das jemals geklärt?

Bitte nicht falsch verstehen, die Arbeit, die Dargo macht, finde ich nachwievor gut. Allerdings sollte das alles handwerklich astrein sein. Natürlich kann und soll es nicht wissenschaftlichen Ansprüchen genügen, aber um Erkenntnisse zu gewinnen, sollte alles nachvollziehbar sein.
Wenn mehr CPU-Leistung in mehr FPS resultiert ist die Szene cpu-limitiert. Fertig.

[blackbox]

Wenn mehr CPU-Leistung in mehr FPS resultiert ist die Szene cpu-limitiert. Fertig.

Wenn du meinst. :rolleyes:

Gut, ich halte mich ab sofort raus. Macht keinen Sinn so und ich möchte den Thread von Dargo nicht mehr beeinflussen.

Weiter machen!

[Madkiller]

Nein, das meine ich nicht. Das ist mir auch nicht fundiert genug.

Wenn es dir nicht fundiert genug ist, überprüfe es doch selber.
Ist einfach und sogar nicht groß zeitaufwändig. Ist ja nicht so, daß wir hier was erzählen, was nur die 1337-Checker blicken.
Oder wenn du es genauer willst: http://alt.3dcenter.org/artikel/timedemos2/

Armaqs Antwort war zwar denkbar kurz aber völlig richtig. Hier redet ja keiner von 1000%iger CPU-Limitierung. Denn die wird es wohl nie geben. >95% dagegen schon öfters.
Wenn du meinst. :rolleyes:

Gut, ich halte mich ab sofort raus. Macht keinen Sinn so und ich möchte den Thread von Dargo nicht mehr beeinflussen.

Weiter machen!
Aber wenn du so darauf reagierst, ist es evlt wirklich besser, wenn wir es sein lassen.

[pest]

simplifiziert = falsch? Siehe oben.


zu stark vereinfachend


... oder du könntest den ersten Teilsatz in Kontext mit dem zweiten Teilsatz setzen. Und natürlich versuchen zu verstehen was ich sagen will.


sorry aber das ist nicht meine Aufgabe, ich stütze mich auf das, was da steht, nicht auf das was der andere denken könnte. Bin ja keine Frau :D


Ne, "wir" versuchen hier nur der Linearität möglichst nah zu kommen. Was für dich nicht ausreichend ist.


dafür müsste man erstmal ein Streudiagramm für jede Anwendung erstellen, um zu sehen, ob bzw. wann der FSB limitiert, wo sein Sättigungspunkt liegt,
und ob man den Anstieg zwischen diesen Punkten mit Hilfe einer Geraden angleichen kann. Imo wird das eher eine Power-Funktion sein.

Man kann diesen ganzen Problemen zwar recht einfach aus dem Weg gehen, aber dargo hat nunmal diesen Weg gewählt.


Kann dargo die tRD mit seinem Board überhaupt einstellen?


sicher, läuft nur unter verschiedenen Namen.


Nö. Aber ich habe bei Spielen mal die CL+tRCD+tRP+tRAS mal verändert, und
bin da nur auf wenige Prozent gekommen. Und das sollten die entscheidensten RAM-Settings sein.


tRD ist das entscheidenste Ramsetting wenn es um Durchsatz/Latenz geht.
Anandtech (http://www.anandtech.com/mb/showdoc.aspx?i=3208&p=7)


Wo? Sandra? :ugly:


FarCry2 in 640x480@VH z.B.


Argumente bitte.

das habe ich jetzt oft genug erläutert. Ich halte es jetzt wie blackbox

die Arbeit von dargo ist nicht zu verachten, ich war nur der Meinung
das man bevor man so eine "große" Sache anfängt erstmal das Grundgerüst
gründlich auseinandernimmt. Bin da wohl aber "zu wissenschaftlich" geprägt.

[dargo]

tRD ist das entscheidenste Ramsetting wenn es um Durchsatz/Latenz geht.
Anandtech (http://www.anandtech.com/mb/showdoc.aspx?i=3208&p=7)

Das ist zwar ganz nett was du hier verlinkst aber der Ramdurchsatz interessiert mich weniger. Ich hätte es gerne in Frames und Games.


FarCry2 in 640x480@VH z.B.

Erläutere bitte genauer wie du voran gegangen bist, sodass die 5-10% zustande kamen.

[pest]

Das ist zwar ganz nett was du hier verlinkst aber der Ramdurchsatz interessiert mich weniger. Ich hätte es gerne in Frames und Games.


naja bei guter Auslastung der CPU, spielt der Durchsatz eben eine nicht untergeordnete Rolle.
Durch das Absenken des FSB und Nichtanpassen div. Parameter entsteht aber eine künstliche Limitierung, die erstmal Nicht viel mit CPU oder Grafikkarte zu tun hat.
Der Sprung von DDR2-1000 auf DDR2-1200 ist auf Low und manchen Games wie UT3 fast linear.

Links kann ich dir bei Gelegenheit nachreichen, habe aber gerade keine Zeit


Erläutere bitte genauer wie du voran gegangen bist, sodass die 5-10% zustande kamen.

mit niedrigem FSB gebootet, tRD auf Auto und dann manuell "nachgebessert"

[dargo]

Der Sprung von DDR2-1000 auf DDR2-1200 ist auf Low und manchen Games wie UT3 fast linear.

1. Ich benche nicht mit low Settings sondern mit maximalen Details. Steht bei jedem Diagramm dabei.
2. Wo ändere ich nur den Ramtakt?


mit niedrigem FSB gebootet, tRD auf Auto und dann manuell "nachgebessert"
Das sind zu wenige Informationen. Ich brauche alles - CPU-Multi, FSB, Speicherteiler, CPU-Takt usw. usf.

Edit:
Da du ja unbedingt auf die tRD bestehst habe ich es mir im Bios angeschaut. Das Bios steht in der Tat auf [Auto] bei diesem Setting. Nur, es sieht folgendermaßen aus:

210MHz FSB = tRD 7
286Mhz FSB = tRD 7
420Mhz FSB = tRD 8

Die 420Mhz FSB werde ich nur brauchen wenn die Anwendung zu ~100% mit einem Quadcore skaliert. Bisher war der höchste FSB bei 312Mhz (NfS: ProStreet) und ich könnte mir gut vorstellen, dass dort die tRD ebenfalls 7 beträgt. Kann ich gerne gleich nochmal nachprüfen. Aber selbst wenn die tRD auf 8 läge darfst du mir gerne in Frames zeigen wieviel das ausmacht wenn alleine der Speicherdurchsatz um 2,7% ansteigt (Link von Anandtech).

PS: die tRD ist also bei beiden Taktfrequenzen von denen man eine CPU-Skalierung ableiten kann gleich. Ist das für dich präzise genug?

Edit2:
312Mhz FSB = tRD 7

Achja, noch was vergessen. Da ich im Bios war habe ich mir also auch die Subtimings aufgeschrieben:

tRRD = 3
tWTR = 3
tWR = 6
tRFC = 52
tRTP = 3

Und die Timings wie schon erwähnt:
CL = 5
tRCD = 5
tRP = 5
tRAS = 15

All diese Timings sind bei jedem Test gleich. :)

[pest]

210MHz FSB = tRD 7
286Mhz FSB = tRD 7
312Mhz FSB = tRD 7
420Mhz FSB = tRD 8
...
All diese Timings sind bei jedem Test gleich. :)

Daran sieht man schon das dein Board für hohe FSBs optimiert wurde.
Ein tRD von 7 bei einem FSB von 210 ist :ucrazy:, vor allem wenn man den entsprechenden Wert bei 420Mhz betrachtet. d.h. bei 420Mhz arbeitet das
Board viel effizienter. Du müsstest den tRD bei 210 mindestens auf 5 absenken, um das zu relativieren.

Leider kann man den tRD nicht mit Nachkommastellen eingeben (außer man geht über PullIns der Speicherkanäle), so dass, wenn man FSB/Bandbreite plotten würde immer wieder große Einbrüche entstehen.

Andererseits, nehmen wir eine wirklich gute Threaded-Optimierung, in der aber z.B. die einzelnen Threads auf gemeinsame Daten zugreifen, würde der FSB von 200-300 bei dem QC extrem stark limitieren.

jetzt ist aber gut...;)

[dargo]

Andererseits, nehmen wir eine wirklich gute Threaded-Optimierung, in der aber z.B. die einzelnen Threads auf gemeinsame Daten zugreifen, würde der FSB von 200-300 bei dem QC extrem stark limitieren.

Du vergisst hier, dass ich linear mit dem CPU-/ und Ram-Takt bei diesen FSB-Bereichen runter gehe.

[pest]

Du vergisst hier, dass ich linear mit dem CPU-Takt bei diesen FSB-Bereichen runter gehe.

das hat m.M. nach erstmal nicht viel damit zu tun.
Ich will bei meiner ganzen Argumentation ja eigentlich indirekt nur darauf hinaus
das man die Blackbox PC nicht einfach in CPU vs. Grafikkarte unterteilen kann.

http://en.wikipedia.org/wiki/Cache_coherency

[dargo]

Ich will bei meiner ganzen Argumentation ja eigentlich indirekt nur darauf hinaus
das man die Blackbox PC nicht einfach in CPU vs. Grafikkarte unterteilen kann.

Hat das hier Jemand behauptet?

Ich dachte es ging hier um CPU-/ und GPU-Limits? Ich weiß nicht was du unter diesen beiden Begriffen verstehst aber mir ist es erstmal egal was bei der Grafikkarte limitiert. Ob das jetzt die Speicherbandbreite, die arithmetische Leistung oder was weiß ich ist. Es senkt die Leistung auf Grafikkarten-Seite. Deswegen sprechen wir vom GPU-Limit. Das Limit beschränkt sich in diesem Zusammenhang nicht ausschließlich nur auf die GPU. Auf der CPU-Seite ist es genau das Selbe - ob jetzt irgendein Cache, Speichertiming, Chipsatztiming oder weiß der Geier was limitiert... all das wirkt sich auf die Leistung in einer cpu-limitierten Szene aus. Deswegen sprechen wir hier vom CPU-Limit.

[pest]

ob jetzt irgendein Cache, Speichertiming, Chipsatztiming oder weiß der Geier was limitiert... all das wirkt sich auf die Leistung in einer cpu-limitierten Szene aus. Deswegen sprechen wir hier vom CPU-Limit.

Ich schrieb doch schon, du führst ein künstliches Limit ein (was so in einer realen Situation nicht auftreten wird)

Nur weil dein Board sagen wir bei FSB133 mit tRD 13 bootet und die
Interprozesskommunikation bei niedrigem FSB leidet, kannst du doch noch
keine Rückschlüsse auf die tatsächliche Performance der CPUs ziehen.

Das sieht doch auf nem anderen Board wieder ganz anders aus.

Sorry das geht mir nicht in den Kopf :|, das du die Basis nicht wenigstens so gleich wie möglich machen willst.

200Mhz tRD7 vs. 300Mhz tRD7 ist Quark, und wird 300Mhz immer überproportional bevorteilen (auf deinem Board!)

[dargo]

Sorry das geht mir nicht in den Kopf :|, das du die Basis nicht wenigstens so gleich wie möglich machen willst.

200Mhz tRD7 vs. 300Mhz tRD7 ist Quark, und wird 300Mhz immer überproportional bevorteilen (auf deinem Board!)
Ich finde es erstaunlich wieviel Energie du in die tRD-Thematik investierst obwohl du mir hier:
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=6965095&postcount=3

sogar dazu rätst über den CPU-Multi zu skalieren. :ugly:

Aber ich will ja nicht so sein, deswegen:

1. Mit 210 und 286Mhz FSB und einem tRD-Wert von 5 bootet mein Board gar nicht. Gigabyte hat sich schon was bei den tRD-Werten gedacht.
2. Ich habe es mal mit 286Mhz und einem tRD-Wert von 6 probiert.

Cobra 11:
2002Mhz mit tRD 7 = 33,333 avg.fps (siehe Diagramm)
2002Mhz mit tRD 6 = 32,267 avg.fps

Willst du jetzt ernsthaft mit mir über den ~1fps diskutieren? :|
Nach deiner Logik müsste der zweite Wert sogar höher sein. Ich nenne sowas Messtoleranzen. Ich habe nirgendwo behauptet, diese Tests würden exakt 100% stimmen. Das können die auch gar nicht da zb. im TC-Modus der dritte Core vollen Zugriff auf die 6MB Cache hat wo sich im QC-Modus die beiden letzten Cores diesen Cache teilen müssen.

Was du hier abziehst ist Korinthenkackerei.

[_DrillSarge]I[]

eigentlich traurig, dass der c2q so sehr am fsb hängt. deshalb wäre ja ein gegencheck mit nem nehalem oder phenom interessant.

[pest]

sogar dazu rätst über den CPU-Multi zu skalieren. :ugly:


ja eben, um die Grundlage gleich zu lassen, warum wiederspricht sich das mit meinen Forderungen.


1. Mit 210 und 286Mhz FSB und einem tRD-Wert von 5 bootet mein Board gar nicht. Gigabyte hat sich schon was bei den tRD-Werten gedacht.
2. Ich habe es mal mit 286Mhz und einem tRD-Wert von 6 probiert.


das ist mir schon klar, das das nicht so funktionieren wird, wie es gedacht ist,
deswegen schrieb ich ja, mindestens auf 5. In meinem verlinkten Artikel
bencht Anandtech bei FSB400 mit tRD 5, bei so einem niedrigen FSB
diese Limitierung auszuhebeln geht eben nicht. Deine Werte beweisen nix.


Was du hier abziehst ist Korinthenkackerei.

ja wenn du meinst, ich habe bei anderen Games, andere Erfahrungen gemacht.
Ich habe mich bei meiner Argumentation auch nicht nur auf den tRD beschränkt, sondern auch andere Dinge angesprochen, wie Cache-Kohärenz, und Threaded-Limitierung des QC bei niedrigem FSB.

[dargo]

ja eben, um die Grundlage gleich zu lassen, warum wiederspricht sich das mit meinen Forderungen.

Welche Grundlage gleich lassen?
8,5x 333Mhz FSB
6,0x 333Mhz FSB

Im ersten Fall ist der FSB der größere Flaschenhals. Wie kommst du darauf, dass diese Lösung besser sei?

[Hvoralek]

Diese Debatte um die Auflösung wird wohl immer mal wieder hochflammen. Vll. solltest Du zwei Anmerkungen in den ersten Startbeitrag hineinnehmen:
Es geht hier nicht darum, festzustellen, ob man einen stärkeren Prozessor braucht. Das kann nur jeder für sich selbst anhand seines jeweiligen Systems ermitteln. Hier geht es darum, ob man, wenn man mehr Prozessorleistung haben möchte, besser zu einem Vierkerner oder zu einem höher taktenden Zwei- oder Dreikerner greifen sollte.
Bei höheren Auflösungen spielt die GraKa eine größere Rolle, sodass die Unterschiede zwischen den Prozessoren kleiner werden. Man müsste aber die Äquivalenzmessungen 1:1 übertragen können: Wenn ein Vierkerner unter 640x480 genau so schnell ist wie ein z.B. 30% höher taktender Doppelkerner, sind die beiden unter 1600x1200 4x/16x ebenfalls gleich schnell, nur die Abstände zu den anderen werden kleiner.
Nun zum Inhalt. Erst einmal finde ich es klasse, dass Du Dich da weiter reinhängst, das ist immerhin ein Haufen Arbeit. Die Ergebnisse sehen ja ganz vielversprechend für Mehrkerner aus: Bisher vier Spiele, von denen eines erkennbar und eines deutlich von 3 bzw. 4 Kernen profitiert; und GTA4 ist da noch nicht einmal bei. Enttäuscht bin ich dagegen von Crysis. Crytek hatte doch immer behauptet, das würde mit vier Kernen sonstwie abgehen, und dann bringen zwei weitere Kerne weniger als 10% mehr Takt? Nach den Ankündigungen ziemlich arm, zumal das auch durchaus komplett auf das Konto des Treibers gehen kann :|

[pest]

Enttäuscht bin ich dagegen von Crysis. Crytek hatte doch immer behauptet, das würde mit vier Kernen sonstwie abgehen, und dann bringen zwei weitere Kerne weniger als 10% mehr Takt? Nach den Ankündigungen ziemlich arm, zumal das auch durchaus komplett auf das Konto des Treibers gehen kann :|

Im CPUBench-Thread von Crysis profitiert ein Quad deutlich.
nen 45nm C2D@4Ghz ist auf Augenhöhe mit nem 45nm C2Q@3.2Ghz
Verabsolutierungen bringen da auch nicht viel

[dargo]

Ich schrieb doch schon, du führst ein künstliches Limit ein (was so in einer realen Situation nicht auftreten wird)

Dazu möchte ich mich noch äußern da ich gestern keine Lust mehr hatte.

Eine ganz einfache Frage ohne dich irgendwie angreifen zu wollen - hast du überhaupt verstanden wie ich bei der Skalierung über den FSB vorgehe? Ich habe nämlich das Gefühl, dass es nicht der Fall ist.

Ich fasse mal zusammen:

1. Du bist der Meinung, dass der Ramdurchsatz mit kleinerem tRD-Wert steigt. Dazu hast du auch einen Anandtech-Link gepostet. Hier möchte dir auch niemand widersprechen. Hinzufügen möchte ich aber einen ganz wichtigen Hinweis - solange die Ausgangsbasis gleich ist!
2. Ich habe folgende Frage gestellt:
Erläutere bitte genauer wie du voran gegangen bist, sodass die 5-10% zustande kamen.
Daraufhin hast du folgendes geantwortet:
mit niedrigem FSB gebootet, tRD auf Auto und dann manuell "nachgebessert"
Das ist doch wohl logisch da du am FSB und/oder Speichertakt nichts geändert hast. Jetzt übertrage das auf meine 1470Mhz und 2002Mhz mit denen ich an die Benchmarks herangehe. Eigendlich müsste es schon hier klingeln.

Was du da gemacht hast ist das selbe als wenn ich die tRD bei gleichem Wert lassen, und den Speichertakt und/oder FSB (denn mit dem FSB steigt auch der CPU-Takt) erhöhen würde. Sobald man den Speichertakt und/oder CPU-Takt erhöht erhöht sich logischerweise auch der Speicherdurchsatz. Durch das Senken der Speichertimings könnte ich ebenfalls dieses Ziel erreichen.

Und falls du immer noch nicht die Zusammenhänge zwischen FSB/CPU-Takt/Speichertimings verstanden hast habe ich einen kleinen Benchmark mit Everest gestartet.

1. 2002Mhz CPU-Takt, 286Mhz FSB, 343Mhz Speichertakt, tRD7
Lesen in MB/s:
5664, 5695, 5690 = Durchschnitt von 5683

Schreiben in MB/s:
6045, 6034, 6028 = Durchschnitt von 6036

2. 1470Mhz CPU-Takt, 210Mhz FSB, 252Mhz Speichertakt, tRD7
Lesen in MB/s:
4171, 4166, 4153 = Durchschnitt von 4163

Schreiben in MB/s:
4446, 4443, 4441 = Durchschnitt von 4443

2002Mhz/1470Mhz CPU-Takt = + 36,19%
286Mhz/210Mhz FSB = + 36,19%
343,2Mhz/252Mhz Speichertakt = +36,19%
5683/4163MB/s Lesen = +36,51%
6036/4443MB/s Schreiben = +35,85%

Wenn du jetzt immer noch nicht erkennst, dass die Skalierung über den FSB das einzig richtige ist kann ich nichts mehr machen. Deutlicher kann ich es nicht mehr darstellen. Deswegen verwundern mich solche Aussagen wie diese:
naja bei guter Auslastung der CPU, spielt der Durchsatz eben eine nicht untergeordnete Rolle.
Durch das Absenken des FSB und Nichtanpassen div. Parameter entsteht aber eine künstliche Limitierung, die erstmal Nicht viel mit CPU oder Grafikkarte zu tun hat.
Ein tRD von 7 bei einem FSB von 210 ist , vor allem wenn man den entsprechenden Wert bei 420Mhz betrachtet. d.h. bei 420Mhz arbeitet das
Board viel effizienter. Du müsstest den tRD bei 210 mindestens auf 5 absenken, um das zu relativieren.
Andererseits, nehmen wir eine wirklich gute Threaded-Optimierung, in der aber z.B. die einzelnen Threads auf gemeinsame Daten zugreifen, würde der FSB von 200-300 bei dem QC extrem stark limitieren.

Du vergisst hier, dass ich linear mit dem CPU-Takt bei diesen FSB-Bereichen runter gehe.
das hat m.M. nach erstmal nicht viel damit zu tun.
Sorry das geht mir nicht in den Kopf , das du die Basis nicht wenigstens so gleich wie möglich machen willst.

200Mhz tRD7 vs. 300Mhz tRD7 ist Quark, und wird 300Mhz immer überproportional bevorteilen (auf deinem Board!)

Ich würde dir empfehlen alles nochmal genau durchzulesen (und immer dabei meine Bench-Konfiguration im Auge behalten), nachdenken und du wirst feststellen, dass du daneben liegst. :)

[pest]

mir geht deine Arroganz mittlerweile ein Wenig auf die Nerven

deine Werte spiegeln genau das wieder, was ich vermeiden wollte.

mein Ziel war es, dich davon zu überzeugen, das es besser ist die Benches
bei möglichst maximalen FSB (>450) zu betreiben, das heißt auch möglichst hohe/gleiche Speicherbandbreite/Takt.

Deswegen auch mein Vorschlag den tRD abzusenken, um das wieder auszugleichen und einen gleichhohen Durchsatz zu halten.

Du weißt nicht wann eine Anwendung zusätzlich durch den niedrigen FSB limitiert wird (die Wahrscheinlichkeit ist bei MT+QC aber höher)


Wenn du jetzt immer noch nicht erkennst, dass die Skalierung über den FSB das einzig richtige ist kann ich nichts mehr machen.


ist ja gut :rolleyes:

[dargo]

Ok, Ende der Diskussion. Du willst oder kannst es einfach nicht verstehen.

[Hvoralek]

Im CPUBench-Thread von Crysis profitiert ein Quad deutlich.
nen 45nm C2D@4Ghz ist auf Augenhöhe mit nem 45nm C2Q@3.2Ghz
Verabsolutierungen bringen da auch nicht vielAuch 25% wären nach den Ankündigungen ziemlich mager. Wie aussagekräftig ist bei Crysis eigentlich diese Timedemo für das tatsächliche Spielgeschehen? Wird alles in Echtzeit berechnet, was auch im Spiel berechnet werden muss? Ist die Stelle repräsentativ gewählt oder hat man eine rausgesucht, an der die Mehrkernoptimierungen besonders durchschlagen?

[dargo]

Wie aussagekräftig ist bei Crysis eigentlich diese Timedemo für das tatsächliche Spielgeschehen?
Imho gleich Null.

Crysis ist eh so ein Ding. Ich hatte mal beim simulierten TC den Taskmanager mir angeguckt. Dabei war die Last auf alle 3 Kerne verteilt. Wie man aber im Diagramm sehen kann bringt es keine (kaum) mehr Frames. Ist aber auch kein Wunder da die CPU-Last je Kern sehr niedrig war. Kann es sein, dass hier nur einfach Windows die Last verteilt hat?

PS: ich kann ja mal bei Gelegenheit die Timedemo-Szene mit einem Savegame versuchen nachzustellen. Wenn mich nicht alles täuscht wurden da eh nur die Hütten mit einem Raketenwerfer "bearbeitet".

[BlackBirdSR]

Auch 25% wären nach den Ankündigungen ziemlich mager. Wie aussagekräftig ist bei Crysis eigentlich diese Timedemo für das tatsächliche Spielgeschehen? Wird alles in Echtzeit berechnet, was auch im Spiel berechnet werden muss? Ist die Stelle repräsentativ gewählt oder hat man eine rausgesucht, an der die Mehrkernoptimierungen besonders durchschlagen?

Ich sags mal so:
Wenn die CPU langsam genug ist und die Szene CPU limitiert, dann sind z.B. mit Dual-Core locker weit mehr als 50% möglich.
Allerdings entsteht da ein ganz großes Problem mit vielen Tests im Web:

Bei einer 4GHz Dual-Core vs 4GHz Quad-Core Maschine ist der Gewinn einfach nicht mehr so hoch, da die CPU schon gehörig viel Leistung entwickelt. Das Gleiche mit einer 2.4GHz CPU könnte schon ganz anders aussehen.

@dargo:
Du musst dir die Gesamtauslastung in Prozent ansehen.
Oder probier doch mal ein garantiert Single-Threaded Spiel: Das wird von Windows auch schän über die Gerne (abwechselnd) verteilt.

[dargo]

@dargo:
Du musst dir die Gesamtauslastung in Prozent ansehen.

Das wird bei mir wohl nicht funktionieren. Ich kann die Daten vom Taskmanager nur auf dem Desktop sehen. Nur, wenn ich aus dem Spiel auf den Desktop switsche ist die CPU-Last logischerweise schon ganz anders. Wobei, ich könnte sie eigendlich mit dem Rivatuner aufzeichen? :uponder:


Oder probier doch mal ein garantiert Single-Threaded Spiel: Das wird von Windows auch schän über die Gerne (abwechselnd) verteilt.
Ist das nicht eigendlich kontraproduktiv? Schließlich müssen die einzelnen Kerne untereinander kommunizieren?

[BlackBirdSR]

Ist das nicht eigendlich kontraproduktiv? Schließlich müssen die einzelnen Kerne untereinander kommunizieren?

Ist IMO auch einer der Gründe für das komische Verhalten der Pehnoms mit aktivierten CnQ2.0
Auf der anderen Seite bleibt die CPU so kühler ;)

[dargo]

Ist IMO auch einer der Gründe für das komische Verhalten der Pehnoms mit aktivierten CnQ2.0

Was meinst du mit komischem Verhalten? Ist wohl an mir vorbeigegangen.

[BlackBirdSR]

Was meinst du mit komischem Verhalten? Ist wohl an mir vorbeigegangen.

Lies dich hier mal durch
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=3344&p=3&cp=3

[Hvoralek]

Ich sags mal so:
Wenn die CPU langsam genug ist und die Szene CPU limitiert, dann sind z.B. mit Dual-Core locker weit mehr als 50% möglich.
Allerdings entsteht da ein ganz großes Problem mit vielen Tests im Web:

Bei einer 4GHz Dual-Core vs 4GHz Quad-Core Maschine ist der Gewinn einfach nicht mehr so hoch, da die CPU schon gehörig viel Leistung entwickelt. Das Gleiche mit einer 2.4GHz CPU könnte schon ganz anders aussehen.Das Problem umgeht man gerade, wenn man nicht auf die %- Zuwächse an fps guckt, sondern auf die Taktfrequenz, die man braucht, um mit weniger Kernen die gleiche Leistung zu erreichen. Die 25% bezogen sich darauf, dass ein Vierkerner so schnell ist wie ein 25% höher taktender Doppelkerner.

[dargo]

GRID ist fertig:
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=6973301&postcount=1

Bin erstaunt, dass GRID noch Vorteile von mehr als zwei Kernen zieht. Wenn man sich nämlich das hier anschaut:
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=5658521&postcount=414

hätte ich es nicht erwartet. Naja, zum einen habe ich diesmal die Strecke mit der höchsten CPU-Last gewählt (trotz 3 Fahrzeugen weniger) und zum anderen kam diesmal Vista und kein WinXP zum Einsatz. Ich weiß allerdings nicht inwieweit Vista darauf Einfluss hat.

[Hvoralek]

So gewaltig ist das nun auch nicht (~20% bei 2 ->4 Kerne). Dass man allein mit einem optimierten GraKatreiber immer zumindest ein bisschen erreichen kann, kennen wir ja aus dem letzten Thread.

[dargo]

So gewaltig ist das nun auch nicht (~20% bei 2 ->4 Kerne). Dass man allein mit einem optimierten GraKatreiber immer zumindest ein bisschen erreichen kann, kennen wir ja aus dem letzten Thread.
Ja, das würde noch eventuell Sinn machen. Aber schau mal was ich mit SC vs. DC ermittelt hatte. Zumindest hier hätte ich nahezu 100% erwartet. Oder ich habe gerade einen Denkfehler. :ugly:
Ich hatte mir gedacht, dass eine Anwendung die nur zu knapp 50% mit einem zweiten Kern gegenüber einem Singlecore skaliert keine Zugewinne mehr von mehr als zwei Cores ziehen könnte.

[Ronny145]

Dass Grid mit mehr als 2 Kernen noch skaliert, ist aber auch nichts neues. Eher wäre es überraschend, wenn hier ein anderes Ergebnis zustande gekommen wäre.

http://www.forum-3dcenter.org/vbulletin/showpost.php?p=6497060&postcount=25
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=6505308&postcount=61

[dargo]

Dass Grid mit mehr als 2 Kernen noch skaliert, ist aber auch nichts neues. Eher wäre es überraschend, wenn hier ein anderes Ergebnis zustande gekommen wäre.

http://www.forum-3dcenter.org/vbulletin/showpost.php?p=6497060&postcount=25
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=6505308&postcount=61
Lol, da habe ich sogar selbst nach gefragt. ;D

Ich würde dann aber auf Vista tippen, denn schmacko hat ebenfalls Vista verwendet. Weißt du zufällig welches OS Nick im Einsatz hatte?

Edit:
Ok, ich bin blind. :hammer:
Steht direkt drunter - Vista64 SP1 bei Nick.

[Hvoralek]

Ja, das würde noch eventuell Sinn machen. Aber schau mal was ich mit SC vs. DC ermittelt hatte. Zumindest hier hätte ich nahezu 100% erwartet. Oder ich habe gerade einen Denkfehler. :ugly:
Ich hatte mir gedacht, dass eine Anwendung die nur zu knapp 50% mit einem zweiten Kern gegenüber einem Singlecore skaliert keine Zugewinne mehr von mehr als zwei Cores ziehen könnte.Wenn ein Spiel zwei Kerne bei weitem nicht voll auslastet, kann ein auf >2 angepasster Treiber nicht mehr viel bringen: Dann ist es egal, ob der auf der Restkapazität des zweiten Kerns läuft (sofern die reicht) oder auf einem "eigenen". Ein zweiter Kern bringt in GRID soviel wie knapp 60% mehr Takt. Ich vermute, dass da die Gesamtauslastung beider Kerne schon ziemlich hoch ist (Es fällt ja auch extra Verwaltungsaufwand an), insofern finde ich es ganz plausibel, dass da noch Potenzial ist.

[dargo]

Farcry 2 ist soweit (siehe Post 1). :)

Der 1,47Ghz DC tanzt etwas aus der Reihe. Messfehler kann ich aber ausschließen, habs 2x gebencht (12 Durchläufe).

[dargo]

Nach langer Zeit mal wieder ein Game - Test Drive Unlimited. Scheint eine reine Triple-Core Anwendung zu sein. :)
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=6973301&postcount=1

[Bullz]

ich bin dumm

Ich freue mich das es solche angaschierten User gibt, aber die Message nach dem Treat

Das war Grundlagenforschung die aber nix ändern wird weil du kein CPU Ing. bist
Keine praxisrelevanten Settings, spiegel settings die keiner spielt

Ich wüsste nicht mal welche Frage ich stellen soll, sobald ich das mache, mache ich schon etwas falsch :P

deswegen kommt eine Aussage: Ich will das quadcore 3 fach besser skalliert wie single Core

Soda nix flasch gemacht hehe

[xiao didi *]

Soda nix flasch gemacht hehe
Vielleicht a bisserl zu tief ins Glas geschaut, ansonsten aber top :uup:

[Thunderhit]

ich bin dumm

Ich freue mich das es solche angaschierten User gibt, aber die Message nach dem Treat

Das war Grundlagenforschung die aber nix ändern wird weil du kein CPU Ing. bist
Keine praxisrelevanten Settings, spiegel settings die keiner spielt

Ich wüsste nicht mal welche Frage ich stellen soll, sobald ich das mache, mache ich schon etwas falsch :P

deswegen kommt eine Aussage: Ich will das quadcore 3 fach besser skalliert wie single Core

Soda nix flasch gemacht hehe

Boah schreib das mal in deutsch auf, wenn möglich gar hochdeutsch.

[dargo]

Weiter gehts mit Need for Speed: Undercover:
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=6973301&postcount=1

Den Triplecore-Support würde ich als "gut" (<80%) bezeichnen. Für ein "sehr gut" fehlt da noch etwas. Der vierte Core bringt mal wieder rein gar nichts. Angesicht der ziemlich tiefen Frames (zumindest am Start) sehr schade.

Achja - für die User die immer noch der Meinung sind, diese Tests wären praxisfremd. ;)

640x480 1xAA/1xAF max. Details
http://img3.imagebanana.com/img/4h2gsvyk/nfs2009041814174412.jpg

1680x1050 4xMSAA/16xAF max. Details
http://img3.imagebanana.com/img/ccalq71x/nfs2009041814205976.jpg

Und das mit einem 3,7Ghz Yorkfield. X-D

[Crazy_Chris]

Und das mit einem 3,7Ghz Yorkfield. X-D

Wird zeit das du auf einen Core i7 aufrüstest. :biggrin: Die CPU limitiert einfach schon zu stark. ;)

[dargo]

Wird zeit das du auf einen Core i7 aufrüstest. :biggrin: Die CPU limitiert einfach schon zu stark. ;)
Hehe, unabhängig davon, dass dieses Game es eh nicht wert ist kommt mir ein i7/i5 erst ins Haus wenn man durch OC ~5Ghz erreicht (natürlich zu humanen Preisen). :D

[=Floi=]

ich bin aber schon ein wenig verwundert, dass ausgerechnet so ein spiel von EA support für 3 core hat. :)

[dargo]

ich bin aber schon ein wenig verwundert, dass ausgerechnet so ein spiel von EA support für 3 core hat. :)
Ich vermute, dass die gleiche Engine wie schon bei NfS: ProStreet verwendet wird. Das ganze wird in Undercover nur mit diesem imo häßlichen PP im wahrsten Sinne des Wortes überstrahlt. X-D
NfS: ProStreet skaliert auch schon sehr gut mit einem Triplecore. :)



640x480 1xAA/1xAF max. Details
http://img3.imagebanana.com/img/4h2gsvyk/nfs2009041814174412.jpg

1680x1050 4xMSAA/16xAF max. Details
http://img3.imagebanana.com/img/ccalq71x/nfs2009041814205976.jpg

Und das mit einem 3,7Ghz Yorkfield. X-D

Das ist echt nicht mehr lustig. Was ein OS so ausmachen kann. :uroll:

Windows 7:

640x480 1xAA/1xAF max. Details
http://img3.imagebanana.com/img/dbnq33ey/nfs2009041919315591.jpg

1680x1050 4xMSAA/16xAF max. Details
http://img3.imagebanana.com/img/o8s8tx34/nfs2009041919303938.jpg

Mal eben 43% mehr CPU-Leistung durch Windows 7. :ugly:
Und ich habe mich schon gewundert was das wieder für eine miese Portierung aus Performancesicht ist. lol

Ich werde den Test noch mal wiederholen. Ich zweifle langsam ob Vista64 für diese Tests wirklich gut geeignet ist. Eigentlich wollte ich kein Windows XP nehmen da der Multicore-Support unter Vista in einigen Games erheblich besser ist.
Naja, an der Multicore-Skalierung zwischen Vista64 und Windows 7 64 wird sich vielleicht nichts ändern, aber die tatsächlichen Frames können wie man sieht unter Vista64 doch teilweise erheblich einbrechen.

Edit:
Und mit dem Performance-Patch V1.0.1.17 gehts noch höher hinaus. :ucrazy3:

640x480 1xAA/1xAF max. Details
http://img3.imagebanana.com/img/ii7yzjzd/nfs2009041919543786.jpg

1680x1050 4xMSAA/16xAF max. Details
http://img3.imagebanana.com/img/0r6hcczl/nfs2009041919533760.jpg

Unfassbar, mit anderem OS und dem Patch hat sich die Performance fast verdoppelt. X-D

[dargo]

So, Windows 7 und V1.0.1.17 von NfS: Undercover ist fertig.
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=6973301&postcount=1

An den Verhältnissen zwischen DC/TC/QC hat sich kaum was geändert. Eins möchte ich aber noch zu diesem Game loswerden - das war eine echte Herausforderung. Mit dem DC (egal ob 1,47Ghz oder 2Ghz) habe ich manchmal unlogische Ergebnisse bekommen. Zb. bei 1,47Ghz einmal ~18fps, dann wieder ~22fps und manchmal ~26fps. Völlig Banane. Zusätzlich hats mit dem DC als die Fahrt losging oftmals stark geruckelt. Dadurch wahrscheinlich auch diese großen Abweichungen. Die Ergebnisse vom TC/QC waren immer gleich. Eventuell hat die Engine bzw. das Game Probleme mit einem DC.

[ROXY]

komisch das die so schlecht mit quads skalieren - wie wird denn das dann mit i7 octa cpus werden?

[dargo]

komisch das die so schlecht mit quads skalieren - wie wird denn das dann mit i7 octa cpus werden?
Ich würde jetzt davon ausgehen, dass Octa-CPUs praktisch nichts mehr in Games bringen. Zumindest in naher Zukunft. Alles über 4 Cores ist imo sinnfrei. Es ist auch irgendwo davon abhängig wie die zukünftigen Konsolen von MS und Sony aussehen werden und die Lage immer noch so wie heute ist - Multiplattform. Die Mehrheit der "Core"-Spiele nutzt als Leadplattform also eine Konsole. Sollte in den nächsten Konsolen ebenfalls ein Octacore Verwendung finden denke ich wird man auch Engines sehen die von mehr als 4 Cores noch gut profitieren. Eine andere Wahl werden die Spieleentwickler nicht haben um Leistung zu entfalten. Allerdings bezweifle ich, dass man 8 Cores jemals gut auslasten können wird.

[RainingBlood]

Unfassbar, mit anderem OS und dem Patch hat sich die Performance fast verdoppelt. X-D


ähm, sind das andere Einstellungen oder eine Mod? Die Beleuchtung von Underground ist zwischen Vista und W7 vollkommen anders.

€: das wirkt auf mich, als würde ein Shadereffekt fehlen.
€2: hm, zumindist beim Performancetreiber @W7 ist es so. Könntest du bitte dein Profil online stellen? Möchte das gerne mal testen.

[dargo]

ähm, sind das andere Einstellungen oder eine Mod? Die Beleuchtung von Underground ist zwischen Vista und W7 vollkommen anders.

€: das wirkt auf mich, als würde ein Shadereffekt fehlen.
€2: hm, zumindist beim Performancetreiber @W7 ist es so. Könntest du bitte dein Profil online stellen? Möchte das gerne mal testen.
Also - wie ich schon im Win7-Thread erwähnt habe, die Schattendarstellung ist mit Patch anders, das fällt auf. Vergleiche aber fairerweise nur Vista/Game V1.0 und Win7/Game V1.0. Ich meine bei Undercover brauchst du kein Savegame, einfach die richtige Strecke wählen. Steht beim Diagramm:
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=6973301&postcount=1

Edit:
Es ist kein Performancetreiber sondern Performancepatch für das Game. :)
http://www.gamestar.de/news/pc/sport/rennspiel/1953554/need_for_speed_undercover.html

[RainingBlood]

so, hab den aktuellen Patch drauf gemacht. Optisch hat sich nichts verändert. Nach ein wenig rumprobieren glaube ich zu wissen, warum es bei den Performancepatch@W7 anders (besser) aussieht:
Umgebungseffekt sind, aus welchem Grund auch immer, auf "niedrig" (Achtung: Schatten müssen dann neu eingestellt werden!).
http://www.abload.de/img/nfsr4rm.jpg

[dargo]

so, hab den aktuellen Patch drauf gemacht. Optisch hat sich nichts verändert. Nach ein wenig rumprobieren glaube ich zu wissen, warum es bei den Performancepatch@W7 anders (besser) aussieht:
Umgebungseffekt sind, aus welchem Grund auch immer, auf "niedrig" (Achtung: Schatten müssen dann neu eingestellt werden!).
http://www.abload.de/img/nfsr4rm.jpg
Hmm... dann muss ich mir das mit dem Patch unter Win7 nochmal genauer anschauen. Ich bin mir ziemlich sicher, dass ich die Settings überprüft habe, mache ich eigentlich immer. :uponder:

Edit:
Aus irgendeinem Grund funktioniert das Game bei mir nicht mehr unter Win7. :confused:
Beim Spielstart höre ich den Sound, danach kommt ein schwarzer Bildschrim und irgend wann rebootet der Rechner einfach. Vorher mit der Build 7077 gings noch. :confused:

Vielleicht liegts am Grafiktreiber (FW182.50 für Vista64). Keine Ahnung, ist aber auch wurscht, Downsampling ist mir wichtiger. :)

[dargo]

Weiter gehts mit Ghostbusters:
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=6973301&postcount=1

Das Spiel bietet leider kein freies Speichern an. Deswegen bin ich gezwungen das automatische Speichern zu nehmen. Zum Glück habe ich eine recht cpu-lastige Szene direkt nach dem automatischen Speichern gefunden. Es läuft ein kurzer Abspann und sobald der zu Ende ist fängt mein Savegame an. Schade, dass kein freies Speichern möglich ist denn das Game skaliert ziemlich gut mit einem Quadcore. Ich bin mir ziemlich sicher, dass da noch mehr als die gemessenen ~57% drin sind.

Übrigens, mit dem Dualcore kommt es bei vielen Durchläufen zu starken Rucklern mit Frameeinbrüchen was bei Triplecore und Quadcore nicht auftritt. Ich habe natürlich diese ruckelnden Durchläufe nicht mit ins Diagramm aufgenommen. Beim DC habe ich mehrere Durchläufe gebencht und nur die 6 genommen die bei einander lagen.

[mapel110]

Das Game hat extreme Schwankungen in den fps. Für mich ist das verbuggt. Mit der Zeit gewöhnt man sich aber dran. Es soll sogar Leute geben, die deswegen den 30 fps Limiter ingame eingeschaltet lassen.

[y33H@]

Ich habe mal mit dem i7 in Prototype [60sec auf dem Times Square] gespielt.

[Core i7-920 @ SMT/TM off, GTX280 @ 186.18 HQ, Asus P6T, 6G DDR3-1333 @ 7-7-7-21, Cores per BIOS deaktiviert, Vista Ultimate x64]

Mit zwei Kernen bin ich zu 99,9% CPU-limitiert, egal ob 640 x 480, no AA/AF oder 1.920 x 1.200, 4x MSAA/16:1 AF :eek: Habe ich in letzter Zeit selten gesehen. 29 bzw. 56 Prozent von DC auf QC sind eine Hausnummer, das knackt iirc nur GTA4.

2 Cores; 640 x 480, no AA/AF

Avg: 38.600 - Min: 25 - Max: 52
Avg: 38.616 - Min: 25 - Max: 51


4 Cores; 640 x 480, no AA/AF

Avg: 60.316 - Min: 49 - Max: 109
Avg: 60.483 - Min: 50 - Max: 111


2 Cores; 1.920 x 1.200, 4x MSAA/16:1 AF

Avg: 38.660 - Min: 25 - Max: 52
Avg: 38.700 - Min: 24 - Max: 52


4 Cores; 1.920 x 1.200, 4x MSAA/16:1 AF

Avg: 49.933 - Min: 33 - Max: 67
Avg: 49.750 - Min: 34 - Max: 69

Im Übrigen muss ich sagen, mir gefällt das was du hier machst, sehr. Weil ich es auch mache ;D Nur ist ein i7 mit zwei Cores oft schon verdammt performant, eignet sich also nicht sooo gut für SC, DC, TC, QC Spielereien.

[dargo]

Das Game hat extreme Schwankungen in den fps.
Extreme Schwankungen? Ich finde es eigentlich normal und noch völlig im Rahmen. Es gibt Games wo der Unterschied zwischen min.fps und max. fps noch viel größer ist.

Nur ist ein i7 mit zwei Cores oft schon verdammt performant, eignet sich also nicht sooo gut für SC, DC, TC, QC Spielereien.
Alles eine Frage der Zeit, lass die GTX380 da sein und schon passt es auch mit dem i7. :wink:

[mapel110]

Es geht nicht um den Abstand zwischen min und max, sondern dass die fps eben schwanken. Hoch und wieder runter, ohne wirkliches Muster. btw scheint sich das mit aktuellen Treibern sogar noch verschlimmert zu haben. Aber okay, die 190er-Treiber sind eh noch nicht so das Wahre.

[dargo]

Hmm... dann muss es wohl am Treiber liegen. Bei mir verhält sich Ghostbusters mit dem FW182.50 eigentlich ganz normal wie jedes andere Game auch.

[Gast]

Alles eine Frage der Zeit, lass die GTX380 da sein und schon passt es auch mit dem i7. :wink:

An der skalierung mit verschiedenen kernen ändert das nicht unbedingt etwas.

[dargo]

An der skalierung mit verschiedenen kernen ändert das nicht unbedingt etwas.
So meinte ich es nicht direkt. Mit einer GTX380 verschieben sich die Limits schlagartig, so dass es viel öfter zu CPU-Limits kommt. Als Beispiel - habe ich heute mit einem i7-920 und einer GTX280 in Szene XY bei 1680x1050 oder 1920x1200 4xMSAA/16xAF ein CPU-Limit von sagen wir mal 70% kannst du davon ausgehen, dass die gleiche Szene mit einer GTX380 nahezu zu 100% cpu-limitiert sein wird. Bei Usern die einen Yorkfield und eine GTX380 nutzen werden wird man noch viel eher stark cpu-limitiert sein. :)

Edit:
Bitte Limits nicht mit unspielbar gleichstellen. Wollte das nur mal sicherheitshalber klarstellen. Ein 100%-iges Limit (ob GPU oder CPU ist jetzt egal) kann auch bei 100fps stattfinden.

[BlackBirdSR]

Bitte Limits nicht mit unspielbar gleichstellen. Wollte das nur mal sicherheitshalber klarstellen. Ein 100%-iges Limit (ob GPU oder CPU ist jetzt egal) kann auch bei 100fps stattfinden.

Guru:massa:
Kann man dich unter Vertrag nehmen? Und ich meine das ernst, also melde dich ;)

Es gibt da so einiges, was man in dieser Richtung absichern müsste. Leider habe ich nicht die HW.

[QUERSCHLÄGER]

Hat jemand die Möglichkeit, daß ganze mal mit 1404 durchzuspielen? Wäre sehr interessant, da es ja auch zu der ganz aktuellen Software gehört. Und wo ja angeblich schon zu Beginn darauf geachtet wurde, Mehrkernteile besser zu nutzen.

[y33H@]

*meld*

[QUERSCHLÄGER]

Gib Gas! =)

[y33H@]

Anno 1404 [1.024 x 768, max. Details @ DX10 / PCGH-Save / i7-920 @ 2,67 GHz /6G DDR3-1333 @ 7-7-7-21 / GTX260-216 @ 702/1.404/1.161]

4 Kerne + SMT
Avg: 47.1 - Min: 46

4 Kerne
Avg: 42.5 - Min: 40

2 Kerne
Avg: 27.7 - Min: 27

1 Kern
Avg: 12.60 - Min: 11Ausgehend von zwei Kernen legt der i7 samt SMT fette 70% obendrauf, ohne SMT immer noch 54%. Analog zum PCGH-Test (http://www.pcgameshardware.de/aid,691470/Lynnfield-im-Test-Benchmarks-des-Intel-Core-i5-750-und-Core-i7-860-in-Anno-1404/CPU/Test/) ist ein Bloomfield-DC (~i3?) mit 2,67 GHz samt in etwa so flott wie ein fiktiver PII X4 930 oder ein QX6700/Q9400.

[|-Sh0r7y-|]

Hab das mal vor einiger Zeit mit GTA 4 gemacht hier die ergebnisse mit bilder.
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=7019426&postcount=25

Ausschnitt:
1 core
11-14fps

2 core
22-28 (kein witz genau das doppelte!!!)

4 core
35-40 (geht in richtung 37-40

[y33H@]

Deckt sich mit meinen Werten. SC auf DC = +100%, DC auf QC = +50%.

[dargo]

Anno 1404 [1.024 x 768, max. Details @ DX10 / PCGH-Save / i7-920 @ 2,67 GHz /6G DDR3-1333 @ 7-7-7-21 / GTX260-216 @ 702/1.404/1.161]
Ausgehend von zwei Kernen legt der i7 samt SMT fette 70% obendrauf, ohne SMT immer noch 54%. Analog zum PCGH-Test (http://www.pcgameshardware.de/aid,691470/Lynnfield-im-Test-Benchmarks-des-Intel-Core-i5-750-und-Core-i7-860-in-Anno-1404/CPU/Test/) ist ein Bloomfield-DC (~i3?) mit 2,67 GHz samt in etwa so flott wie ein fiktiver PII X4 930 oder ein QX6700/Q9400.
Wie siehts mit den Limits bei den 4 Kernen aus? Sprich, limitiert hier noch die GTX260 oder hast du dabei ein 100%-iges CPU-Limit?

[y33H@]

100% CPU-Limit. Wenn ich eine GTX285 mit OC reinpacke, ändert sich an den Fps nichts. Selbiges gilt für ein Erhöhen der Auflösung bis hoch zu 1.680.

[QUERSCHLÄGER]

Bei 1404 sind´s aber ordentliche Zahlen. Da kann man von einem echten Vorteil sprechen, nich so´n Wischiwaschi wie Software vergangener Tage.

Wenn jemand noch einen "alten" Quad hat, bitte mal hinterherschieben. Q66 oder so, wäre auch interessant, ob die langsam auch am Limit radieren.

[y33H@]

Siehe verlinkten PCGH-Test ;) 25,9 Avg und 24 Min sind spielbar.

[QUERSCHLÄGER]

A ja.

[IVN]

Anno 1404 [1.024 x 768, max. Details @ DX10 / PCGH-Save / i7-920 @ 2,67 GHz /6G DDR3-1333 @ 7-7-7-21 / GTX260-216 @ 702/1.404/1.161]

2 Kerne
Avg: 27.7 - Min: 27

1 Kern
Avg: 12.60 - Min: 11

Von 1 auf 2 Kerne steigt die Rechenkraft um Faktor 2, die FPS um 2,198...wie geht das?

[y33H@]

Mit der massiven Parallelisierung des Codes kommt der SC nicht klar, der braucht da länger als wenn der Code seriell wäre. Daher ist der DC mehr als doppelt so schnell. Ist oft zu beobachten.

[Gast]

Das müsste sich doch bei SC + HT weniger stark auswirken, richtig?

[mapel110]

Mit der massiven Parallelisierung des Codes kommt der SC nicht klar, der braucht da länger als wenn der Code seriell wäre. Daher ist der DC mehr als doppelt so schnell. Ist oft zu beobachten.
Könnte es nicht auch sein, dass es sich mit der Cache-Assoziativität beißt, dieses Abschalten der Cores?! Das würde dann auch stark Performance kosten.

[Hvoralek]

Von 1 auf 2 Kerne steigt die Rechenkraft um Faktor 2, die FPS um 2,198...wie geht das?Das liegt wohl an einer "Grundlast" an Dingen, die nicht pro Frame, sondern fest pro Zeiteinheit berechnet werden müssen (KI, Physik, sonstige Spielmechanik). Das Thema hatten wir hier schon häufiger. Gerade bei Strategiespielen merkt man das oft, v.a. bei Supreme Commander ganz deutlich. Deswegen halte ich auch fps- Angaben in diesem Zusammenhang nur für bedingt hilfreich.

/edit: D.h. natürlich auch, dass Anno deutlich schwächer von Mehrkernern profitiert, als es auf den ersten Blick aussieht. Wahrscheinlich bräuchte hier der Doppelkerner weniger als 54% Mehrtakt, um den Quad zu schlagen.

[dargo]

Mit der massiven Parallelisierung des Codes kommt der SC nicht klar, der braucht da länger als wenn der Code seriell wäre. Daher ist der DC mehr als doppelt so schnell. Ist oft zu beobachten.
Ich sehe die Ursache wo anders - dass Games mit höheren Taktraten (oder in diesem Fall Cores) besser als 1:1 skalieren sieht man praktisch immer. Eine mögliche Erklärung dazu hat früher schon Madkiller gegeben. Bestimmte Aufgaben wie zb. KI/Physik/OS/Eingabegeräte verursachen eine feste CPU-Last bzw. Grundlast. Mit steigernder CPU-Leistung bleibt somit mehr für die Frames übrig.

Ganz extrem wird es wenn man mit dem SC gerade so die Schwelle für die festen Anforderungen erfüllt. Siehe Sega Rally:
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=5658521&postcount=414

Edit:
Argh... Hvoralek war schneller. ;)


/edit: D.h. natürlich auch, dass Anno deutlich schwächer von Mehrkernern profitiert, als es auf den ersten Blick aussieht. Wahrscheinlich bräuchte hier der Doppelkerner weniger als 54% Mehrtakt, um den Quad zu schlagen.
Genau aus diesem Grund (kam auch von dir der Vorschlag ;)) teste ich wie hoch man einen DC takten muss um auf die gleichen Frames des QCs zu kommen. :)

[y33H@]

@ Gast

SMT wirkt sich auf jeden Fall aus.

@ mapel110

Kann sein - andererseits steht dem einem Kern mehr L3 zu Verfügung.

@ Hvoralek

Guter Punkt =)

[RainingBlood]

Hmm... dann muss ich mir das mit dem Patch unter Win7 nochmal genauer anschauen. Ich bin mir ziemlich sicher, dass ich die Settings überprüft habe, mache ich eigentlich immer. :uponder:



habe es ganz frisch getestet und kann einen deutlichen Performancezuwachs bei nfs: underground bestätigen!
Win7 legt klar die Meßlatte.

[dargo]

Du meinst sicherlich Undercover? :)

[RainingBlood]

ja, richtig.

[dargo]

Need for Speed: Shift ist fertig.
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=6973301&postcount=1

Leichte Vorteile für den TC. QC bringt leider rein gar nichts.

[y33H@]

Wo hast du gebencht? "Grands Hatch GP" mit 15 Gegnern?

[mapel110]

Wo hast du gebencht? "Grands Hatch GP" mit 15 Gegnern?
Need for Speed: Shift - Strecke 'Willow Springs GP' mit 16 Fahrzeugen und maximalen Details

Steht über dem Bild zur Verzierung. ^^

[Gast]

Von 1 auf 2 Kerne steigt die Rechenkraft um Faktor 2, die FPS um 2,198...wie geht das?


die kerne habe schliesslich noch was anderes zu tun, das ist nicht ungewöhnlich ;)

[dargo]

DIRT 2 ist fertig:
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=6973301&postcount=1

Gute +50% für den Quad, hätte schon etwas mehr erwartet. 73% Leistungszuwachs durch den Quad.

[=Floi=]

das sind ja teilweise fast 70-90%! (bin zu faul zum rechnen) ich finde das nicht schlecht.

was läuft denn bei dirt1 schief?

[dargo]

das sind ja teilweise fast 70-90%! (bin zu faul zum rechnen) ich finde das nicht schlecht.

Naja, wo du die 90% her hast weiß ich nicht. Die ~73% beim 2Ghz QC vs. DC sehen auf den ersten Blick sehr gut aus. Wenn du dir aber anschaust wie hoch ich einen DC takten muss damit ich auf die gleichen Frames wie der 1,47Ghz QC komme relativiert sich das wieder. Es sind gute 50%.

[y33H@]

@ dargo

Von 35,1 auf 60,7 Fps sind +72,9% und von 23,8 auf 39,7 Fps sind es +66,8%. Das deckt sich mit den PCGH-Werten (http://www.pcgameshardware.de/aid,700759/Dirt-2-im-CPU-Test-mit-DirectX-9-und-DirectX-11-Phenom-sehr-gut-im-Rennen-Quadcores-herrschen/Rennspiel-Sportspiel-Simulation/Test/):Der Q6600 beispielsweise schlägt sein Dualcore-Pendant E6600 um satte 67 Prozent, ein Q9650 ist 62 Prozent schneller als ein E8400.Und auch die +16,7% von TC auf QC passen: Selbst von drei auf vier Kerne legt Dirt noch zu, der Phenom II X4 925 liegt rund 18 Prozent vor dem Phenom II X3 720 BE.

[Undertaker]

Dargo hat aber Recht, dass man eigentlich die Taktraten für identische Leistung vergleichen muss, und nicht den fps-Unterschied bei gleichem Takt. ;) Hier kann es nämlich sonst zu einer fälschlicherweise zu hohen Skalierung für den Quad kommen, da die die fps durch konstanten Lastanteile wie Physik o.ä. überproportional steigen.

[dargo]

Hier kann es nämlich sonst zu einer fälschlicherweise zu hohen Skalierung für den Quad kommen, da die die fps durch konstanten Lastanteile wie Physik o.ä. überproportional steigen.
Jep. Wenn man mit der langsamsten CPU (in meinem Fall der DC) nahe an der Grundlast knabbert kann das Ergebnis mit dem Quadcore sehr leicht verfälscht werden. Genau das passiert bei meinem DIRT2-Savegame. 2Ghz QC legt bei meinem Test um satte ~73% zu, in Wahrheit sind es aber nur ~51% für den Quad, was man am 1,47Ghz QC vs. XGhz DC sieht.

Ähnlich sieht es in CoD: MW2 aus welches ich auch fertig habe.

Call of Duty: Modern Warfare 2 ist auch fertig:
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=6973301&postcount=1

[y33H@]

Richtig, eine hohe Grundlast "verfälscht". Absolut gesehen in Fps fällt die Differenz größer aus.

[dargo]

Absolut gesehen in Fps fällt die Differenz größer aus.
Und das ist das eigentliche Problem, welches bei euren Benchmarks nicht erkennbar ist. Der User sieht - oh, der Quad legt um satte 73% zu, was aber nicht stimmt. Jetzt bitte die kleine Kritik nicht in den falschen Hals bekommen. :) Es ist nun mal so - der User wird etwas irregeführt.
Ich teste das gleich mal bei mir nach. Theoretisch müsste ich also den DC mit ca. 3462Mhz (+~73%) takten damit ich die gleichen Frames bekomme wie der 2Ghz Quad. Praktisch müssten es aber um die 3062Mhz (+~51%) sein.

[y33H@]

Momentchen - der Quad erzielt 73 Prozent mehr Fps. Mehr lässt sich anhand der Fps-Balken eines E6600 und eines Q6600 erst mal nicht sagen und mehr macht PCGH ja auch nicht. Der Begriff Grundlast und was diese ist/macht ist den meisten nicht bekannt und die daraus folgende Tatsache, dass der Quad im eigentlichen Sinne keine 73 sondern nur 50 Prozent schneller ist, auch nicht. Dies müsste man den Leuten erst mal in einem Artikel näher bringen. Für normale CPU-Tests, in denen die Leute einfach nur sehen wollen, wo sich ihre CPU einordnet, ist das imo nichts. Aber wir haben ja dich =)

[dargo]

@y33H@
Ich muss mich entschuldigen, ich war doch auf dem völlig falschen Dampfer. Bei meinen Tests sind nicht die Werte 1,47Ghz QC vs. XGhz DC ausschlaggebend sondern tatsächlich die 2Ghz QC vs. 2GHz DC. Dann sind die +73% mit einem Quad doch recht ordentlich.

@Undertaker
Ich glaube wir hatten da einen falschen Gedankengang. Ich habe jetzt mal folgenden Test angestellt:

Aus dem Diagramm der ersten Seite am Beispiel DIRT2:
2Ghz QC vs. 2Ghz DC = + ~73%
1,47Ghz QC vs. 2,226Ghz DC = + ~51%

Jetzt habe ich DIRT 2 mit 3,066Ghz DC (7x438) getestet. Die Taktsteigerung gegenüber 2Ghz beträgt ~53%. Die Framerate liegt bei 54,28fps (+ ~55% gegenüber 2Ghz DC, die ~2% Unterschied zähle ich zur Messtoleranz). Dh. ich muss tatsächlich den DC mit 3462Mhz takten damit er mit dem 2Ghz QC gleichzieht.

[Undertaker]

Ich muss zugeben, jetzt auch nicht mehr ganz bei den Messwerten durchzusehen, meine Aussage oben war mehr grundlegender Natur - ich versuch es nochmal zusammenzufassen:

1. 1,47GHz QC = 2,226GHz DC?
2. 2GHz QC = 3,46GHz DC?

Vorausgesetzt, dass diese Werte alle im sauberen, vollständigen CPU-Limit entstanden sind, lässt sich für mich hier nur ein Fakt eindeutig feststellen: Der Grad der Quadcore-Skalierung ist von der fps-Höhe bzw. der konkreten Leistung der CPU bei einem bestimmten Takt abhängig.
Mich wundert nur, dass die Skalierung mit steigender Leistung (in Form eines höheren Taktes) zulegt. Oder aber ich habe jetzt hier einen Denkfehler...?

Edit: Mal eine Beispielrechnung:

Ein Spiel kann einen Quadcore zu 75% auslasten. Ferner herrschen konstante 1000MHz Grundlast auf einem Kern und ein 2GHz Dualcore schafft 50fps. Ergibt:

2GHz Dualcore: 50fps
2GHz Quadcore: 80fps (+60%)
3GHz Dualcore: 80fps
3GHz Quadcore: 133fps (+67%)
4,5GHz Dualcore: 133fps

Wie man sieht, scheint die Quadcore-Skalierung mit steigendem Takt zuzunehmen. Tatsächlich aber ist der Taktvorteil, den ein Dualcore für identische fps benötigt, aber absolut konstant. Wenn deine Benches stimmen kann man wie oben geschrieben nur davon ausgehen, dass die Kernauslastung eben nicht immer konstant ist.

[dargo]

Ich muss zugeben, jetzt auch nicht mehr ganz bei den Messwerten durchzusehen, meine Aussage oben war mehr grundlegender Natur - ich versuch es nochmal zusammenzufassen:

1. 1,47GHz QC = 2,226GHz DC?
2. 2GHz QC = 3,46GHz DC?

Korrekt. Wobei ich den zweiten Punkt nicht zu 100% genau testen kann da ich als Grundbasis für meine Tests den CPU-Multi 7 gewählt habe. Um auf 3,46Ghz zu kommen bräuchte ich schon einen FSB von 494Mhz was mein Brett nicht mehr schafft. Mit 8x432 komme ich mit 59,8fps aber knapp in die Region vom 2Ghz QC (60,7fps).


Vorausgesetzt, dass diese Werte alle im sauberen, vollständigen CPU-Limit entstanden sind...

Alles 100% CPU-Limit. Sonst erwähne ich es extra falls bei irgendeinem CPU-Setting es nicht der Fall sein sollte.


... lässt sich für mich hier nur ein Fakt eindeutig feststellen: Der Grad der Quadcore-Skalierung ist von der fps-Höhe bzw. der konkreten Leistung der CPU bei einem bestimmten Takt abhängig.

Nicht nur Quadcore-Skalierung... es ist allgemein bei der CPU-Skalierung der Fall. Man könnte es auch etwas anders formulieren - je höher die Grundlast vom Spiel umso schneller muss ich die jeweiligen Taktraten der CPUs wählen um den tatsächlichen Vorteil einer schnelleren CPU (völlig egal ob mehr Kerne oder höhere Taktraten) zeigen zu können. Ich würde ja gerne einmal mit standard 8,5x333Mhz und 8,5x400Mhz testen. Das Problem ist halt nur, dass ich damit Gefahr laufe ins GPU-Limit zu stoßen. Das Testsetup werde ich leider erst mit einer schnelleren Graka ändern können.

Nochmal zur Übersicht:
2Ghz QC = 60,7fps vs. 2Ghz DC = 35,1fps (+ ~73%)
1,47Ghz QC = 39,667fps vs. 2,226Ghz DC = 39,8fps (+ ~51%)
3,066Ghz DC = 54,28fps
3,456Ghz (8x432) = 59,8fps

[Undertaker]

Nicht nur Quadcore-Skalierung... es ist allgemein bei der CPU-Skalierung der Fall. Man könnte es auch etwas anders formulieren - je höher die Grundlast vom Spiel umso schneller muss ich die jeweiligen Taktraten der CPUs wählen um den tatsächlichen Vorteil einer schnelleren CPU (völlig egal ob mehr Kerne oder höhere Taktraten) zeigen zu können.

Logisch, aber das meinte ich auch nicht. Ich sprach davon, dass man eigentlich davon ausgehen sollte, dass der Taktvorteil von einem Dualcore für fps-Gleichheit zu einem Quadcore konstant sein sollte, siehe die oben eingefügte Beispielrechnung. Erklärbar wird dieses Phänomen nur dadurch, dass die CPU-Auslastung trotz CPU Limit mit steigender Taktrate steigt. Und das ist dann der Punkt, der mir etwas merkwürdig erscheint. ;)

[Botcruscher]

Das ist der Supcom-Effekt. Durch mehr vorhandene Leistung läuft das Game Effizienter und Reserven werden frei. Da sind dann mehr FPS drin als durch die Rohleistung zu erwarten ist.

[dargo]

Logisch, aber das meinte ich auch nicht. Ich sprach davon, dass man eigentlich davon ausgehen sollte, dass der Taktvorteil von einem Dualcore für fps-Gleichheit zu einem Quadcore konstant sein sollte, siehe die oben eingefügte Beispielrechnung. Erklärbar wird dieses Phänomen nur dadurch, dass die CPU-Auslastung trotz CPU Limit mit steigender Taktrate steigt. Und das ist dann der Punkt, der mir etwas merkwürdig erscheint. ;)
Ich glaube du hast mich nicht ganz verstanden. Das Grundproblem ist die Grundlast. Je nachdem welches Testsetup man aufstellt kann das zu falschen Schlüssen führen wie man an meinem Beispiel sieht. Für mich machen die Ergebnisse in DIRT 2 alle Sinn. Ich kann das anhand einer Ausrechnung der Grundlast in Zahlen beweisen. Ich hoffe ihr könnt mir folgen. :freak:

Edit:
Die Grundlast von DIRT 2 inkl. OS in meinem Savegame beansprucht bei meiner CPU ca. 350Mhz bei zwei Kernen. Wie ich dazu komme?

2Ghz DC = 35,1fps
1,47Ghz DC = 23,767fps

Dh., der 2Ghz DC liefert 47,68% mehr Frames bei 36,19% mehr Taktrate. Daraus ergibt sich wie gesagt eine Grundlast von ca. 350Mhz.

2002Mhz - 350 = 1652Mhz für die Framesberechnung
1470Mhz - 350 = 1120Mhz für die Framesberechnung

1652Mhz sind um 47,5% schneller als 1120Mhz was ja exakt zu meinen Werten 35,1 vs. 23,767fps passt. Natürlich könnte man es noch genauer ausrechnen aber ich denke die 18 Hundertstel % wird mir jeder verzeihen. ;)

Jetzt rechnen wir mal weiter - laut meinem Test ist ein 2Ghz QC 155,39% schneller als ein 1,47Ghz DC (60,7 vs. 23,767fps) und ein 2Ghz QC um 72,93% schneller als ein 2Ghz DC (60,7 vs. 35,1fps). Auch das ergibt Sinn - die Grundlast ändert sich ja nicht und beträgt weiterhin 350Mhz. Dh. wir müssen jetzt die 1652Mhz (2Ghz - Grundlast) um 72,93% erhöhen. Das ergibt 2857Mhz für die reinen fps. Diese 2857Mhz sind exakt 155,xx% schneller als die 1120Mhz vom 1,47Ghz DC.

Kann mir wirklich noch jeder folgen? :| :D

[Undertaker]

Ich denke schon das ich dir da folgen kann, die Skalierung des Dualcores ist nach der Rechnung absolut schlüssig. :) Dennoch verschiebt sich mit einer Taktänderung, siehe dazu meine Rechnung oben - welche für 2x350MHz Grundlast genauso klappt wie für meine beispielhaften 1000MHz (auf einem Kern) -, die CPU-Auslastung. Und das verwundert mich...

Also nochmal das, was zu erwarten wäre:

Wenn ein 2GHz Dualcore so schnell ist, wie ein 1,5GHz Quad, dann sollte ein 4GHz Dualcore auch so schnell sein, wie es 3GHz Quad es ist. Und das für jede beliebige Grundlast, das Setting mit doppeltem Takt kann also ruhig drei mal so schnell sein, wie jenes mit dem niedrigeren. Andernfalls ändert sich die Kernauslastung.

Übrigens: Du hast selbst gerade die Unschlüssigkeit berechnet: Ein 2857MHz + 350MHz Grundlast DC sollte so schnell sein, wie der 2GHz Quad. Real brauchst du aber über 3,4GHz. Ergo skaliert der Quadcore hier besser, als es die Theorie mit konstanter Kernauslastung voraussagt.

Edit: Und noch ein Schwachpunkt dieser Herangehensweise: Wenn wir bei einem Dualcore 2x350MHz Grundlast haben, wissen wir noch nicht genau, wie das bei einem Quadcore aussieht. Hier wären auch 700/3MHz auf 3 Kernen oder 700/4MHz auf 4 Kernen denkbar... Darum imho nicht so ganz sauber. Ich würde die Grundlast eher als Singlecorelast betrachten (rein modellhaft reicht das zu), dafür aber einen Auslastungsfaktor für den Quadcore einführen (sofern wir einen Dualcore als 100%ig ausgelastet betrachten können, ansonsten benötigen wir einen Skalierungsfaktor von Dual->Quad).

[dargo]

Also nochmal das, was zu erwarten wäre:

Wenn ein 2GHz Dualcore so schnell ist, wie ein 1,5GHz Quad, dann sollte ein 4GHz Dualcore auch so schnell sein, wie es 3GHz Quad es ist.
Du hast hier einen Denkfehler. :)

Im zweiten Fall stehen beiden CPUs mehr Resourcen zur reinen Framesberechnung zur Verfügung als im ersten Fall, somit ändert sich auch das Skalierungsverhältnis. Vergiss bitte nicht, dass die Grundlast sich nicht ändert. Genaueres morgen, muss jetzt in die Heija. :wink:

[Undertaker]

Argh, wir reden aneinander vorbei. :D

Sagen wir beispielsweise, von einem Quadcore können nur genau 3 Kerne ausgenutzt werden, diese aber zu 100%. Dann ist ein 2GHz Quad so schnell wie ein 3GHz Dualcore, korrekt? Beide haben effektiv "6000MHz" zu Verfügung. Davon können jetzt z.B. 1000MHz (als Summe von allen Kernen, also evntl. 3*333MHz auf dem Quad und 2*500MHz auf dem Dualcore) für die Grundlast verwendet werden, bleiben "5000MHz". Also, egal wie groß die Grundlast ist, die verbleibende Leistung ist identisch. Soweit sind wir uns einig?

Dann zum nächsten Schritt: Wir verdoppeln nun jeweils den Takt, bei weiterhin gleichen Randbedinungen: Der Quad wird zu 75% (=3 Kerne), der Dualcore zu 100% ausgelastet.
Der 6GHz Dualcore hat nun "12000MHz" (2x6GHz), davon "11000MHz" für die fps. Der 4GHz Quadcore hätte ebenfalls "12000MHz" (4*4GHz*0,75 bzw. direkt 3*4GHz) und davon "11000MHz" für die fps - es wären wieder beide Exemplare gleich schnell. Und das trotz beliebiger Grundlast.
Nichtsdestotrotz würde die Taktverdoppelung durch die Grundlast natürlich überproportional skalieren, sowohl der DC als auch der QC würden ihre fps mit dem Faktor 2,2 multiplizieren.

Genau diese Rechnung klappt auch für jede beliebige andere Auslastung von Quad- und Dualcore - Hauptsache, sie verändert sich nicht mit dem Takt.

Also, am besten schlafen wir da wirklich nochmal eine Nacht drüber, auch wenn ich mir gerade recht sicher bin, kann sich natürlich immer ein Denkfehler einschleichen. Ein spannendes Thema, so oder so. ;)

[dargo]

Argh, wir reden aneinander vorbei. :D

Sagen wir beispielsweise, von einem Quadcore können nur genau 3 Kerne ausgenutzt werden, diese aber zu 100%. Dann ist ein 2GHz Quad so schnell wie ein 3GHz Dualcore, korrekt? Beide haben effektiv "6000MHz" zu Verfügung. Davon können jetzt z.B. 1000MHz (als Summe von allen Kernen, also evntl. 3*333MHz auf dem Quad und 2*500MHz auf dem Dualcore) für die Grundlast verwendet werden, bleiben "5000MHz". Also, egal wie groß die Grundlast ist, die verbleibende Leistung ist identisch. Soweit sind wir uns einig?

Dann zum nächsten Schritt: Wir verdoppeln nun jeweils den Takt, bei weiterhin gleichen Randbedinungen: Der Quad wird zu 75% (=3 Kerne), der Dualcore zu 100% ausgelastet.
Der 6GHz Dualcore hat nun "12000MHz" (2x6GHz), davon "11000MHz" für die fps. Der 4GHz Quadcore hätte ebenfalls "12000MHz" (4*4GHz*0,75 bzw. direkt 3*4GHz) und davon "11000MHz" für die fps - es wären wieder beide Exemplare gleich schnell. Und das trotz beliebiger Grundlast.
Nichtsdestotrotz würde die Taktverdoppelung durch die Grundlast natürlich überproportional skalieren, sowohl der DC als auch der QC würden ihre fps mit dem Faktor 2,2 multiplizieren.

Genau diese Rechnung klappt auch für jede beliebige andere Auslastung von Quad- und Dualcore - Hauptsache, sie verändert sich nicht mit dem Takt.

Also, am besten schlafen wir da wirklich nochmal eine Nacht drüber, auch wenn ich mir gerade recht sicher bin, kann sich natürlich immer ein Denkfehler einschleichen. Ein spannendes Thema, so oder so. ;)
Hehe. :)

Entweder du verstehst mich nicht ganz oder wir reden wirklich aneinander vorbei. :D

Nehmen wir mal dein Beispiel:

CPU 1 = 3Ghz DC
CPU 2 = 2Ghz QC

Beide liefern gleiche fps, ich nehme mal einfach 100fps. Würde anhand der fps bedeuten, dass der Quadcore mit den beiden zusätzlichen Cores um 50% zulegt. Die Grundlast beträgt 1000Mhz (in Summe aller Kerne). Somit haben beide CPUs je 5Ghz (die Kernleistung jetzt mal zusammengerechnet) für die Berechnung der 100fps.
Jetzt verdoppeln wir die Taktraten beider CPUs:

CPU 1 = 6Ghz DC
CPU 2 = 4Ghz QC

Da die Grundlast gleich bleibt haben wir bei den CPUs je 11Ghz für die fps. Im ersten Fall waren es 5Ghz, im zweiten sind es 11Ghz. Wir haben die Taktraten der CPUs um 100% erhöht, die tatsächlichen Taktraten/Resourcen für die Frames haben aber um 120% zugenommen. Somit steigt bei höheren Taktraten die Skalierung, was man in meinen Diagrammen mit der höheren Taktrate auch wunderbar erkennen kann. :)

[Undertaker]

Jetzt haben wir es glaube ich gleich. :D Also, wir sind uns jetzt einig, dass in dieser Beispielrechnung ein 6GHz DC so schnell wie ein 4GHz QC ist, wenn ein 3GHz DC einem 2GHz QC entspricht (bei jeweils überproportionaler Skalierung mit dem Takt auf Grund konstanter Grundlast, aber das nur am Rande)

Knackpunkt ist: Wenn ich einen QC und einen DC mit identischer Leistung nehme und beide prozentual identisch übertakte, sollten beide immernoch die gleiche Leistung liefern (wie gerade in unserem 3->6GHz DC / 2->4GHz Quad Fall).
In Dirt 2 scheint dies aber nicht der Fall zu sein. Ein 1,47GHz Quad entspricht einem 2,226GHz Dualcore (=51% Mehrtakt). Ergo sollte ein 2GHz QC ebenso einem 51% höher getakteten DC, also einem Modell mit 3,03GHz, entsprechen. Real braucht es nach deinen Benches dafür aber etwa 3,5GHz. Das bedeutet zwangsläufig, dass die Auslastung eines Quadcores mit höherem Takt ansteigt, ein durchaus wunderliches Phänomen - das mit der Grundlastproblematik nicht erklärbar ist, die betrifft QC wie DC in gleicher Weise und kann ausgeklammert werden.

Also: Ich wundere mich nicht über die Taktskalierung, sondern über die Kernskalierung.

[Botcruscher]

Knackpunkt ist: Wenn ich einen QC und einen DC mit identischer Leistung nehme und beide prozentual identisch übertakte, sollten beide immernoch die gleiche Leistung liefern (wie gerade in unserem 3->6GHz DC / 2->4GHz Quad Fall).


Nein eben nicht. Ganz simpel kann man sagen, dass Windows und die Treiber eine Grundlast erzeugen, danach kommen Eingabe, Physik, KI ... und zuletzt der Render. Gleichzeitig hampeln auch nicht mehr mehrere Thraeds auf einer CPU rum und stehen sich im Weg.

[Undertaker]

Ist doch alles klar... Aber dieses Verhältnis verschiebt sich nicht! Wenn ein Quadcore zu 75% ausgelastet wird, dann ist er generell so schnell wie ein Dualcore, der 50% höher taktet. Völlig egal, ob ich hier 2GHz zu 3GHz oder 4GHz zu 6GHz vergleiche.
Nochmal, hier geht es nicht um die Grundlast! Die betrifft beide und kann, sofern ich bei gleichen fps vergleiche, ausgeklammert werden. Relevant wird die Grundlast, wenn ich zwischen CPUs verschiedener Leistungsfähigkeit vergleichen möchte, hier kann es dadurch zu nichtlinearem Skalierungsverhalten kommen. Völlig logisch und nicht das, was hier verwundert.

[dargo]

Ist doch alles klar... Aber dieses Verhältnis verschiebt sich nicht! Wenn ein Quadcore zu 75% ausgelastet wird, dann ist er generell so schnell wie ein Dualcore, der 50% höher taktet. Völlig egal, ob ich hier 2GHz zu 3GHz oder 4GHz zu 6GHz vergleiche.

Nein, eben nicht. Wie soll ich das nur erklären? :uponder:

[Undertaker]

Nein, eben nicht. Wie soll ich das nur erklären? :uponder:

Das sagt aber auch deine Rechnung oben aus. Nehmen wir 1000MHz Grundlast und 75% Quad-Auslastung an, haben der 3GHz DC und der 2GHz QC "5000MHz" für die fps. Bei 6GHz/4GHz haben beide 11000MHz für die fps.

Ich denke, wir reden immernoch aneinander vorbei. Ich vermute du glaubst, ich wundere mich über die überproportionale fps-Steigerung bei einer Takterhöhung. Aber nein, das ist nicht gemeint. Es geht nur um das Taktverhältnis DC zu QC bei gleicher Leistung (ganz fett, denn sonst klappt das nicht). Ohne Auslastungsänderung bei einer der beiden CPUs gibt es bei einer identischen Taktänderung beider auch weiterhin keine Leistungsunterschiede.

[dargo]

@Undertaker

Nächster Versuch. :D

Blende den Quadcore einfach mal aus. Hier die einzelnen Ergebnisse mit dem DC:

1. 1,47Ghz = 23,767fps
2. 2,002Ghz = 35,1fps
3. 3,066Ghz = 54,28fps
4. 3,456Ghz = 59,8fps

Von 1 zu 2 erhöht sich die Taktrate um 36,19% bei 47,68% höherer Framerate. Von 2 zu 3 sieht es schon ganz anders aus - Taktrate legt um 53,14% zu während die Frames um 54,64% steigen. Bei 3 zu 4 ist die Taktrate um 12,72% höher, die Frames steigen nur noch um 10,16%.
Beim vierten Punkt muss man aber aufpassen - ich habe für die 3456Mhz ein anderes Verhältnis zwischen FSB und CPU-Multi gewählt da mein Mainboard keine 494Mhz FSB schafft. Außerdem war der Speicherteiler 2:2 und nicht wie im Fall 1 und 2 bei 2:2.40. Ich bin mir relativ sicher - wenn ich das Verhältnis FSB zum CPU-Multi und Speicher weiter beibehalten hätte würden die Frames bei 3 zu 4 um exakt 12,72% steigen, also 1:1. Aber das nur nebenbei.

Warum die Frames bei 1 zu 2 dermaßen überproportional zulegen sind wir uns denke ich einig oder? Der 1,47Ghz liegt mit Abstand am nähesten an der Grundlast.

Jetzt kommen wir nochmal zu meinem fett markierten Satz. Wenn man die Prozentwerte in Zahlen umwandelt und das ganze in einen Dreisatz packt bedeutet es folgendes - Ich investiere knapp 76% mehr CPU-Takt für 100% mehr Frames. Oder anders ausgedrückt - ich investiere 100% mehr Takt für knapp 132% mehr Frames.

Wenn man das ganze auf den DIRT 2-Test überträgt bedeutet dies nichts anderes als, dass ich in den DC (in meinem Fall 2226Mhz) Einiges weniger an Taktrate investieren muss um mit dem 1,47Ghz Quadcore gleichzuziehen. Wohlgemerkt immer nur dann wenn man mit dem Testsetup sich nahe an der Grundlast bewegt.

Nehmen wir 1000MHz Grundlast und 75% Quad-Auslastung an, haben der 3GHz DC und der 2GHz QC "5000MHz" für die fps. Bei 6GHz/4GHz haben beide 11000MHz für die fps.

Das ist soweit korrekt. In beiden Fällen haben die CPUs die gleichen Resourcen für die Framesberechnung zur Verfügung. Fall 1 - 5Ghz zu 5Ghz und Fall 2 - 11Ghz zu 11Ghz. Trotzdem werden beide CPUs im zweiten Fall 220fps liefern wenn beide im ersten Fall 100fps berechnen können.

[Undertaker]

Das ist soweit korrekt. In beiden Fällen haben die CPUs die gleichen Resourcen für die Framesberechnung zur Verfügung. Fall 1 - 5Ghz zu 5Ghz und Fall 2 - 11Ghz zu 11Ghz. Trotzdem werden beide CPUs im zweiten Fall 120fps liefern wenn beide im ersten Fall 100fps berechnen können.

Ich vermute mal, du meinst 50fps im Fall 1 und 110fps im Fall 2? Korrekt, da sind wir uns ja auch schon seit zwei Seiten absolut einig. Der Punkt ist: Sowohl in Fall 1 und in Fall 2 sind DC und QC gleich schnell, da beide um den gleichen Prozentsatz übertaktet wurden. Für Dirt 2 würde das, ich wiederhol es nochmal, folgendes ergeben:

1,47GHz QC == 2,226GHz DC klappt, ergibt 51,4% höhere Auslastung des QC im Vergleich zum DC
36% OC bei beiden:
2GHz QC == 3,03GHz DC klappt nicht
Wir brauchen ~57% OC beim Dualcore:
2GHz QC == ~3,5GHz DC klappt, ergibt ~75% höhere Auslastung des QC im Vergleich zum DC

Deswegen kann ich den Quadcore auch nicht ausklammern, mir geht es ja gerade um das Verhältnis zum Dualcore... ;) Oder um das mal in real vorstellbare Werte umzurechnen: Wir nehmen mal an, das ein Dualcore in Dirt 2 immer zu 100% ausgelastet wird. Dann würde dir der Taskmanager bei dem 1,47GHz Quad eine Auslastung von 75,7% anzeigen, bei dem 2GHz Quadcore aber eine Auslastung von 87,5%!

[dargo]

Ich vermute mal, du meinst 50fps im Fall 1 und 110fps im Fall 2?

Ah sorry, war mein Fehler - es sollte natürlich 220fps zu 100fps heißen. Oder halt 110 zu 50fps, völlig egal.


Korrekt, da sind wir uns ja auch schon seit zwei Seiten absolut einig. Der Punkt ist: Sowohl in Fall 1 und in Fall 2 sind DC und QC gleich schnell, da beide um den gleichen Prozentsatz übertaktet wurden. Für Dirt 2 würde das, ich wiederhol es nochmal, folgendes ergeben:

1,47GHz QC == 2,226GHz DC klappt

51% OC bei beiden:

2GHz QC == 3,03GHz DC klappt nicht

Deswegen kann ich den Quadcore auch nicht ausklammern, mir geht es ja gerade um das Verhältnis zum Dualcore... ;)
Die 3,03Ghz DC können auch nicht klappen wenn du dir dieses Beispiel noch einmal durch den Kopf gehen lässt:
In beiden Fällen haben die CPUs die gleichen Resourcen für die Framesberechnung zur Verfügung. Fall 1 - 5Ghz zu 5Ghz und Fall 2 - 11Ghz zu 11Ghz. Trotzdem werden beide CPUs im zweiten Fall 220fps liefern wenn beide im ersten Fall 100fps berechnen können.


PS: die 51% in deinem Beispiel beziehen sich nicht auf das OC der beiden CPUs sondern ist nur das Skalierungsergebnis zwischen 1,47Ghz QC und 2,226Ghz DC. Hast es imo etwas ungünstig niedergeschrieben.

[Undertaker]

Hast irgendwie ein altes Zitat von mir erwischt, hab mein Posting doch eine Stunde vor deinem Posting nochmal editiert. :confused: Egal...


Die 3,03Ghz DC können auch nicht klappen wenn du dir dieses Beispiel noch einmal durch den Kopf gehen lässt:

Nun, was hatten wir in unserem Beispiel: Da haben wir sowohl beim DC als auch beim Quad den Takt um 100% erhöht und erhielten 120% mehr fps.
Jetzt in Dirt 2 erhöhen wir den Takt von DC und QC um ~36%, der DC legt um 54% zu, der QC um 71,4%. Je nach Grundlast wäre jeder Wert für sich betrachtet durchaus denkbar, nur wäre zu erwarten gewesen, das beide um 54%/71% zulegen, und nicht der eine stärker als der andere. Das widerspricht unserem Beispiel.

[Demogod]

Ich wollte das vor ein paar Monaten schonmal schreiben und jetzt tue ich es:
in dem Moment, in dem man auch am FSB rumspielt sind alle weiteren Messergebnisse IMO komplett wegschmeissbar. IMO sollte man C2D und C2Q nach Möglichkeit immer (wenn man bencht und Ergebnisse vergleichen will) mit nem FSB von 400 fahren (1:1 FSB/RAM).

[dargo]

Hast irgendwie ein altes Zitat von mir erwischt, hab mein Posting doch eine Stunde vor deinem Posting nochmal editiert. :confused: Egal...

Ähm... ja sorry, hatte zwischendurch mein Mittag zu mir genommen. ;)


Nun, was hatten wir in unserem Beispiel: Da haben wir sowohl beim DC als auch beim Quad den Takt um 100% erhöht und erhielten 120% mehr fps.
Jetzt in Dirt 2 erhöhen wir den Takt von DC und QC um ~36%, der DC legt um 54% zu, der QC um 71,4%. Je nach Grundlast wäre jeder Wert für sich betrachtet durchaus denkbar, nur wäre zu erwarten gewesen, das beide um 54%/71% zulegen, und nicht der eine stärker als der andere. Das widerspricht unserem Beispiel.
Mir brummt schon mein Schädel mit den ganzen Zahlen. :freak:

Wo kommen jetzt deine 54 und 71% eigentlich her? :confused:
Nach meinem Diagramm legt der DC von 1,47Ghz auf 2Ghz um 47,68% und beim QC um 53,02% zu.

[Undertaker]

Das sind die Leistungsgewinne, wenn ich einmal den 2,226GHz DC um 36% übertakte (ergibt 54% Mehrleistung), sowie wenn ich den 1,47GHz QC um 36% übertakte (ergibt 71% Mehrleistung). Vor dem übertakten sind beide gleich schnell, übertakte ich sie prozentual identisch, dann nicht mehr.

[dargo]

Das sind die Leistungsgewinne, wenn ich einmal den 2,226GHz DC um 36% übertakte (ergibt 54% Mehrleistung), sowie wenn ich den 1,47GHz QC um 36% übertakte (ergibt 71% Mehrleistung).
Ich kann dir echt nicht mehr folgen. ;(

[Undertaker]

Ein allerletzter Versuch, ich glaub dann lassen wir das besser. ;)

1,47Ghz QC = 39,667fps
2,226Ghz DC = 39,8fps

36% OC:

1,47GHz * 1,36 = ~2GHz
2,226Ghz * 1,36 = ~3,03GHz

2GHz QC = 60,7fps
3,066Ghz DC = 54,28fps

Die letzten beiden fps-Werte sollten identisch sein, da wir zwei identisch schnelle CPUs um das gleiche Maß übertaktet haben. Der Dualcore ist aber langsamer, in einem Maß das über die Messtoleranz hinaus geht. Das widerspricht der Theorie unseres obigen Beispiels.

[=Floi=]

hier soll es doch um die kernskalierung gehen und die lese ich aus dem gleichen takt heraus. was du die ganze zeit machst ist die taktskalierung zu testen. darum geht es hier aber nicht und das will ich auch nicht sehen.

mir geht es um den unterschied zwischen den einzelnen prozessoren und deren kerne. das zählt und das ist wichtig. was hat mir der quad (oder i7) gebracht oder was könnte er bringen. Es ist auch noch nett anzusehen, wenn ein spiel nicht nur von 3 kernen profitiert, sondern auch noch von 4 oder gar mehr.
Wenn die kernskalierung passt, dann ist der takt nicht mehr so wichtig und auch zukünftig wird man den vorteil einer neuen cpu nützen können.
je schlechter die skalierung mit mehr kerne, desto schlechter skaliert diese software mit zukünftigen prozessoren und man läuft zwangsläufig in ein cpu-limit. das sieht man sehr schön an den klassikern wie ut2004 oder gothic 2 und den üblichen verdächtigen.

[Undertaker]

hier soll es doch um die kernskalierung gehen und die lese ich aus dem gleichen takt heraus.

Genau das klappt eben nicht wegen der Grundlastproblematik. Beispiel: Ein Spiel erzeugt 2x1000MHz Grundlast. Habe ich einen 3x1000MHz Triplecore, hat dieser nur 1000MHz für die fps. Ein 4x1000MHz Quadcore wäre hier glatt doppelt so schnell wie der Triplecore (perfekte Quad-Auslastung vorausgesetzt). Für steigende Taktraten sinkt dieser Vorteil von 50% auf grenzwertmäßig 25%.

Vergleiche zur Kernskalierung sind somit immer nur bei gleicher Leistung, nicht bei gleichem Takt, sauber! Ansonsten verfälscht die Grundlast.

[dargo]

Ein allerletzter Versuch, ich glaub dann lassen wir das besser. ;)

1,47Ghz QC = 39,667fps
2,226Ghz DC = 39,8fps

36% OC:

1,47GHz * 1,36 = ~2GHz
2,226Ghz * 1,36 = ~3,03GHz

2GHz QC = 60,7fps
3,066Ghz DC = 54,28fps

Die letzten beiden fps-Werte sollten identisch sein, da wir zwei identisch schnelle CPUs um das gleiche Maß übertaktet haben. Der Dualcore ist aber langsamer, in einem Maß das über die Messtoleranz hinaus geht. Das widerspricht der Theorie unseres obigen Beispiels.
Jetzt verstehe ich was du meinst. Bevor ich aber eine falsche Theorie auftstelle muss ich noch was loswerden.

Das hat mir jetzt keine Ruhe gelassen und ich habe folgendes getestet:

2226Mhz DC mit 7x318 (Speicherteiler 2:2, sprich 318Mhz Speichertakt) = 37,667fps
2226Mhz DC mit 7x318 (Speicherteiler 2:2.40, sprich 382Mhz Speichertakt) = 40,067fps

Wenn der größere Speicherteiler schon alleine über 6% höhere Frames liefert können wir diese Werte hier vergessen:

1. 1,47Ghz = 23,767fps
2. 2,002Ghz = 35,1fps
3. 3,066Ghz = 54,28fps
4. 3,456Ghz = 59,8fps

Beim dritten Punkt hatte ich nur den Speicherteiler verringert, beim vierten Punkt zusätzlich noch einen größeren CPU-Multi gewählt wodurch noch ein größerer Flaschenhals entsteht. Beide Werte sind zu gering bei diesen Taktraten. Diese Werte sollten eigentlich höher ausfallen. Leider limitiert hier mein Board und Speicher wenn ich beim CPU-Multi von 7 bleiben will.

Ich werde mal einen anderen Test aufstellen wo das Verhältnis zwischen CPU-Multi, Speicherteiler und FSB immer gleich bleibt.

[Ph0b0ss]

Ein Beispiel zur Skalierung bei Taktverdoppelung:

Grundlast sind 500 Mhz und nicht parallelisierbar. Die fps-Berechnung ist in 2 gleichwertige Threads parallelisierbar (1:1). 100Mhz reichen für 1 fps. Einmal so gewählt, das beide CPUs die gleiche fps-Leistung bringen. Dann das Ganze nochmal jeweils mit doppeltem Takt.

http://www.abload.de/img/skalierung4g22.gif (http://www.abload.de/image.php?img=skalierung4g22.gif)

[Undertaker]

Ein Beispiel zur Skalierung bei Taktverdoppelung:

Grundlast sind 500 Mhz und nicht parallelisierbar. Die fps-Berechnung ist in 2 gleichwertige Threads parallelisierbar (1:1). 100Mhz reichen für 1 fps. Einmal so gewählt, das beide CPUs die gleiche fps-Leistung bringen. Dann das Ganze nochmal jeweils mit doppeltem Takt.

http://www.abload.de/img/skalierung4g22.gif (http://www.abload.de/image.php?img=skalierung4g22.gif)

Das ist aber so nicht ganz korrekt:

Wieso hat bei dir der Dualcore auf dem 2. Kern nicht 1250MHz und 2500MHz zur Verfügung? Da sagtest doch, dass die Grundlast nur auf einem Kern anliegt. Damit wäre er auch im ersten Beispiel schneller und der Grundsatz, dass wir zwei gleich schnelle CPUs betrachten und identisch hochtakten, wäre verletzt.

Jetzt verstehe ich was du meinst. Bevor ich aber eine falsche Theorie auftstelle muss ich noch was loswerden.

Das hat mir jetzt keine Ruhe gelassen und ich habe folgendes getestet:

2226Mhz DC mit 7x318 (Speicherteiler 2:2, sprich 318Mhz Speichertakt) = 37,667fps
2226Mhz DC mit 7x318 (Speicherteiler 2:2.40, sprich 382Mhz Speichertakt) = 40,067fps

Wenn der größere Speicherteiler schon alleine über 6% höhere Frames liefert können wir diese Werte hier vergessen:

1. 1,47Ghz = 23,767fps
2. 2,002Ghz = 35,1fps
3. 3,066Ghz = 54,28fps
4. 3,456Ghz = 59,8fps

Beim dritten Punkt hatte ich nur den Speicherteiler verringert, beim vierten Punkt zusätzlich noch einen größeren CPU-Multi gewählt wodurch noch ein größerer Flaschenhals entsteht. Beide Werte sind zu gering bei diesen Taktraten. Diese Werte sollten eigentlich höher ausfallen. Leider limitiert hier mein Board und Speicher wenn ich beim CPU-Multi von 7 bleiben will.

Ich werde mal einen anderen Test aufstellen wo das Verhältnis zwischen CPU-Multi, Speicherteiler und FSB immer gleich bleibt.

Mit so großen Differenzen dadurch hätte ich jetzt nicht gerechnet, aber immerhin haben wir jetzt einen Anhaltspunkt, woraus diese Abweichung resultieren könnte. Ich bin mal gespannt, was du mit einem gleichbleibendem Verhältnis bekommst. :)

[Ph0b0ss]

Das ist aber so nicht ganz korrekt:

Wieso hat bei dir der Dualcore auf dem 2. Kern nicht 1250MHz und 2500MHz zur Verfügung? Da sagtest doch, dass die Grundlast nur auf einem Kern anliegt. Damit wäre er auch im ersten Beispiel schneller und der Grundsatz, dass wir zwei gleich schnelle CPUs betrachten und identisch hochtakten, wäre verletzt.

Der fps-Thread ist in dem Beispiel nicht beliebig parallelisierbar, genauso wie es in der Realität oft vorkommt. Hier kann er auf 2 Threads aufgeteilt werden, welche aber voneinander soweit abhängig sind, das kein Thread von beiden schneller als der andere rechnen kann. Also ein festes 1:1 Verhältnis. Genauso ist es doch auch bei fast allen Spielen, dass z.B. Kern 1 zu 100% ausgelastet wird und der Kern 2 nur noch zu 50%, da es einfach nicht weiter parallelisierbar ist. Das gleiche gilt für noch mehr Kerne, halt nur noch schlimmer, je mehr.

[Undertaker]

Ob so eine Annahme realistisch ist weiß ich nicht... Zumindest würde dann ein anderer Punkt verletzt, den ich als Schluss ganz am Anfang getroffen habe:

Wenn deine Benches stimmen kann man wie oben geschrieben nur davon ausgehen, dass die Kernauslastung eben nicht immer konstant ist.

In deinem Fall wäre der 1,25GHz Quad zu 80% ausgelastet, der 2,5GHz Quad zu 90%.

[dargo]

Meine Fresse, war das ne schwere Geburt. :freak:
Ich hatte nämlich noch einen kleinen Fehler entdeckt - DIRT 2 hat die dumme Angewohntheit nach jedem neuen Laden der Strecke die Startauftstellung zu ändern. Dh., einmal stehe ich fast in der Mitte (links 5 Gegner, rechts 2), einmal ganz rechts (links alle Gegner) usw. Fast jedes Mal sieht man also einen leicht abweichenden Bildausschnitt. Ich habe mal den Unterschied gemessen - ergibt 3,5% Unterschied bei den Frames. :uhammer:

So, jetzt nach gefühlten tausend Ladevorgängen:crazy: der Strecke ergibt sich folgendes Bild:

http://img99.imageshack.us/img99/3720/dirt2test.png

Diesmal gibts in jeder Situation den CPU-Multi 8 und einen Speicherteiler von 2:2. Der CPU-Takt wird nur über den FSB geändert.


Edit:
@Undertaker

Unsere Theorie bewahrheitet sich auch hier nicht. Und ich habe schon eine Vermutung woran es liegt. Hierbei:
In beiden Fällen haben die CPUs die gleichen Resourcen für die Framesberechnung zur Verfügung. Fall 1 - 5Ghz zu 5Ghz und Fall 2 - 11Ghz zu 11Ghz. Trotzdem werden beide CPUs im zweiten Fall 220fps liefern wenn beide im ersten Fall 100fps berechnen können.

haben wir denke ich den Fehler gemacht die Taktraten der einzelnen Kerne zu addieren. Das würde nur zutreffen wenn die Engine alle 4 Kerne zu 100% auslasten könnte. Wie ich dazu komme?
Schauen wir uns mal die einzelnen DC-Werte an:

1. 1680Mhz DC = 24,067fps
2. 2496Mhz DC = 39,200fps
3. 2928Mhz DC = 48,433fps

Von 1 zu 2 erhöht sich die Taktrate um 48,57%, die Framerate um 62,87%. Von 2 zu 3 erhöht sich die Taktrate um 17,30% während die Framerate um 23,55% steigt. Im Verhältnis nimmt also die Skalierung mit höherem Takt zu, was ja im Einklang mit unserer Theorie ist. Ich gehe jetzt davon aus, dass ein DC auf beiden Kernen zu 100% ausgelastet wird.

[Undertaker]

Auch in unserer Rechnung sind wir davon ausgegangen, dass sich ein Quadcore nur zu 75% auslasten lässt. ;) Der Knackpunkt ist hier, dass sich die Auslastung mit steigender Taktrate zu verbessern scheint (bzw. nein, sie muss sogar, anders kann es hier nicht zu einer Differenz kommen) - das erschien mir zunächst merkwürdig.
Möglicherweise hat Phoboss aber mit dem Grundzug seiner Theorie recht: Bei abhängigen Threads für die fps-Berechnung wird eine CPU mit mehr Kernen speziell bei niedrigen Taktraten mehrfach "bestraft", in seinem Beispiel büßten beide Kerne den durch die Grundlast beanspruchten Takt ein, der Single-Core nur einmal. Mit steigendem Takt sinkt der Einfluss der Grundlast auf die zur Verfügung stehende Leistung, diese "Benachteiligung" des Quads verliert an Bedeutung und das Leistungsverhältnis verschiebt sich pro QC.

Das aber wirklich rein spekulativ als mögliche Ursache, etwas besseres will mir aber auch nicht einfallen. ;)

Siehe 2 Postings weiter. ;)

[dargo]

Der Knackpunkt ist hier, dass sich die Auslastung mit steigender Taktrate zu verbessern scheint (bzw. nein, sie muss sogar, anders kann es hier nicht zu einer Differenz kommen) - das erschien mir zunächst merkwürdig.

Ironischerweise ist es bei meinem letzten Test genau andersrum. :freak:


Möglicherweise hat Phoboss aber mit dem Grundzug seiner Theorie recht: Bei abhängigen Threads für die fps-Berechnung wird eine CPU mit mehr Kernen speziell bei niedrigen Taktraten mehrfach "bestraft", in seinem Beispiel büßten beide Kerne den durch die Grundlast beanspruchten Takt ein, der Single-Core nur einmal.

Warum eigentlich?


Mit steigendem Takt sinkt der Einfluss der Grundlast auf die zur Verfügung stehende Leistung...

Hier sind wir uns einig. :D


...diese "Benachteiligung" des Quads verliert an Bedeutung und das Leistungsverhältnis verschiebt sich pro QC.

Hierbei verliere ich den Überblick. :tongue:

[Gast]

mmh dargo, mal ein grosses lob für dich, tolle tabellen :)

[Undertaker]

Oh Gott sry, vergiss mein letztes Posting mal lieber wieder... :freak: Als wäre es nicht schon kompliziert genug hab ich verdreht, dass nach deinen neuen Werten ja jetzt der Dualcore besser skaliert...

Nun, im Umkehrschluss bedeutet dass jetzt, dass der Quad mit steigendem Takt immer schlechter ausgelastet werden kann. Spontan würde ich da jetzt vermuten, dass wir die Theorie genau umkehren müssen:

Stellen wir uns vor, die Grundlast ist gerade besonders gut parallelisierbar, beträgt 1000MHz und kann z.B. auf 4 Threads á 250MHz aufgeteilt werden. Die fps können nur auf zwei vollständig ausgelasteten Kernen berechnet werden (alles nur beispielhafte Extremwerte, damit es deutlicher wird). 100MHz ermöglichen 1fps. Ergibt:

1000MHz QC: 4x250MHz für Grundlast -> 2x750MHz für fps: 15fps
1250MHz DC: 2x500MHz für Grundlast -> 2x750MHz für fps: 15fps

Nun 100% OC auf beide:

2000MHz QC: 4x250MHz für Grundlast -> 2x1750MHz für fps: 35fps
2500MHz DC: 2x500MHz für Grundlast -> 2x2000MHz für fps: 40fps

In einem solchen Szenario kann man erkennen: Da stärker parallelisierbare Bestandteil, die Grundlast, nimmt mit höherem Takt an Bedeutung ab. Ergo sinkt die Auslastung jener CPU am stärksten, die über die meisten Kerne verfügt -> die Skalierung mit einer Takterhöhung sinkt im Vergleich.

[dargo]

Die Verwirrung wird immer größer. ;D

Was ich mich nach dieser neuen Erkenntnis gerade frage - wozu lote ich eigentlich in meinen Tests aus wie hoch ich den DC takten muss um mit dem QC gleichzuziehen wenn die Skalierung eh vom Takt abhängig ist und sich halt ändert? :|
Im Prinzip sagt diese Auslotung nichts über die Auslastung vom Quad aus. :freak:

[Undertaker]

Tja, genau das war ja der Ausgangspunkt meiner Verwunderung, die die ganze Diskussion hier losgetreten hat. :freak: Entgegen (zumindest meiner) vorherigen Ansicht lassen sich allgemeine Aussagen zu QC-Profiten bzw. ganz allgemein dem Parallelisierungsgrad eines Spiels nur äußerst grob in allgemeiner Form treffen. Es sind sowohl Fälle denkbar, in denen eine auf den ersten Blick gute Quadcore-Skalierung mit höheren Taktraten deutlich abnimmt, als auch der genau entgegengesetzte Fall. Definitive Schlüsse sind nur für konkrete Fälle möglich, insofern ist es gut, dass du bisher jedes Spiel schon auf zwei verschiedenen Taktstufen getestet hast. :)

Zu resümieren bleibt also, dass man sich in jedem Fall auf ein möglichst praxisrelevantes Setting beschränken sollte (also Taktraten von 3-4GHz), was allerdings selbst in kleinsten Auflösungen in vielen Spielen zum GPU-Limit führen könnte - kein Ei des Columbus also, das muss ich eingestehen. Ein Test zur Kernskalierung speziell mit sehr niedrigem Takt birgt zumindest immer die Gefahr, selbst bei peinlich genauer Kontrolle aller Skalierungsfaktoren wie beispielsweise FSB, Speichertakt usw., einen nicht unerheblichen systematischen Fehler mitzuschleppen.

So, ich glaub solangsam haben wir das jetzt umfassend genug untersucht. Nen schönen Abend noch an alle. :D

[dargo]

Zu resümieren bleibt also, dass man sich in jedem Fall auf ein möglichst praxisrelevantes Setting beschränken sollte (also Taktraten von 3-4GHz), was allerdings selbst in kleinsten Auflösungen in vielen Spielen zum GPU-Limit führen könnte - kein Ei des Columbus also, das muss ich eingestehen.
Das wäre noch ein lösbares Hindernis, eine schnellere Graka müsste nur her. Das größte Problem hierbei ist allerdings - wie soll ich einen DC dann auch 6-8Ghz hochtakten? :freak:
Wobei ich nicht glaube, dass die von mir niedrig gewählten Taktraten das Problem sind. Wie gesagt, solange man im gleichen Maße den Speicherteiler und CPU-Multi mit dem FSB ändert sollte der Flaschenhals immer gleich groß sein.

[Undertaker]

Das wäre noch ein lösbares Hindernis, eine schnellere Graka müsste nur her. Das größte Problem hierbei ist allerdings - wie soll ich einen DC dann auch 6-8Ghz hochtakten? :freak:

Tja, da scheitert es dann irgendwie...

Wobei ich nicht glaube, dass die von mir niedrig gewählten Taktraten das Problem sind. Wie gesagt, solange man im gleichen Maße den Speicherteiler und CPU-Multi mit dem FSB ändert sollte der Flaschenhals immer gleich groß sein.

Schon klar - aber wir vermuten ja, dass durch unterschiedliche Parallelisierbarkeit von Grundlast und "fps-Berechnung" selbst bei genauer Beachtung deiner gerade genannten Punkte je nach Takt verschiedene Ergebnisse heraus kommen können.

Auf Dirt 2 bezogen:

Bei einem 1,68GHz QC muss ein DC für gleiche Leistung noch fast 50% höher takten. Bei einem 2,1GHz QC sind es nur noch etwa 40%. Womöglich braucht man bei einem 3GHz QC dann nur noch einen 20% schnelleren DC, d.h. ein 3,6GHz E8400 wäre schon so schnell wie ein Q9650? Ganz so extrem wirds wohl nicht sein, aber nur um die Tendenz zu verdeutlichen. Zumindest die erkennt man ja auch, wenn man sich deine bisher genutzten 1470/2002MHz Benches anschaut. Für eine allgemeine Aussage, ob wir in einem Spiel einen brauchbaren MC-Support haben, finde ich die immernoch top. :)

[dargo]

Auf Dirt 2 bezogen:

Bei einem 1,68GHz QC muss ein DC für gleiche Leistung noch fast 50% höher takten. Bei einem 2,1GHz QC sind es nur noch etwa 40%. Womöglich braucht man bei einem 3GHz QC dann nur noch einen 20% schnelleren DC, d.h. ein 3,6GHz E8400 wäre schon so schnell wie ein Q9650? Ganz so extrem wirds wohl nicht sein, aber nur um die Tendenz zu verdeutlichen.

Das wäre in der Tat interessant zu sehen. Ich versuche mal das nachzustellen. Hab eh nichts besseres dank Krankenschein zu tun. :D
Ich hoffe bloß, dass bei 3Ghz QC meine GPU nicht schon limitiert, sonst bringt es ja nichts.

Edit:
Oh man, ich merke jetzt erst, dass DIRT 2 einen Framelimiter von 60fps hat. :uhammer:
Vergesst ganz schnell das DIRT2-Diagramm im ersten Post. Ich nehms wieder raus bis mir was dazu einfällt.

Edit 2:
@Undertaker
Es ist unglaublich wie stark der FSB und die Speicherbandbreite beim C2D/C2Q limitiert (umso erstaunlicher, dass der Yorkfield noch so gut mit einem Phenom 2 mithalten kann). Ich habe mal folgendes mit CoD: MW2 getestet:

8,5*236Mhz FSB (2006Mhz CPU-Takt) mit Speicherteiler 2:2, sprich 236Mhz Speichertakt = 55,35fps
7,0*286Mhz FSB (2002Mhz CPU-Takt) mit Speicherteiler 2:2.40, sprich 343Mhz Speichertakt = 73,40fps (siehe Diagramm im ersten Post)

Das sind im zweiten Fall +~33% mehr Leistung. :eek: Jetzt wissen wir auch woher der Großteil der höheren Pro/Mhz-Leistung beim i5/i7 kommt. :cool:
Ich werde mal mein Testsetup ändern. Denn dadurch, dass es zu so einem enormen Unterschied kommt kann ich auch 2833Mhz QC (8,5x333Mhz FSB) in mein Testsetup aufnehmen (also so wie man die CPU auch kaufen kann) ohne Angst haben zu müssen ins GPU-Limit zu rutschen.

[Ph0b0ss]

8,5*236Mhz FSB (2006Mhz CPU-Takt) mit Speicherteiler 2:2, sprich 236Mhz Speichertakt = 55,35fps
7,0*286Mhz FSB (2002Mhz CPU-Takt) mit Speicherteiler 2:2.40, sprich 343Mhz Speichertakt = 73,40fps (siehe Diagramm im ersten Post).

Hast du das gleiche auch mal mit nur 2 Kernen getestet? Falls es da nicht so krasse Leistungsunterschiede gibt, würde das ja theoretisch bedeuten, das beim i7 oder beim Phenom, dank wegfallendem FSB bzw. deutlich größerer Speicherbandbreite, die Skalierung Dualcore vs. Tripple-/Quadcore noch deutlich besser sein könnte, als bei den Messungen mit deinem C2D!

[dargo]

Hast du das gleiche auch mal mit nur 2 Kernen getestet? Falls es da nicht so krasse Leistungsunterschiede gibt, würde das ja theoretisch bedeuten, das beim i7 oder beim Phenom, dank wegfallendem FSB bzw. deutlich größerer Speicherbandbreite, die Skalierung Dualcore vs. Tripple-/Quadcore noch deutlich besser sein könnte, als bei den Messungen mit deinem C2D!
Die Ergebnisse sind erstmal unter Vorbehalt. Ich muss mein Win7 neu aufsetzten weil:
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=7707208&postcount=494

:freak:

Dh. die DIRT2 und CoD: MW2 Benches werden auf jeden Fall wiederholt. Aus unerklärlichen Gründen macht mein System völlig wirres Zeug was die CPU-Leistung angeht. :|

Edit:
So, jetzt mit einem sauberen System ist wieder alles in Butter. Und hier die Ergebnise:

QC:
8,5*236Mhz FSB (2006Mhz CPU-Takt) mit Speicherteiler 2:2, sprich 236Mhz Speichertakt = 56,65fps
7,0*286Mhz FSB (2002Mhz CPU-Takt) mit Speicherteiler 2:2.40, sprich 343Mhz Speichertakt = 66,55fps

DC:
8,5*236Mhz FSB (2006Mhz CPU-Takt) mit Speicherteiler 2:2, sprich 236Mhz Speichertakt = 41,90fps
7,0*286Mhz FSB (2002Mhz CPU-Takt) mit Speicherteiler 2:2.40, sprich 343Mhz Speichertakt = 51,05fps

Interessant, dass der Flaschenhals beim DC etwas größer ist.

[Undertaker]

Der Dualcore liegt im niedrigeren fps-Bereich, damit schlagen Leistungssteigerungen Grundlastbedingt generell stärker an. Ist doch das Gleiche wie bei einer Takterhöhung. :)

[Ph0b0ss]

Hab auch mal eine kleinen Test mit COD MW2 gemacht:

http://www.abload.de/img/cod_mw2ys6m.gif (http://www.abload.de/image.php?img=cod_mw2ys6m.gif)

[dargo]

Der Dualcore liegt im niedrigeren fps-Bereich, damit schlagen Leistungssteigerungen Grundlastbedingt generell stärker an. Ist doch das Gleiche wie bei einer Takterhöhung. :)
Lol, daran habe ich jetzt gar nicht gedacht. :freak:
Dann takte ich mal den langsameren DC erstmal so hoch, dass er auf die 56,xxfps vom langsameren QC kommt.

Hab auch mal eine kleinen Test mit COD MW2 gemacht:

http://www.abload.de/img/cod_mw2ys6m.gif (http://www.abload.de/image.php?img=cod_mw2ys6m.gif)
Ich weiß zwar nicht wie fordernd deine Szene war, ist aber lustig zu sehen, dass selbst ein 2Ghz i7 mit nur 2 Kernen die 60fps locker halten kann. ;D

Edit:
So schnell wendet sich das Blatt:

QC:
8,5*236Mhz FSB (2006Mhz CPU-Takt) mit Speicherteiler 2:2, sprich 236Mhz Speichertakt = 56,65fps
7,0*286Mhz FSB (2002Mhz CPU-Takt) mit Speicherteiler 2:2.40, sprich 343Mhz Speichertakt = 66,55fps

DC:
8,5*236Mhz FSB (2006Mhz CPU-Takt) mit Speicherteiler 2:2, sprich 236Mhz Speichertakt = 41,90fps
7,0*286Mhz FSB (2002Mhz CPU-Takt) mit Speicherteiler 2:2.40, sprich 343Mhz Speichertakt = 51,05fps

DC:
8,5*300Mhz FSB (2550Mhz CPU-Takt) mit Speicherteiler 2:2, sprich 300Mhz Speichertakt = 57,10fps
7,0*364Mhz FSB (2548Mhz CPU-Takt) mit Speicherteiler 2:2.40, sprich 437Mhz Speichertakt = 62,75fps

Man oh man, was man alles bei CPU-Tests berücksichtigen muss. :freak:
Gott sei Dank hat das ganze hier keine Auswirkung auf meine Tests. Ich weiß schon warum ich nur über den FSB skaliere. ;)

[Ph0b0ss]

Ich weiß zwar nicht wie fordernd deine Szene war, ist aber lustig zu sehen, dass selbst ein 2Ghz i7 mit nur 2 Kernen die 60fps locker halten kann. ;D

Ist vom Akt I "die alte Leier", da wo die ganze Mannschaft vor einem steht und im Hintergrund welche Basketball spielen. Also Level geladen und nicht bewegt und fps genommen, als sie stabil waren.

[dargo]

Das gibts ja gar nicht. Ihr werdet nicht glauben was mein System ausgebremst hat. Es war folgendes Setting im CP. :ulol: :crazy2:

http://www2.pic-upload.de/thumb/09.12.09/smdcn1asmbib.png (http://www.pic-upload.de/view-3906711/CP.png.html)

bei den anderen drei Skalierungssettings sind die Frames wieder in Ordnung. :ugly:

[dargo]

mmh dargo, mal ein grosses lob für dich, tolle tabellen :)
Danke. :)

Ich habe das Testsetup jetzt geändert. Damit kann man denke ich mehrere Sachen ableiten.

Los gehts mit CoD: MW2.
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=6973305&postcount=2

@Undertaker
Jetzt habe ich alle möglichen Fehlerquellen ausgeschaltet. Der Witz ist, dass sogar dieses Setting hier:
http://www2.pic-upload.de/thumb/10.12.09/faxn3dqn2icg.png (http://www.pic-upload.de/view-3912845/CP1.png.html)

zu leichten Abweichungen führen kann.

Maximale Leistung bevorzugen ist im niedrigen fps-Bereich um 3,5% bei mir schneller gewesen als Adaptiv. :freak:

Somit werde ich jetzt grundsätzlich ersteres für Benchmarks nutzen, natürlich sind auch sämliche Stromsparmechanismen bei der CPU deaktiviert. Ich muss dazu noch was loswerden - es ist verdammt schwer mit Savegames bei CoD: MW2 und DIRT 2 zu arbeiten. Besonders in tieferen fps-Bereichen schwanken ständig die einzelnen Ergebnise. Und zwar so stark, dass man dies keinesfalls in die Kategorie Messtoleranz abschieben könnte. Ich habe dafür schon eine brauchbare Lösung gefunden - einfach ca. 1Min. das zu testende Savegame durchspielen. Es hört sich verrückt an, scheint aber so als ob sich das Spiel erstmal an die CPU-Leistung gewöhnen müsste (Streamingprobleme?). :|
Es kommt dann zwar immer noch vereinzelt zu stark abweichenden Ergebnisen, aber deutlich seltener. Ich nehme natürlich immer nur die Ergebnise für meine Diagramme wo es zu keinen nennenswerten Abweichungen kommt. Man könnte auch sagen immer die höchsten avg.fps.

Edit:
Wie man aber sieht gibts hier auch eine Abweichung die unsere Theorie in Frage stellt. Die 1768Mhz QC und 2210Mhz DC liegen gleichauf. Beide CPUs um 25% übertaktet ergeben nicht das selbe Ergebnis bei den Frames. Den DC musste ich schon um ~34% übertakten um mit den 2210Mhz QC gleichzuziehen. Ich bin aber immer noch der Meinung, dass die Grundlast dafür verantwortlich ist. Wie man sieht ist im oberen fps-Bereich (also weiter vom Störfaktor Grundlast entfernt) der 2833Mhz QC auch um ~34% schneller als der 2833Mhz DC. Schauen wir mal ob dieses Verhalten auch bei anderen Games auftritt.

[y33H@]

Das "gewöhnen" ist keine Seltenheit ;(

[dargo]

Das "gewöhnen" ist keine Seltenheit ;(
Ja, das ist sehr ärgerlich und man muss höllisch aufpassen, sonst bencht man sich nur Müll zusammen. Wobei dieses "gewöhnen" imo nur bei tieferen Frames verstärkt auftritt.

[Undertaker]

Edit:
Wie man aber sieht gibts hier auch eine Abweichung die unsere Theorie in Frage stellt. Die 1768Mhz QC und 2210Mhz DC liegen gleichauf. Beide CPUs um 25% übertaktet ergeben nicht das selbe Ergebnis bei den Frames. Den DC musste ich schon um ~34% übertakten.

Das wäre jetzt doch aber wieder genau die entgegengesetzte Entwicklung wie im letzten Test, wo man den QC prozentual stärker übertakten musste, um eine gleiche Leistung beizubehalten? Nicht, dass letztlich alle Besonderheiten, die wir hier meinen per "Messung" auszumachen, auf mehr oder minder starke Schwankungen des Benchmarks zurückzuführen sind...?

[dargo]

Das wäre jetzt doch aber wieder genau die entgegengesetzte Entwicklung wie im letzten Test, wo man den QC prozentual stärker übertakten musste, um eine gleiche Leistung beizubehalten? Nicht, dass letztlich alle Besonderheiten, die wir hier meinen per "Messung" auszumachen, auf mehr oder minder starke Schwankungen des Benchmarks zurückzuführen sind...?
Warte bis ich mit DIRT2 fertig bin. Vorher haben wir uns auf DIRT 2 bezogen. Ich kann nämlich beim letzten DIRT 2-Test aufgrund von meinem künstlichen Vsync. (http://www.forum-3dcenter.org/vbulletin/showpost.php?p=7708023&postcount=239) keine Messfehler ausschließen.

[Undertaker]

Hatte übersehen, dass du nicht mehr bei Dirt sondern bei CoD warst. Btw, das neue Testsetup gefällt mir sehr gut. :)

[dargo]

Ok, DIRT 2 ist nun fertig.
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=6973305&postcount=2

Lustigerweise ist es in diesem Spiel genau andersrum. :freak:
Messfehler ausgeschlossen - nachdem sich das Game "eingewöhnt" hat sind die einzelnen Ergebnisse bombenstabil.

[dargo]

Resident Evil 5 ist nun soweit:
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=6973305&postcount=2

RE5 ist das Paradebeispiel schlechthin um zu sehen wie sinnlos der Taskmanager ist, wenns um die CPU-Auslastung geht.

http://img23.imageshack.us/img23/7226/re5o.th.png (http://img23.imageshack.us/i/re5o.png/)

Hier sieht man wunderbar wie wenig davon in die Frames fließt. Dabei wurde hier im Forum die RE5-Engine so in Bezug auf Multithreading gelobt. Ähnliches konnte ich schon bei Timeshift beobachten. Ich möchte zu gern wissen womit die CPU da beschäftigt ist. Die Framerate ist es jedenfalls nicht.

[Ph0b0ss]

@dargo

Wie hast du genau bei Resident Evil 5 DX9 gemessen? Einfach Kapitel 1 'Die öffentliche Versammlung' geladen und nicht bewegt? Möchte das mal mit dem i7 nachstellen und gucken, ob die Quad-Skalierung genauso ist wie bei deinem C2Q.

[dargo]

@dargo

Wie hast du genau bei Resident Evil 5 DX9 gemessen? Einfach Kapitel 1 'Die öffentliche Versammlung' geladen und nicht bewegt? Möchte das mal mit dem i7 nachstellen und gucken, ob die Quad-Skalierung genauso ist wie bei deinem C2Q.
Nee, so einfach ist es nicht. Puh... wie soll ich es am besten beschreiben? :uponder:

Augenblick...

Edit:
Ich glaube so ist es am einfachsten - sichere dir erstmal deine Savegames. Dann ersetze sie mit meinen:
35861

Wenn du im Spiel bist einfach auf "Spiel fortsetzen" gehen. So fängt mein Savegame an:
http://www2.pic-upload.de/thumb/12.12.09/3w1cztivrwrn.jpg (http://www.pic-upload.de/view-3930195/RE5DX9-2009-12-12-16-04-28-80.jpg.html)

Noch wird nichts gebencht. Du gehst erstmal den Weg entlang, springst einmal runter und gehst in dieses Haus:
http://www2.pic-upload.de/thumb/12.12.09/b336j6x6vtiq.jpg (http://www.pic-upload.de/view-3930196/RE5DX9-2009-12-12-16-05-00-07.jpg.html)

Sobald du im Haus bist läuft eine Zwischensequenz. Diese überspringst du mit Esc. Danach nicht bewegen. Die Benchtaste drückst du erst wenn der erste Zombie die Fensterscheibe zerstört. Benchdauer mit Fraps 5 Sekunden. Das ganze insgesamt 4x wiederholen (Esc und über Menü neustarten). Die avg.fps dürfen kaum von einander abweichen (ca. 0,5fps ist normal). Dann nimmst du den Durchschnitt der vier avg.fps Messungen.

Edit:
Wichtig:
Achtung: Der "JobThread" in der config.ini von Resident Evil 5 muss mindestens der Kernanzahl minus eins entsprechen!

Quelle (http://www.pcgameshardware.de/aid,690425/CPU-Benchmarks-von-Resident-Evil-5-Core-i7-fuehrt-Phenoms-trotzdem-stark-Update-mit-Core-i5-750-und-Core-i7-860/Action-Spiel/Test/)

[Ph0b0ss]

Achtung: Der "JobThread" in der config.ini von Resident Evil 5 muss mindestens der Kernanzahl minus eins entsprechen!

Steht bei mir logischerweise auf 7. Hast du den bei Tests mit weniger als voller Kernzahl verringert?