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

[dargo]

Steht bei mir logischerweise auf 7. Hast du den bei Tests mit weniger als voller Kernzahl verringert?
Ich hab den JobThread immer auf die jeweilige Kernzahl gesetzt:

DC - JobThread = 2
TC - JobThread = 3
QC - JobThread = 4

[Ph0b0ss]

@dargo

Hab jetzt mit deinen Einstellungen getestet:

Core i7 @1768Mhz (136x13) Uncore=2176Mhz Ram=1088 Mhz 8-8-8-21 6GB Tripple

Ergebnis:

2 Core (ohne HT): 58,7fps
4 Core (ohne HT): 101,6fps

Edit:
Core i7 @3276Mhz (182x18) Uncore=2184Mhz Ram=1092 Mhz 8-8-8-21 6GB Tripple

2 Core (ohne HT): 103,1fps

Tests mit mehr Takt gehen leider nicht, da das Spiel bei 120fps begrenzt!

[dargo]

Interessant. Wie hoch muss die Taktrate beim DC sein um die ~102fps zu erreichen?

Edit:
Hmm... das heißt also der i7 skaliert mit 4 Cores erheblich besser. Wenn ich mir die Benchmarks der PCGH hier ansehe:
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/

scheint der Phenom II X4 945 taktbereinigt mit den zwei zusätzlichen Cores um ca. 55% schneller zu sein als der Phenom II X2 550.

Bei mir sinds nur +~37% und bei dir gleich +~73%. Der DC muss sogar um ~85% übertaktet werden um mit dem QC gleichzuziehen. Wie kommt das? Limitiert beim Yorkfield der FSB und die Speicherbandbreite wirklich so stark? :|

Edit 2:
Mit Bedauern muss ich feststellen, dass die ganze Arbeit mit dem Quadcore umsonst war. :(
Der FSB und/oder die Speicherbandbreite limitieren dermaßen stark beim QC S775, dass er gar nicht zeigen kann was in einer echten Multithreading-Engine steckt. ;(

Hier mein Beispiel an Resident Evil 5:
QC 2210Mhz (8,5x260Mhz FSB), Speichertakt 260Mhz = 71,15fps
DC 2210Mhz (8,5x260Mhz FSB), Speichertakt 260Mhz = 51,30fps

QC-Vorteil von knapp 39%. Da wir uns eigentlich mit den 2208Mhz im höheren fps-Bereich befinden sinds eigentlich nur noch ~37% Vorteil (siehe Diagramm auf der ersten Seite).
--------------------------------------------------------------
QC 2208Mhz (6x368Mhz FSB), Speichertakt 442Mhz = 93,20fps
DC 2208Mhz (6x368Mhz FSB), Speichertakt 442Mhz = 62,15fps

QC-Vorteil von nahezu 50%.

Den i5/i7 muss ich mir wohl schneller zulegen als mir lieb ist. Ich werde weitere Benchmarks somit erstmal einstellen.

Edit 3:
Hier noch ein schönes Beispiel der Limitierung:

QC 2652Mhz (6x442Mhz FSB), Speichertakt 442Mhz = 103,35fps
DC 2652Mhz (6x442Mhz FSB), Speichertakt 442Mhz = 65fps

QC-Vorteil von 59%!

[Ph0b0ss]

[B]Mit Bedauern muss ich feststellen, dass die ganze Arbeit mit dem Quadcore umsonst war. :(

Finde ich gar nicht! Du hast mit Savegames sehr gut gezeigt, was für Vorteile ein Quad gegenüber einem Dual haben kann. Solche realistischen Savegametests findet man praktisch gar nicht im Netz. Außerdem zeigen die Tests gut, was man real mit einem Sockel 775 System zu erwarten hat, wenn man von Dual auf Quad aufrüsten möchte (und das hier einen hoher FSB/Speichertakt wichtiger ist, als gedacht). Gibt ja noch sehr viele User mit Sockel 775.

Außerdem ist es eine Schweinearbeit, so ein paar Savegametest zu machen, wie ich gestern selbst gemerkt habe. Gar nicht so einfach dabei keine Fehler zu machen (hat man schnell mal ne falsche Einstellung drin beim herumtakten /ini-Einstellungen /GPU-Einstellungen)!:freak:

Den i5/i7 muss ich mir wohl schneller zulegen als mir lieb ist. Ich werde weitere Benchmarks somit erstmal einstellen.

Ist die Frage, der i7 Skaliert wohl mit deutlich weniger Verlusten, aber die Skalierungsmöglichkeiten der Engine 1:1 wiedergeben kann er wohl auch nicht. Gut man könnte auf sehr niedrigen Takt DDR3-2000+ Tripple draufknallen, das würde das Problem abschwächen. Nur wird dann der L3 extrem übertaktet, was wiederum die Praxisnähe einschränkt. Naja zum zocken der Konsolenports brauchste jedenfalls kein neues System.:freak:

Edit:

Im Prinzip müsste man alle Tests 4 mal machen. Einmal quasi simuliert um die Engine-Skalierungsmöglichkeiten ohne bremsende Flaschenhälse zu zeigen (dann auch über 4 Kerne hinaus). Dann noch jeweils einmal in der Praxis auf C2Q, Phenom II X4 und i7 Systemen um zu sehen, was davon in der Realität ankommt.

[dargo]

Ist die Frage, der i7 Skaliert wohl mit deutlich weniger Verlusten, aber die Skalierungsmöglichkeiten der Engine 1:1 wiedergeben kann er wohl auch nicht.

Nun, wenn ich mir den Taskmanager bei mir in unserem RE5-Savegame anschaue dann bedeutet das rechnerisch, dass ca. 87,5% von einem Quadcore ausgelastet werden. Und das deckt sich ziemlich genau mit deinen Ergebnissen wo du den DC um ~85% übertakten musst.

Naja zum zocken der Konsolenports brauchste jedenfalls kein neues System.
Das ist mir schon klar. Die Frames ansich sind in jedem Game (zumindest meinem Genre) mit 3,7Ghz praktisch immer auf min. 60fps. Mir geht es eher ums Prinzip - was nützen mir 4 Kerne die in Games nie vernünftig ausgelastet werden können.

[Ph0b0ss]

Nun, wenn ich mir den Taskmanager bei mir in unserem RE5-Savegame anschaue dann bedeutet das rechnerisch, dass ca. 87,5% von einem Quadcore ausgelastet werden. Und das deckt sich ziemlich genau mit deinen Ergebnissen wo du den DC um ~85% übertakten musst.

Mit HT komme ich an der Stelle auf eine Auslastung von 50-55% bei JobThread=8. Also minimal mehr als 4 Kerne werden genutzt. Es werden auch an anderen Stellen meistens der Virtuelle-Kern 1 der 4 Kerne fast voll ausgelastet + Virtuelle-Kern 2 von Kern 1+2 mit leichter Auslastung (10-40%).

[dargo]

Der Witz an der Sache ist ja, dass der Taskmanager beim i5/i7 durchaus eine Aussagekraft über die Kernauslastung hat. Beim Yorkfield sagt der TM rein gar nichts aus. :freak:
Ich habe noch eine sehr gute Szene aus Timeshift im Kopf. Ich hatte mal mit 4 Cores mir den Taskmanager angeschaut. Alle Kerne fast am Anschlag. Dann habe ich die gleiche Szene mit einem gleichgetakteten DC gebencht und mich gewundert warum dieser kaum langsamer ist. Jetzt wissen wir es - extreme FSB/Bandbreitenlimitierung beim S775 QC. :usad:

[Ph0b0ss]

Durch das Doppel-Dualcore-Design geht sicher auch schon ordentlich was an Performance verloren. Gerade bei Spielen, wo viele Berechnungen Ergebnisse von vorigen Berechnungen benötigen, muss warscheinlich ne Menge von einem Dualcore zum anderen über den Bus geschickt werden.:freak:

[dargo]

Durch das Doppel-Dualcore-Design geht sicher auch schon ordentlich was an Performance verloren. Gerade bei Spielen, wo viele Berechnungen Ergebnisse von vorigen Berechnungen benötigen, muss warscheinlich ne Menge von einem Dualcore zum anderen über den Bus geschickt werden.:freak:
Jep, das sehe ich exakt auch so.

[BeetleatWar1977]

Jep, das sehe ich exakt auch so.
Nur mal der Gedankengang: Den QC bei dem doppelten FSB des DC benchen um den Flaschenhals zu eleminieren? :freak:
schließlich braucht die doppelte Menge an Kernen ja auch die doppelte Menge an Daten!

[dargo]

Nur mal der Gedankengang: Den QC bei dem doppelten FSB des DC benchen um den Flaschenhals zu eleminieren? :freak:
schließlich braucht die doppelte Menge an Kernen ja auch die doppelte Menge an Daten!
So einfach ist es nun auch nicht. Nur weil ein zusätzlicher DC angeflanscht ist heiß es noch lange nicht, dass die doppelte Datenmenge am FSB für die Kommunikation zwischen den beiden DCs ansteht. Außerdem begrenzt der kleinste CPU-Multi von 6 eine Verdoppelung vom FSB. Einen 1768Mhz DC (8,5x208) mit einem 2496Mhz QC (6x416) zu vergleichen macht ja überhaupt keinen Sinn. Und den FSB zu erhöhen reicht auch nicht. Die Speicherbandbreite müsste auch noch angepasst werden.
Wie man sich wendet und dreht - ein S775 QC ist leider ungeeignet um die Multithreading-Stärken einer Engine zu zeigen.

[BeetleatWar1977]

Vielleicht mal andersrum denken, du schaltest doch zum Testen bei deinem Quad 2 Kerne ab oder?
Wenn ja welche?

[dargo]

Vielleicht mal andersrum denken, du schaltest doch zum Testen bei deinem Quad 2 Kerne ab oder?
Wenn ja welche?
Ich weiß worauf du hinaus willst. Du kannst beim DC nicht einfach den Core 0 und 2 nutzen. Das verhindert allein schon Windows. Es sieht so aus:

DC = Core 0+1
TC = Core 0+1+2 (zusätzlich also der erste Core vom zweiten Dualcore)
QC = 0+1+2+3

Windows interpretiert die Cores nur etwas anders:
Core 0+1 = in Windwos 1+2
Core 2+3 = in Windwos 3+4

[BeetleatWar1977]

Ich weiß worauf du hinaus willst. Du kannst beim DC nicht einfach den Core 0 und 2 nutzen. Das verhindert allein schon Windows. Es sieht so aus:

DC = Core 0+1
TC = Core 0+1+2 (zusätzlich also der erste Core vom zweiten Dualcore)
QC = 0+1+2+3

Windows interpretiert die Cores nur etwas anders:
Core 0+1 = in Windwos 1+2
Core 2+3 = in Windwos 3+4
und da liegt auch noch ein Problem:
Den Quad hat 2x6MB Cache wenn ich mich nicht irre
Core 0+1 Cache1
Core 2+3 Cache2

Das verhunzt die TC-Werte total.

Äh - moment mal. Ich kann im Bios die einzelnen Cores ausschalten (also unabhängig vom Windows), geht das bei deinem Board auch? Wenn ja probier mal 0+2 vielleicht sind die Werte dann aussagekräftiger;)

[dargo]

und da liegt auch noch ein Problem:
Den Quad hat 2x6MB Cache wenn ich mich nicht irre
Core 0+1 Cache1
Core 2+3 Cache2

Das verhunzt die TC-Werte total.

Dass beim TC dem dritten Core die vollen 6MB Cache zur Verfügung stehen ist lange bekannt. Das eigentliche Problem ist aber hier nicht der TC.


Äh - moment mal. Ich kann im Bios die einzelnen Cores ausschalten (also unabhängig vom Windows), geht das bei deinem Board auch? Wenn ja probier mal 0+2 vielleicht sind die Werte dann aussagekräftiger;)
Erstens geht das bei mir nicht und zweitens würde ein solcher DC im Vorteil gegenüber dem QC liegen. Den beiden Cores würden jeweils 6MB Cache zur Verfügung stehen. Da wäre jegliche Vergleichbarkeit nicht mehr gegeben.

[Gast]

Ich habe mich dem auch Thema auch mal angenommen (ist aber schon eine Weile her). Als Bsp. siehe Bild (39 fps mit i920@default + 2x 260GTX 216 + OC mit Sli). Mit zwei Kernen und ohne HT waren es ein bisschen über 20 Frames.


ttp://img5.imagebanana.com/view/6xinjux9/ut3_cpu.jpg
http://img5.imagebanana.com/img/6xinjux9/thumb/ut3_cpu.jpg (http://img5.imagebanana.com/view/6xinjux9/ut3_cpu.jpg)

[=Floi=]

da sollten aber noch bots laufen, weil so die last viel zu gering ist.

[Gast]

"Fast" richtig, nur leider gibt es keine TimeDemos (so wie bei UT99 oder UT04) mehr, die 1:1 identisch ablaufen. Aber an den Screen sieht man, dass beim Spielstart ein DC überfordert ist. Mit Bots um so mehr.

[_DrillSarge]I[]

"Fast" richtig, nur leider gibt es keine TimeDemos (so wie bei UT99 oder UT04) mehr, die 1:1 identisch ablaufen.
reicht ja schon sich mit noclip (bei ut "ghost") sich in ne map mit 15 bots zu stellen. man erkennt schnell, dass selbst nen hochgetakteter DC zu schwach dafür ist

UDK auf deck mt 10 bots
http://www.abload.de/thumb/unbenannt7ci0.jpg (http://www.abload.de/image.php?img=unbenannt7ci0.jpg)
wenn man dann selber noch durch die map läuft und mitspielt pendelt sich das so zwischen 70-80% cpu-last ein

[dargo]

*ausgrab* :)

Hier schon mal ein kleiner Vorgeschmack auf die Tests mit dem Nehalem:

Q9550:
http://www4.pic-upload.de/thumb/08.05.10/c6fw5ddkora1.png (http://www.pic-upload.de/view-5565114/GRID_1.png.html)

i5-750 @2Ghz (15x133, Speicher @667Mhz):
QC = 79,933fps
DC = 57,4fps

Hier sieht man schon die bessere Skalierung vom Nehalem bei Quad vs. Dual. Ich denke bei richtigen Multithreading-Spielen (zb. Resident Evil 5) dürfte der i5 noch viel besser @Quad skalieren. :)

Edit:
Es bestätigt sich das was ich erwartet habe. Eigentlich wurden meine Erwartungen bei weitem übertroffen. Es ist beinah unfassbar. :eek:

Resident Evil 5:
Q9550:

http://www4.pic-upload.de/thumb/08.05.10/lwf7fplodhe.png (http://www.pic-upload.de/view-5565829/ResidentEvil5.png.html)

i5-750 @1768Mhz (13x 136, Speicher @681Mhz):
QC = 105,733fps
DC = 50,533fps

X-D

Ich kann nur jedem Gamer raten - schafft euch auf keinen Fall einen Kentsfield/Yorkfield an. Die Quadcores werden dermaßen vom FSB (vorallem der FSB) und der Speicherbandbreite limitiert, dass es nicht mehr feierlich ist!

PS: ausführliche Tests mit Diagrammen folgen demnächst. =)

[QUERSCHLÄGER]

Also sei mir nicht böse, aber diese Einschätzung muß man nicht teilen. Verrichten selbst DC bei 3Ghz noch fast überall anstandslos ihre Arbeit, setzen die 775er Quads das Sahnehäubchen obendrauf und liefern nahezu durchgehend spielbare Bilder/s. Da juckt es herzlich wenig, wie weit es nach oben gehen könnte.

Unter der Premisse eines Neukaufes ist da keine unbeantwortete Frage, da greift man zum i5/7, wie auch immer. Aber den gestern noch guten alten Quads jetzt plötzlich ihre Leistungsfähigkeit durch so eine Aussage absprechen zu wollen, finde ich etwas idiotisch. Gestern wurde sich noch einer drauf gerubbelt und nu isses schlecht. Nein, das ist es nicht.

[y33H@]

Ist doch nichts neues ;D Aber THX für die Fortführung dieses Threads.

[dargo]

Also sei mir nicht böse, aber diese Einschätzung muß man nicht teilen. Verrichten selbst DC bei 3Ghz noch fast überall anstandslos ihre Arbeit, setzen die 775er Quads das Sahnehäubchen obendrauf und liefern nahezu durchgehend spielbare Bilder/s. Da juckt es herzlich wenig, wie weit es nach oben gehen könnte.

Ich habe auch nicht gesagt, dass die S775 Quads zu wenig Bilder liefern würden. Ich habe nur gesagt, dass eine Nehalem-Plattform für Gamer die deutlich bessere Alternative ist. Games mit höherer CPU-Last werden kommen... garantiert. Mit der Nehalem-Plattform hat der Gamer einfach deutlich länger spielbare Frames, das beweist RE5 mehr als deutlich. Und ich behaupte sogar, dass sich ein Upgrade vom DC-S775 auf QC-S775 nicht mal lohnt. Schon gar nicht bei solchen Preisen:
http://geizhals.at/deutschland/a374021.html

Da würde ich ganz klar einen kompletten Systemwechsel vorziehen.

Ist doch nichts neues ;D
Ich wollte es nicht glauben als ich noch das Yorkfield-System hatte. Jetzt habe ich es schwarz auf weiß.

[Gast]

Und ich behaupte sogar, dass sich ein Upgrade vom DC-S775 auf QC-S775 nicht mal lohnt. Schon gar nicht bei solchen Preisen:
http://geizhals.at/deutschland/a374021.html

Da würde ich ganz klar einen kompletten Systemwechsel vorziehen.

Du hast es erkannt. Und genau das habe ich auch vollzogen. Eigentlich hatte ich vor 2 Jahren geplant, erstmal einen kleinen E2140 hochzutakten und später auf Q9550 upzugraden, aber ich wäre schon blöd, um 220 € für einen Q9550 zu investieren. Für den Preis kriege ich ja einen i7. :eek:

[y33H@]

Ich wollte es nicht glauben als ich noch das Yorkfield-System hatte. Jetzt habe ich es schwarz auf weiß. Schön =)

Ich bin nicht grundlos bereits damals auf einen i7-920 (und mittlerweile auf einen i5-750 @ 3,6 GHz) umgestiegen - obwohl ich einen Xeon 3210 ["Q6400] @ 3,2 GHz mein Eigen nenne.

[Botcruscher]

Ich wollte es nicht glauben als ich noch das Yorkfield-System hatte. Jetzt habe ich es schwarz auf weiß.

Das Thema ist seit Ewigkeiten durch. Das ganze war schon klar als es um das Thema "Quadcore" bei Intel oder doch besser nur dual-dualcore. Später gab es dann mit dem P1 den ersten richtigen Quadcore und die Vergleiche bei massiver Threadlast gegeben. Der Core hat schon damals schon voll abgekackt. StafanV ist von der blauen Übermacht dafür noch richtig zugeflamt worden.

[y33H@]

Link? :D

[mapel110]

Ich habe auch nicht gesagt, dass die S775 Quads zu wenig Bilder liefern würden. Ich habe nur gesagt, dass eine Nehalem-Plattform für Gamer die deutlich bessere Alternative ist. Games mit höherer CPU-Last werden kommen... garantiert. Mit der Nehalem-Plattform hat der Gamer einfach deutlich länger spielbare Frames, das beweist RE5 mehr als deutlich. Und ich behaupte sogar, dass sich ein Upgrade vom DC-S775 auf QC-S775 nicht mal lohnt. Schon gar nicht bei solchen Preisen:
http://geizhals.at/deutschland/a374021.html

Jup, wenn man die Zahlen von Frank1974 kennt, weiß man das schon recht lange.
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=7561344&postcount=87
Seitdem hab ich auch Abstand davon genommen, mir noch einen QC aufs Board zu schnallen.

[Botcruscher]

Ich weiß nicht mal mehr was damals überhaupt getestet wurde. Ich glaub es war Cinebench mit 4 bis 16 Threads Core Quad vs P1.

[dargo]

Es geht los mit Resident Evil 5 wieder (siehe Edit). :)
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=6973305&postcount=2

Die deutlich bessere Skalierung gegenüber dem Yorkfield vom TC und QC ist nicht zu übersehen. Kann mir aber jemand erklären warum der i5-750 mit dem Takt so schlecht skaliert? Das war beim Yorkfield noch ganz anders.

[Der HeinZ]

Verhält sich das wohl ähnlich bei einem Phenom?

[mapel110]

Die deutlich bessere Skalierung gegenüber dem Yorkfield vom TC und QC ist nicht zu übersehen. Kann mir aber jemand erklären warum der i5-750 mit dem Takt so schlecht skaliert? Das war beim Yorkfield noch ganz anders.
Sollte das nicht an der höheren ProMhz-Leistung liegen?!

[Undertaker]

Die deutlich bessere Skalierung gegenüber dem Yorkfield vom TC und QC ist nicht zu übersehen. Kann mir aber jemand erklären warum der i5-750 mit dem Takt so schlecht skaliert? Das war beim Yorkfield noch ganz anders.

Hast du den Uncoretakt entsprechend mitskaliert? Mögliche beginnende GPU-Limits gegengetestet?

[dargo]

Hast du den Uncoretakt entsprechend mitskaliert? Mögliche beginnende GPU-Limits gegengetestet?
GPU-Limits sind ausgeschlossen. Der Uncoretakt skaliert ja auch 1:1 mit dem BCLK mit.

Sollte das nicht an der höheren ProMhz-Leistung liegen?!
Ich kann dir nicht ganz folgen. Wie meinst du das?

[mapel110]

Einzelne Kerne leisten eben schon so viel mehr, dass es durch mehere Kerne keine so hohe Leistungssteigerung mehr geben kann.

[Undertaker]

Hab mal nachgerechnet, teils passt die Skalierung doch?

1,4->2,7GHz Dualcore: +90% Takt, +89% fps

In den anderen Fällen haut es allerdings nicht so gut hin - aber so kann es ja eigentlich kein prinzipielles Problem sein. Eigenartig, am besten Werte nocheinmal nachmessen.

Einzelne Kerne leisten eben schon so viel mehr, dass es durch mehere Kerne keine so hohe Leistungssteigerung mehr geben kann.

Das wäre nur der Fall, wenn andere Limits auftraten. War laut Dargo aber nicht so.

[dargo]

Einzelne Kerne leisten eben schon so viel mehr, dass es durch mehere Kerne keine so hohe Leistungssteigerung mehr geben kann.
:confused:

Ich habe gefragt warum die Architektur (wobei ich das noch nicht 100% bestätigen kann, schließlich habe ich bis jetzt nur ein Spiel getestet) mit höherem Takt < 1:1 skaliert. Erhöhe ich den Takt um 20% (siehe Diagramm) steigt die Framerate um 12-14%. Das war beim Yorkfield noch ganz anders, der hat immer > 1:1 mit höherem Takt skaliert.

Hab mal nachgerechnet, teils passt die Skalierung doch?

1,4->2,7GHz Dualcore: +90% Takt, +89% fps

Ups, diesen Fall habe ich noch gar nicht nachgerechnet. Da hast du allerdings recht. :)


In den anderen Fällen haut es allerdings nicht so gut hin - aber so kann es ja eigentlich kein prinzipielles Problem sein. Eigenartig, am besten Werte nocheinmal nachmessen.

Das ist ja das kuriose. Messfehler ausgeschlossen, habs mehrfach geprüft.

Edit:
Um es nochmal in Zahlen zu fassen:
1447Mhz DC = 49,35fps
1739Mhz DC = 56,30fps (+20% Takt, +14% Frames)
2752Mhz DC = 93,35fps (+90% Takt, +89% Frames)

Schon seltsam oder?

Es wird noch kurioser:
1739Mhz DC = 56,30fps
2752Mhz DC = 93,35fps (+58% Takt, +66% Frames)

Hierbei ist die Skalierung wieder einiges > 1:1. :confused:

[Gast]

Erstaunlich finde ich: i5 1739 MHz: 104,25 FPS vs. Yorkfield 2833 MHz: 92,30 FPS.

[dargo]

Erstaunlich finde ich: i5 1739 MHz: 104,25 FPS vs. Yorkfield 2833 MHz: 92,30 FPS.
Das liegt an der erheblichen Bremse der Yorkfield/Kentsfield-Architektur, nämlich dem FSB und natürlich auch der geringeren Speicherbandbreite. Wobei der größte Bremsklotz der FSB ist. Diese CPUs können ihre Leistung in sehr guten Multi-Threading Spielen praktisch gar nicht auf die Straße bringen. Die höhere Pro/Mhz-Leistung vom i5 kommt noch hinzu.

[y33H@]

Du hast Pro-MHz teils fast 50% (GTA4) von Yorkfield auf Lynnfield (kein SMT-Benefit!).

Das ist abartig, vor allem wenn man überlegt wie fett der Core 2 anno dazumal war.

[Coda]

Das liegt aber eher an den getrennten Kernen als an der Architektur an sich.

[Gast]

Am sinnvollsten wäre ein Vergleich (natürlich bei gleichem Takt) von Wolfdale vs. Core i3 ohne HTT und gleichzeitig Yorkfield vs. Core i7 ohne HTT. Daraus könnte man auf den Einfluss der Architektur als auch der Kerne schließen, ohne dieses undefinierte Kernabschalten.

-carsten

[dargo]

Das liegt aber eher an den getrennten Kernen als an der Architektur an sich.
Nicht unbedingt:

Yorkfield @1768Mhz DC = 39,80fps
Lynnfield @1739Mhz DC = 56,30fps

Beim Yorkfield @DC sind die beiden Kerne nicht mehr getrennt.

[Gast]

Am sinnvollsten wäre ein Vergleich (natürlich bei gleichem Takt) von Wolfdale vs. Core i3 ohne HTT und gleichzeitig Yorkfield vs. Core i7 ohne HTT. Daraus könnte man auf den Einfluss der Architektur als auch der Kerne schließen, ohne dieses undefinierte Kernabschalten.

-carsten

+1 :uup:

[dargo]

Am sinnvollsten wäre ein Vergleich (natürlich bei gleichem Takt) von Wolfdale vs. Core i3 ohne HTT und gleichzeitig Yorkfield vs. Core i7 ohne HTT. Daraus könnte man auf den Einfluss der Architektur als auch der Kerne schließen, ohne dieses undefinierte Kernabschalten.

-carsten
Kannst du alles von den beiden RE5-Diagrammen ableiten. Yorkfield @DC = Wolfdale, i5-750 @DC = i3. Naja... einen kleinen Unterschied gibts doch, der i5 (auch beim simulierten DC) hat den doppelten L3 Cache im Vergleich zum i3 zur Verfügung. Und die 29Mhz Taktunterschied wirst du mir wohl verzeihen oder? :wink:

[Gast]

Zeig mal, wo steht, welche Kerne abgeschaltet werden... Cachemäßig und so. Da bin ich mir nämlich gar nicht so sicher.

-carsten

[dargo]

Zeig mal, wo steht, welche Kerne abgeschaltet werden... Cachemäßig und so. Da bin ich mir nämlich gar nicht so sicher.

-carsten
Meinst du beim Yorkfield? Beim DC werden immer Core 2 und 3 abgeschaltet. Sprich, dem simulierten Wolfdale stehen dann Core 0 und 1 inkl. 6MB Cache zur Verfügung.

Edit:
Im Prinzip ist es egal ob Yorkfield oder i5/i7. Windows 7 schaltet automatisch immer zuerst die letzten Cores ab. Core 0 und 2 oder 1 und 3 zu nutzen ist gar nicht erst möglich.

[Gast]

…und genau dafür würde ich gern mal einen Beleg sehen.

-carsten

[Gast]

Das liegt an der erheblichen Bremse der Yorkfield/Kentsfield-Architektur, nämlich dem FSB und natürlich auch der geringeren Speicherbandbreite. Wobei der größte Bremsklotz der FSB ist. Diese CPUs können ihre Leistung in sehr guten Multi-Threading Spielen praktisch gar nicht auf die Straße bringen. Die höhere Pro/Mhz-Leistung vom i5 kommt noch hinzu.

Der Test ist ja sowas von bescheiden :(

1. 1768Mhz (8,5x 208Mhz FSB), Speichertakt 208Mhz

208 MHz FSB, für einen Quad, ja kein Wunder das dieser bei einem Ram-lastigen (?) Game absäuft. Der Speichertakt des i5 war im übroigen doppelt so hoch!


@dargo
lass doch mal den Yorkfield mit 6x295Mhz laufen. Wobei selbst das noch zu niedrig wäre, für einen "fairen" Vergleich.

[dargo]

…und genau dafür würde ich gern mal einen Beleg sehen.

-carsten
Schau dir zb. mal Speedfan an welche Cores angezeigt werden wenn einzelne deaktiviert sind.

Der Test ist ja sowas von bescheiden :(

1. 1768Mhz (8,5x 208Mhz FSB), Speichertakt 208Mhz

208 MHz FSB, für einen Quad, ja kein Wunder das dieser bei einem Ram-lastigen (?) Game absäuft.

Wenn du dir den Q9550 genauer anschaust habe ich der CPU bei meiner Konstellation die gleiche Speicherbandbreite zur Verfügung gestellt wie Intel es vorsieht. ;)

[Undertaker]

…und genau dafür würde ich gern mal einen Beleg sehen.

-carsten

Wie wäre es denn, die Kerne einfach per Taskmanager-Zuweisung einer bestimmten Anwendung zu entziehen? Ist natürlich nicht 100%ig sauber, da ein so auf zwei Kerne reduzierter Quadcore noch zusätzliche Ressourcen für Hintergrundprogramme und die allgemeine Systemlast besäße, die einem echten Dualcore fehlen - allerdings sollten sich dadurch entstehende Differenzen in einem unkritisch geringen Rahmen befinden.

Mit dieser Möglichkeit sollte man dafür definitiv Einfluss darauf nehmen können, welche Kerne genau abgeschaltet werden - hab ich mal mit meinem Arrandale getestet, hier merkt man ja sehr deutlich, ob man bei der Deaktivierung von zwei Threads nur ohne SMT, aber weiterhin auf zwei physischen Kernen arbeitet, oder aber nur noch ein Kern mit SMT aktiv ist.

[Gast]

Schau dir zb. mal Speedfan an welche Cores angezeigt werden wenn einzelne deaktiviert sind.


Wenn du dir den Q9550 genauer anschaust habe ich der CPU bei meiner Konstellation die gleiche Speicherbandbreite zur Verfügung gestellt wie Intel es vorsieht. ;)
Käse, der FSB von 208Mhz schmällert die RamBandbreite! Dem Q9550 stehen 333MHz FSB zu!

[dargo]

Käse, der FSB von 208Mhz schmällert die RamBandbreite! Dem Q9550 stehen 333MHz FSB zu!
Q9550 = 2833Mhz, 8,5x 333Mhz FSB, 333Mhz Speichertakt
Q9550@1768Mhz, 8,5x 208Mhz FSB, 208Mhz Speichertakt

62% vom Original-CPU-Takt, 62% vom Original-FSB, 62% der Original-Speicherbandbreite

Klingelts? :)

[Gast]

Q9550 = 2833Mhz, 8,5x 333Mhz FSB, 333Mhz Speichertakt
Q9550@1768Mhz, 8,5x 208Mhz FSB, 208Mhz Speichertakt

62% vom Original-CPU-Takt, 62% vom Original-FSB, 62% der Original-Speicherbandbreite

Klingelts? :)

Das Problem ist, das bei 208MHz FSB der Yorkfield limitiert wird.

Das erkannt man doch auch an dem FSB-Zuwachs:

Yorkfield QC: von 1768Mhz zu 2833MHz => 53,55 FPS 92,30 FPS
=> 60% Taktsteigerung und ergeben 72,4% mehr an FPS

Lass doch mal zum Vergleich den Yorkfield mit 6x295MHz laufen.

[dargo]

Das Problem ist, das bei 208MHz FSB der Yorkfield limitiert wird.

Der Yorkfield wird immer mit mehr als 2 Cores stark limitiert, egal wie hoch der FSB ist.


Yorkfield QC: von 1768Mhz zu 2833MHz => 53,55 FPS 92,30 FPS
=> 60% Taktsteigerung und ergeben 72,4% mehr an FPS

Ich hatte schon gesagt, dass der Yorkfield mit höherem Takt > 1:1 skaliert. Eine Erklärung dafür hatten wir in diesem Thread auch schon.


Lass doch mal zum Vergleich den Yorkfield mit 6x295MHz laufen.
Geht nicht, System ist schon länger verkauft. Außerdem brauche ich das gar nicht testen um zu wissen, dass die Frames dann höher sind als mit 8,5x 208. Ist doch logisch wenn man den Flaschenhals verkleinert. ;)

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

Auch hier das gleiche Verhalten. Bei Takterhöhung in erster Linie eine Skalierung < 1:1. Erst der 2332Mhz DC skaliert genau 1:1 mit im Vergleich zum 1558Mhz QC. Was sagen die CPU-Gurus zu diesem Phänomen? :)

[Gast]

Der Yorkfield wird immer mit mehr als 2 Cores stark limitiert, egal wie hoch der FSB ist.

Das stimmt so nicht, ab 450MHz ist der Vorteil des i5 fast zu nichte.
Von wegen höhere proMhz-Leistung des i5..

[dargo]

Das stimmt so nicht, ab 450MHz ist der Vorteil des i5 fast zu nichte.

Das ist Unsinn, ohne Angabe vom CPU-Takt erst recht.

[Gast]

Das ist Unsinn, ohne Angabe vom CPU-Takt erst recht.
ja natürlich bei gleichem CPU-Takt! Anders würde es ja keinen Sinn ergebenm wenn ich von proMhz-Leistung spreche!

[Undertaker]

ja natürlich bei gleichem CPU-Takt! Anders würde es ja keinen Sinn ergebenm wenn ich von proMhz-Leistung spreche!

Der entscheidende Faktor ist das Verhältnis von FSB-Takt zu Kerntakt des Core 2. Wenn du diesen Faktor konstant lässt, hast du für jeden beliebigen Takt die gleiche pro-MHz Leistung. Ein 200MHz FSB bei 1,5GHz ist limitiert nicht stärker als 400MHz bei 3GHz.

[Gast]

Der entscheidende Faktor ist das Verhältnis von FSB-Takt zu Kerntakt des Core 2. Wenn du diesen Faktor konstant lässt, hast du für jeden beliebigen Takt die gleiche pro-MHz Leistung. Ein 200MHz FSB bei 1,5GHz ist limitiert nicht stärker als 400MHz bei 3GHz.
In der theorie vielleicht. Aber praktisch? Nein, Dargo beweißt das ja: 60% mehr Takt resultieren in 72% mehr FPS.

[dargo]

ja natürlich bei gleichem CPU-Takt! Anders würde es ja keinen Sinn ergebenm wenn ich von proMhz-Leistung spreche!
Und welchen Sinn macht das in der Praxis? Welchen CPU-Multi hättest du denn gerne bei deinem 450Mhz FSB? Wie wärs mit 6,5? Dann sind wir mit 2925Mhz fast bei den originalen 2833Mhz des Q9550. Wenn ich jetzt die CPU mit sagen wir mal 3,7Ghz takten möchte kannst du mir gerne das Brett zeigen welches einen FSB von 569Mhz schafft. Ganz davon zu schweigen ob die CPU das überhaupt mitmacht. Den Superduper DDR2-1200 Speicher brauchst du dann auch noch der jenseits der Spezifikation läuft.

Nach deiner Logik könnte ich aus dem i5/i7 auch deutlich mehr rausquetschen:

Möglichst kleinen CPU-Multi nehmen, den BCLK @max. und diesen Speicher hier:
http://geizhals.at/deutschland/a501521.html

[Undertaker]

In der theorie vielleicht. Aber praktisch? Nein, Dargo beweißt das ja: 60% mehr Takt resultieren in 72% mehr FPS.

Überproportinale Skalierungen einer Taktsteigerung sind grundlastbedingt.

[y33H@]

Das kommt u.a. in Anno gerne vor.

[dargo@work]

@y33H@

Konntet ihr bei euren CPU-Benchmarks mit dem Nehalem auch beim höheren Takt eine Skalierung < 1:1 beobachten? Das gibt mir jetzt irgendwie keine Ruhe. ^^

[y33H@]

Nicht nur mit Nehalem, auch Yorkfield/Deneb/whatever. Ist aber selten, da eine so extreme Grundlast wie bei Anno 1404 kaum vorkommt.

[dargo@work]

Nicht nur mit Nehalem, auch Yorkfield/Deneb/whatever. Ist aber selten, da eine so extreme Grundlast wie bei Anno 1404 kaum vorkommt.
Ich dachte bei Anno gibts eine starke Grundlast, sprich die Skalierung mit höherem Takt ist größer 1:1??? Hab dich zumindest so verstanden.
Ich habe bei RE5 und GRID genau das Gegenteil gemessen wenn du dir die einzelnen Ergebnisse genauer anschaust. Beim Yorkfield hatte ich afaik noch kein Spiel mit einer Skalierung kleiner 1:1 bei einer höheren Taktrate.

[Gast]

Das stimmt so nicht, ab 450MHz ist der Vorteil des i5 fast zu nichte.
Von wegen höhere proMhz-Leistung des i5..

Das ist vollkommen richtig.
Der Yorkfield muss mindestens mit FSB 1600 an vernünftigem RAM (ab DDR2-1066) betrieben werden um überhaupt erstmal eine gewisse Vergleichbarkeit zu den heutigen Iirgendwas zu schaffen.

Natürlich hat Dargo wenigstens in einem Punkt recht - das größte Problem der Penryn-Generation ist zweifelsohne der FSB-Flaschenhals.
Doch genau darum sollte vor diesem Hintergrund das Bestreben sein, diesen Hals bestmöglich zu kompensieren. Und das erreicht man eben nur durch Hochreißen des FSB auf deutlich über 400 MHz.
Was Intel selbst an Bandbreite ursprünglich "vorgesehen" hat - sprich FSB 1333 - darf in dieser Betrachtung hier sowieso keine Rolle spielen.
Es geht schließlich um das technisch Mögliche.

Vorher sollte man es sich nicht erlauben, ein derart gewagtes Fazit zu ziehen.

[dargo]

Oh man! Ich benche gerade Shift und kriege hier bald die Kriese. :freak:
So wie es aussieht sind die Benchmarks mit RE5 und GRID mit dem i5-750 schon mal für die Tonne. :usad:

Gott sei Dank ist mir das jetzt aufgefallen und nicht erst nachdem ~20 Spiele getestet wurden. :eek:

Mir ist ein dicker Fehler im System aufgefallen. Zur Erinnerung - ich betreibe die CPU beim kleinsten Takt mit 14x 111 BCLK. Das Problem ist, dass das Board selbst mit 111 manchmal nicht booten will. Habe also als Lösung das Tool "Turbo V Evo" von Asus genommen. Mit diesem Tool lässt sich unter anderem der BCLK "on the fly" in Windows ändern. Man muss also nicht ständig neustarten was viel Zeit kostet. Nun, das Tool kann man vergessen. Gerade eben Shift mit 14x 152 BCLK getestet (gebootet wurde mit einem BCLK von 138, anschließend mit dem Tool den BCLK angehoben). Ergebnis mit einem DC 43,3fps. Dann habe ich den Rechner mit 14x 152 BCLK übers Bios neugestartet und nochmal gebencht. Ergebnis - 48fps. :facepalm:

Scheinbar will Windows "on the fly" die neue Taktrate nicht ordnungsgemäß annehmen, obwohl CPU-Z diese korrekt anzeigt. Tja, wollte mir eine Menge Zeit sparen. Leider muss ich dann doch wieder jedes Mal über das Bios gehen.

Die Benchmarks von RE5 und GRID werden wiederholt.

PS: jetzt muss ich auch noch herausfinden mit welchem min. BCLK mein Brett immer einwandfrei bootet. :uhippie:

[dargo]

So... der min. BCLK beträgt bei mir 112. Damit bootet das Brett immer einwandfrei. Resident Evil 5 und GRID sind nun fertig:
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=6973305&postcount=2

Und wie man sieht passt diesmal die Skalierung beim höheren Takt. Was so ein Tool alles anrichten kann. :ugly:

[mapel110]

min-fps und Frameverläufe wären sehr geil bei den Vergleichen.

[dargo]

@mapel110
Was willst du mit einem Frameverlauf und min.fps in einem fünf-sekündigen Test der zu 100% cpu-limitiert ist? :)
Die min.fps verhalten sich praktisch wie die avgs, nur dass die Abweichung der einzelnen Werte minimal größer ist da Fraps die min.fps nur in Ganzzahlen erfasst.

[mapel110]

@mapel110
Was willst du mit einem Frameverlauf und min.fps in einem fünf-sekündigen Test der zu 100% cpu-limitiert ist? :)
Die min.fps verhalten sich praktisch wie die avgs, nur dass die Abweichung der einzelnen Werte minimal größer ist da Fraps die min.fps nur in Ganzzahlen erfasst.
Ach so testest du, dann ists okay.

[dargo]

Testverfahren:
Es wurden ausschließlich Savegames verwendet. Das Savegame wurde diesmal 7x hintereinander geladen. Gemessen wurde erst nachdem das Savegame zum zweiten mal geladen war. Aus den 6 Messungen wurde ein Durchschnitt ermittelt.
Ist zwar der Text vom SC vs. DC. Im Prinzip hat sich aber nichts geändert. Die Dauer beträgt weiterhin 5 Sekunden. Allerdings sind es nur noch 4 Messungen. 6 waren überflüssig da die einzelnen Werte kaum von einander abweichen. :)

[Fetter Fettsack]

Toller Thread, dargo. So viel in so kurzer Zeit hab ich noch nie über CPUs gelernt.^^

Wenn ich das richtig sehe, dann schaust du auch auf die Auslastung im Taskmanager. Ist das Absicht, dass du da nur ein recht ungefähres Bild bekommst (schließlich bekommt man ja nicht die wirkliche Auslastung zu Gesicht sondern eine mit Wartezeiten "belastete")?
Du könntst die Auslastung nämlich auch direkt "in der CPU" (sorry für die dämliche Formulierung :) ) auslesen, wie mir gütiger Weise ein gewisser Privatmann mit Bond-Avatar einmal mitteilte.

-->http://www.withopf.com/tools/perfwatch/

[dargo]

Wenn ich das richtig sehe, dann schaust du auch auf die Auslastung im Taskmanager.

Jein.

Ich schaue mir zwar ab und zu den Taskmanager an, er ist aber keine Garantie dafür, dass eine hohe Auslastung gleichzeitig mehr Frames bedeutet. Gerade bei einem Kentsfield/Yorkfield kann man sich auf den Taskmanager überhaupt nicht mehr verlassen.

Im Prinzip werden erstmal aktionreiche Szenen gesucht. Diese belasten in der Regel die CPUs stark.


Du könntst die Auslastung nämlich auch direkt "in der CPU" (sorry für die dämliche Formulierung :) ) auslesen, wie mir gütiger Weise ein gewisser Redakteur mit Bond-Avatar einmal mitteilte.

-->http://www.withopf.com/tools/perfwatch/
Ich werde mir das Tool mal genauer anschauen. Vielleicht ist dieses deutlich aussagekräftiger. :)

Edit:
Das fängt schon gut an. X-D

36880

Eine Idee woran das liegen kann? Win7 x64 ist im Einsatz.

[y33H@]

wie mir gütiger Weise ein gewisser Redakteur mit Bond-Avatar einmal mitteilte.Privatmann, bitte ;)

@ dargo
Q: Ich erhalte unter Vista/x64 die Meldung "Der zum Betrieb notwendige Treiber kann nicht geladen werden, Fehlercode 9,0,12,577". Was kann ich tun?

A: Das liegt daran, dass Vista/x64 signierte Treiber verlangt. Sie können das umgehen, indem Sie beim Booten F8 drücken und dann im Menü "Erzwingen der Treibersignatur deaktivieren" wählen. Diese Einstellung bleibt allerdings nicht erhalten, wenn Sie neu starten; beim Standby jedoch schon.

[Fetter Fettsack]

Admin Rights?

EDIT: Hat sich erledigt.

@ y33h@

Is gebongt. ;)

EDIT 2:

Bei Win7 müsste es aber eine Möglichkeit geben, die Treibersignierungsanforderung on-the-fly auszuschalten, sodass man sich das F8 drücken sparen kann.

Mehr weiß ich momentan nicht, da ich gerade von einem XP-System schreibe. Im Thread für das DX10/11 SSAA-Tool stand aber genaueres darüber, wenn ich mich recht entsinne.

[dargo]

@y33H@

Merci. =)

[dargo]

So... TDU ist mit dem i5-System fertig.

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

Jetzt vergleicht das mal mit dem Yorfield. :freak:

Ich wollte zuerst die Ergebnisse nicht glauben, habe es 3x gebencht und alle Settings überprüft - Messfehler sind somit ausgeschlossen. Kann sich jemand diesen Riesenunterschied bei der Skalierung der beiden Architekturen erklären? Ich habe zwar eine Vermutung, mich würde aber erstmal eure Meinung dazu interessieren.

Übrigens - ich habe den i5-750 mal probeweise mit 2008Mhz @DC getestet. Ergebnis:

i5-750@2Ghz@DC = 61,7fps
Q9550@2Ghz@DC = 31,53fps

:| :O

Dass der Lynnfield bei guten Multithreading-Spielen bei gleicher Taktrate beinahe doppelt so schnell sein kann ist mir mittlerweile bekannt. Aber als Dualcore :confused:
Limitiert der FSB selbst beim Wolfdale dermaßen stark? :|

[Fetter Fettsack]

Dass der Lynnfield bei guten Multithreading-Spielen bei gleicher Taktrate beinahe doppelt so schnell sein kann ist mir mittlerweile bekannt. Aber als Dualcore
Limitiert der FSB selbst beim Wolfdale dermaßen stark?

Was spricht denn dagegen, dass der i5-750 die Leistung, die er mit vier Kernen bringt, nicht auch mit zwei bringen kann (Leistung im Sinne von 2 Kerne= 4 Kerne/2).
Bzgl. Wolfdale: ob Quad oder DualCore, da (mWn) die ganze Architektur mehr oder weniger am FSB-Limit hängt, kommt mir das Ergebnis nicht sonderlich komisch vor. Oder übersehe ich da etwas?

[y33H@]

Aber als DualcoreL3? So als Vermutung.

[dargo@work]

Was spricht denn dagegen, dass der i5-750 die Leistung, die er mit vier Kernen bringt, nicht auch mit zwei bringen kann (Leistung im Sinne von 2 Kerne= 4 Kerne/2).

Nun, wenn der Lynnfield sich extrem vom Yorkfield absetzen kann liegts eigentlich nur daran, dass Spiel XY sehr gut mit 4 Kernen skaliert und beim Yorkfield halt der FSB stark bremst. TDU skaliert aber wie man sieht sehr schlecht mit 4 Kernen. Zumindest beim Lynnfield, beim Yorkfield sah die Sache doch schon erheblich anders aus (siehe Diagramm). Die Skalierugsunterschiede kann ich mir nicht so recht erklären.

[dargo@work]

L3? So als Vermutung.
Du meinst TDU wäre extrem cachelastig? Warum legt es dann mit dem Yorkfield @4 Cores so zu?

[dargo]

Ich habe noch ein wenig rumgetestet. Meine Vermutung war, dass für den starken Einbruch des Wolfdales die Grundlast verantworlich ist. Dem ist aber imo nur zum Teil der Fall. Um das herauszufinden habe ich den i5-750 so weit runtergetaktet, dass er auch in den 30fps Bereich kommt:

i5-750@1012Mhz (9x112,4) = 29,80fps
i5-750@1570Mhz (9x174,4) = 49,40fps

55% mehr Takt resultieren in 66% mehr Frames. Die Grundlast dürfte aber bei diesem Ergebnis kaum für den extremen Vorteil vom i5-750@DC verantworlich sein.

[Fetter Fettsack]

Also wird es wohl doch an einem Limit beim Yorkfield@DC liegen (müssen).

Wegen der Skalierung: könnte es möglich sein, dass man in bei TDU extra für den Yorkfield optimiert hat (wie auch immer das aussehen mag [kommt mir persönlich aber etwas unwahrscheinlich vor]?)

EDIT: Ich hab da eine Weile über folgendes Zitat von dir nachgedacht, aber ich werd nicht shclau draus. Bitte klär mich auf, welches Diagramm du genau meinst. Ich hab zwar das mit dem Q9550 und das mit dem i5 "gefunden", aber da sind unterschiedliche Taktraten zu sehen. Hab ich da eine Erklärung zum Testsetup übersehen? Sei bitte so gütig und klär mich auf. =)

[dargo]

Welches Zitat von mir meinst du?

[Fetter Fettsack]

TDU skaliert aber wie man sieht sehr schlecht mit 4 Kernen. Zumindest beim Lynnfield, beim Yorkfield sah die Sache doch schon erheblich anders aus (siehe Diagramm). Die Skalierugsunterschiede kann ich mir nicht so recht erklären.

Der Leib dargo, für dich gegeben. ;D

(man verzeihe mir meine blasphemischen Anwandlungen :D)

[dargo]

Schau dir das Diagramm vom Lynnfield und dann vom Yorkfield (erster Post) genau an. Man sieht, dass TDU beim Yorkfield mit 3 Kernen einiges zulegt. Beim Lynnfield sieht es ganz anders aus.

[Fetter Fettsack]

Mhhh, da fällt mir nur das ein, was y33h@ schon ansprach: der Cache. Wenn du den Yorkfield mit drei Kernen laufen lässt, dann hat er die vollen 12MB. Würde auch erklären, wieso der vierte Kern keine sonderlichen Sprünge bringt.

Was mich jetzt aber wundert, ist, dass der Lynnfield, je höher er getaktet wird, auffällig "viel" mit dem Zuschalten des vierten Kerns zulegt, jedoch vom Zweiten zum Dritten kaum bis wenig. Finde ich insofern komsich, da ja TDU nicht gut skalieren soll.

EDIT: Wird wahrscheinlich architekturbedingt sein (jaja, eine grandiose Erkenntnis, ich weiß^^).

[dargo]

Mhhh, da fällt mir nur das ein, was y33h@ schon ansprach: der Cache.
Wenn du den Yorkfield mit drei Kernen laufen lässt, dann hat er die vollen 12MB. Würde auch erklären, wieso der vierte Kern keine sonderlichen Sprünge bringt.

Nein, er meinste die 8MB L3 Cache vom Lynnfield. Dass der shared Cache vom Yorkfield bei 3 Cores der CPU vollständig zur Verfügung steht ist mir klar. Das ist aber beim Lynnfield auch der Fall. Oder zumindest ähnlich. Dem Lynnfield steht zb. der L3 Cache mit vollen 8MB bei 1, 2, 3 und 4 Cores zur Verfügung.


Was mich jetzt aber wundert, ist, dass der Lynnfield, je höher er getaktet wird, auffällig "viel" mit dem Zuschalten des vierten Kerns zulegt, jedoch vom Zweiten zum Dritten kaum bis wenig. Finde ich insofern komsich, da ja TDU nicht gut skalieren soll.
Ja, hierbei gibts bei mir auch ein großes Fragezeichen.

[Fetter Fettsack]

Nein, er meinste die 8MB L3 Cache vom Lynnfield. Dass der shared Cache vom Yorkfield bei 3 Cores der CPU vollständig zur Verfügung steht ist mir klar. Das ist aber beim Lynnfield auch der Fall. Oder zumindest ähnlich. Dem Lynnfield steht zb. der L3 Cache mit vollen 8MB bei 1, 2, 3 und 4 Cores zur Verfügung.

Macht aber trotzdem Sinn, wie ich meine.

Lynnfield:

2 Kerne + 8MB........46,95/72,70fps
3 Kerne + 8MB........51,05/74,10fps
4 Kerne + 8MB........54,15/80,00fps

Yorkfield:

2 Kerne + 6MB........17,833/31,533fps
3 Kerne + 12MB......33,667/46,667fps
4 Kerne + 12MB......36,300/47,033fps


Irgendwie passt das schon zusammen. Wenn wir davon ausgehen, dass der Lynnfield eine recht effiziente Architektur hat und dementsprechend ohne Probleme mit 8MB auskommt, dann passen die Leistungssteigerungen (abgesehen vom Ausreißer beim vierten Kern) zu der These einer Cacheabhänigkeit.

Dies deshalb, weil man beim (durchaus ineffizienteren) Yorkfield sieht, dass bei 6MB Cache mehr auch die Leistung sprunghaft ansteigt. Dass die Auswirkung auf die fps durch das Zuschalten eines weiteren Kerns hingegen sich grob gesagt wie beim Lynnfield in Grenzen hält, spricht meiner Ansicht nach durchaus dafür, dass wie hier einen Cacheliebhaber haben.

Bezüglich der unerwarteten Leistungssteigerung beim vierten Kern des Lynnfield würde ich jetzt einfach ins Blaue hinein vermuten, dass die CPU vermutlich irgendein internes "Feature" hat, dass erst mit vier Kernen sein volles Potenzial entfalten kann (interkernale Kommunikation^^).

[y33H@]

@ dargo

Der Yorkfield hat kein Shared für alle (!) Cores. Weder L3 noch L2.

[G A S T]

Too much Text

Danke für die kleine Übersicht.

Du hast da zwar eine interessante Theorie... aber das kann so einfach nicht stimmen.

Der Leistunngssprung des Lynnfield beim letzten Kern lässt sich dadurch jedenfalls nicht erklären. Es wäre völlig daneben zu glauben, dass mit der Aktivierung des vierten Kerns irgendein Zahnrädchen anspringt, dass dann nochmal extra "pusht". Das würde nämlich im Umkehrschluss bedeuten, dass Intel seine CPUs im 2-3 Kern-Betrieb künstlich drosselt...

Andererseits verstehe ich nicht, warum der Yorkfield beim Zuschalten des 4. Kerns so gut wie keine Steigerung erfährt.
Auch wundert mich der hier sehr deutliche Vorsprung des Lynnfield insgesamt.
Gerade wenn man dabei auch bedenkt, dass dem Yorkfield insgesamt 33,33 % mehr Cache zu Verfügung steht. Der FSB allein genügt nicht zur Erklärung.

[dargo]

@ dargo

Der Yorkfield hat kein Shared für alle (!) Cores. Weder L3 noch L2.
Doch, der Yorkfield hat einen shared L2 Cache. Das er nicht für alle Cores zur Verfügung steht weiß ich. Sind ja zwei "zusammengeklatschte" CPUs in dem Sinne, sprich:

Core 0 und/oder 1 = 6MB L2
Core 2 und/oder 3 = 6MB L2
Core 0/1 und 2 = 6MB für 0/1 und 6MB für 2

usw. usf.


Andererseits verstehe ich nicht, warum der Yorkfield beim Zuschalten des 4. Kerns so gut wie keine Steigerung erfährt.
Auch wundert mich der hier sehr deutliche Vorsprung des Lynnfield insgesamt.
Gerade wenn man dabei auch bedenkt, dass dem Yorkfield insgesamt 33,33 % mehr Cache zu Verfügung steht. Der FSB allein genügt nicht zur Erklärung.
Mögliche Ursache - beim Zuschalten vom vierten Core beim Lynnfield greifen bei TDU die "Optimierungen" vom Grafiktreiber. NV hatte früher mal verkündet, man wolle den Quadcore besser unterstützen. Beim Yorkfield wurden wesentlich ältere Grafiktreiber verwendet.

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

[Fetter Fettsack]

Der Leistunngssprung des Lynnfield beim letzten Kern lässt sich dadurch jedenfalls nicht erklären. Es wäre völlig daneben zu glauben, dass mit der Aktivierung des vierten Kerns irgendein Zahnrädchen anspringt, dass dann nochmal extra "pusht". Das würde nämlich im Umkehrschluss bedeuten, dass Intel seine CPUs im 2-3 Kern-Betrieb künstlich drosselt...

Eben nicht, ich hatte das eher als ein Feature gedacht, das für den Gebrauch von vier Kernen optimiert ist. Wenn einer fehlt, dann geht es natürlich nimmer gut und wenn es mit abnehmender Kernanzahl übermäßg "einbricht" haben wir den Salat. Bezüglich drosseln: wieso soll man bei einem QuadCore ein Feature einbauen und das dann auch auf den DualCore-Betrieb des Quads optimieren? Erschiene mir etwas sinnfrei.

Allerdings klingt dargos Theorie auch ganz interessant.

EDIT: Eigentlich sieht man auch bei den DIRT 2 Benches, dass der Lynnfield schön gleichmäßig ansteigt (und bei den Quad-Ergebnissen etwas überproportional zulegt (Quad-Optimierungen?), während der Yorkfield immer erst mit seinen vollen 12MB Cache so richtig anspringt.

[dargo]

@Fetter Fettsack

Für die etwas bessere Quadcore-Skalierung bei TDU ist der NV-Treiber verantwortlich.

2332Mhz QC mit Threaded-Optimierung im CP = 80,00fps
2332Mhz QC ohne Threaded-Optimierung im CP = 75,65fps

Bei DIRT 2 wird das sicherlich auch greifen, kann ich mal bei Gelegenheit testen.

Edit:
Bei DIRT 2 bringt die "Treiber-Optimierung" nichts.

2332Mhz QC mit Threaded-Optimierung im CP = 76,60fps
2332Mhz QC ohne Threaded-Optimierung im CP = 77,30fps

Das fällt schon unter Messschwankung.

[dargo]

Gibts hier jemanden mit einem Clarkdale? Mich würde mal interesieren wieviel die zusätzlichen 4MB L3 Cache dem Lynnfield @Dualcore bringen.

[Fetter Fettsack]

@ dargo

Gut, dann bin ich mit meinem internen CPU-Feature daneben gelegen. Danke für die Aufklärung.

[Fetter Fettsack]

del.

[y33H@]

@ dargo

Viel :D

[dargo]

@ dargo

Viel :D
Ich brauche Zahlen. ;) Kommst du an ein System mit dem Clarkdale ran und hättest du dann Lust ca. zwei Games mit mir zu testen?

[y33H@]

Kann ich machen, muss aber bis zum WE warten.

[S940]

Gibts hier jemanden mit einem Clarkdale? Mich würde mal interesieren wieviel die zusätzlichen 4MB L3 Cache dem Lynnfield @Dualcore bringen.
Vergess dann aber nicht, dass dabei nicht nur die +4MB L3 getestet werden, sondern auch die bessere RAM Anbindung ...

Here’s where things get disgusting. Memory latency is about 76% higher than on Lynnfield. That’s just abysmal. It’s also reflected in the memory bandwidth scores. While Lynnfield can manage over 15GB/s from its dual-channel memory controller, Clarkdale can’t break 10. Granted this is higher than the Core 2 platforms, but it’s not great.
http://www.anandtech.com/show/2901/2

[dargo]

Vergess dann aber nicht, dass dabei nicht nur die +4MB L3 getestet werden, sondern auch die bessere RAM Anbindung ...

http://www.anandtech.com/show/2901/2
Argh... dann hat der Clarkdale auch einen anderen IMC? Aber sollte das nicht egal sein? Ich meine selbst mit DDR3-1600 habe ich eine Speicherbandbreite im DC von nur 10,24GB/s. Oder sinds 20,28GB/s? Wie war die Formel nochmal? :D

Edit:
Wir könnten aber den Speicherdurchsatz so gut wie möglich angleichen. Drei Speicherteiler sind ja vorhanden. :)

[S940]

Argh... dann hat der Clarkdale auch einen anderen IMC?
Jo, der IMC sitzt auf dem GPU DIE und wird per QPI ans CPU DIE angeflanscht. Quasi wie früher FSB, nur das QPI halt schneller ist.
http://www.xbitlabs.com/images/cpu/clarkdale-review/clarkdale-scheme.png
http://www.xbitlabs.com/articles/cpu/display/clarkdale-review_3.html

Aber sollte das nicht egal sein? Ich meine selbst mit DDR3-1600 habe ich eine Speicherbandbreite im DC von nur 10,24GB/s. Oder sinds 20,28GB/s? Wie war die Formel nochmal? :D Einfach mal 8.
1600*8 = 12,8 GB/s für single channel, dual channel dann das doppelte.
QPI bremst in dem Fall schon schön, v.a. muss auch noch der komplette PCIe 2.0 Verkehr durch ...

Edit:
Wir könnten aber den Speicherdurchsatz so gut wie möglich angleichen. Drei Speicherteiler sind ja vorhanden. :)
Kannst Du machen, aber Hauptproblem dürfte eher die Latenz sein ... Ht4U hat bei den Clarkdales eine schlechtere RAM Latenz als bei nem E8600 gemessen. Die Latenz bringst Du nur schlecht weg ... man könnte höchstens versuchen Lynnfields mit Katastrophentimings wie z.B. CL12 und DDR3-1066 auszubremsen. Aber wie genau das dann wäre, und ob die BIOSe sowas zuließen .. :uponder:

Aber selbst wenns ginge, das Verhalten des gemeinsame "QPI-FSBs" inklusive PCIe Verkehr ist schlecht vorauszusagen.

ciao

Alex

[Gast]

Jo, der IMC sitzt auf dem GPU DIE und wird per QPI ans CPU DIE angeflanscht. Quasi wie früher FSB, nur das QPI halt schneller ist.
http://www.xbitlabs.com/images/cpu/clarkdale-review/clarkdale-scheme.png
http://www.xbitlabs.com/articles/cpu/display/clarkdale-review_3.html


Der L3-Cache sitzt aber auf dem CPU-Die.

[S940]

Der L3-Cache sitzt aber auf dem CPU-Die.Hab ich was anderes behauptet ?

[dargo@work]

Wie hoch ist eigentlich der Durchsatz vom QPI beim Clarkdale?

[S940]

Wie hoch ist eigentlich der Durchsatz vom QPI beim Clarkdale?
Bei 3,2 GHz Takt sollten es 2 x 12,8 GB/s (up/down) sein. Nach dem Speicherbenches bleiben wohl am Ende effektiv ~10-11 GB/s übrig.

[dargo]

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

[Hvoralek]

Mittlerweile profitieren wohl die meisten Spiele schon ganz ordentlich von drei/vier Kernen. Seit dem Umstieg auf das i5- System war die Skalierung nur bei TDU wirklich schwach.

[dargo]

Mittlerweile profitieren wohl die meisten Spiele schon ganz ordentlich von drei/vier Kernen. Seit dem Umstieg auf das i5- System war die Skalierung nur bei TDU wirklich schwach.
Ja, so kann mans sagen. Mit dem Yorkfield konnte ich architekturbedingt nicht das Ausmaß der Quadcoreskalierung zeigen. Nur TDU "tanzt" hier ganz schön aus der Reihe. Mir ist bei TDU aber ein kleiner Fehler gerade aufgefallen - die 1712Mhz DC erreichen die Werte vom 1574Mhz TC und nicht QC. Da muss ich den nötigen DC nochmal testen. Mich würde aber brennend interessieren was die vollen 8 MB L3 Cache dem Lynnfield bringen. Wenns nämlich viel ist könnte es schon Games geben die den Quad perfekt auslasten. Bei RE5 habe ich zwar +82% gemessen, durch den Cache-Vorteil wäre es aber auch denkbar, dass es real an die +~100% sind.

Edit:
TDU korrigiert. Es werden 1,8Ghz DC benötigt um mit dem 1,57Ghz QC gleichzuziehen.

Jo, der IMC sitzt auf dem GPU DIE und wird per QPI ans CPU DIE angeflanscht. Quasi wie früher FSB, nur das QPI halt schneller ist.
http://www.xbitlabs.com/images/cpu/clarkdale-review/clarkdale-scheme.png
http://www.xbitlabs.com/articles/cpu/display/clarkdale-review_3.html

Hast du zufällig so ein Schaubild auch vom Lynnfield und Yorkfield/Kentsfield?

[Undertaker]

Lynnfield
http://www.abload.de/img/intel_lynnfield_core-i37bj.jpg (http://www.abload.de/image.php?img=intel_lynnfield_core-i37bj.jpg)

Nehalem
http://www.abload.de/img/intel_lynnfield_core-ifkvh.jpg (http://www.abload.de/image.php?img=intel_lynnfield_core-ifkvh.jpg)

Penryn
http://www.abload.de/img/penryn_plattform4moj.png (http://www.abload.de/image.php?img=penryn_plattform4moj.png)

[dargo]

Danke schon mal, was besseres gibts aber nicht? Ich würde gerne die Anbindung an den IMC, L3 etc. beim Lynnfield und Nehalem sehen.

[Undertaker]

Hmm, Speichercontroller und L3 sind bei Nehalem und Lynnfield doch on-die - hier sollte es keine Nadelöhre geben. :confused:

[dargo@work]

Argh... sorry, mein Fehler.

[dargo]

NfS-Shift ist auch soweit.
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=6973305&postcount=2

[dargo]

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

[dargo]

Mir ist etwas seltsames in der Mafia II-Demo aufgefallen. Ich frage mich gerade was die Engine hier anstellt? Wollte gerade die Demo auf Multithreading untersuchen. Mein i5-750 ist mit 3,7Ghz getaktet. Auflösung war 640x480 1xAA/1xAF, Details @max. und APEX aus. Ich komme also ganz am Anfang aus dem Haus, die Framerate liegt bei ~80fps. Dachte mir sofort, puh das Game braucht ganz schön viel CPU-Leistung, kurz auf den Desktop geswitscht - alle 4 Cores fast am Anschlag. Dann wieder ins Spiel rein und habe einfach paar Sekunden gewartet und nichts getan. Plötzlich geht die Framerate auf ~150fps hoch. :| Der Witz an der Sache ist, wenn ich bei den 150fps wieder auf den Desktop gehe und zurück ins Spiel sinds wieder 80fps. Was ist denn hier los? Außerdem werden bei den 150fps insgesamt dann nur noch 3 Cores ausgelastet.

[=Floi=]

warum sind die unteren cod mw 2 werte höher bei weniger mhz und wohl gleichen settings und gleicher demo?!

[dargo]

warum sind die unteren cod mw 2 werte höher bei weniger mhz und wohl gleichen settings und gleicher demo?!
Wie meinen? Es sind übrigens immer Savegames der Vollversionen.

[=Floi=]

sind die unteren werte mit dem neuen system gemacht worden? ich bin davon ausgegangen, dass alles mit der selben kombi gefahren wurde.

du könntest mal bei den bildern noch die hardware und treiberversionen integrieren.

oben:
http://img707.imageshack.us/img707/2493/cod62.png

unten:
http://img51.imageshack.us/img51/1713/cod6i5.png

[dargo]

Achso... das meinst du. Das obere Diagramm ist vom Yorkfield-System. :)
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=440739

[=Floi=]

liegt die leistungssteigerung am IMC und den restlichen neuerungen in der infrastruktur, oder liegt das an der gesteigerten pro mhz leistung?

[dargo]

liegt die leistungssteigerung am IMC und den restlichen neuerungen in der infrastruktur, oder liegt das an der gesteigerten pro mhz leistung?
An beidem. Wobei die gestiegene Pro/Mhz Leistung unter anderem aus dem IMC etc. resultiert. Ich würds mal so formulieren - Die Leistungssteigerung resultiert aus der höheren Pro/Mhz Leistung und der besseren Multicoreauslastung durch den Wegfall vom FSB.

[=Floi=]

also da bekommst du schon lob von mir. so "direkt" habe ich den vergleich Q9XXX zu I7 auch noch nicht gesehen. schon erstaunlich was hier möglich ist, wenn die cpu wirklich gefordert wird und wenn andere limitierungen rausfallen.


edit
also die grafikkarte war schon gleich?

[dargo]

also da bekommst du schon lob von mir.

Danke. :)


so "direkt" habe ich den vergleich Q9XXX zu I7 auch noch nicht gesehen. schon erstaunlich was hier möglich ist, wenn die cpu wirklich gefordert wird und wenn andere limitierungen rausfallen.

Nun, es war schon länger bekannt. Früher konnte es nur Niemand zeigen da durchgehend mit nichts sagenden Timedemos gebencht wurde. Bei Timedemos ist die CPU-Last halt dermaßen niedrig, dass es mit den üblichen Grafikkarten kaum ersichtlich war. Erst mit CF/SLI hat man bei Timedemos den tatsächlichen Unterschied zeigen können. Zwei Grafikkarten hatten halt dermaßen Power, dass selbst die niedrige CPU-Last der Timedemos zu heftigen CPU-Limits führte.


also die grafikkarte war schon gleich?
Bei dem Yorkfield war noch eine übertaktete GTX260 im Einsatz. Das spielt aber keine Rolle denn meine Savegames sind immer zu 100% cpu-limitiert. Das wird mit der schnellsten Test-CPU-Taktfrequenz von mir stets vorher geprüft.

[y33H@]

Bei Taktgleichheit ist ein Lynnfield einem Yorkfield je nach Spiel 20 bis über 50% voraus, das ist ziemlich krass.

[Fetter Fettsack]

Der Witz an der Sache ist, wenn ich bei den 150fps wieder auf den Desktop gehe und zurück ins Spiel sinds wieder 80fps. Was ist denn hier los? Außerdem werden bei den 150fps insgesamt dann nur noch 3 Cores ausgelastet.

Gibt es dann irgendwelche spieltechnischen Auffälligkeiten, wenn diese Sympthome auftreten?

[dargo]

Bei Taktgleichheit ist ein Lynnfield einem Yorkfield je nach Spiel 20 bis über 50% voraus, das ist ziemlich krass.
Bei RE5 sind es weit mehr als +50%, nämlich fast +100%. Sobald eine Engine stark von 4 Cores profitiert nimmt der Vorsprung vom Lynnfield bzw. Nehalem deutlich zu.

Gibt es dann irgendwelche spieltechnischen Auffälligkeiten, wenn diese Sympthome auftreten?
Nein, mir ist nichts aufgefallen.

[Fetter Fettsack]

Ich frage deshalb, weil es vielleicht sein könnte, dass da irgendein spielinterner Dienst, der viel berechnen lässt, das switchen nicht verträgt. Deshalb auch die Erkundigung nach den Auffälligkeiten, ob womöglich irgendwelche Effekte "weniger" werden.

Was macht dann eigentlich der vierte Kern?

[dargo]

Was macht dann eigentlich der vierte Kern?
Du beziehst dich hier wohl auf die Aussage, dass nach paar Sekunden 3 Cores ausgelastet werden oder? Nun, zwei Cores laufen am Anschlag und zwei Cores zu je ~50%. Deswegen die Aussage von mir bezüglich 3 Cores-Auslastung.

[Ph0b0ss]

Mir ist etwas seltsames in der Mafia II-Demo aufgefallen. Ich frage mich gerade was die Engine hier anstellt? Wollte gerade die Demo auf Multithreading untersuchen. Mein i5-750 ist mit 3,7Ghz getaktet. Auflösung war 640x480 1xAA/1xAF, Details @max. und APEX aus. Ich komme also ganz am Anfang aus dem Haus, die Framerate liegt bei ~80fps. Dachte mir sofort, puh das Game braucht ganz schön viel CPU-Leistung, kurz auf den Desktop geswitscht - alle 4 Cores fast am Anschlag. Dann wieder ins Spiel rein und habe einfach paar Sekunden gewartet und nichts getan. Plötzlich geht die Framerate auf ~150fps hoch. :| Der Witz an der Sache ist, wenn ich bei den 150fps wieder auf den Desktop gehe und zurück ins Spiel sinds wieder 80fps. Was ist denn hier los? Außerdem werden bei den 150fps insgesamt dann nur noch 3 Cores ausgelastet.

Das komische Verhalten hab ich auch. Beim zurückswitchen ins Spiel nur die hälfe der fps und dann sogar 80% Auslastung mit HT! Nach einigen Sekunden dann wieder normale fps und nur 40% Auslastung mit HT.

[dargo]

Das komische Verhalten hab ich auch. Beim zurückswitchen ins Spiel nur die hälfe der fps und dann sogar 80% Auslastung mit HT! Nach einigen Sekunden dann wieder normale fps und nur 40% Auslastung mit HT.
Danke, ich dachte schon ich wäre der einzige mit diesem Phänomen. :freak:
An der Demo scheint so einiges nicht zu stimmen, mal die Full abwarten.

[Undertaker]

Hmm, sowas ist bei mir nicht zubeobachten, zumindest nicht so deutlich. 95-105fps, wenn ich direkt nach dem Start aus dem Haus laufe. Switch zum Desktop, Auslastung lag bei 60-80%. Switch zurück, nur noch ~80fps - steigt nach einigen Sekunden sprunghaft wieder auf 95-105. Auslastung weiterhin konstant bei 60-80% auf 6 Kernen.

-------------------------------------------------------------

Mal was ganz anderes: Bei der Untersuchung einiger Spiele auf 6-Core Profite fiel mir in Bad Company 2 folgendes auf:

Taktrate 1,25GHz, 1024x768 max. Details:

1/2/3/4/5/6 Kerne:

http://www.abload.de/thumb/bfbc2game2010-08-1511-bwu0.png (http://www.abload.de/image.php?img=bfbc2game2010-08-1511-bwu0.png)http://www.abload.de/thumb/bfbc2game2010-08-1511-mk91.png (http://www.abload.de/image.php?img=bfbc2game2010-08-1511-mk91.png)http://www.abload.de/thumb/bfbc2game2010-08-1511-5m1l.png (http://www.abload.de/image.php?img=bfbc2game2010-08-1511-5m1l.png)http://www.abload.de/thumb/bfbc2game2010-08-1511-kvqy.png (http://www.abload.de/image.php?img=bfbc2game2010-08-1511-kvqy.png)http://www.abload.de/thumb/bfbc2game2010-08-1511-em1n.png (http://www.abload.de/image.php?img=bfbc2game2010-08-1511-em1n.png)http://www.abload.de/thumb/bfbc2game2010-08-1511-0mqd.png (http://www.abload.de/image.php?img=bfbc2game2010-08-1511-0mqd.png)

Von 1-3 Kerne skaliert das Spiel zunächst einmal exzellent, auf 4 Kerne ist ebenfalls noch ein messbarer Schub vorhanden. Jetzt wird es aber eigenartig: Während die Bildrate mit 5 Kernen nochmals ein kleines Stückchen steigt, fällt sie mit 6 Kernen reproduzierbar ab - und zwar bis auf das Niveau des 3-Kerners. :confused: Irgendwelche Ideen, was da falsch läuft?

[Fetter Fettsack]

Zitat von dargo

Deswegen die Aussage von mir bezüglich 3 Cores-Auslastung.

Jop, dann hab ich das falsch verstanden.

Komisch, dass Ph0b0ss ebenfalls mit einer Intel-CPU diese Auswirkungen hat. Ich nehme an, dass seine CPU ebenfalls aus der i-X Reihe stammt, vielleicht verträgt sich da irgendein Feature sonderbarer Weise nicht mit dem Switchen. Vielleicht sollte jemand mit einer S775 CPU ebenfalls Nachschau halten, wie sich die Demo dort verhält.

Zitat von Undertaker

Irgendwelche Ideen, was da falsch läuft?

CPU-Limit :ulol:

Gibt es irgendein auffälliges Verhalten bzw. gröbere Unterschiede bei der Auslastung zwischen 5 Kernen und 6?

[dargo]

Irgendwelche Ideen, was da falsch läuft?
Eventuell ist der Windows-Sheduler für dieses Problem verantwortlich?

Edit:
Mal eine ganz blöde Idee - das Spiel kennt keinen Sechskerner und schaltet auf 3 Cores um? Ein ähnliches Problem gabs schon bei DIRT 1. Das Spiel brach mit 3 Cores extrem ein.
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=6973301&postcount=1

[OT71]

Eventuell ist der Windows-Sheduler für dieses Problem verantwortlich?

Edit:
Mal eine ganz blöde Idee - das Spiel kennt keinen Sechskerner und schaltet auf 3 Cores um? Ein ähnliches Problem gabs schon bei DIRT 1. Das Spiel brach mit 3 Cores extrem ein.
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=6973301&postcount=1


ja kann ich bestätigen....dirt I bricht bei einem X3 egal ob athlon II oder phenom auf das niveau einer single cpu ein.

erst nach dem ich den X3 im bios zu einem X2 gemacht hatte gingen frames wieder hoch....

[Undertaker]

Hmm, wäre eine Möglichkeit, allerdings umso merkwürdiger, dass dann der eigentlich noch unüblichere 5-Kerner so gut performt... Na wer weiß.

[dargo@work]

Hmm, wäre eine Möglichkeit, allerdings umso merkwürdiger, dass dann der eigentlich noch unüblichere 5-Kerner so gut performt... Na wer weiß.
Der wird wahrscheinlich als 4 Kerner erkannt. ^^

[Schlammsau]

Kann man eigentlich in Windows 7, einzelnen Games oder Programmen bestimmte Cores zuweisen?
Meinetwegen für DiRT2 zB nur 4 Kerne usw.....

[Undertaker]

Taskmanager -> Zugehörigkeit festlegen.

[Schlammsau]

Taskmanager -> Zugehörigkeit festlegen.
Ok.....

[L.ED]

Tut es Dieses Tool unter Vista/Windows 7 nicht mehr?: EasyToolz (http://home.arcor.de/jasonvoorhees2k/index.html?titleFrame=programme/programme.html&mainFrame=programme/easytoolz.html)

Relativ geniales, klein, schlicht, flott, mit nur einem einzigen wirklich Manko, man kann damit keine nativen 64bit.exe automatisiert Verwalten. Hmm ob man den Autor mal Kontaktiert(?), sollte doch nicht all Zuviel Arbeit machen dieses Manko fix zu beheben (als 64Bit nativ Version reicht vermutlich hier schon)?

Sollte es unter Win7 nicht mehr laufen(?), wäre es für mich Persönlich ein Grund mehr weiterhin nicht all zu bald zu wechseln. Denn beinahe ebenso gewichtig hier die ebenfalls enthaltene automatisierte Prioritätssteuerung (absolut Top).

PS:
Wenn schon halt nötig, dann komfortabel, mit dem Taskmanager rumzueiern ist alles andere als das, insbesondere wenn man sich schon an was anderes gewöhnt. ^^

[Ph0b0ss]

Es gibt noch "Process Lasso". Damit kann man auch einzelne Prozesse an bestimmten CPUs zuweisen. Kann man dann auch speichern, damit bestimmte Prozesse immmer auf den zugewiesenen Kernen laufen.

[L.ED]

Dieses Tool scheint es tatsächlich zu bringen und ist u.a. hier *Download* (http://www.netzwelt.de/download/6475-process-lasso.html) in der vermutlich aktuellsten frei Version zu bekommen.

PS:
Bringt es auf dem 2then leider doch nicht ganz, es unterscheidet nicht ohne weiteres wenn ein Programm mehrfach gestartet wird und man diese z.b. an unterschiedliche Kerne nebst Prioritäten binden möchte = nicht möglich (beispielsweise für mmorpg clienten interessant). Soweit auf dem 2then Blick, mag aber sein das was übersehe, an Optionen wird man ja erstmal wieder erschlagen. :/

PPS:
EasyToolz kann besagtes wenn die Programme in getrennten Ordnern doppelt vorgehalten, oder alternativ die .exe nochmal unter einem anderen Namen, das könnte möglicherweise hier auch Funktionieren ist aber ab und an so leider nicht überall gangbar und von daher suboptimal.

[dargo]

Ich versuche gerade Mass Effect 2 auf die Kernskalierung zu untersuchen und stoße dabei auf zwei merkwürdige Sachen.

1. Auf einem Dualcore varieren die Frames deutlich stärker in meinem Savegame als auf einem Triple- und Quadcore. Der 2,33Ghz DC schwankt in der Szene zwischen ~80 und 90fps. Das dumme ist dann, dass man bei den tatsächlichen Ergebnissen wirklich einmal beispielsweise 80, 85, 90 avg.fps bekommt. Eine exakte Vergleichbarkeit ist also hier schwierig.
2. Der Quadcore kann kaum mehr Frames liefern als der Triplecore, was der Taskmanager übrigens auch wunderbar wiederspiegelt. Der Dualcore bricht aber extrem ein.

Gerade Punkt 2 verwundert mich sehr.

[san.salvador]

Wieso verwundert das? Das Spiel scheint für drei Cores (hat die Xbox, wenn ich mich nicht irre) optimiert zu sein.

[dargo]

Wieso verwundert das? Das Spiel scheint für drei Cores (hat die Xbox, wenn ich mich nicht irre) optimiert zu sein.
Ich habe mich vielleicht falsch ausgedrückt. Der Triplecore legt ca. 78% gegenüber dem Dualcore zu. Eigentlich dürften es ca. 50% sein. Ich frage mich warum der Zuwachs durch den dritten Kern so überproportional steigt. Dass die Auslagerung von Treibern, OS etc. soviel ausmachen soll kann ich kaum glauben.

Edit:
Übrigens ich habe eine Lösung für den ersten Punkt gefunden. Vorher lag der Durchschnitt aus dem kleinsten und größten Ergebnis bei ca. 6% in jede Richtung (für meinen Geschmack eine zu große Abweichung). Jetzt habe ich es hinbekommen, dass es nur noch ~3,5% sind. Da kann man schon eher gebrauchen. :)

[Undertaker]

Ich habe mich vielleicht falsch ausgedrückt. Der Triplecore legt ca. 78% gegenüber dem Dualcore zu. Eigentlich dürften es ca. 50% sein. Ich frage mich warum der Zuwachs durch den dritten Kern so überproportional steigt. Dass die Auslagerung von Treibern, OS etc. soviel ausmachen soll kann ich kaum glauben.

Das kannst du über Tests mit verschiedenen Taktraten herausfinden. Schwindet der Zuwachs mit höherem Takt bzw. steigt mit niedrigerem Takt noch weiter an, deutet das klar auf Grundlast.

[dargo]

Das kannst du über Tests mit verschiedenen Taktraten herausfinden. Schwindet der Zuwachs mit höherem Takt bzw. steigt mit niedrigerem Takt noch weiter an, deutet das klar auf Grundlast.
Das ist auch meine Vermutung. Wenns tatsächlich so ist dann hat ME2 aber eine verdammt hohe Grundlast. Immerhin sind wir mit einem Lynnfield @2,33Ghz DC bei ~85fps. :eek: Naja, ich muss erstmal die Tests komplett fertig haben. Dann können wir der Sache auf den Grund gehen. :)

Edit:
Mass Effect 2 ist fertig:
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=6973305&postcount=2

Der Triplecore legt wie gesagt ordentlich zu, Quad ist um ~81% schneller als DC.

[Fetter Fettsack]

Wenn sich User melden, die eine Sandy Bridge CPU gekauft haben, würdest du es dann begrüßen, wenn die sich hier betätigen?

[dargo]

Inwiefern betätigen? An der Kernskalierung in Games wird sich durch SB im Vergleich zum Lynnfield (außer SMT) nichts ändern.

[Fetter Fettsack]

Nun, ob es Sinn macht, wollte ich ja erfragen. :)

[sentinel_first]

Das Problem mit den Kernen skalieren ist auch immer eine Fleißaufgabe der Programmierer, bzw. auch der Engine.

Problem ist:

- 4 (parallele relativ gleichmäßige) Aufgaben auf 4 Kerne zu verteilen ist trivial
- 4 Aufgaben auf 2 Kerne zu verteilen ist es quasi auch
- 4 Aufgaben auf 3 Kerne zu verteilen ist nicht so toll, im besten Fall bekommt ein Kern 2 Aufgaben und die Gesamtlösung dauert genauso lange wie bei einem 2 Kerner, da der Coremanager allerdings freie Kapazitäten sieht entlastet er einen doppelt belasteten Kern von einer Aufgabe und teilt diese dem freien Kern zu, welcher natürlich von Anfang an wieder rechnen muss und schon ist ein 3 Kerner etwas langsamer als ein DC und nicht zu vergessen ist die erforderliche Synchronität der Aufgaben, welche sich stetig abhängige Teilergebnisse austauschen müssen

Die neueren Spieleengines sollen diese Probleme aber wohl komplett im Hintergrund problemlos beherschen können, eigentlich sollte es nur noch bei älteren Spielen und evtl. bei schlechten Konsolenports auftreten (3-Kern X-BOX oder andere BOX k. A.).

So wurde es mir zumindestens mal erklärt :cool:

[Mad-Marty]

4 Aufgaben auf 3 Kerne ist überhaupt kein Problem. Die gleichen sich Rechenlasttechnisch doch eh komplett aus. Da greift dann normales TimeSlicing.

Und wenn schon mit Synchronisationspunkten gearbeitet wird zwischen Threads, rechnet ein Kern bestimmt nicht nochmal von vorn weil die anderen hinterher hinken ... er wird einfach warten.
Wäre ja ziemlich blöd das selbe nochmal rechnen zu lassen von denjenigen Programmierern.

[dargo]

NfS: Hot Pursuit ist fertig. :)
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=6973305&postcount=2

[dargo]

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

Meine Güte... das Spiel ist die reinste Katastrophe was die Ausnutzung moderner Prozessoren angeht. Dabei sollte es eine überarbeitete Engine sein. :ugly: Katastrophe in zweierlei Hinsicht. Erstens hat das Spiel von sich aus schon eine extreme CPU-Last. Zweitens verschenkt man unheimlich viel Leistung da die Engine über einen Dualcore praktisch nicht mehr skaliert. Und sowas setzt man 2011 in die Welt. :facepalm:

Übrigens - falls immer noch einige der Meinung sind ich würde in praxisfremden Settings testen bietet sich Shift 2 wie Faust aufs Auge an.

i5-750@2332Mhz, GTX470@680Mhz

http://s7.directupload.net/images/110409/jw44ge72.jpg


http://s1.directupload.net/images/110409/jtvcyzyg.jpg

Der eine Frame resultiert aus anderem Seitenverhältnis. Den Post muss ich mir irgendwo antackern. Denn, die Diskussionen wirds garantiert irgendwann wieder geben. :D

[Fetter Fettsack]

Und sowas setzt man 2011 in die Welt.

Weil man sich damit Kosten sparen will? Wäre meine Vermutung.

[airbag]

Ist halt alles zu einfach gesagt. Gerade eine vernünftige Implementierung dürfte Unmengen Zeit und Arbeit kosten bzw. kann so einige Probleme verursachen.

Mal ein simples Beispiel

Beim Threading sollte generell darauf geachtet werden, das jeder Thread sein eigenes Objekt hat. Kleines Beispiel. Ich hatte Übung 9 mit Threads geschrieben. Dabei hab ich darauf vertraut, dass Math.random() eine statische Funktion ist. Das Problem ist, dass Math.random auf eine Instanz von Random zurückgreift. Jetzt haben dort 4 Threads 1 Objekt benutzt. Dadurch ging die Performance in den Keller.

[dargo]

Weil man sich damit Kosten sparen will? Wäre meine Vermutung.
Ich kann das mit den Kosten bald nicht mehr hören. Obwohl es sicherlich möglich und auch legitim wäre. Im Prinzip haben sie an der Engine was Kernskalierung angeht zu Shift 1 absolut nichts geändert. Das hat genauso beschissen skaliert. Das Problem ist nur hierbei, dass die Frames sich in Shift 2 fast halbiert haben. Gerade bei solchen Games wo eine extreme CPU-Last herrscht erwarte ich eine wesentlich bessere Kernskalierung. Ich frage mich auch gerade wie die Konsolen da noch die 30fps durchgehend halten können? Bei einer 1:1 Umsetzung ist das nämlich unmöglich. Es gibt drei Möglichkeiten:

1. Die CPU-Last bei Konsolen ist wesentlich geringer. Keine Ahnung wo da gespart wurde. Eventuell an der Physik?
2. Haben die Konsolen keine 16 Fahrzeuge auf der Strecke.
3. Die PC-Version ist total vermurkst. Eventuell kann hier ein späterer Patch noch was rausholen. Ich werde das mal im Auge behalten.

[Fetter Fettsack]

Ich kann das mit den Kosten bald nicht mehr hören.

Ändert leider nichts daran, das es wahrscheinlich so ist.

[dargo]

Ich habe endlich eine geeignete Stelle in Crysis 2 gefunden die auch reproduzierbar getestet werden kann. Hatte ich schon mal gesagt, dass ich Spiele ohne freies Speichern hasse? :mad: :P Das Ergebnis poste ich aber erstmal unter Vorbehalt da es nicht ganz Sinn ergibt.
http://s1.directupload.net/images/110411/lx9ur4j7.png
So muss eine moderne Engine skalieren. :up: Da muss ich ein dickes Lob an das Crytek-Team aussprechen. Ich hoffe bloß in Zukunft kommen mehr Spiele mit der CE3 raus. Ein Dualcore wird gnadenlos vernichtet. Eine perfekte Skalierung vom Quad.

Das einzige was mir hier Sorgen macht sind die Ergebnisse vom 1574Mhz DC und 1872Mhz DC. Das ergibt einfach keinen Sinn. Ich habe hier den FW270.51 in Verdacht. Hatte vorher schon die gleiche Szene mit dem FW270.32 getestet und da war ein 2332Mhz QC erheblich langsamer als ein 2332Mhz TC (was ebenfalls Murks ist). Igendwas ist faul an der 270-er Serie. Ich werde den Test also nochmal mit einem offiziellen, aktuellen Forceware wiederholen.

Edit:
Habe den Fehler gefunden. Wie ich vermutet hatte ist für dieses Missgeschick die 270-er Serie, zumindest in Crysis 2 verantwortlich. Mit dem FW267.91 passt es wunderbar. Und somit wäre Crysis 2 nun auch fertig.
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=6973305&postcount=2

Bitte mehr von solchen Engines. :up: Hier wäre sicherlich auch interessant zu erfahren wie weit noch ein Sechskerner skaliert. :)

[Kladderadatsch]

http://s1.directupload.net/images/110411/lx9ur4j7.png

Edit:
Habe den Fehler gefunden. Wie ich vermutet hatte ist für dieses Missgeschick die 270-er Serie, zumindest in Crysis 2 verantwortlich. Mit dem FW267.91 passt es wunderbar. Und somit wäre Crysis 2 nun auch fertig.
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=6973305&postcount=2

komisch, du schreibst in deinem link "diesmal nicht mit maximalen details, da dann schon die graka limitieren würde", hast bei 1800mhz qc aber 10 fps weniger. macht der forceware so einen unterschied?:confused:

[dargo]

komisch, du schreibst in deinem link "diesmal nicht mit maximalen details, da dann schon die graka limitieren würde", hast bei 1800mhz qc aber 10 fps weniger. macht der forceware so einen unterschied?:confused:
Du musst das relativ sehen. Die 8fps sind nur 5%. Außerdem schwanken die Frames in meiner Testszene etwas wo du bei den avgs. eine Abweichung zum höchsten oder niedrigsten Wert (ich teste ja mit 4 Durchläufen und nehme davon den Durchschnitt) von ca. 2% haben kannst. Zusätzlich sehe ich die 270-er Serie als problematisch an denn ein 2332Mhz QC lieferte mir in der Szene mit einem FW270.32 noch um die 155fps wo ein FW270.51 194fps lieferte (leichtes GPU-Limit).

[Kladderadatsch]

also der forceware. krass, so riesige unterschiede gab es früher (vor ~5-7 jahren) imo nicht. aber ich habe ehrlich gesagt auch noch nie 4 durchläufe pro setting gemessen. du bist ja wahnsinnig:D

[dargo]

Wie gesagt, 5% sind fast nichts wenn man rauf/runter noch ~2 prozentige Abweichungen bei den Werten berücksichtigt. Und 4 Durchläufe je Setting sind gar nichts. Früher hatte ich 6 genommen, und dann
sogar mit 3 verschiedenen CPU-Taktraten. :D Ist aber beruhigend zu wissen, dass du den Aufwand einschätzen kannst.
Es gibt halt Spiele und Szenen die sich unterschiedlich verhalten. Bei manchen Spielen würdest du theoretisch mit nur einem Durchgang zurechtkommen weil die Frames bei jedem Durchgang bombenstabil sind
und sich quasi nur hinter dem Komma minimal unterscheiden. Andere haben wiederum etwas größere Abweichung. Mit 4 Durchläufen von avg.fps und davon noch der Durchschnitt bekommt man aber schon sehr
brauchbare Werte.

Edit:
Übrigens, dass Messschwankungen da sind sieht man gleich an den Werten. 1872Mhz heißt knapp 19% mehr CPU-Power als 1574Mhz. Wenn wir jetzt meine gemessenen Werte vergleichen.

1574Mhz QC = 139,10
1872Mhz QC = 161,95
Frames steigen um 16,4%.

1574Mhz TC = 119,75
1872Mhz TC = 139,00
Frames steigen um 16%.

Du siehst also hier schon, dass die Frames eigentlich um knapp 19% steigen müssten wenn die Szene zu 100% cpu-limitiert ist. Und das ist sie. Liegt wie gesagt an den kleinen Messschwankungen. Hätte ich folgende Konstellation:

1574Mhz QC = 137,80
1872Mhz QC = 163,90

hätte man exakt mehr Frames was die CPU auch mehr taktet. Stellst du jetzt die einzelnen Werte gegenüber - 137,8 zu 139,1 und 161,95 zu 163,90 ist die Abweichung in beiden Beispielen je nur lächerliche ~1%. Bei den Dualcores sieht es schon etwas anders aus da man sich der Grundlast nähert. Dort legt die 1872Mhz CPU gleich um 25% zu bei 19% höherem Takt. Ist völlig normal wenn man sich in der Nähe der Grundlast bewegt.

[blackbox]

Wenn man sich den neuen I3 Prozessor anschaut, dann könnte man wieder ins Grübeln kommen.... von wegen Kerne sind wichtig...... ;)

[y33H@]

Im Zweifel fährt man mit wenigen dicken Kernen halt besser.

[Raff]

Und nur weil die meisten Spiele kotig skalieren, heißt das nicht, dass die Zusatzkerne sinnlos sind. Abseits des Zockings bringt jeder Kern mehr Bums – wobei Takt natürlich immer sinnvoll ist, wenn mal wieder Befehle seriell abgearbeitet werden.

Bitte mehr von solchen Engines. :up: Hier wäre sicherlich auch interessant zu erfahren wie weit noch ein Sechskerner skaliert. :)

Was für ein Level/Checkpoint ist das denn? =)

MfG,
Raff

[dargo]

Was für ein Level/Checkpoint ist das denn? =)

Masken runter, steht beim Diagramm dabei.

[y33H@]

In dem Level gibt's mehrere Checkpoints. Kannst du es hochladen?

[dargo]

Und nur weil die meisten Spiele kotig skalieren, heißt das nicht, dass die Zusatzkerne sinnlos sind. Abseits des Zockings bringt jeder Kern mehr Bums – wobei Takt natürlich immer sinnvoll ist, wenn mal wieder Befehle seriell abgearbeitet werden.

Wenn ich meine Videos in MKV oder MP4 umwandle wäre ein 6 Kerner auf Basis von Sandy Bridge nicht schlecht.

[Raff]

Masken runter, steht beim Diagramm dabei.

Meh, ich hab das verlinkte Posting nicht gelesen. K, das sehe ich mir mal an. Da bin ich aber noch nicht ... :D

In dem Level gibt's mehrere Checkpoints. Kannst du es hochladen?

... daher wäre das eine gute Idee.

MfG,
Raff

[dargo]

In dem Level gibt's mehrere Checkpoints. Kannst du es hochladen?
Wenn du mir sagst wie ich schnell das passende Savegame im entsprecheden Ordner finde:freak:... kein Problem.

Edit:
Oder stimmt das mit der Nummer überein? Warte mal... muss ich kurz testen.

[y33H@]

Einfach nach Datum sortieren, denn das "Fortsetzen"-Save ist idR das neueste. Dummerweise sind die Nummern fürn Ar*** und selbst Saves benennen darf man bei diesem Konsolen-Port auch nicht.

[dargo]

Boah... die Nummerierung ist echt was für den Anus. :freak:

Savegame zum nachmachen (http://www.multiupload.com/5OEAL95RWO)

Hinweis:
Benchen natürlich erst nach dem zweiten Laden. Direkt nach dem Laden den Panzermodus einschalten damit man etwas länger lebt. Die Waffe schnell so ausrichten, dass das Crosshair auf die Mitte der Tür hinten zeigt und sich selbst nicht bewegen. Die Position sich möglichst genau für weitere Durchläufe merken. Taste zum benchen erst drücken wenn der Hinweis mit der F-Taste erscheint. Ich habs hier wie immer 5 Sekunden gebencht.

Testet bitte falls möglich einen Sechskerner mit einer GTX580 bei einem vollständigen CPU-Limit. Das würde mich echt interessieren.

[y33H@]

Raff hat doch seinen X6 und eine GTX 580. Vll ist er ja so lieb =)

[dargo]

Raff hat doch (m)einen X6 und eine GTX 580. Vll ist er ja so lieb =)
Ein X6 wäre ideal da die Pro/Mhz-Leistung nicht so hoch ist. Zur Not muss er mit dem Takt etwas runter. Wie man aber feststellt ob eine Szene zu 100% cpu-limitiert ist brauche ich Raff wohl nicht erklären. :wink:

[Geächteter]

Wenn man sich den neuen I3 Prozessor anschaut, dann könnte man wieder ins Grübeln kommen.... von wegen Kerne sind wichtig...... ;)
Bei FSX benötigt man mehr als 2 Kerne, ansonsten gibt es dort spürbare Mikroruckler, speziell wenn die fps bei um die 20 und kleiner rumdümpeln, was sie bei FSX häufig tun. :freak:
Mit Triple und höher sind se weg bei gleicher fps. :)

[blackbox]

Ja, aber schau dir mal an, was der neue I3 so alles wegputzt...... irgendwie ist der I3 sowieso hier im Forum etwas unterrepräsentiert.

[Nightspider]

Wenn man sich den neuen I3 Prozessor anschaut, dann könnte man wieder ins Grübeln kommen.... von wegen Kerne sind wichtig...... ;)

Wenn ich mal mit dem I3 Bad Company 2 zocken würde, würde ich mich insgeheimfragen, was das denn für eine lahme Office CPU wäre. ;D

[Raff]

Ein X6 wäre ideal da die Pro/Mhz-Leistung nicht so hoch ist. Zur Not muss er mit dem Takt etwas runter. Wie man aber feststellt ob eine Szene zu 100% cpu-limitiert ist brauche ich Raff wohl nicht erklären. :wink:

Zur Not takte ich die Kiste via Overdrive auf 400 MHz herunter. ;D

MfG,
Raff

[dargo]

Zur Not takte ich die Kiste via Overdrive auf 400 MHz herunter. ;D

Hehe... viel weiter runter als 2,2-2,4Ghz wirst du denke ich mit der GTX580 nicht müssen. Höchstens bei max. Details und/oder wenn die Engine mit 6 Kernen noch sehr gut skaliert.

[Raff]

Die Grafikkarte kann ich auch mit 950 MHz keulen – ein Limit durch die ist ausgeschlossen. =)

MfG,
Raff

[dargo]

Die Grafikkarte kann ich auch mit 950 MHz keulen – ein Limit durch die ist ausgeschlossen. =)

Oh, sei dir da nicht so sicher. ;) Mein i5-750 @3,7Ghz dürfte die GTX580 selbst bei 1000Mhz @max. Details schon zur kleinen Limitierung führen. Die Frames wären zwar dann schon im Bereich von ca. 250-300fps, bei Limitierungen spielt aber die Framerate bekanntlich keine Rolle. Es limitiert immer was, alles eine Frage der Kräfteverhältnisse. :D

[Raff]

Savegame zum nachmachen (http://www.multiupload.com/5OEAL95RWO)

Hinweis:
Benchen natürlich erst nach dem zweiten Laden. Direkt nach dem Laden den Panzermodus einschalten damit man etwas länger lebt. Die Waffe schnell so ausrichten, dass das Crosshair auf die Mitte der Tür hinten zeigt und sich selbst nicht bewegen. Die Position sich möglichst genau für weitere Durchläufe merken. Taste zum benchen erst drücken wenn der Hinweis mit der F-Taste erscheint. Ich habs hier wie immer 5 Sekunden gebencht.

Testet bitte falls möglich einen Sechskerner mit einer GTX580 bei einem vollständigen CPU-Limit. Das würde mich echt interessieren.

Done!

Ich habe meine neue Alltagseinstellung als Basis genommen: 264x11 = 2,9 GHz bei 2.640 MHz NB-, 2.212 HT- und 880 MHz RAM-Takt. Der Multiplikator lässt sich hier minimal auf 8 senken – und damit habe ich die folgenden Werte ermittelt: 264x8 = 2.112 MHz. Die GTX 580/1,5G rennt mit fetten 950/1.900/2.400 MHz und muss sich nur mit 800x600 Pixeln herumschlagen.

Die Kerne wichen der Reihe nach via MSConfig. Ich gebe mal alle Werte an, vor allem weil die Min-Fps schwanken.

6 Kerne:
1 - Avg: 103.000 - Min: 97 - Max: 107
2 - Avg: 101.800 - Min: 97 - Max: 108
3 - Avg: 102.600 - Min: 96 - Max: 108

5 Kerne:
1 - Avg: 100.800 - Min: 93 - Max: 106
2 - Avg: 99.400 - Min: 92 - Max: 105
3 - Avg: 100.400 - Min: 94 - Max: 106

4 Kerne:
1 - Avg: 82.000 - Min: 77 - Max: 88
2 - Avg: 81.000 - Min: 75 - Max: 85
3 - Avg: 82.600 - Min: 75 - Max: 89

2 Kerne:
1 - Avg: 45.000 - Min: 36 - Max: 51
2 - Avg: 46.000 - Min: 41 - Max: 51
3 - Avg: 44.000 - Min: 36 - Max: 52


Zum Vergleich: 6 Kerne @ 2,9 GHz (+37,5 Prozent Takt)

1 - Avg: 140.000 - Min: 133 - Max: 152
2 - Avg: 139.000 - Min: 130 - Max: 150
3 - Avg: 140.400 - Min: 130 - Max: 152

Was sehen wir? Es skaliert linear mit dem Takt, ist also vollständig CPU-limitiert (yay!). Auch sehen wir, dass zwei Kerne für spielbare Fps ausreichen, der Wechsel auf vier aber immerhin ein Plus von ~82 Prozent bringt. Von 4 auf 5 steigen die Fps überraschenderweise nochmal deutlich an, nämlich von rund 82 auf rund 100 (+22 Prozent). Von 5 auf 6 ist ebenfalls eine reproduzierbare Steigerung messbar ... allerdings nur ~2 Prozent.

Oh, ich habe da ein klitzekleines Detail übersehen. X-D Fiel mir erst auf, als ich sah, dass du um Welten mehr Fps bei weniger Takt hast: Ich nutze eine "Ultra-Autoexec", die diverse Dinge voll aufrotzt (Patch 1.4 ist nicht installiert). Eventuell verfälscht das alles (zum Guten) ...

MfG,
Raff

[M4xw0lf]

Wäre das nicht toller Stoff für einen Kleinen PCGH-Artikel? ^^

[Raff]

Die sollen mal ihre PC-Kunden bedienen, dann steigt das Interesse wieder. ;)

MfG,
Raff

[dargo]

Was sehen wir? Es skaliert linear mit dem Takt, ist also vollständig CPU-limitiert (yay!). Auch sehen wir, dass zwei Kerne für spielbare Fps ausreichen, der Wechsel auf vier aber immerhin ein Plus von ~82 Prozent bringt. Von 4 auf 5 steigen die Fps überraschenderweise nochmal deutlich an, nämlich von rund 82 auf rund 100 (+22 Prozent). Von 5 auf 6 ist ebenfalls eine reproduzierbare Steigerung messbar ... allerdings nur ~2 Prozent.

Interessant finde ich hierbei, dass die AMD-CPU einen Core mehr braucht um die Frames vom Dualcore zu verdoppeln als der Lynnfield. Ich weiß allerdings nicht ob es problemlos vergleichbar ist da du eine andere Config verwendet hast. Warum eigentlich? :( Hättest du die gleichen Settings genommen hätten wir gleichzeitig eine Vergleichbarkeit zwischen Phenom II und Lynnfield. Naja... trotzdem danke für den Test.

Edit:
Oder besser ausgedrückt - warum kann der Lynnfield die Frames vom DC auf QC exakt verdoppeln wenn ein Phenom 2 die Frames "nur" um 82% steigern kann? Schließlich nutzen beide CPUs kein SMT. Und Grafiktreiber kommen auch beide von NV.


Ich gebe mal alle Werte an, vor allem weil die Min-Fps schwanken.

Hier hast du auch ein wunderbares Beispiel warum ich in Savegames von den min.fps nichts halte.
2 Kerne:
1 - Avg: 45.000 - Min: 36 - Max: 51
2 - Avg: 46.000 - Min: 41 - Max: 51
3 - Avg: 44.000 - Min: 36 - Max: 52

Im Durchschnitt ergibt sich folgendes Bild:

avg.fps = 45,00fps
min.fps = 37,66fps

Der durchschnittliche avg.wert weicht max. um knapp über 2% von den einzelnen, gemessenen Werten. Der durchschnittliche min.wert hat schon eine Abweichung von stolzen ~9%.

[Raff]

Interessant finde ich hierbei, dass die AMD-CPU einen Core mehr braucht um die Frames vom Dualcore zu verdoppeln als der Lynnfield. Ich weiß allerdings nicht ob es problemlos vergleichbar ist da du eine andere Config verwendet hast. Warum eigentlich? :(

Wie gesagt, mir ist das leider zu spät aufgefallen. Check the Anhang if you want. :)

MfG,
Raff

[dargo]

Was ist mit den Ingame-Settings? Kann ich sie auf "sehr hoch" lassen oder müssen sie auf "max." stehen? Sprich, wird die Ingame-Einstellung komplett ignoriert?

Edit:

Phenom 2 @2112Mhz (264x8)
4 Kerne:
1 - Avg: 82.000 - Min: 77 - Max: 88
2 - Avg: 81.000 - Min: 75 - Max: 85
3 - Avg: 82.600 - Min: 75 - Max: 89

i5-750 @2112Mhz (117,3x18, Speicher @587Mhz), GTX470 @680Mhz

4 Kerne:
1 - Avg: 114.200 - Min: 109 - Max: 119
2 - Avg: 114.800 - Min: 109 - Max: 119
3 - Avg: 114.200 - Min: 110 - Max: 119

Ich bin allerdings mit diesen Settings und der GTX470 schon gpu-limitiert.

i5-750 @2112Mhz (117,3x18, Speicher @587Mhz), GTX470 @607Mhz

4 Kerne:
1 - Avg: 107.600 - Min: 104 - Max: 110
2 - Avg: 109.400 - Min: 105 - Max: 112
3 - Avg: 107.400 - Min: 105 - Max: 109

Außerdem sind die Werte eh nicht genau vergleichbar da nicht klar ist ob die Flaschenhälse 1:1 bei der Taktfrequenzänderung reduziert wurden. Ich zb. kann es bei 2112Mhz gar nicht. Dazu wäre ein BLCK von 105,6 (20-er CPU-Multi) nötig womit mein Board gar nicht mehr bootet. Deshalb die 117x18.

[dargo]

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

Der Vorsprung vom Quadcore, bzw. die benötigte Taktrate beim Dualcore um auf den Wert vom QC zu kommen ist brutal in diesem Spiel. :freak: Erstaunlich aber wie wenig das Spiel von 3 Kernen profitiert.

@y33H@
Jetzt frage ich mich was hier schief gelaufen ist?
http://www.pcgameshardware.de/aid,825548/Zum-Release-Dirt-3-im-Technik-Test-Sechs-CPU-Kerne-im-Vorteil-gelungener-DirectX11-Modus/Rennspiel-Sportspiel-Simulation/Test/

Warum legt bei euch der Vierkerner so wenig zu gegenüber dem Zweikerner? :confused: In meinem Test zersägt der QC regelrecht den DC. Am Grafiktreiber kann es nicht liegen, ich verwende den selben.

[Undertaker]

Das kann ich übrigens überhaupt nicht verstehen. Mit welcher Begründung kann ein Dualcore die weit mehr als doppelte Taktrate benötigen, um auf die selben fps wie ein Quad zu kommen? Zwar halbiert sich der zur Verfügung stehende L2 Cache, so gigantische Auswirkungen sollte das aber nicht haben. Grundlast ist ebenfalls kein Argument in einer solchen Konstellation.

[ZÜNDELholz]

Warum legt bei euch der Vierkerner so wenig zu gegenüber dem Zweikerner? :confused: In meinem Test zersägt der QC regelrecht den DC. Am Grafiktreiber kann es nicht liegen, ich verwende den selben.

Liegt an der lahmen AMD-CPU. Intel skaliert da besser.

[Undertaker]

Liegt an der lahmen AMD-CPU. Intel skaliert da besser.

Der Phenom II ist zweifellos langsamer, aber die Kernskalierung sollte deswegen nicht nennenswert anders sein.

[ZÜNDELholz]

Der Phenom II ist zweifellos langsamer, aber die Kernskalierung sollte deswegen nicht nennenswert anders sein.

anscheinend doch, denn der Pfenom lahmt extrem der 580gtx hinterher.
Selbst eine Kernverdoppelung bringt da keine grossartigen sprünge . :) Siehe PCGH-Test.

[dargo]

Das kann ich übrigens überhaupt nicht verstehen. Mit welcher Begründung kann ein Dualcore die weit mehr als doppelte Taktrate benötigen, um auf die selben fps wie ein Quad zu kommen? Zwar halbiert sich der zur Verfügung stehende L2 Cache, so gigantische Auswirkungen sollte das aber nicht haben.
Ich verstehe es auch nicht ganz. Dem Dualcore steht übrigens der gesamte L2 Cache zur Verfügung. Heißt, der DC hat zumindest theoretisch sogar einen Vorteil.
Übrigens - die 4013Mhz beim DC sollte man nicht überbewerten. Ich musste den CPU-Multi schon stark von 14 auf 20 erhöhen. Dadurch entstehen größere Flaschenhälse was die Speicherbandbreite und den Uncore angeht. Würde mein Mainboard weit über 208 BCLK kommen sollten wesentlich weniger Mhz für die 78fps beim DC nötig sein. Ich schätze mal ca. 3780Mhz (14x 270) würden reichen. Das habe ich aus den Werten 2332Mhz QC vs. DC abgeleitet. In diesem Fall sagt dieser Benchmarkteil mehr aus. Wie gesagt, durch die starke Anhebung vom CPU-Multi kommt es nicht mehr zur einer 1:1 Skalierung.

Nichtsdestotrotz ist der 2332Mhz QC mehr als doppelt so schnell wie der gleichgetaktete DC. Vielleicht liegts doch an einer hohen Grundlast? :uponder: Ich werde das mal mit größeren Taktraten gegentesten, sodass ich bei der langsamen CPU auf mindestens 60fps komme. Bei der schnelleren CPU habe ich noch einiges an Spielraum nach oben offen bis die GPU anfängt zu limitieren.

Liegt an der lahmen AMD-CPU. Intel skaliert da besser.
Das würde ich dir noch glauben wenn wir hier mit einem Kentsfield oder Yorkfield vergleichen würden. Dank FSB ist die Kernskalierung bei diesen CPUs miserabel. Beim Phenom 2 gibt es aber diesen Flaschenhals nicht. Und warum skaliert der Phenom 2 mit zwei weiteren Kernen (Sechskerner) wieder so gut laut der PCGH?

[Botcruscher]

Hypothese: die CPU wird ausgelesen und die Codepfade sind eben doch nicht gleich. PS: Der PCGH Artikel schneidet das Thema Bananensoftware ja an... Fazit: Mal wieder die "Programmierqualität" bewiesen.

[ZÜNDELholz]

. Und warum skaliert der Phenom 2 mit zwei weiteren Kernen (Sechskerner) wieder so gut laut der PCGH?

Er skaliert bei zusätzlichen 2 kernen nur um ca. 40% bei den average FPS, egal ob von 2 auf 4 oder von 4 auf 6.

[dargo]

Er skaliert bei zusätzlichen 2 kernen nur um ca. 40% bei den average FPS, egal ob von 2 auf 4 oder von 4 auf 6.
Von 2 auf 4 sinds +30%. Von 4 auf 6 +45%. Im ersten Fall verdoppelt sich die Kernzahl und die Frames steigen nur um 30%. Im zweiten Fall steigt die Kernzahl nur um 50% und die Frames steigen weiter, und das sogar um einen höheren Wert als im ersten Fall. Das ergibt doch keinen Sinn. :confused:

[y33H@]

Ich hab derzeit Urlaub und bin in Paris, aber ich melde mich Ende nächster Woche ausführlich =)

[ZÜNDELholz]

Von 2 auf 4 sinds +30%. Von 4 auf 6 +45%. Im ersten Fall verdoppelt sich die Kernzahl und die Frames steigen nur um 30%. Im zweiten Fall steigt die Kernzahl nur um 50% und die Frames steigen weiter, und das sogar um einen höheren Wert als im ersten Fall. Das ergibt doch keinen Sinn. :confused:



Selbst eine Kernverdoppelung (bei AMD) bringt da keine grossartigen sprünge

Du bestätigtst damit vollends meine Aussage!

Und wie siehts bei Deinem Intel -bench aus:
Du verdoppelst die kernzahl und die FPS steigen um ca. das doppelte. Das macht Sinn, also kann man schreiben, dass man mit Intel die sinnvolle Variante an Hardware besitzt.

[dargo]

Und wie siehts bei Deinem Intel -bench aus:
Du verdoppelst die kernzahl und die FPS steigen um ca. das doppelte. Das macht Sinn, also kann man schreiben, dass man mit Intel die sinnvolle Variante an Hardware besitzt.
Ich glaube du verstehst immer noch nicht worauf ich hinaus will. Die Phenom 2 Architektur hat keinen Flaschenhals wie ein Kenstfield oder Yorkfield @FSB. Wenn also ein Lynnfield dermaßen gut beim QC gegenüber DC zulegt dann sollte das beim Phenom 2 ebenfalls der Fall sein (völlig unabhängig von den tatsächlichen fps). Ansonsten gibts im Spiel wohl einen Bug in Verbindung mit AMD CPUs oder dem Tester ist ein Fehler unterlaufen. Außerdem macht eine weitere Steigerung der Frames durch den Sechskerner gar keinen Sinn wenn der Vierkerner schon so wenig zulegt. Das sieht aus als ob irgendwas den Vierkerner @AMD limitieren würde.

Ich hab derzeit Urlaub und bin in Paris, aber ich melde mich Ende nächster Woche ausführlich =)
Ah... ok, schönen Urlaub dann. :)

[ZÜNDELholz]

Ich glaube du verstehst immer noch nicht worauf ich hinaus will. Die Phenom 2 Architektur hat keinen Flaschenhals wie ein Kenstfield oder Yorkfield @FSB. Wenn also ein Lynnfield dermaßen gut beim QC gegenüber DC zulegt dann sollte das beim Phenom 2 ebenfalls der Fall sein (völlig unabhängig von den tatsächlichen fps). Ansonsten gibts im Spiel wohl einen Bug in Verbindung mit AMD CPUs oder dem Tester ist ein Fehler unterlaufen. Außerdem macht eine weitere Steigerung der Frames durch den Sechskerner gar keinen Sinn wenn der Vierkerner schon so wenig zulegt. Das sieht aus als ob irgendwas den Vierkerner @AMD limitieren würde.



Mir gings auch nicht um den FSB, weil schon längst out of date, sondern darum, dass AMD ne "verkorkste" Architektur besitzt, was man auch schön an den verkorksten Benchwerten von PCGH erkennen kann.
Die CPU-Spezialisten im Board können ja mal ins Detail gehen, warum hier AMD versagt. Wird bestimmt ganz viele interessieren.

[Botcruscher]

Bei Fehlern in der AMD-CPU dürfte die nie ordentlich skalieren. Das macht sie aber. Die Erklärung ist daher quatsch.

[dargo]

Nichtsdestotrotz ist der 2332Mhz QC mehr als doppelt so schnell wie der gleichgetaktete DC. Vielleicht liegts doch an einer hohen Grundlast? :uponder: Ich werde das mal mit größeren Taktraten gegentesten, sodass ich bei der langsamen CPU auf mindestens 60fps komme. Bei der schnelleren CPU habe ich noch einiges an Spielraum nach oben offen bis die GPU anfängt zu limitieren.

Ach Mist... schon mit 2,9Ghz QC limitiert meine GTX470 @700Mhz. ;( Weiß einer zufällig welche Grafiksettings in DIRT 3 ausschließlich auf Kosten der GPU gehen? Ich muss die GPU-Last senken. Ambient Occlussion ist klar. Werden die Schatten auch nur von der Graka berechnet? Und wie siehts mit der Nachverarbeitung aus?

Edit:
Die Grafiksettings die nur zu Lasten der GPU gehen auf die schnelle zu finden wird wohl unmöglich sein. Andere Idee...

Ich habe jetzt mit minimalen Details und 640x480 1xAA/1xAF verglichen. Dabei ist allerdings zu beachten, dass dadurch auch die CPU-Last wesentlich sinkt.

2893Mhz (14x 206,6) QC (Speichertakt 827Mhz) = 208,75 avg.fps
2893Mhz (14x 206,6) DC (Speichertakt 827Mhz) = 101,95 avg.fps

Mit den ~102fps bin ich deutlich weiter von der Grundlast entfernt als noch mit den 48fps beim 2332Mhz DC. Der Vorsprung vom QC @2893Mhz vs. DC beträgt jetzt nur noch knapp 105%. Bei 2332Mhz QC vs. DC warens noch knapp 128% Vorsprung. Bei 2893Mhz passen also die Verhältnisse wesentlich besser. Ich würde also sagen es lag doch an der Grundlast.

Edit 2:
Auch mit noch höherer Taktrate ändert sich an den Verhältnissen praktisch nichts mehr.

3699Mhz (19x 194,7) QC (Speichertakt 779Mhz) = 244,25 avg.fps
3699Mhz (19x 194,7) DC (Speichertakt 779Mhz) = 118,35 avg.fps

[Undertaker]

Eine Quadcoreskalierung von über 100% ist mit der Grundlastproblematik durchaus plausibel erklärbar. Über die mehr als doppelte Taktrate des Dualcores für identische fps wie der Quad wundere ich mich hingegen immernoch - kannst du das ebenfalls nochmal mit niedrigen Details vergleichend testen?

[dargo]

Über die mehr als doppelte Taktrate des Dualcores für identische fps wie der Quad wundere ich mich hingegen immernoch...

Ich kanns mir momentan auch nicht so recht erklären. Kann es sein, dass aufgrund der hohen Grundlast ein Core schon dermaßen blockiert ist, dass die zu berechnenden Frames nur noch beim DC auf einem einzigen Core laufen und er dadurch völlig überfordert ist? Vielleicht könnte ich das gegentesten indem ich herausfinde wie hoch der TC getaktet werden muss auf auf die Frames vom QC zu kommen?


kannst du das ebenfalls nochmal mit niedrigen Details vergleichend testen?
Wie meinst du das jetzt? Einfach nochmal 1658Mhz QC vs. xxxxMhz DC bei min. Details?

Edit:
Moment mal... eigentlich ist es logisch. Oder ich habe einen Denkfehler. :D

Fassen wir mal zusammen:

Je weiter ich mich von der Grundlast mit höheren Frames entferne umso kleiner wird der Vorsprung vom QC vs. DC über Faktor 2.

max. Details
1658Mhz QC = 78,45 (237%)
1658Mhz DC = 33,05

2332Mhz QC = 109,30 (228%)
2332Mhz DC = 48,00

min. Details
2893Mhz QC = 208,75 (205%)
2893Mhz DC = 101,95

Dass der DC jetzt so hoch getaktet werden muss erkläre ich mir folgendermaßen - der "neue" DC muss den fps-Bereich 33-78fps (siehe Diagramm) abdecken, womit noch ein großer Anteil der Grundlast Auswirkung zeigt.

Edit 2:
Ich habe schon eine Idee wie ich meine These belegen kann. Ich hasse nur die Tests bei DIRT 3 (war in DIRT 2 übrigens nicht anders:mad:). Jedes Mal wenn man eine Strecke komplett neulädt startet man vom anderen Platz womit sich natürlich die Frames ändern. Manchmal muss ich bis zu 7x eine Strecke neuladen bis ich meine Startposition erreiche. :uhammer: Was hat sich CM dabei nur gedacht? :facepalm: Es wäre auch viel zu viel verlangt vor dem freien Rennen sich eine Startposition aussuchen zu können. :freak:

[Undertaker]

Wie meinst du das jetzt? Einfach nochmal 1658Mhz QC vs. xxxxMhz DC bei min. Details?

Eine beliebige Kombination von Dual- und Quadcore, bei der beide die identischen fps erreichen. Und das am besten mal mit niedrigen Details, da wir ja mit dem Ergebnis bei hohen Details so unsere Erklärungsnöte bekommen... ;)

Ich kanns mir momentan auch nicht so recht erklären. Kann es sein, dass aufgrund der hohen Grundlast ein Core schon dermaßen blockiert ist, dass die zu berechnenden Frames nur noch beim DC auf einem einzigen Core laufen und er dadurch völlig überfordert ist?

Was genau soll man sich jetzt darunter vorstellen können? Nehmen wir beispielsweise an, wir haben einen 2,5GHz Dualcore und einen 1,0GHz Quadcore. Egal wie hoch die Grundlast jetzt ist, der Dualcore besitzt auf dem Papier immer die geringere Restleistung für die Grafikdarstellung und sollte damit die niedrigeren fps liefern. Bei angenommenen 500MHz Grundlast und perfekter Parallelisierung des Spiels - das ist wohl unrealistisch optimistisch - müsste der Dualcore in dieser Rechnung 28,6% schneller sein.
Jetzt nehmen wir unter gleichen Voraussetzungen einen 1,0GHz Quadcore und einen 2,0GHz Quadcore: Das 2,0GHz Modell wäre hier 114% schneller, ein übliches Grundlastphänomen und absolut erklärbar.

Softwareprobleme ausgeschlossen bleibt für mich als einzige Erklärung, dass der Dualcore nur auf die Hälfte des L2 Cache zugreifen kann und dadurch seine Leistung verliert. Aber so richtig befriedigt mich das noch nicht...

[dargo]

Meine These bestätigt sich, es liegt einfach an der hohen Grundlast.

640x480 1xAA/1xAF, min. Details
1658Mhz DC (14x 118,4), Speichertakt 474Mhz = 55,00 fps
1658Mhz QC (14x 118,4), Speichertakt 474Mhz = 120,00 fps
3853Mhz DC (20x 192,7), Speichertakt 771Mhz = 119,05 fps

Den einen fps musst du mir verzeihen. Ich habe die 3853Mhz mir anhand der anderen Ergebnisse ausgerechnet und sie kommen auch tatsächlich fast hin. Der Benchaufwand ist bei DIRT 3 aus den besagten Gründen zu hoch, als dass ich hier den Takt noch weiter exakt finden möchte um auf die 120fps zu kommen. Rein rechnerisch wären es ca. 3884Mhz.

Zur Erinnerung - bei max. Details brauchte ich noch 4013Mhz (20x 200,7) um die gleichen Frames wie der 1658Mhz QC zu erreichen. Hier sinds nur noch 3884Mhz weil ich weiter von der Grundlast entfernt bin. Bei max. Details musste der Bereich 33-79fps abgedeckt werden, bei min. Details 55-120fps.


Softwareprobleme ausgeschlossen bleibt für mich als einzige Erklärung, dass der Dualcore nur auf die Hälfte des L2 Cache zugreifen kann und dadurch seine Leistung verliert. Aber so richtig befriedigt mich das noch nicht...
Ach... ich merke jetzt erst, dass du den L2 Cache und nicht L3 meinst. :anonym: Ich dachte vorher die ganze Zeit an den L3 und habe mich gewundert. Schließlich stehen dem DC die ganzen 8MB zur Verfügung. Er ist also im Prinzip im Vorteil gegenüber dem QC. Aber warum sollte ein halbierter L2 Cache beim DC ein Nachteil sein? Schließlich halbiert sich auch die Kernzahl.

[Undertaker]

Ach... ich merke jetzt erst, dass du den L2 Cache und nicht L3 meinst. :anonym: Ich dachte vorher die ganze Zeit an den L3 und habe mich gewundert. Schließlich stehen dem DC die ganzen 8MB zur Verfügung. Er ist also im Prinzip im Vorteil gegenüber dem QC. Aber warum sollte ein halbierter L2 Cache beim DC ein Nachteil sein? Schließlich halbiert sich auch die Kernzahl.

Die Kernzahl halbiert sich auch, die Threadzahlen und Datenmengen des Spiels bleiben ja aber gleich. ;) Mal stark vereinfacht: Wenn Dirt 3 z.B. 12 Threads hat, laufen auf dem Dualcore 6 pro Kern, auf dem Quadcore nur 3 - somit hat jeder Thread auf dem Quad den doppelten Cache zur Verfügung, was effektiv etwas höhere IPC bedeuten sollte.

Aber nochmal zu deiner Grundlastthese: Also einer von uns beiden muss da gerade auf dem Schlauch stehen. :confused: Das Grundlastproblem wird doch nur dann relevant, wenn man CPUs unterschiedlicher Leistungsfähigkeit vergleicht. Durch den konstanten Grundlastanteil kann jedes Prozent zusätzlicher Leistungsfähigkeit die fps überproportional erhöhen (mit nach oben abnehmendem Faktor, logisch da der Grundlastanteil sinkt).

Ein Dualcore doppelter Taktrate besitzt nun doch aber die identische Rechenleistung wie ein Quadcore. Die konstante Grundlast nimmt somit bei beiden den gleichen Teil der zur Verfügung stehenden Rechenleistung ein, ich kann mir somit nicht erklären, dass doppelte Taktrate bei halber Kernzahl nicht immer mindestens dieselbe Performance erreicht - obige Cacheproblematik außen vor.

[dargo]

Die Kernzahl halbiert sich auch, die Threadzahlen und Datenmengen des Spiels bleiben ja aber gleich. ;) Mal stark vereinfacht: Wenn Dirt 3 z.B. 12 Threads hat, laufen auf dem Dualcore 6 pro Kern, auf dem Quadcore nur 3 - somit hat jeder Thread auf dem Quad den doppelten Cache zur Verfügung, was effektiv etwas höhere IPC bedeuten sollte.

Soweit richtig. Du vergisst aber glaube ich, dass der Cache beim DC auch doppelt so hoch taktet. Somit sollte es auf +/- Null hinauslaufen.


Aber nochmal zu deiner Grundlastthese: Also einer von uns beiden muss da gerade auf dem Schlauch stehen. :confused: Das Grundlastproblem wird doch nur dann relevant, wenn man CPUs unterschiedlicher Leistungsfähigkeit vergleicht. Durch den konstanten Grundlastanteil kann jedes Prozent zusätzlicher Leistungsfähigkeit die fps überproportional erhöhen (mit nach oben abnehmendem Faktor, logisch da der Grundlastanteil sinkt).

Ein Dualcore doppelter Taktrate besitzt nun doch aber die identische Rechenleistung wie ein Quadcore. Die konstante Grundlast nimmt somit bei beiden den gleichen Teil der zur Verfügung stehenden Rechenleistung ein, ich kann mir somit nicht erklären, dass doppelte Taktrate bei halber Kernzahl nicht immer mindestens dieselbe Performance erreicht - obige Cacheproblematik außen vor.
So langsam glaube ich, dass es an der verflixten Tatsache liegt, dass ich beim Board nicht über einen BCLK von 208 hinaus kann und dadurch das Bild völlig verfälscht wird. Im Diagramm sieht man ja, dass ich 4013Mhz beim DC brauche um auf die gleichen fps wie der 1658Mhz QC zu kommen. Theoretisch müsste ich ja ~3316Mhz (14x 236,8) beim DC brauchen. Und ich kann mir durchaus vorstellen, dass durch das völlig andere Flaschenhalsverhältnis bei den 4013Mhz (immerhin gehts hier schon um den CPU-Multi 20 anstatt 14) diese zusätzlichen ~700Mhz beim CPU-Takt benötigt werden. Nur wie kann ich das nachweisen trotz der Mainboardlimitierung? :uponder:

Edit:
Ok... ich habe die Ursache gefunden. Wie ich schon angedeutet habe liegt es an dem extremen Unterschied zwischen CPU-Multi 14 und 20. Die Flaschenhälse ändern sich so extrem, dass erheblich mehr CPU-Takt beim 20-er Multi nötig sind.

640x480 1xAA/16xAF min. Details
1574Mhz QC (14x 112,4), Speichertakt 450Mhz = 109,10 avg.fps
2977Mhz DC (14x 212,6), Speichertakt 850Mhz = 105,65 avg.fps

Ich hätte gedacht mein BCLK würde auf max. 208 gehen. 212 gehen auch noch wie man sieht. Und wie man weiter gut erkennen kann müssten für die 109fps beim DC rein rechnerisch sogar nur 3074Mhz reichen. Das wäre sogar weniger als Faktor 2 (3148Mhz). Das könnte wiederum daran liegen was ich schon vorher gesagt habe - dem DC stehen die vollen 8MB L3 Cache zur Verfügung.

@Undertaker
Du hast völlig recht. Ein doppelt so hoch getakteter DC hat die gleiche Rechenleistung wie ein QC gleicher Architektur. Alles andere ergibt keinen Sinn. Ich muss wohl oder übel den Test vo DIRT 3 wiederholen. ;( Die Arbeit mit anderen CPU-Multis (vorallem wenn sie sich stark unterscheiden) ist für den Anus. Ich muss erstmal das Maximum beim BCLK ausloten. 224 wären für die Tests optimal.

PS: da soll noch einer sagen OC über den Multi wäre vorteilhaft. ;) *andensandybridgedenk*
In der Lynnfield/Nehalem Architektur steckt noch jede Menge Potential. Wir brauchen nur kleinere Multis und höhere BCLKs + mehr Speicherbandbreite. :D

[dargo]

So... DIRT 3 ist nun in der korrigierten Fassung fertig.
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=6973307&postcount=3

Ich habe mich wie im Link zu lesen von der Vorgehensweise beim DC einen anderen CPU-Multi zu nehmen verabschiedet. Das führt nur unnötig zum Chaos. Sollte der maximale Takt von 3052Mhz beim DC nicht reichen muss hochgerechnet werden. Eine andere, sinnvolle Alternative sehe ich hier nicht.

PS: wie man sieht braucht der DC bei max. Details immer noch einen höheren Takt als Faktor 2 um mit dem QC mitzuhalten. :freak: Weitere Erklärungsversuche? :biggrin:

PPS: die aktuellen Werte sind mit den alten nicht mehr vergleichbar. Diesmal habe ich eine andere Startposition gewählt (die öfter vorkommt) und ca. eine Sekunde später im Savegame gebencht.

[dargo]

Nach einer gefühlten Ewigkeit habe ich mich endlich durchgerungen eine passende Testszene in BF: BC2 zu suchen. Habe ich mich eigentlich schon genug über fehlendes freie Speichern in diversen Games aufgeregt? :P
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=6973307&postcount=3

Der Dualcore und Triplecore werden in diesem Game regelrecht zersägt. :eek:

[y33H@]

Wie wird das erst bei BF3? :eek:

[dargo]

Nun... von der Frostbite 2.0 erwarte ich zumindest eine perfekte Skalierung mit einem Sixcore. Selbst ein Octacore sollte noch Vorteile bringen können. Das würde ich zumindest von einer modernen Spiele-Engine erwarten. Leider kann ich eine Skalierung mit sechs Kernen selbst in BF: BC2 nicht testen. Intel ruht sich einfach zu lange auf ihren Quadcores @SB aus. :(

[Nightspider]

Perfekte Skalierung für 6 Kerner? Wovon träumst du?
Sogut wie kein Schwein hat mehr als 4 Kerne.
Und wenn die Engine ein Plus von 30% bei SMT oder 6 Kernern bringt, so wie schon die Frostbite Engine 1.5, dann reicht das allemal.

Die Multithreading Fähigkeiten der Frostbite Engine 1.5 waren schon gut genug. Ich hätte da als Entwickler kein Handlungsbedarf gesehen.

Eine perfekte 6Kern Skalierung wird man so schnell nicht sehen und auch nicht benötigen, wenn die Mehrheit nur 4 Kerne hat, was bei Intel auch lange so bleiben wird.

[dargo]

Perfekte Skalierung für 6 Kerner? Wovon träumst du?
Sogut wie kein Schwein hat mehr als 4 Kerne.

Der Begriff PS3 sagt dir was? Zudem gehe ich davon aus, dass die FB 2.0 für mehrere Jahre entwickelt wurde. In ~2 Jahren wird es sicherlich schon mehr Gamer mit einem Sixcore geben. Dass so wenige Sixcores bei den Gamern im Umlauf sind liegt einzig daran, dass Intel keine bezahlbaren anbietet. Das wird sich hoffentlich bald ändern.


Und wenn die Engine ein Plus von 30% bei SMT oder 6 Kernern bringt, so wie schon die Frostbite Engine 1.5, dann reicht das allemal.

Woher kommen diese 30% beim Sixcore? :)

[y33H@]

Dafür bietet Intel seit Ende 2008 (!) CPUs mit vier Kernen plus SMT an, welches idR ebenfalls mehr Leistung bringt, wenn 4C auf 6C in mehr Performance resultiert. Siehe BC2.

[Nightspider]

Der Begriff PS3 sagt dir was? Zudem gehe ich davon aus, dass die FB 2.0 für mehrere Jahre entwickelt wurde. In ~2 Jahren wird es sicherlich schon mehr Gamer mit einem Sixcore geben. Dass so wenige Sixcores bei den Gamern im Umlauf sind liegt einzig daran, dass Intel keine bezahlbaren anbietet. Das wird sich hoffentlich bald ändern.



Wieviele Games, die es auch für die PS3 gibt, haben denn auch eine 6 Kern Unterstützung am PC? 1% aller PS3 Games? 1,5% aller PS3 Games? ;D

Glaube es gibt nur 5-10 Games überhaupt, die etwas (die meisten Games profitieren bisher wenig von 6 Kernen) von 6 Kernen profitieren. Und einige Spiele laufen mit SMT sogar noch langsamer.

Die Frostbite Engine 2.0 ist auch mit bisheriger CPU Skalierung viel besser für die Zukunft gerüstet als andere Engines.
Ich sehe immernoch kein Handlungsbedarf.

Intel wird wohl auch bis Anfang 2013 nur 4 Kerne im Mainstream Bereich verkaufen.
Und 30% mehr beim SixCore kommen jedenfalls von keiner perfekten Skalierung. ;)
Laut deiner Definition sollten knapp 50% oder gar mehr Prozente rauskommen.

[dargo]

Und 30% mehr beim SixCore kommen jedenfalls von keiner perfekten Skalierung. ;)
Ich warte immer noch auf die Quelle mit den 30%.

@y33H@
Kannst du mit deinem X6 testen wie gut dieser gegenüber einem X4 in meiner Testszene von BC2 skaliert? Mich würde interessieren ob da noch um die +50% rauskommen. Du brauchst aber eine schnelle Graka, am besten GTX480/580. Zur Not kann man aber auch mit den CPU-Taktraten runter.

[y33H@]

Du kannst mal Raff fragen, der hat einen X6 daheim. Ich werde diese Woche nicht dazu kommen und wenn ich wieder abseits von online involviert bin, stehen andere CPUs auf dem Plan. Und mein Urlaub =)

[Nightspider]

Solche Benchmarks gibts zuhauf im Netz und ist schon lange bekannt.
http://www.pcgameshardware.de/aid,805899/Intel-Sandy-Bridge-im-CPU-Test-Core-i7-2600K-Core-i5-2500K-und-Core-i5-2400-auf-dem-Pruefstand/CPU/Test/?page=3

Das BC2 bestens von 4 und 6 Kernen profitiert ist schon seit 1,5 Jahren bekannt.
Im oben genannten Test sind es 28% Vorteil für den 2600K mit SMT Taktbereinigt zum 2500K. Der Cache bringt in BC2 kein Vorteil.

Gut möglich, das in niedrigeren Auflösungen mehr als 30% drin sind. Würde BC2 auch höhere Spielerzahlen als 32 zulassen wäre ein 30-50%iger Vorteil zum QuadCore gar nicht mal so unwahrscheinlich.

Von daher wäre der Handlungsbedarf für Dice sehr gering. Außer man findet leicht noch hier und da Dinge zum optimieren.
Die Frostbite Engine 2 ist auch nur eine weiterentwickelte Frostbite Engine 2.0. Und in den letzten 1,5 Jahren hat sich bei der Anzahl der CPU Cores bei Intel gar nichts getan. Und die Konsolen sind sowieso noch gleich lahm.

[dargo]

Solche Benchmarks gibts zuhauf im Netz und ist schon lange bekannt.
http://www.pcgameshardware.de/aid,805899/Intel-Sandy-Bridge-im-CPU-Test-Core-i7-2600K-Core-i5-2500K-und-Core-i5-2400-auf-dem-Pruefstand/CPU/Test/?page=3

Die Tests der PCGH mit der Testszene aus "Crack the Sky" kenne ich. Die ist mir aber zu ungenau da nicht vollständig im CPU-Limit. Man sieht schon am i5-2500 vs. i5-2400 und X6 1090T vs. X6 1055T, dass vom höheren Takt nur ca. 50% durchschlagen. X6 1090T vs. X4 955BE ist beim gleichen Takt dadurch nur 26% schneller. Ich vermute nämlich, dass die FB 1.5 schon perfekt mit einem Sixcore skaliert. Würde das aber gerne von einem User mit einem X6 bestätigt sehen. Eine passende Testszene die vollständig cpu-limitiert ist hätte ich ja.

Im oben genannten Test sind es 28% Vorteil für den 2600K mit SMT Taktbereinigt zum 2500K. Der Cache bringt in BC2 kein Vorteil.
Woher willst du das wissen ohne einen geeigneten Gegentest?

Edit:
Das könnte man eh nur mit dieser CPU gegentesten:
http://geizhals.at/deutschland/615496

Die CPU auf 3,4Ghz bringen und schon könnte man rausfinden was die zusätzlichen 2MB Cache beim i7-2600 bringen. Andersrum... den i7-2600 per Multi auf 3,1Ghz bringen und SMT ausschalten. Der Xeon hat keinen freien CPU-Multi. :ugly:

[Ri*g*g*er]

Ich wette der Cache bringt 100 % etwas kommt nur drauf an wieviel ...

Auch die alten Battlefield Games haben von einem grossem Cache profitiert.
Insbesondere Battlefield 2 mit den Fahrzeugen und grossen Maps.

Frostbite 2.0 ist die EA Engine für die Zukunft siehe auch Need for Speed.
Es wird eine sehr gute Kernskalierung dabei sein.

Warten wir die Engine ab und die entsprechenden Prozessoren dann werden wir es schwarz auf weiss sehen.

Gruss
Ri*g*g*er

[Nightspider]

Battlefield 2 hatte ne ganz andere Engine. Das die Frostbite Engine 2 ne gute Kernskalierung hat ist wie gesagt sowieso klar, wenn schon die 1.5 bestens mit 6 kernen klar kommt.

Bei den ersten Sandy Bridge Benchmarks gab es auch diverse Benchmarks in denen man sehen konnte, das Bad Company 2 nicht wirklich und wenn dann nur minimal von 2MB mehr Cache profitiert.

[dargo]

Bei den ersten Sandy Bridge Benchmarks gab es auch diverse Benchmarks in denen man sehen konnte, das Bad Company 2 nicht wirklich und wenn dann nur minimal von 2MB mehr Cache profitiert.
Hier kommt halt die Frage auf inwieweit die Tests repräsentativ waren. Wenn ich mir diverse CPU-Tests im Netz so anschaue wo der Großteil noch in GPU-Limits gebencht wird kennst du sicherlich meine Antwort.

[Nightspider]

Den Cache Vorteil hätte ich vor paar Monaten benchen können, ich hatte nen 2500K und einen 2600K da aber es wäre fast unmöglich gewesen repäsentative Zahlen zu erhalten, ohne Safegames oder integrierten Benchmark, da die Cache-Vorteile auch nur zwischen 0-5% liegen dürften. Das dürfte ohne Benchmark schon durch die Messungenauigkeiten untergehen.
Es gibt nur extrem wenig Spiele, die stark auf einen großen Cache anspringen.

Eher interessieren mich da die Cache Vorteile zwischen 2500K/2600K und den neuen Sandy Bridge E Modellen mit 10-16 MB Cache.

[Savay]

@dargo: hast du schon wen? wenn nicht kann ich mal mein glück probieren.
musst mir nur sagen wie genau du BF:BC2 gebencht hast. hab zwar nur ne HD5870@900MHz aber irgendwie sollte man (zumindest in BF:BC2) schon ins CPU limit kommen können... :)


Eher interessieren mich da die Cache Vorteile zwischen 2500K/2600K und den neuen Sandy Bridge E Modellen mit 10-16 MB Cache.

wieso sollte sich da plötzlich viel tun wenn zwischen dem i3, i5 und i7 schon kaum ein unterschied ausmachbar ist oder ist der L3 schneller als bei den normalen SB?! :wink: abnehmender grenzertrag und so...

[dargo]

@dargo: hast du schon wen? wenn nicht kann ich mal mein glück probieren.
musst mir nur sagen wie genau du BF:BC2 gebencht hast. hab zwar nur ne HD5870@900MHz aber irgendwie sollte man (zumindest in BF:BC2) schon ins CPU limit kommen können... :)

Hast du einen X6?

[Savay]

ja

[Knuddelbearli]

wie kann ein Quadcore 110% schneller wie ein Dualcore mit sonst genau gleichen Daten sein ? ( da wäre Windows Grundlast ne Möglichkeit )

Bzw ein doppelt soschneller Dualcore langsamer als der Quad? ( da funktioniert das Argument Grundlast nicht mehr )

[y33H@]

Weil dem Dualcore die Stärke der Parallelisierung nicht schmeckt.

[dargo]

wie kann ein Quadcore 110% schneller wie ein Dualcore mit sonst genau gleichen Daten sein ? ( da wäre Windows Grundlast ne Möglichkeit )

Bzw ein doppelt soschneller Dualcore langsamer als der Quad? ( da funktioniert das Argument Grundlast nicht mehr )
Habe ich mich auch schon gefragt. Wilde Theorie meinerseits - dafür ist ebenfalls die Grundlast verantwortlich. Diesmal aber nicht die Grundlast aufgrund der vorhandenen Rechenleistung (einfacher ausgedrückt Mhz) sondern zusätzlich die der zu verarbeitenden Threads. Mir ist beim Test aufgefallen, dass der vierte Core praktisch ständig auf 100% läuft. Ich kann dir allerdings nicht sagen was er da gerade rechnet. Er ist auf jeden Fall "blockiert". Wenn jetzt die Engine so ausgelegt ist, dass bestimmte Sachen aufgeteilt werden (zb. KI und Physik auf einen eigenen Thread und die tatsächliche Frameberechnung auf einen separaten Thread) hat der DC nur einen Core dafür übrig. Der Quad noch zwei zusätzliche. Da ich aber sehe, dass selbst der TC eher schlecht als recht zulegt wird die Engine wohl die Sachen auf 3 Threads verteilen womit beim Quad sich ein einzelner Core ausschließlich um die Frames kümmert.

Keine Ahnung ob man das so einfach erklären kann, vielleicht spinne ich nur ein wenig rum. :D

Edit:
Wo wir schon beim Thema sind - gibts hier freiwillige die einen Nehalem oder SB i7 haben und die gleiche Szene testen möchten? Mich würde brennend interessieren wie sich die Coreskalierung mit SMT und nur 3 Cores gegenüber dem Lynnfield ohne SMT verhält. Man sieht bei meinem Test, dass der TC eher schlecht (zumindest im Vergleich zum QC) skaliert. Interessieren würde mich halt ob SMT 3 Cores erheblich hilft oder ob nur ein eher geringer Framezuwachs stattfindet zb. plus insgesamt ~50% gegenüber DC. Ich würde auf Zweiteres tippen da SMT keine echten Cores ersetzen kann.

[Savay]

hab mal quick&dirty mit FRAPS nen paar durchgänge vom anfang der "Crack the Sky" mission gemacht...
kam folgendes raus...ist nicht zu 100% exakt da die durchläufe nie ganz identisch waren aber nen tendenz kann man wenigstens erkennen. aufgrund der länge der sequenz sollte der fehler nicht übermäßig elementar sein.

ich packs mal in nen spoiler...sind immerhin keine "offiziellen" dargo-approved-werte nach seiner vorgehensweise und nicht direkt vergleichbar und aufgrund der unzulänglichen bench methode meinerseits wie gesagt auch nicht zu 100% exakt! :tongue:



bei den avg-FPS bin ich bei 6 und 4 kernen scheinbar noch ganz leicht im GPU-limit....denke das kann man aber erstmal vernachlässigen bis "richtige" werte kommen. :cool:
die min-FPS sind schon etwas interessanter

https://lh5.googleusercontent.com/-hcPU_rQsa7g/Tmfgm__K_II/AAAAAAAABD4/lsCqqCkCisE/BFBC2_Skalierung.jpg

irgendwie scheint der K10 als TC besser zu skalieren...aber vielleicht ist es auch nur eine anomalie vom savegame. :smile:
werde morgen mal mit dargo zusammen sein savegame austesten.

EDIT: was auffällig ist: wenn das spiel auf 2 kernen läuft gibt es seltsame mikroruckler...das führt dazu das sich 3 kerne mit 1875MHz "flüssiger" anfühlen als 2 kerne mit 3500MHz. :freak:

(...) wird die Engine wohl die Sachen auf 3 Threads verteilen womit beim Quad sich ein einzelner Core ausschließlich um die Frames kümmert. (...)

ich denke das könnte eine erklärung sein...die engine ist ja mit sicherheit mit der XBox360 als plattform entwickelt worde...da ist nunmal nen triple-core+SMT drin. um das ding wirklich optimal zu nutzen sind 3 hauptthreads und nen paar kleinere helferthreads ja gradzu ideal. die "haupt"threads für die grundlast auf die kerne, und das kleinvieh um die pipelines optimal zu füllen...so holt man das maximum aus der CPU... :)
bei nem dualcore mit 2 threads bremsen dann sicher die ressourcen und die verwaltung der hauptthreads vorallem wenn sie aufeinander warten müssen. (vielleicht ist das "ruckeln" das ich mit 2 kernen festgestellt habe auch ein indiz dafür)
bei mir ist der sprung von dual auf triplecore ja bspw. auch ziemlich groß... (+80%) von da aus auf den Quad aber recht klein (25%) :smile:

nen DC mit SMT sollte da evtl. ähnlich skalieren wie nen TC wenn es 2 hauptthreads und mehrere kleine helferthreads sind...vielleicht aber auch etwas schlechter wenn es quasi 3 hauptthreads + helferthreads sind, dann bringt SMT natürlich eher weniger.

[Savay]

Perfekte Skalierung für 6 Kerner? Wovon träumst du?


davon denke ich: :)

https://lh6.googleusercontent.com/-eJxF2oN7DWQ/TnNM8x5bnuI/AAAAAAAABH0/O5fOrc5wf-g/s288/BFBC2_Skalierung_4.jpg (https://lh6.googleusercontent.com/-eJxF2oN7DWQ/TnNM8x5bnuI/AAAAAAAABH0/O5fOrc5wf-g/BFBC2_Skalierung_4.jpg)

https://lh4.googleusercontent.com/-6VJqjTNj1IE/TnNOmaDDheI/AAAAAAAABH0/mZKnORsQEXI/s288/BFBC2_Verl%2525C3%2525A4ufe_2.jpg (https://lh4.googleusercontent.com/-6VJqjTNj1IE/TnNOmaDDheI/AAAAAAAABH0/mZKnORsQEXI/BFBC2_Verl%2525C3%2525A4ufe_2.jpg)

soweit so linear! :wink:

das ganze basiert auf der flugsequenz am anfang von "crack the sky". die vorgehensweise ist ähnlich wie bei dargo aber einfach auf diese etwas längere sequenz (31sek) angewendet.
die durchläufe schwanken zwar stets aber deswegen auch die MW bildung...in diesem fall über 4 durchläufe...je mehr durchläufe desto exakter enstpricht es natürlich dem durchschnittlichen frameverlauf über die szene!
die schwankungsbreite bei den absoluten min-FPS und den avg-FPS der jeweiligen durchläufe ist ziemlich gering.

das annähernd lineare verhalten lässt sich denke ich so schon erkennen (rote linie)...auch das die FPS bei 2 und 4 kernen stärker vom MW abweichen. die schwankungsbreite ist etwas größer was mich in dem eindruck bestärkt, dass mehr kerne/threads zu einem etwas konstanterem frameverlauf und einem subjektiv flüssigeren spieleindruck führt. 2 kerne "ruckeln" bei mir deshalb immer...selbst wenn ich die CPU auf 3,5GHz takte.

3 und 5 kerne habe ich mir bisher gespart. wenn mir extrem langweilig ist wiederhole ich die geschichte vlt noch mit einer von beiden varianten, ich bin aber überzeugt davon, dass sich nichts wesentliches daran ändern wird.

[Nightspider]

Oha. :D

Scheint aber wirklich eher selten zu sein. Zumindest können wir dann davon ausgehen, das BF3 vllt noch öfter die 6 Kerne perfekt ausnutzt, aufgrund mehr Contents und mehr Spieler.

[y33H@]

Den bisherigen Sheets nach sollte das nahezu linear skalieren, könnte eine Bulldozer-Domäne werden.

[Nightspider]

Wobei eben nicht in jeder Situation ganze 6 Kerne oder mehr ausgelastet werden und die momentane Last nur 4 Kerne voll auslastet.
Genau dann wäre Intel wieder vorne.
Könnte am Ende beim Durschnitt auf Gleichstand rauskommen, während die FPS Graphen sich merklich unterscheiden.

Wobei Intel eben 30% rausholt mit SMT und AMD nur max. 50% mit 6 Kernen.
Also max. 20% mehr in Extremsituationen. Da sehe ich immernoch Intel vorne.

[Savay]

bezogen auf die auslastung: so extrem sind die situationen IMO eigentlich garnicht...da reicht schon das nen bissl was explodiert und ein paar KI gegner rumrennen.

die sequenz die ich benutzt habe ist ca. folgende:
http://www.youtube.com/watch?v=lCiD5D2ueyo

am anfang ist 1 sek. zuviel gegen ende fehlen somit die letzten 2 die bei mir einfließen. grade die letzten 10sek sind eher nicht sonderlich anspruchsvoll. sieht man ja auch am verlauf.
ABER: da ich schon auf 2GHz runter zum benchen musste um bei 1024*768 im absoluten CPU limit zu landen wird man irgendwo ab 3GHz sicher langsam in ein GPU limit laufen...womit die skalierung natürlich "abflacht". von höheren auflösungen und FSAA/AF ganz zu schweigen.

man sieht übrigens schön am taskmanager...die CPU auslastung geht mit steigender auflösung und FSAA/AF deutlich runter weil sie (bei mir) auf die GPU warten muss. im CPU limit schwankt sie grob zwischen 75-90%. wäre schön wenn ich das irgendwie mitplotten könnte. :freak:

BTW ob nen i5 in der gleichen situation schneller oder gleichschnell oder langsamer wäre lässt sich ja nur anhand der skalierung meines X6 auch nicht wirklich sagen.
zumindest rein theoretisch müsste er bei der skalierung etwas vor nem lynnfield mit gleichem takt ohne SMT liegen...evtl reichts in summe für einen i7 auf lynnfield basis. aber das ist reine spekulation basierend auf raffs zahlen aus dem anderen thread. :)

[dargo]

Nachdem ich schon länger den Singleplayer-Part von BF3 durchgespielt habe und somit einige Stellen kenne (es fehlt ja schon wieder die Möglichkeit frei zu Speichern :P) habe ich nun Battlefield 3 fertig.
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=6973307&postcount=3

Wie zu erwarten war perfekte Quadcore-Skalierung.

[Ronny145]

Sogar SMT profitiert ziemlich stark im PCGH Test. Und 6 Kerne+SMT können sich auch noch etwas absetzen.

[dargo]

Nachschub mit einem weiteren Frostbite 2.0 Game... Need for Speed: The Run.
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=6973307&postcount=3

Der Dualcore wird sowas von zersägt. Bitte mehr Frostbite 2.0 Spiele, ich liebe diese Engine. :up: Zumal sie auch optisch was zu bieten hat.

[darkcrawler]

wie kann ein Quadcore 110% schneller wie ein Dualcore mit sonst genau gleichen Daten sein ? ( da wäre Windows Grundlast ne Möglichkeit )

Bzw ein doppelt soschneller Dualcore langsamer als der Quad? ( da funktioniert das Argument Grundlast nicht mehr )

der dual benötigt mehr threadwechsel, welche doch ordentlich zeit benötigen

[dargo]

Project Cars mit der Build 0207 ist fertig.
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=6973307&postcount=3

Übrigens... mit einem i5-750 und einer GTX480 ist die Szene selbst in Full-HD und 4xMSAA/16xAF zu 100% cpu-limitiert. ;D

[y33H@]

Same here ;-)

[BeetleatWar1977]

Project Cars mit der Build 0207 ist fertig.
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=6973307&postcount=3

Übrigens... mit einem i5-750 und einer GTX480 ist die Szene selbst in Full-HD und 4xMSAA/16xAF zu 100% cpu-limitiert. ;D
hm, wurde der 3te Kern vom Spiel überhaupt genutzt oder hat nur der GK-Treiber Arbeit ausgelagert......:confused:

[Undertaker]

Das wundert mich generell bei vielen Spielen. In dargos Messungen sind die Triple-Cores meist extrem schlecht - obwohl z.B. die Phenom II X3 in vielen Reviews vergleichsweise gut gegenüber anderen DCs abschneiden.

Woran könnte das wohl liegen... :uponder:

[Zergra]

hm, wurde der 3te Kern vom Spiel überhaupt genutzt oder hat nur der GK-Treiber Arbeit ausgelagert......:confused:
Nö, wird nicht genutz liegt auch an Windows was das umlagert sonst kann ich mir das nicht vorstellen :)