Nehalem-Architektur unter 3D-Last: Wo ist der Flaschenhals?

[S940]

Wenn sich auf diese Weise nun herauskristallisiert hat, dass ein Nehalem in Spielen bei gleichem Takt etwa 50% mehr FPS liefern kann als ein Phenom II, dann kann man natürlich keine konkreten Aussagen auf ein beliebiges Spiel daraus ableiten. Man kann aber realtiv treffsicher einschätzen, was man als Kaufinteressent von einer solchen CPU (im Mittel über die eigenen Spiele) erwarten kann und man kann bei Preis-/Leistungsvergleichen zwischen CPUs bequem Übertaktungsziele in die Bewertung einbeziehen. Somit ist dieser "IPC"-Wert in der Praxis sehr nützlich, um CPUs zu vergleichen.
Nö, bestes Beispiel der aktuelle Anno Test cb vs. PCGH.
Je nach Testszenario gibts im gleichen Spiel einmal mehr "Rechenleistung" mit dem Nehalem, oder eben mit dem Deneb.

Nach welchen Kriterien willst Du jetzt Deine CPU vergleichen oder gar auswählen ? Wem willst Du glauben, und wieso ?

Vll liegts auch einfach nur an der Engine bzw. dem Bench? Es nutzen ja idR alle nur den "Small Ranch", Leo hat die "Action Scene" genutzt und da ist der i5 schneller als ein rechnerischer 965 BE. Taktnormiert +25% flotter. Allerdings liegt hier kein GPU-Limit vor.
Klar, was sonst, die Szene wirds sein, wie bei Anno auch. Fragt sich jetzt, was in jedem Fall der Grund ist. Ist es eventuell sogar der gleiche ?

Frohes Fest

Alex

[y33H@]

Klar, was sonst, die Szene wirds sein, wie bei Anno auch.Höre ich da leichte Ironie, Alex?

[puntarenas]

Solch eine Testmethode kann nicht repräsentativ sein, weil die Testsituation natürlich schon jeglicher praktischen Relevanz entbehrt.
Deshalb habe ich den Wert (also das ermittelte Verhältnis zwischen Architekturen) doch auch als paradox bezeichntet. Er kann von vorn herein nicht repräsentativ sein, er ist aber nichtsdestotrotz ungeheuer nützlich in der Diskussion.

Mal andersrum, wie würdest du das denn handhaben. Gegeben sei ein Kaufberatungsthread und jemand möchte gern erfahren, welche Neuanschaffung das bessere Preis-/Leistungsverhältnis hat, entscheidend sei vor allem die Spieleleistung. Zur Auswahl stehen Phenom II für 350€ oder Core i5 für 420€.

Was willst du ihm denn nun ganz praktisch raten, denn nach deiner strengen Lehre kennst du weder die Spieleleistung der einen, noch der anderen Architektur. Du kannst dafür wunderbar argumentieren, warum der laienhafte Begriff der Spieleleistung völlig unzureichend ist, um das komplexe System von der Hardware bis zur Software hinreichend zu erfassen. Erklärst du ihm jetzt, dass es so etwas wie eine verallgemeinerte Spieleleistung nicht gibt und erklärst seine Frage für unberechtigt? Fail.

Betrachte die "Pro-/Mhz-Leistung" oder "IPC" in diesem Kontext hier einfach als das, was sie auch sein soll, eine grob gemittelte Tendenz, voller Unzulänglichkeiten, die allen Beteiligten bewusst sind. Als solche ist der Wert unglaublich nützlich, was offensichtlich sein dürfte, denn es wäre viel zu ermüdend, jedesmal zahllose konkrete Einzelfälle aufzuzählen.

[Raff]

Ich stelle an diesem Punkt mal eine These auf: In jedem Spiel gibt es Szenen, wo mal die eine und mal die andere CPU schneller ist. Also mal führt die AMD-Architektur, mal die Intels. Das ließe sich nur unheimlich aufwändig zusammentesten. Danach blickte man aber ganz anders auf jeden Test ...

MfG,
Raff

[dargo]

Doch, bei FC 2 gibt's einen Knick. Bei der Ordinatenskaleneinteilung schätze ich, dass es 4 FPS sind, die der i5 unter 1920 x 1200 zurückliegt, wo er unter 1280 x 1024 noch etwa 20 FPS vorne lag.

Ich habe jetzt für dich extra eine pixelgenaue Zeichnung gemacht (die PCGH möchte mir bitte verzeihen ;)):

http://www4.pic-upload.de/26.12.09/3q9yhqo19v1p.png

Worüber diskutieren wir hier eigentlich? :freak:

[Gast]

Ich stelle an diesem Punkt mal eine These auf: In jedem Spiel gibt es Szenen, wo mal die eine und mal die andere CPU schneller ist. Also mal führt die AMD-Architektur, mal die Intels. Das ließe sich nur unheimlich aufwändig zusammentesten. Danach blickte man aber ganz anders auf jeden Test ...

MfG,
Raff

Die These mag evtl. stimmen, für das hier beobachtete Problem ist sie aber unzutreffend. Die Situation ist nämlich die, dass Spiel x unter 800 x 600 20 % schneller auf Architektur a als auf Architektur b läuft, lediglich bei Erhöhung der Auflösung beim gleichen Spiel und der gleichen Szene aber 5 % langsamer als b wird.

[Gast]

Worüber diskutieren wir hier eigentlich? :freak:

Hierüber: http://www.hardware-infos.com/tests.php?test=74&seite=7

[dargo]

Nö, bestes Beispiel der aktuelle Anno Test cb vs. PCGH.
Je nach Testszenario gibts im gleichen Spiel einmal mehr "Rechenleistung" mit dem Nehalem, oder eben mit dem Deneb.

Nach welchen Kriterien willst Du jetzt Deine CPU vergleichen oder gar auswählen ? Wem willst Du glauben, und wieso ?

Wie oft muss man dir eigentlich sagen, dass der Anno-Test von CB fehlerhaft ist? Ich habe dir schon mal gesagt, dass die einzelnen Ergebnisse einiger CPUs beim Test der CB absolut keinen Sinn ergeben.

Hierüber: http://www.hardware-infos.com/tests.php?test=74&seite=7
Ein kurzer Blick auf diesen Test verrät mir schon, dass der Reviewer Mumpitz gebencht hat. Ansonsten kannst du mir erklären wie ein i7 965 XE in einer Timedemo bei den avg.fps 12% schneller als der i7 870 sein kann. Und bei den min.fps nur noch 1%?

Was soll ich in so einem Fall von diesem Test halten?

Ich stelle an diesem Punkt mal eine These auf: In jedem Spiel gibt es Szenen, wo mal die eine und mal die andere CPU schneller ist. Also mal führt die AMD-Architektur, mal die Intels. Das ließe sich nur unheimlich aufwändig zusammentesten. Danach blickte man aber ganz anders auf jeden Test ...

Solange der größte Flaschenhals die Grafikkarte ist (vollständiges GPU-Limit) kann es keinen Gewinner geben. Das ist unmöglich.

[S940]

Höre ich da leichte Ironie, Alex?
Haha, ne dieses Mal war es wirklich Ernst gemeint, sorry =)
Was soll es bei 2 unterschiedlichen Ergebnissen sonst sein, wenn der Rest alles identisch ist ?

Das muss die Szene sein, ist ja auch logisch, da unterschiedlich viel los ist / sein kann.

Ist halt jetzt besonders unglücklich, dass Ihr bei Anno so eine Nehalem Sahnestückchen Szene erwischt habt. Bei FC2 könnte das durchaus ähnlich laufen.

Wenn Du ein Lob der ganzen Community willst, dann klemm Dich dahinter und versuch es zu klären, wird sicherlich technisch werden, aber Ihr heißt ja PCG Hardware ;)
Ohne Technik geht da eh nichts ;-)

[y33H@]

Das ist unmöglich. Ganz so hart würde ich es nicht formulieren. Die Infrastruktur erlaubt es sicherlich, dass nahe des GPU-Limits eine CPU vorne liegt - ein absolutes GPU-Limit hast du wohl nur extrem selten (die CPU ist ja immer irgendwie beteiligt).

[S940]

Wie oft muss man dir eigentlich sagen, dass der Anno-Test von CB fehlerhaft ist? Ich habe dir schon mal gesagt, dass die einzelnen Ergebnisse einiger CPUs beim Test der CB absolut keinen Sinn ergeben.
Und ich hab Dir schon mal gesagt, dass ich die Ergebnisse normal & erklärbar finde.

Langsam werden Deine Unterstellungen direkt unverschämt. :mad:

Mir vorwerfen, ich würde nichts lesen was Du sagst, aber selbst nicht auf meine Fragen / Hinweise antworten, obwohl ich Dich bereits einmal darauf hingewiesen habe ...

Da Weihnachten ist will ich wirklich keine reinstressen, aber unterlasse in dem Fall dann bitte auch solche falschen Postings wie obiges (no)

Frohes Fest

[Coda]

Falls Du also weiterhin auf Deiner Idee verharrst, dass PCIe3 eine revolutionäre Neuerung wäre, dann nenne mal Ross und Reiter, also *was* das Transfervolumen in Zukunft anschwellen lassen bzw. wer es wie ausnutzen soll ?
Dynamische Geometrie- und Textur- und Konstanten-Daten. Das wird sich genauso steigern wie alles andere auch.

Die Schnittstellen werden so entworfen, dass sie auf keinen Fall einen Bottleneck darstellen. Und das ist auch gut so. PCIe 1 wird zunehmends einer.

[Gast]

Ein kurzer Blick auf diesen Test verrät mir schon, dass der Reviewer Mumpitz gebencht hat. Ansonsten kannst du mir erklären wie ein i7 965 XE in einer Timedemo bei den avg.fps 12% schneller als der i7 870 sein kann. Und bei den min.fps nur noch 1%?

Was soll ich in so einem Fall von diesem Test halten?

Die Wahrscheinlichkeit, dass man bei 4 Nehalems + 6 Phenoms in auch nur 2 Spielen à 2 Auflösungen (niedrig und hoch) derart falsch misst, dass rein zufällig sämtliche Nehalems in niedrigen Auflösungen (absteigend vom größeren zum kleineren Modell) vorne sind und in hohen Auflösungen sämtliche Phenoms (absteigend vom größeren zum kleineren Modell), erscheint mir doch recht gering, wenn nicht rein zufällig ein systematischer Fehler im Intel-System steckt (zum Beispiel: Fraps misst bei Intel-CPUs generell falsch oder so).

Dass mit den min. FPS ist doch durchaus möglich. Dazu muss innerhalb einer Testsequenz nur mal ganz kurz eine Szene auftauchen, die nicht Takt-, sondern L2-Cache-limitierendend ist und schwupps liegen beide CPUs bei den min. FPS gleichauf, obwohl 99 % der Szene ansonsten evtl. taktfrequenzlimitiert ist und bei den avg. FPS die höhergetaktete deutlich vorne liegt.

Bei dem von dir genannten Fall sieht mir das aber eher nach einem Messfehler aus. Da der i7-965 EE die anderen 9xxer simuliert und der i7-870 die anderen i7-8xxer, haben die vermutlich irgendwo einen Taktwechsel vergessen. Das heißt ja nicht, dass sämtliche Messergebnisse nicht stimmen. Die Tendenz zeigen ja nun auch andere Reviewer auf. Es messen ja nun nicht alle rein zufällig falsch und dabei immer so falsch, dass Nehalems unter höheren Auflösungen schwächer als Denebs werden. :ugly:

[dargo]

Ganz so hart würde ich es nicht formulieren. Die Infrastruktur erlaubt es sicherlich, dass nahe des GPU-Limits eine CPU vorne liegt...

Ich habe vom vollständigen GPU-Limit gesprochen. :)


...ein absolutes GPU-Limit hast du wohl nur extrem selten...

In "praxisnahen" Spielsettings sicherlich. Ist ja bei der CPU nicht anders. Es ist immer ein Zusammenspiel zwischen den beiden "Parteien".

(die CPU ist ja immer irgendwie beteiligt).
Das ist soweit richtig. Die CPU berechnet aber nicht nur die fps. Vergiss die Grundlast nicht.

[S940]

Dynamische Geometrie- und Textur- und Konstanten-Daten. Das wird sich genauso steigern wie alles andere auch.

Die Schnittstellen werden so entworfen, dass sie auf keinen Fall einen Bottleneck darstellen. Und das ist auch gut so. PCIe 1 wird zunehmends einer.Naja, dann passt es doch. Ging ja um die Frage, ob PCIe 2.0 in 3-4 Jahren noch ausreichen würde, um damit ein passables System mit neuer CPU (Zambezi), neuer GPU aber altem Mainboard, Chipsatz/RAM zu haben.

Im Moment würde ich sagen, dass PCIe1 noch reicht, die paar Prozent Unterschied merkt keiner.

Bis in 1-2 Jahren wäre dann sicherlich PCIe 2.0 langsam anzuraten, aber es bestünde kein zwingender Grund auf PCIe 3.0 aufzurüsten.

Noch eine Zusatzfrage, falls Du Dich auskennen solltest: Welches Spiel erzeigt deiner Meinung nach z.Zt. am meisten PCIe Last ?

Thx & noch ne frohe letzte Weihnachtsstunde :)

Alex

[Odal]

Blöde Frage, wozu ? Die Seite vorher vergleicht 4,8 & 6,4 GT/s, Du jetzt 6,4 zu 7,2. Falls Du Dich also darauf beziehen solltest, ist das etwas misslungen.
Ansonsten, falls Du das nur so zum Spass gemacht haben solltest, dann sieht man, dass der QPI über 6,4 in der speziellen Szene bei dem Spiel nicht bremnst. Hübsch, aber nichts weltbewegendes.


Bringt auch nicht wirklich was. Die Jungs im velinkten Test haben zw. 4,8 & 6,4 max. 5% gemessen, da kann es zw. 4,2 und 4,8 gar nicht viel zu messen geben.

wenn du dich mal ein wenig mit dem Lynnfield beschäftigt hättest, wüsstest du das sie das gar nicht können. Es gibt nur Multis von 32x und 36x für den QPI und base clock spielereien ändern den Takt des kompletten Uncore und nicht nur den qpi

[Selbst ist der Mann]

Ach Herr Je, ist ja nicht mehr feierlich wie hier eingeprügelt wird, nur weil der Nehalem nicht immer & überall vorne liegt.

Wer das Geld hat dem kann ich nur empfehlene sowohl ein Core i5/i7 System als auch ein Phenom II System selber zu testen. Dann erst kann man selbst entscheiden wo Spiele runder und geschmeidiger laufen, mMn mit dem Phenom II System.

[Undertaker]

Nun, ein Vorschlag zur Güte:

Wir testen hier einmal die Szene der PCGH und einmal die Szene von CB. Beschränken wir uns auf Settings im CPU-Limit, könnte man sogar Unterschiede bzgl. der Grafikleistung für unsere Abschätzung vernachlässigen.

Ich könnte einen PII zur Verfügung stellen. :) Einen i5/i7 und C2Q sollten wir doch hier auch noch finden.

[dargo]

Nun, ein Vorschlag zur Güte:

Wir testen hier einmal die Szene der PCGH und einmal die Szene von CB. Beschränken wir uns auf Settings im CPU-Limit, könnte man sogar Unterschiede bzgl. der Grafikleistung für unsere Abschätzung vernachlässigen.

Ich könnte einen PII zur Verfügung stellen. :) Einen i5/i7 und C2Q sollten wir doch hier auch noch finden.
Ich kann mit dem Yorkfield dienen, habe aber kein Anno.

[Odal]

mit einem i5 und anno1404 kann ich dienen

aber meines wissens ist zwar der pcgh benchmark transparent aber der CB benchmark ist es nicht
d.h. es gibt afaik kein öffentliches savegame und benchmarkanleitung

[S940]

wenn du dich mal ein wenig mit dem Lynnfield beschäftigt hättest, wüsstest du das sie das gar nicht können. Es gibt nur Multis von 32x und 36x für den QPI und base clock spielereien ändern den Takt des kompletten Uncore und nicht nur den qpiDann verstehe ich erst recht nicht, wieso Du Dir die Mühe des Tests gemacht hat, hat doch dann wirklich so gut wie keine Aussagekraft. Höchstens der Maximalwert ist einigermaßen brauchbar, 6,4 Ghz scheinen zu reichen - zumindest in der gewählten Szenen / Spiel Kombination, immerhin eine kleine Erkenntnis.

[Wuge]

die nicht Takt-, sondern L2-Cache-limitierendend ist

Ein Cache beeinflusst die Leistung, kann diese aber nicht limitieren.

[S940]

Ein Cache beeinflusst die Leistung, kann diese aber nicht limitieren.
Richtig, er meinte wohl eher "abhängig", nicht "limitierend".
Das hieße dann:
eine Szene auftauchen, die nicht Takt-, sondern L2-Cache-limitierendend abhängig ist

[Odal]

Dann verstehe ich erst recht nicht, wieso Du Dir die Mühe des Tests gemacht hat, hat doch dann wirklich so gut wie keine Aussagekraft. Höchstens der Maximalwert ist einigermaßen brauchbar, 6,4 Ghz scheinen zu reichen - zumindest in der gewählten Szenen / Spiel Kombination, immerhin eine kleine Erkenntnis.

ich versteh nicht was du nicht verstehst :confused:

1. war das keine mühe
2. wurde ja spekuliert das das pcie interface bzw. dessen anbindung im Lynnfield einen Bottleneck (unter hoher GPU Last) darstellen könnte woran spekulativ der QPI der die 16 pcie lanes anbindet schuld sein könnte....

nun war die änderung des QPI beim default i5 zw. 4.3ghz QPI und 4.8 ghz QPI praktisch kaum messbar und von linearer Skalierung mal ganz zu schweigen. Daher ist der QPI als möglicher Bottleneck auszuschliessen (zumindest bzgl. der Bandbreite).

der Unterschied zw. dem i5@default und @4ghz ergibt sich daraus das der Bench hier stellenweise schon ins CPU Limit rennt beim i5@default
(dargo hat das auch an seinem c2q schon gezeigt)

was man noch vermessen könnte wäre ob der takt des uncore eine gravierende auswirkung auf die Performance im "GPU Limit" haben könnte

da müsste man mal schaun inwie weit man qpi cpu takt und ram takt möglichst gleich hallten könnte und nur den uncore (ausser qpi) beeinflusst

[Unbekannter Nr. 1]

aber meines wissens ist zwar der pcgh benchmark transparent aber der CB benchmark ist es nicht
d.h. es gibt afaik kein öffentliches savegame und benchmarkanleitung

Vielleicht kann der Marc (y33H@) aushelfen, wenn neben Volker auch ihm bekannt ist, dass je nach Szene der Phenom II oder der Core i5/i7 in Anno 1404 deutlich vorne liegt. Inwieweit sich das mit seinen Prinzipien vereinbaren lässt weiß ich nun nicht, aber vielleicht erklärt er sich ja bereit ein ausgewähtes Savegame Szenario zur Verfügung zu stellen, das den Phenom II bevorteilt, wenn man ihn darum bittet.

[S940]

2. wurde ja spekuliert das das pcie interface bzw. dessen anbindung im Lynnfield einen Bottleneck (unter hoher GPU Last) darstellen könnte woran spekulativ der QPI der die 16 pcie lanes anbindet schuld sein könnte....
Ja ;)

nun war die änderung des QPI beim default i5 zw. 4.3ghz QPI und 4.8 ghz QPI praktisch kaum messbar und von linearer Skalierung mal ganz zu schweigen. Daher ist der QPI als möglicher Bottleneck auszuschliessen (zumindest bzgl. der Bandbreite).
Kannst Du eben nicht, erstens hast Du nur eine Szene eines Spiels vermessen, zweitens ist es auch gar nicht linear, schrieb ich schon vorher:
Bringt auch nicht wirklich was. Die Jungs im velinkten Test haben zw. 4,8 & 6,4 max. 5% gemessen, da kann es zw. 4,2 und 4,8 gar nicht viel zu messen geben.
____________________________


der Unterschied zw. dem i5@default und @4ghz ergibt sich daraus das der Bench hier stellenweise schon ins CPU Limit rennt beim i5@default
(dargo hat das auch an seinem c2q schon gezeigt)
An dargos Geschichte ist immer noch die Frage, ob das wirklich ein CPU oder nicht ein FSB Limit war, da er ja über den FSB übertaktet. Hab ich auch schon angesprochen, aber anscheinend interessiert es keinen.

was man noch vermessen könnte wäre ob der takt des uncore eine gravierende auswirkung auf die Performance im "GPU Limit" haben könnte

da müsste man mal schaun inwie weit man qpi cpu takt und ram takt möglichst gleich hallten könnte und nur den uncore (ausser qpi) beeinflusst
Naja wäre mit einer 1366 CPUs wohl einfacher, wenn man mal von dem RAM Takt = halber NB Takt Zusammenhang absieht.

Eventuell hat die ganze Geschichte ja doch nichts mit dme GPU Limit zu tun, sondern ist nur vom Cache abhängig. In dem Fall würde dann ein höherer L3/Uncore Takt sicherlich was bringen.

ciao

Alex

[Odal]

Ja ;)

Kannst Du eben nicht, erstens hast Du nur eine Szene eines Spiels vermessen, zweitens ist es auch gar nicht linear, schrieb ich schon vorher:


Das war aber die Szene (Farcry2 Ranch Medium DX9 UltraHigh) welche als Anlass für diesen Thread diente und wo der Nehalem angeblich eine GPU schwäche aufwies...

Die Jungs im velinkten Test haben zw. 4,8 & 6,4 max. 5% gemessen, da kann es zw. 4,2 und 4,8 gar nicht viel zu messen geben.

wie schon erwähnt die können garkeinen vergleich QPI 4.8 vs QPI 6.4 gemacht haben
das maximale was geht ohne an anderen Schrauben zu drehen ist was ich machte und da ergaben 12.5% mehr QPI Bandbreite eine praktisch nicht messbare FPS Änderung (<=1%) im "GPU Limit"


Naja wäre mit einer 1366 CPUs wohl einfacher, wenn man mal von dem RAM Takt = halber NB Takt Zusammenhang absieht.


bei den 1366 CPUs verhält sich die sache wieder ganz anders weil deren GPU Anbindung im wesentlichen abweicht und der QPI dort nicht nur das PEG anbindet

[Undertaker]

mit einem i5 und anno1404 kann ich dienen

aber meines wissens ist zwar der pcgh benchmark transparent aber der CB benchmark ist es nicht
d.h. es gibt afaik kein öffentliches savegame und benchmarkanleitung

Nun, man könnte die PCGH-Szene ja schoneinmal nachstellen, um diesbzgl. Unterstellungen diverser Personen auszuräumen - bei einem entsprechend fortgeschrittenen Savegame sollten sich ja auch diverse andere fordernde Stellen finden lassen, mal schauen ob die wirklich je nach Szene extrem unterschiedlich auf verschiedenen Architekturen performen - ich glaub ja nicht wirklich an diese Theorie. ;)
Ich meld mich mal die nächsten Tage, dass wir das mal nachstellen können. :)

[S940]

Das war aber die Szene (Farcry2 Ranch Medium DX9 UltraHigh) welche als Anlass für diesen Thread diente und wo der Nehalem angeblich eine GPU schwäche aufwies...
Tja, dann habt Ihr mit 2560er Auflösung und der Szene wohl einen Hinweis gegeben, dass da wirklich allein die GPU wichtig ist.
Im ersten Post dieses Threads wird für die Anomalie aber nur eine 1280er Auflösung angeführt. Bencht doch mal nochmal bei z.B. 1680 und schaut was da passiert.


wie schon erwähnt die können garkeinen vergleich QPI 4.8 vs QPI 6.4 gemacht haben
Schau genau hin, die haben nen S1366 Prozessor, und vergleichen C0 gegen D0 Chips. Letzerer hat ja den höheren QPI Takt. Der Thread hier ist ja auch allegemein über Nehalem, nicht exklusive Lynnfield :)


bei den 1366 CPUs verhält sich die sache wieder ganz anders weil deren GPU Anbindung im wesentlichen abweicht und der QPI dort nicht nur das PEG anbindetDas Thema hatte ich mal mit Chrisch durchgekaut, Chrisch behielt dabei (wohl) die Oberhand, denn jedes Lynnfield Sys hat auch einen QPI Takt, d.h. intern ist der PEG Slot zu 99% immernoch per QPI angebunden. Hätte nie gedacht, dass es sich Intel so einfacht macht und quasi nur einen halben x58 Chipsatz integriert und das Ganze intern per QPI verbindet. Aber es muss wohl so sein, wenn sie es eleganter gelöst hätten, gäbs keinen QPI Multiplier/Takt mehr (dabei meine ich nicht den BaseClk).

ciao

Alex

[Undertaker]

Hmm OK, das PCGH Anno-Save stürzt bei mir beim laden ab... Aber ka warum. :confused: Auf welcher Patch-Version basiert das Save? :confused: Ansonsten müsste man einfach ein anderes bzw. im Optimalfall sogar mehrere verschiedene nehmen...

[Odal]

Tja, dann habt Ihr mit 2560er Auflösung und der Szene wohl einen Hinweis gegeben, dass da wirklich allein die GPU wichtig ist.
Im ersten Post dieses Threads wird für die Anomalie aber nur eine 1280er Auflösung angeführt. Bencht doch mal nochmal bei z.B. 1680 und schaut was da passiert.

dann hat das aber nix mehr mit dem Topic zutun, was ja lautet "Nehalem unter 3D Last - wo ist der flaschenhals"
aber von mir aus können wir den auch noch mal in 1280x1024 laufen lassen
da spielt dann aber der CPU takt eine entscheidene Rolle, muss also vorher abgeklärt werden



Schau genau hin, die haben nen S1366 Prozessor, und vergleichen C0 gegen D0 Chips. Letzerer hat ja den höheren QPI Takt. Der Thread hier ist ja auch allegemein über Nehalem, nicht exklusive Lynnfield :)


was sich beim D0 genau geändert hat weiß nur Intel und Leute mit entsprechendem Insiderwissen. Der Bloomfield hat auch generell einen höheren QPI und damit müssen ja auch doppelt soviele pcie lanes versorgt werden, sowie das DMI und die dadurch angebundene Southbridge


Das Thema hatte ich mal mit Chrisch durchgekaut, Chrisch behielt dabei (wohl) die Oberhand, denn jedes Lynnfield Sys hat auch einen QPI Takt, d.h. intern ist der PEG Slot zu 99% immernoch per QPI angebunden. Hätte nie gedacht, dass es sich Intel so einfacht macht und quasi nur einen halben x58 Chipsatz integriert und das Ganze intern per QPI verbindet. Aber es muss wohl so sein, wenn sie es eleganter gelöst hätten, gäbs keinen QPI Multiplier/Takt mehr (dabei meine ich nicht den BaseClk).


Wie sollten sie das PEG sonst anbinden? Irgendwie muss ja die Kommunikation mit der "CPU" als auch dem Ram erfolgen

[Odal]

Hmm OK, das PCGH Anno-Save stürzt bei mir beim laden ab... Aber ka warum. :confused: Auf welcher Patch-Version basiert das Save? :confused: Ansonsten müsste man einfach ein anderes bzw. im Optimalfall sogar mehrere verschiedene nehmen...

im Review steht Anno 1.0

[Ph0b0ss]

Hmm OK, das PCGH Anno-Save stürzt bei mir beim laden ab... Aber ka warum. :confused: Auf welcher Patch-Version basiert das Save? :confused: Ansonsten müsste man einfach ein anderes bzw. im Optimalfall sogar mehrere verschiedene nehmen...

Bei mir auch sofort CTD, wenn ich das PCGH Anno-Save laden will. Mit Patch 1.1. PCGH haben wohl auch 1.1 genommen:

• Anno 1404 v1.1 (D3D10)

http://www.pcgameshardware.de/aid,697048/Radeon-HD-5870-im-Test-CPU-Skalierung-mit-6-CPUs-in-WoW-Risen-Anno-1404-FC2-und-Crysis-Warhead/Grafikkarte/Test/

[Undertaker]

Mit 1.0 gehts auch nicht... Wenn jemand also ein anderes Save mit einer möglichst großen Stadt zur Hand hat... ;)

[S940]

dann hat das aber nix mehr mit dem Topic zutun, was ja lautet "Nehalem unter 3D Last - wo ist der flaschenhals"
aber von mir aus können wir den auch noch mal in 1280x1024 laufen lassen
da spielt dann aber der CPU takt eine entscheidene Rolle, muss also vorher abgeklärt werden
Nö, im Topic steht nur 3D Last, solange der Schirm irgendein 3D Bildchen anzeigt, ist das noch ok :)
Im Ernst, damit wäre natürlich auch noch VGA & SVGA gültig, was man aber eben nicht will ^^ Aber Euere 2560er Mammutauflösung könnte eben schon des guten zuviel sein. 1680 sollte als Mittelwert eigentlich optimal sein, wenn Du / Ihr Euch die Mühe machen wollt, dann gerne auch noch 1280 oder 1920.



was sich beim D0 genau geändert hat weiß nur Intel und Leute mit entsprechendem Insiderwissen. Der Bloomfield hat auch generell einen höheren QPI und damit müssen ja auch doppelt soviele pcie lanes versorgt werden, sowie das DMI und die dadurch angebundene Southbridge
Aso ja natürlich, zw. C0 & D0 gabs noch mehr Änderungen, das stimmt, könnte gut sein, dass da ausser des QPI Taktes noch was anderes gedreht wurde. Müßte man halt mit einem D0 @4,8 überprüfen.


Wie sollten sie das PEG sonst anbinden? Irgendwie muss ja die Kommunikation mit der "CPU" als auch dem Ram erfolgenDirekt an die interne Crossbar, die gibts bei Intel genauso wie bei AMD, hab dazu in der Diskussion mit Chrisch ein Intel Schema aus nem QPI Pdf gepostet, schmeiß einfach die SuFu an, wenns Dich genauer interessiert. Chrisch hat danach seine Version gepostet - die vermutlich den Kern getroffen hat.

ciao

Alex

[Undertaker]

Aso ja natürlich, zw. C0 & D0 gabs noch mehr Änderungen, das stimmt, könnte gut sein, dass da ausser des QPI Taktes noch was anderes gedreht wurde. Müßte man halt mit einem D0 @4,8 überprüfen.

Öhm, also soweit ich weiß, haben sowohl C0 als auch D0 4,8GT/s, sind aber ebenso für 6,4GT/s freigegeben. Performancegewinn aber praktisch nicht existent.

[Wuge]

Wie man aus dem Link erkennen kann, ist der D0 am GPU Limit bei 6,4 GT/s aber 5% schneller als C0 bzw. D0 mit 4,8 GT/s. Könnten natürlich auch Messfehler sein.

[Odal]

Direkt an die interne Crossbar, die gibts bei Intel genauso wie bei AMD, hab dazu in der Diskussion mit Chrisch ein Intel Schema aus nem QPI Pdf gepostet, schmeiß einfach die SuFu an, wenns Dich genauer interessiert. Chrisch hat danach seine Version gepostet - die vermutlich den Kern getroffen hat.

ciao

Alex

ehm was für ne interne crossbar? der Nehalem ist doch kein zusammengepappter Dual Core mehr die cores kommunizieren doch wohl über ihre 8MB shared L3 cache

[S940]

ehm was für ne interne crossbar? der Nehalem ist doch kein zusammengepappter Dual Core mehr die cores kommunizieren doch wohl über ihre 8MB shared L3 cache
Und wie wird der L3 angeschlossen und QPI und der IMC ? ;-)
Da gibts ne Crossbar, wie bei AMD. Wenn Du Dich mit Netzwerken auskennst, sowas wie nen Switch, x Eingänge (alle Datenverbraucher, also die Kerne) und y Ausgänge (IMC, L3, QPI), ich kram die Bilder mal noch aus:
Bloomfield (S1366 CPU) Schema:
http://www.abload.de/img/ixbar4k1w.png

Vermutlicher Lynnfield Aufbau, Copyright gebührt Chrisch ^^
http://www.abload.de/img/qpi-nurmalsofwmw.png

Ich dachte eben, dass Intel QPI komplett streicht und PCIe / DMI direkt anschflanscht. Haben sie aber wohl nicht gemacht ... ansonsten gäbs keinen QPI Takt im BIOS der 1156 Bretter zu finden.

ciao

Alex

[Odal]

Und wie wird der L3 angeschlossen und QPI und der IMC ? ;-)
Da gibts ne Crossbar, wie bei AMD. Wenn Du Dich mit Netzwerken auskennst, sowas wie nen Switch, x Eingänge (alle Datenverbraucher, also die Kerne) und y Ausgänge (IMC, L3, QPI), ich kram die Bilder mal noch aus:
Bloomfield (S1366 CPU) Schema:
http://www.abload.de/img/ixbar4k1w.png


Wie wie wird der L3 Cache angeschlossen? Der L3 Cache hängt an der CPU über L2/L1 cache und beinhaltet als inclusive cache sämtliche daten des L2 cache aller cores
somit können die cores direkt über den L3 cache kommunizieren

[S940]

Wie wie wird der L3 Cache angeschlossen? Der L3 Cache hängt an der CPU über L2/L1 cache und beinhaltet als inclusive cache sämtliche daten des L2 cache aller cores
somit können die cores direkt über den L3 cache kommunizieren
Natürlich, aber wie kommen die Daten in den L3 rein ? Und wie genau ist der L3 "angehängt" ? Wer stellt z.B. sicher, dass nicht ein Kern schreibt, wenn der andere liest ? Oder dürfen / können alle 4 Kerne gleichzeitig zugreifen ?

Ist alles etwas komplexer ;)
Datenabgleich geschieht natürlich im L3, transportiert werden die Daten dabei über die Crossbar.

ciao

Alex

[Odal]

Der Cache Controller. der hat aber nix mit dem PEG zutun.

[S940]

Der Cache Controller. der hat aber nix mit dem PEG zutun.Jo, aber den L3 Cache Controller gibts nur 1x ;-)
Der Datenverkehr zum/vom L3 läuft über die besagte XBAR, manchmal wirds auch Queue genannt:

Nehalem is a fully integrated quad-core device, with an inclusive and shared last level cache. A central queue acts as a crossbar and arbiter between the four cores and the ‘uncore’ region of Nehalem, which includes the L3 cache, integrated memory controller and QPI links.
http://www.realworldtech.com/page.cfm?ArticleID=RWT040208182719&p=2

Aber mit PCIe hat der L3 in der Tat nichts zu tun, an der XBar hängt ja leider nur QPI, kein PCIe :(

ciao

Alex

[Odal]

der PEG controller hängt aber im Lynnfield per QPI am IMC

wäre auch ziemlich schwachsinnig die 8MB L3 cache vollzuschaufeln weil die GPU auf daten im Hauptspeicher zugreifen muss z.b. besonders krass im fall des vram überlaufs

[S940]

der PEG controller hängt aber im Lynnfield per QPI am IMC:confused:
Du weisst dass IMC für Integrated Memory Conroller steht ?
Was bitte hätten die PCIe Lanes der Grafikkarte (direkt) am Speicherkontroller zu suchen ?

Da hast Du eindeutig was falsch verstanden, schick mal nen Link wo Du das her hast, dann schau ichs mir morgen mal an.

Bis dann

Alex

P.S: Les Dir bis dahin vielleicht die komplette Seite des obigen Realworldtech Artikels durch.

[Odal]

Bloomfield
http://666kb.com/i/bfbodg2ylutnk84lz.jpg

Lynnfield
http://666kb.com/i/bfboe9nyxdi7ah847.gif

[Gast]

Könnt ihr mir mal einen Gefallen tun und den integrierten Truecrypt 6.3a-Benchmark für 100 MB Buffersize durchführen und das AES-Ergebnis posten? Dauert keine 30 Sekunden und man muss Truecrypt nicht einmal installieren.

Wer es nicht hat oder kennt: http://www.truecrypt.org/downloads

Anschließend, falls man es nicht installieren will, beim Ausführen der Datei auf "Extract" statt "Install" klicken. Danach die TrueCrypt.exe im entpackten Ordner ausführen und: "Tools -> Benchmark". Buffer Size auf 100 und das Ergebnis für AES hier posten.

Mich interessiert vor allem i5 / i7 vs. Phenom II X4.

Mir will irgendwie nicht in den Schädel, warum ein X4 620 2,6 GHz 10 % schneller als ein i5-750 2,66 GHz oder ein i7-960 trotz SMT (wovon Truecrypt profitiert) immer noch langsamer als ein X4 965 BE sein soll. Das ist ja fast schlimmer als die Spieleergebnisse. Hier scheint die Architektur des Phenom z. B. deutlich schneller zu sein, warum auch immer.

[Odal]

ich lads mal runter, aber imho gibts da keinen Zweifel das das einfach auf den Phenoms viel besser rennt

[Avalox]

Mir will irgendwie nicht in den Schädel, warum ein X4 620 2,6 GHz 10 % schneller als

Das hast du unter Linux des öfteren, dort schlägt ein Phenom II X3 710 (!) öfter einen Core i7 920 im konkreten Anwendungsfall. Ganz zu schweigen vom i5.

Gerade bei sehr Daten intensiven Prozessen.

http://www.phoronix.com/scan.php?page=article&item=intel_lynnfield&num=7

Alles eine Sache der Anwendung, der Optimierung, der Entwicklungsumgebung und dem System.

[Undertaker]

Das die Werte dort teils völlig abstrus sind, sollte aber auch jedem auffallen. ;) Ein i5 750 doppelt so schnell wie ein i7 920? Ein i5 750 fast so schnell wie ein i7 870, ein i7 920 aber knapp 40% in Front?

@Gast oben:

Truecrypt findest du auch bei CB, das ist seit jeher eine AMD-Domäne und geht praktisch nur auf Takt ab. Trotz ziemlich langsamem DDR2-800, nur 1,8GHz NB und 2t bin ich bei 3,5GHz so schnell wie ein X4 965BE.

[Avalox]

Das die Werte dort teils völlig abstrus sind, sollte aber auch jedem auffallen. ;) Ein i5 750 doppelt so schnell wie ein i7 920? Ein i5 750 fast so schnell wie ein i7 870, ein i7 920 aber knapp 40% in Front?



Die Werte sind nicht abstrus und sehr nachvollziehbar. Es wird eine Benchmark Suite genutzt. Wenn du ein wenig auf der Seite suchst wirst du auch heraus finden, dass dort oftmals auf erstaunliches Verhalten eingegangen wird.

http://www.phoronix.com/scan.php?page=article&item=intel_lynnfield&num=9

So ist auch PostgreSQL (welches unter Linux z.B. auch deutlich performanter als unter Windows ist) eingehend erklärt. Es ist schlicht ein Verhalten, welches mit Intels Hyper Threading einhergeht.

Entgegen so manchen Benchmarks sind die von phoronix durchaus interessant, was wahrscheinlich auch daher kommt, dass sich die Jungs dort eh besser auskennen als der Durchschnitt.

[Odal]

Das hast du unter Linux des öfteren, dort schlägt ein Phenom II X3 710 (!) öfter einen Core i7 920 im konkreten Anwendungsfall. Ganz zu schweigen vom i5.

Gerade bei sehr Daten intensiven Prozessen.

http://www.phoronix.com/scan.php?page=article&item=intel_lynnfield&num=7

Alles eine Sache der Art der Anwendung, der Optimierung, der Entwicklungsumgebung und dem System.

Leider gibts in deinem Link nur den Crypt vergleich Phenom-Nehalem
mich hätte mal der Vergleich für z.b. GCC interessiert

@truecrypt bench auf 4Ghz erreiche ich gerade mal 563MB/s @stock teste ich gleich

[Undertaker]

@Avalox: Wenn SMT zu einem Einbruch auf die Hälfte führt, sind die Werte für mich ziemlich witzlos - denn unter solchen Bedingungen wird es keiner aktivieren. Das Verhalten bei Apache bleibt völlig unerklärlich.

-> Ab in die Tonne.

[Gast]

Truecrypt findest du auch bei CB, das ist seit jeher eine AMD-Domäne.

Mich interessiert das Warum. Evtl. besteht ein Zusammenhang zu den "Einbrüchen" bei hohen Auflösungen. Vielleicht wird bei Truecrypt genau der "flaschenhalsbehaftete" Teil der Nehalem-Architektur bemüht, der z. B. bei der Anno-Szene zu einem derart schwachen Ergebnis führte. Denn ansonsten ist Nehalem gerade in Anwendungen sehr sehr sehr viel flotter. Autodesk 3ds Max 2010: 42 %, Lame: 22 %, MainConcept H.264/AVC Pro: 26 %, Paint.NET: 65 %, SPECjvm2008: 33 %, WinRar: 42 %.

[S940]

@Odal:
Ja da hast Du dann blöderweise den Nachteil der wikipedia Idee... jeder kann Bilder malen und die dann hochladen. Das gezeigte Schema ist 100% falsch, die interne Organisation ist wie besagt wie an einem Netzwerk-Switch mit parallelen Anschlüssen, in Reihe - wie in dem Wikipedia Bild - ist da nichts geschaltet.

Der Speicherkontroller hat mit dem PCIe / QPI Anschluss nichts am Hut. Da hat nur einer das Uncore Konzept falsch verstanden.

Dass das mit QPI und IMC nicht stimmt, siehst Du schon an meinem ersten Bildchen das ich oben gepostet hatte, dass ist von einem offiziellem Intel PDF, dass stimmt garantiert :)

Dein PEG Edit ist deshalb natürlich auch falsch, da ist Chrischs Paint Lösung gefragt. Ob die stimmt ist nicht 100%ig klar, aber ich nehms zu 99% an. Für QPI im Lynnfield wäre ausser einer Tunnelfunktion zum PCIe Anschluss ansonsten wirklich kein Grund. Also muss Chrischs Edit korrekt sein.

@Truecrypt:
Das ist hangecodeter Assembler, der stark die FPU fordert, und die FPU des K10 ist schneller als die des Nehalems - das gibt sogar Intel zu. Es fällt nur nicht häufig auf, da es ausserhalb des HPC Bereichts nicht viele Leute interessiert.

Auf der Intel Server Seite gabs mal einen Crash-Test Simulations Bench, bei dem (vermutlich) ebenfalls die FPU raucht. Wie auch immer, ein alter Barcelona Opteron war fast so schnell wie ein Intel Chip mit deutlich mehr MHz. Der Bench wurde von Intel durchgeführt - also sicherlich nicht pro AMD optimiert ^^
Dass dann ein Shanghai schneller ist, liegt nahe.

Intel weiss auch über den Verschlüsselungsnachteil Bescheid, in den 32nm Westmeres gibts wieder mal eine Befehlssatzerweiterung, nennt sich AES, und bringt natürlich ein paar AES Verschlüsselungsbefehle mit.

Von VIA gibts schon seit längerem Besseres in Form der PADLock Befehle, aber das interessiert Intel wieder einmal wenig :(

Edit:
@Gast: Nein, Truecrypt hat sicherlich nichts mit dem Anno Bench gemein, bei Anno hab ich nachwievor den L1 und/oder den L2 Cache in Verdacht. Der ist mit den ganzen Objekten der Riesenkarte sicherlich überbelastet, v.a. wenn auch noch SMT angeschalten ist.

Indiz ist der Frameverlauf, der i7 fängt stark an, viel stärker als die AMDs. Das ist logisch, da Intels Rechenwerke bekanntermaßen schneller sind, aber dann fällt die Leistungs rapide ab. D.h. die Rechenwerke stehen still, und das tuen sie nur, wenn sie länger auf Daten warten müssen, d.h. im Intel Fall, dass die Daten nicht im L1 und vermtulich auch nicht im L2 sind.
AMD dagegen holt auf, und überholt, da werden wohl die L1/L2 Caches geladen und benützt, während die Intels den langsameren L3 oder RAM bemühen müssen.

Normalerweise wird sowas von cleveren Prefetch Algorithmen verdeckt, aber dazu muss man ein Zugriffsmuster erkennen. Das es sowas im Anno Fall gibt, bezweifle ich ganz stark, die zahlreichen Schiffahrtslinien, Inseln etc. pp. auf der Riesenkarte haben sicherlich ein chaotisches, unvorhersagbares RAM Zugriffsverhalten.

ciao

Alex

[Odal]

truecrypt beim i5@default komm ich auf 393MB/s

[Gast]

truecrypt beim i5@default komm ich auf 393MB/s

Also fast genau auf den CB-Wert. Danke.

Ich im Übrigen auch. E2140 @ 3040 MHz: 219 MB/s. Scheint sich nicht einmal der L2-Cache auszuwirken. Bei CB: E8400 3,0 GHz: 222 MB/s.

[Undertaker]

Mich interessiert das Warum.

Die Core 2 sind bei Truecrypt ebenfalls schwach. Der Code scheint AMD-CPUs einfach besser zu schmecken, wurde evntl. auf einer entsprechenden CPU optimiert, nutzt eine AMD-Befehlssatzerweiterung o.ä. - wer weiß.

[Undertaker]

Ach ja, zur FPU Theorie:

http://www.computerbase.de/artikel/hardware/prozessoren/2009/test_amd_phenom_ii_x4_920_940_black_edition/13/#abschnitt_truecrypt_60

Schon ein Athlon 64 ist bei gleichem Takt schneller als ein Core 2 und erreicht praktisch die gleichen Werte wie ein Athlon II mit der deutlich stärkeren FPU.

[Gast]

Also fast genau auf den CB-Wert. Danke.

Ich im Übrigen auch. E2140 @ 3040 MHz: 219 MB/s. Scheint sich nicht einmal der L2-Cache auszuwirken. Bei CB: E8400 3,0 GHz: 222 MB/s.
mit einem Q9650@4.58Ghz schaffe ich es auf 670 MB/s

[Ronny145]

truecrypt beim i5@default komm ich auf 393MB/s


Und ohne Turbo auf 355-360 und damit nur auf Q6600 Niveau. Pro Mhz Leistung damit schlechter als ein Kentsfield.

[S940]

Wer Assebler lesen kann, darf sich gerne durch den Quellcode wühlen, ist vermutlich dieser hier:
http://gladman.plushost.co.uk/oldsite/AES/aes-src-16-04-07.zip
http://gladman.plushost.co.uk/oldsite/AES/index.php

Auf den ersten Blick sehe ich da 0 FPU, da wird nur immer in den INT Registern herumgerechnet. INT ist aber doch bei Intel normalerweise immer schneller ?

Naja, hab den Code nur überflogen hab vermutlich was übersehen.

ciao

Alex

[2+2=4]

Die Core 2 sind bei Truecrypt ebenfalls schwach. Der Code scheint AMD-CPUs einfach besser zu schmecken, wurde evntl. auf einer entsprechenden CPU optimiert, nutzt eine AMD-Befehlssatzerweiterung o.ä. - wer weiß.
Ach ja, zur FPU Theorie:

http://www.computerbase.de/artikel/hardware/prozessoren/2009/test_amd_phenom_ii_x4_920_940_black_edition/13/#abschnitt_truecrypt_60

Schon ein Athlon 64 ist bei gleichem Takt schneller als ein Core 2 und erreicht praktisch die gleichen Werte wie ein Athlon II mit der deutlich stärkeren FPU.


Welche Befehlssatzerweiterung sollte das sein, wenn es SSE4a logischerweise nicht sein kann.

[Undertaker]

Vielleicht wird ja mal 3DNow genutzt. :D Tja, ka. Mit einem grundlegenden Architekturvorteil ist es zumindest schwierig zu erklären, wenn selbst der alte K8 schon extrem gut pro Takt performt.

[S940]

Welche Befehlssatzerweiterung sollte das sein, wenn es SSE4a logischerweise nicht sein kann.Siehe oben, dass sind die 08/15 INT Register ...
Keine Ahnung was da bei Intel schief läuft, der Cache kanns ja nicht sein, wenn der E2140 genauso schnell ist.

ciao

Alex

[Undertaker]

Interessant auch, bei Sandras AES-Test schneiden die Intel-Modelle deutlich besser ab.

[1x1=1]

Ja vor allem hat man als User so viel praktischen nutzen von Sandras AES-Test :D Ich vermute der ist im Vergleich zu Truecrypt auch nicht transparent, sprich nicht open source. *rolleyes*

[Undertaker]

Wenn du es so willst, auch der integrierte Truecrypt Benchmark sagt wenig ;) Beispiel WinRAR:

http://www.computerbase.de/artikel/hardware/prozessoren/2009/test_prozessoren_2009/7/#abschnitt_winrar
http://www.computerbase.de/artikel/hardware/prozessoren/2009/test_prozessoren_2009/11/#abschnitt_winrar

Synthetisch ist ein X4 965BE 33% schneller als ein E8600. In der realen Anwendung führt auf einmal letzterer mit 4%...

[Gast]

@Undertaker
Dir ist vermutlich aufgrund der Konzentration auf das Gegenreden//Rechtbehalten vermutlich das Wesentliche 1x1=1s Aussage entgangen. Sandras AES ist überhaupt nicht nachvollziehbar bzw. nicht auf Manipulationen nachprüfbar, gute Intel-Ergebnisse sind da fast schon erwartungsgemäß bis obligatorisch. Truecrypt ist völlig tarnsparent und die AMD-Ergebnisse sind überwältigend. Vermutlich gerade wegen des fehlenden Versteckspiels.

[Undertaker]

Ich denke, seinen Satz mit dem "praktischen Nutzen" hast eher du falsch verstanden. ;) Ebenso die doch verwunderliche, von mir weiter oben erwähnte Besonderheit, das alle AMD-Modelle von Athlon 64 bis Phenom II pro Kern und Takt beinahe identisch schnell sind.

[1x1=1]

Zumal der Winrar-Vergleich witzlos ist, da beim Komprimieren (real) max. 2 Kerne vollausgelastet werden, das kann sich bei Multicore auch auf alle Kerne verteilen. folglich bei einem Tripel-Core sind es dann 66%, bei einem Quad-Core 50% CPU-Auslastung ingesamt. Der integrierte Benchmark dagegen erzeugt deutlich höhere CPU-Auslastungen, kein wunder das der Wolfdale da nicht mithalten kann. Truecrypt nutzt jedoch alle vorhandenen Kerne, deswegen ist das Winrar-Szenario nicht übertragbar.

[Undertaker]

Das Problem bleibt auch, wenn du zwei Quadcores vergleichst, ersetz z.B. den E8600 mit dem Q9550 und vergleiche weiterhin mit dem X4 965BE. Die integrierten Benchmarks können aus verschiedensten Gründen von der realen Anwendung abweichende Ergebnisse produzieren, korrekterweise sollten sich Reviews immer auf einen eigenen Bench der realen Anwendung beschränken.

[Wuge]

... bei Anno hab ich nachwievor den L1 und/oder den L2 Cache in Verdacht. Der ist mit den ganzen Objekten der Riesenkarte sicherlich überbelastet, v.a. wenn auch noch SMT angeschalten ist.

Indiz ist der Frameverlauf, der i7 fängt stark an, viel stärker als die AMDs. Das ist logisch, da Intels Rechenwerke bekanntermaßen schneller sind, aber dann fällt die Leistungs rapide ab. D.h. die Rechenwerke stehen still, und das tuen sie nur, wenn sie länger auf Daten warten müssen, d.h. im Intel Fall, dass die Daten nicht im L1 und vermtulich auch nicht im L2 sind.
AMD dagegen holt auf, und überholt, da werden wohl die L1/L2 Caches geladen und benützt, während die Intels den langsameren L3 oder RAM bemühen müssen.

Normalerweise wird sowas von cleveren Prefetch Algorithmen verdeckt, aber dazu muss man ein Zugriffsmuster erkennen. Das es sowas im Anno Fall gibt, bezweifle ich ganz stark, die zahlreichen Schiffahrtslinien, Inseln etc. pp. auf der Riesenkarte haben sicherlich ein chaotisches, unvorhersagbares RAM Zugriffsverhalten.

ciao

Alex

Selbst wenn man auf den großen L3 muss ist das noch sehr sehr schnell! Das Verhätniss aus Hitrate und Latenz dürfte insgesamt besser ausfallen als beispielsweise auf einem Core 2.

Letzteres (Frames sinken wenn Cache vollläuft) klingt für mich - nicht persönlich nehmen - haarstreubend. Die Abläufe in der CPU sind so rapide, dass sich Stalls ab dem ersten angezeigten Frame auswirken. Bis dahin sind ja schließlich schon einige Millionen CPU-Cycles durchgelaufen. Auch die theoretische Power der Rechenwerke ist kaum von Bedeutung - die sind außer für HPC Anwendungen generell oversized. Sowohl bei Intel als auch bei AMD. Um Deine These zu vervollständigen müssten man noch hinzufügen, dass der P4 einen Inputlag auf Grund der langen Pipeline hatte und ein Atom von allen aktuellen CPUs am schnellsten auf Mausklicks reagiert.

Ein Einbruch am GPU-Limit kann kaum durch die Kern-Architektur begründet sein, wenn der gleiche Workload (für die CPU spielt die Auflösung schließlich keine* Rolle) am CPU-Limit deutlich schneller ausgeführt wird als auf anderen CPUs.

Wenn es das vermutete Phänomen tätsachlich gibt, dann liegt es meines Erachtens in der Peripherie der CPU-Kerne begründet.

[S940]

Selbst wenn man auf den großen L3 muss ist das noch sehr sehr schnell! Das Verhätniss aus Hitrate und Latenz dürfte insgesamt besser ausfallen als beispielsweise auf einem Core 2.
Äh bei der Aussage stellen sich meine Haare auch zu Berge ;-)

Core2 hat 6 MB L2 mit 14-15 Takten, Nehalem 256kb L2 mit 11-13 Takten und (nutzbare) 7 MB L3 mit 30-40 Takten.

Wie da irgendwas besser ausfallen sollte, erschließt sich mir nicht.
Sehr oft helfen die Prefetcher, aber wenn die eben versagen muss man mit den Latenzen leben.

Mag nicht oft vorkommen, aber oft ist der Core2 / Phenom2 schließlich auch nicht vorne :)

Ein Einbruch am GPU-Limit kann kaum durch die Kern-Architektur begründet sein, wenn der gleiche Workload (für die CPU spielt die Auflösung schließlich keine* Rolle) am CPU-Limit deutlich schneller ausgeführt wird als auf anderen CPUs.Siehe weiter vorne, ich hab da schon mal angefragt, ob bei Anno in den unterschiedlichen Auflösungen wirklich der gleiche Kartenausschnitt angezeigt wird, und nur vergrößert / verkleinert wird, oder nicht doch viel mehr Details dargestellt werden. In dem Fall wäre das ein kleiner Unterschied. Leider hat keiner darauf geantwortet :(
Im Anno Fall ist das aber eh egal, da dort auch der Phenom2 bei der kleinen 1024er Auflösung vorne liegt, das Problem also eher auflösungsunabhängig ist.

Die Abläufe in der CPU sind so rapide, dass sich Stalls ab dem ersten angezeigten Frame auswirken. Bis dahin sind ja schließlich schon einige Millionen CPU-Cycles durchgelaufen.Auch wieder wahr, in der einen Sekunde eines frames passieren "ein paar Takte in der CPU".
Aber irgendwas muss bremsen ... bei der Riesen cb Karte halte ich es nicht für unmöglich, dass irgendwo im Code alle Objekte abgeklappert werden müssen, die - wegen der schieren Anzahl - halt andauernd zw. L2 und L3 hin und hergeladen werden. Im PCGH Bench gibts ja keine Probleme - und das im gleichen Spiel.
Um Deine These zu vervollständigen müssten man noch hinzufügen, dass der P4 einen Inputlag auf Grund der langen Pipeline hatte und ein Atom von allen aktuellen CPUs am schnellsten auf Mausklicks reagiert.
Öhm .. was hat das mit meiner Idee zu tun, dass bei Anno eventuell der Cache überläuft ? Ich sehe da keinen Zusammenhang.

Wenn es das vermutete Phänomen tätsachlich gibt, dann liegt es meines Erachtens in der Peripherie der CPU-Kerne begründet.
Hmm "Peripherie", also doch Cache ? ^^
Im Ernst, spekulier doch mal weiter, was könnte es sein ? Was anderes mache ich auch nicht :)
Das Problem ist ja, dass eigentlich alles andere ausfällt.
QPI: schnell genug
PCIe: ebenfalls
IMC: auch topp
Uncoretakt: schneller als bei AMD
Rechenwerke: größtenteils auch schneller als AMD.

Es bleibt nur der Cache als größter Unterschied übrig. Oder die Benchmethode ^^ CB hat ja ein paar Angaben gemacht, wie man die Ergebnisse verfälschen könnte. Falls PCGH so benchen sollte, und sozusagen den Rest abschneidet, können wir uns die Spekulation hier sparen ^^

ciao

Alex

[Gast]

korrekterweise sollten sich Reviews immer auf einen eigenen Bench der realen Anwendung beschränken.

Dann frage ich mich aber welche Erkenntnis uns deine Erwähnung des völlig theoretischen/synthetischen Sandra AES bringen soll? Weiter entfernt von der Realität und jeglicher Nachvollziehbarkeit geht nicht mehr.

[Undertaker]

Im Anno Fall ist das aber eh egal, da dort auch der Phenom2 bei der kleinen 1024er Auflösung vorne liegt

In der PCGH-Demo mit noch niedrigeren fps auf den PII führt der i5/i7 allerdings mit etwa 50-80% Vorsprung pro Takt... Und auch bei CB ist es nur ein Gleichstand pro Takt, was allerdings schon ungewöhnlich stark ist.

[Wuge]

@S940

Der nutzbare Last-Level-Cache des Nehalem ist 8 MB. Auch wenn der L2 teile davon vorhalten muss. Aber das spielt ja nicht die Rolle.

In der Praxis ist die Zugriffszeit des L3 nach meinem Kenntnisstand und allem was ich bisher gesehen haben - auch bei Random - weit weg von 40 Takten. Der L3 des i7 ist bei gleichem (Unocre vs. Core-Takt) nicht wesentlich langsamer als der L2 der Core 2 CPUs. Wenn das Prefetching gut funktioniert, sogar schneller da die Daten im L2 vorhanden sind wenn sie benötigt werden. Die Latenz des L2 liegt übrigens bei etwa 10 Takten - je nach Zugriffsmuster.

---

Meine Grundaussage sollte die sein, dass ein gleicher Programmcode nicht anders abläuft und auf einmal im CPU-Kern ein Flaschenhals entsteht, nur weil die Grafiklast erhöht wird. Der Kartenausschnitt ist nicht von der Auflösung abhängig sondern kann gezoomt werden. Zumal die Objekte in der Karte ja nicht durch den CPU-Cache geschleust werden. Der Cache arbeitet ja nicht auf Datei oder Objektebene. Und selbst wenn es so wäre, sollte der große L3 gerade dann zum Vorteil werden, denn die Objekte sind permanent vorhanden und würden prima mit dem Prefetcher harmonieren.

---

Mit Peripherie meine ich QPI->Switch->PCIe. Aber wie Du schon sagst, aus theoretischer Sicht kein Flaschenhals erkennbar.

Ich tippe nach wie vor darauf, dass die C-States bei den Intels aktiviert sind. Je geringer die CPU-Last wird (bei mir - astreine GPU-Limitierung - langweilt sich die CPU teilweise bei Anno in hohen Ausflösungen) umso ehr besteht die Gefahr, dass Kerne in C3 oder C6 gehen und das kostet beim Aufwachen genau die paar Prozentpunkte um die wir Spekulieren.

---

Möglicherweise können wir uns die Speku auch ganz sparen, denn die Abweichungen sind nicht hinreichend reproduzierbar und damit zunächst Messtoleranzen. Möglicherweise kommt das durch die Messmethode und unterschiedliche Systemtimer zu Stande (siehe APIC, HPET-Problematik).

---

Btw. TrueCrypt scheint wohl kaum parallelisierbar zu sein und läuft in einem 1-IPC-Stream durch. Der i7 erreicht hier gerade einmal eine um 25% höhere per Core IPC-Rate als mein Netburst-Rechner. Da zählt nur Takt... Typisch Brute-Force. Die FPU kanns kaum sein, denn auch bei klassischer FPU-Last kommt ein i7 schon recht gut gegen andere CPUs weg. Wenn SSE genutzt wird allemal - siehe Prime. Ist der AES-Code eigentlich x87 oder vielleicht sogar reine ALU-Arbeit?

[S940]

@S940

Der nutzbare Last-Level-Cache des Nehalem ist 8 MB. Auch wenn der L2 teile davon vorhalten muss. Aber das spielt ja nicht die Rolle.
Nö, wegen inklusiv Design können nur 7 MB genützt werden, der Rest geht für die Kopien der 4 L2s drauf. Die L1 vernachlässige ich dabei.

In der Praxis ist die Zugriffszeit des L3 nach meinem Kenntnisstand und allem was ich bisher gesehen haben - auch bei Random - weit weg von 40 Takten. Der L3 des i7 ist bei gleichem (Unocre vs. Core-Takt) nicht wesentlich langsamer als der L2 der Core 2 CPUs. Wenn das Prefetching gut funktioniert, sogar schneller da die Daten im L2 vorhanden sind wenn sie benötigt werden. Die Latenz des L2 liegt übrigens bei etwa 10 Takten - je nach Zugriffsmuster.
Höre ich zum ersten Mal, dass das sooooo gut sein soll. Mit Prefetch natürlich, aber ohne glaube ich Dir das nicht. Sei mir bitte nicht böse, aber das müßtest Du mir mit Links nachweisen ;)

---

Meine Grundaussage sollte die sein, dass ein gleicher Programmcode nicht anders abläuft und auf einmal im CPU-Kern ein Flaschenhals entsteht, nur weil die Grafiklast erhöht wird. Der Kartenausschnitt ist nicht von der Auflösung abhängig sondern kann gezoomt werden. Zumal die Objekte in der Karte ja nicht durch den CPU-Cache geschleust werden. Der Cache arbeitet ja nicht auf Datei oder Objektebene. Und selbst wenn es so wäre, sollte der große L3 gerade dann zum Vorteil werden, denn die Objekte sind permanent vorhanden und würden prima mit dem Prefetcher harmonieren.
Jo normal gebe ich Dir da gerne recht, aber irgendwas passiert halt bei Anno. Das einzige auf das ich komme ist eben der kleine L2 plus nutzloser Prefetcher. Das der Cache nur auf Datenebene arbeitet ist auch klar, aber irgendein Konstrukt für dem ganzen Firlefanz muss ja irgendwo im Speicher liegen :)

---

Mit Peripherie meine ich QPI->Switch->PCIe. Aber wie Du schon sagst, aus theoretischer Sicht kein Flaschenhals erkennbar.
Ja, direkt frustrierend ^^

Ich tippe nach wie vor darauf, dass die C-States bei den Intels aktiviert sind. Je geringer die CPU-Last wird (bei mir - astreine GPU-Limitierung - langweilt sich die CPU teilweise bei Anno in hohen Ausflösungen) umso ehr besteht die Gefahr, dass Kerne in C3 oder C6 gehen und das kostet beim Aufwachen genau die paar Prozentpunkte um die wir Spekulieren.
Ahhh ... C-States... ja gute Idee, bin ich auf alle Fälle nicht dagegen. Bei den neuen USB3/SATA3 Chips kosten die Stromsparmodi komischerweise auch Leistung und PCGH hatte ja mit Turbo-Off gebencht. Also eventuell ein Turbo-Loch (http://de.wikipedia.org/wiki/Turbolader#Nachteile_der_Turboaufladung) :(

---

Möglicherweise können wir uns die Speku auch ganz sparen, denn die Abweichungen sind nicht hinreichend reproduzierbar und damit zunächst Messtoleranzen. Möglicherweise kommt das durch die Messmethode und unterschiedliche Systemtimer zu Stande (siehe APIC, HPET-Problematik).
Klingt interessant, hast Du nen Link dazu ? Hab ich noch nicht gehört.

---
Btw. TrueCrypt scheint wohl kaum parallelisierbar zu sein und läuft in einem 1-IPC-Stream durch. Der i7 erreicht hier gerade einmal eine um 25% höhere per Core IPC-Rate als mein Netburst-Rechner. Da zählt nur Takt... Typisch Brute-Force. Die FPU kanns kaum sein, denn auch bei klassischer FPU-Last kommt ein i7 schon recht gut gegen andere CPUs weg. Wenn SSE genutzt wird allemal - siehe Prime. Ist der AES-Code eigentlich x87 oder vielleicht sogar reine ALU-Arbeit?Hab hier, oder im anderen Parallelthread den Link zum ASM Sourcecode gepostet. Ich seh da nichts Weltbewegendes, nur die Standard INT Register und ein paar movs.

ciao

Alex

[Wuge]

Nö, wegen inklusiv Design können nur 7 MB genützt werden, der Rest geht für die Kopien der 4 L2s drauf. Die L1 vernachlässige ich dabei.


Es sind nutzbare 8 MB Cache beim i7. Hätte er exklusive L2 dann wären es 9 :) Aber der Punkt ist o.k. - kann man so oder so sehen.


Höre ich zum ersten Mal, dass das sooooo gut sein soll. Mit Prefetch natürlich, aber ohne glaube ich Dir das nicht. Sei mir bitte nicht böse, aber das müßtest Du mir mit Links nachweisen ;)


Auf die schnelle hätte ich nur Random-Werte aus RMMA anzubieten, da hatte ich das mal getestet. Aktuell ist der Rechner aber mit F@H beschäftigt ;)


Jo normal gebe ich Dir da gerne recht, aber irgendwas passiert halt bei Anno. Das einzige auf das ich komme ist eben der kleine L2 plus nutzloser Prefetcher. Das der Cache nur auf Datenebene arbeitet ist auch klar, aber irgendein Konstrukt für dem ganzen Firlefanz muss ja irgendwo im Speicher liegen :)


Muss das Zeug überhaupt durch die CPU. Ich dachte eigentlich immer das die Objektdaten von der Engine im RAM bleiben und nur von der Grafikkarte zum Rendern geholt werden. Aber wie gesagt, der Bildinhalt (und damit das für die CPU relevante) ist eh gleich.


Ahhh ... C-States... ja gute Idee, bin ich auf alle Fälle nicht dagegen. Bei den neuen USB3/SATA3 Chips kosten die Stromsparmodi komischerweise auch Leistung und PCGH hatte ja mit Turbo-Off gebencht. Also eventuell ein Turbo-Loch (http://de.wikipedia.org/wiki/Turbolader#Nachteile_der_Turboaufladung) :(


Der Performance-Nachteil ist definitiv da. In jeder Anwendung mit wechselnder Last. Der Turbo kann das teilweise (über)kompensieren aber wenn man ohne Turbo arbeitet hat man definitiv einen Performanceverlust - und zwar einen der plötzlich und hart kommt, da der Thread erstmal steht bis die schlafenden Kerne wieder da sind.


Klingt interessant, hast Du nen Link dazu ? Hab ich noch nicht gehört.


Link hab ich nicht parrat. Die APIC-Timer sind allerdings unzuverlässig. Daher gibts beim i7 den HPET (High Performane Event Timer). Es gibt hier irgendwo einen Thread (Windows 2008 R2 ist da das Thema) in dem die Unzulänglichkeiten des "alten" Timers durchgekaut werden.

Alleine die Tatsache, dass es verschiedene timer gibt, die nicht exakt gleich arbeiten, verbietet schon eine Diskusion über kleine % Unterschiede bei Benchmarks ;)


Hab hier, oder im anderen Parallelthread den Link zum ASM Sourcecode gepostet. Ich seh da nichts Weltbewegendes, nur die Standard INT Register und ein paar movs.


Alles klar. Deshalb "rockt" der Crunchmaster-Prescott auch mit seinem hohen Takt und den schnellen ALUs.

[Vladez]

Ich denke weiterhin, dass der Nehalem bei dem Annobench der Cache Probleme bereitet.
Denn ein Phenom II x2 mit seinen 6Mb L3 Cache ist etwas langsamer als ein Athlon II x4 ohne L3 (wobei der Phenom auch 500Mhz schneller taktet ;))


Der Athlon II x2 ist mit 3Ghz aber deulich langsamer als der Phenom II x2 mit 3.1 Ghz --> Beim K10 wirkt sich der L3 Cache erheblich auf die Leistung aus; auch beim Nehalem?


_________________

Andere Theorie:

Speichercontroller
Wie werden die Speichercontroller beim Nehalem genutzt?

Beim K10 kann ja zwischen Ganged und Unganged wählen. Afaik nutzt CB den Unganged Modus.
Vielleicht ist das der Grund für die enorme Performance, die die Phenoms in diesem Bench zeigen?!

Kann das auch der Grund für den GPU-Limit-Performance-Abfall ( :D) der Nehalems sein?


Leider kenne ich mich nicht so sehr mit dem Thema aus - sind meine Ideen also Schwachsinn oder einfach extrem genial?^^

[Avalox]

Beim K10 kann ja zwischen Ganged und Unganged wählen. Afaik nutzt CB den Unganged Modus.


Das ist anwendungsabhängig. Je nach Anwendung ist ganged, oder unganged vorteilhaft. Tendenziell ist unganged im Schnitt etwas besser in einem Anwendungsfall mit vielen parallelen Anwendungen.
Da der "ganged" Betrieb höhere Anforderungen an den Speichercontrolle, bzw. des gesamten Speichersystems hat und deshalb generell problematischer ist hat Intel komplett auf diesen Modus verzichtet. Intel unterstützt dort nur den unganged Betrieb in seinen CPUs mit internen Speichercontroller, einen ganged Betriebsoption gibt es dort nicht.

[Vladez]

Deswegen haber ich es ja angesprochern ;)

Der K10 ist meistens dem Nehalem unterlegen, außer in einer Szene in Anno.
Da kam mir eben die Idee mit Unganged vs. Ganged.

Aber wenn bei Intel sowieso nur "Unganged" gibt, ist meine Vermutung widerlegt :(

[S940]

Es sind nutzbare 8 MB Cache beim i7. Hätte er exklusive L2 dann wären es 9 Aber der Punkt ist o.k. - kann man so oder so sehen.Ja, 8 MB nutzbarer gesamt Cache. So kann mans auch sagen. Hab das nur aufgesplittet, da wir ja getrennt von L2/L3 sprachen.
Auf die schnelle hätte ich nur Random-Werte aus RMMA anzubieten, da hatte ich das mal getestet. Aktuell ist der Rechner aber mit F@H beschäftigt Ok, RMMA ist gut, solange es nicht der Pseudo Random Test wird ^^. Kannst bei Gelegenheit gerne kurz den D-Cache Zugriffstest bis ~7MB machen, dann sollte der Screenshot einigermaßen hochauflösend sein, da das RAM abgeschnitten werden sollte.
Muss das Zeug überhaupt durch die CPU. Ich dachte eigentlich immer das die Objektdaten von der Engine im RAM bleiben und nur von der Grafikkarte zum Rendern geholt werden. Aber wie gesagt, der Bildinhalt (und damit das für die CPU relevante) ist eh gleich.Dazu gibts bei PCGH die Anno Entwicklertagebücher, die einen relativ guten Einblick in die Anno Internas geben:
Multi-Threading am Beispiel unserer 3D Engine
Es ist wichtig, bei dem Design der Softwareapplikation Elemente zu finden, die sich von Natur aus besonders gut zur parallelen Bearbeitung eignen, bzw. die Architektur entsprechend anzupassen. Da unsere 3D Engine vom eigentlichen Spiel abgekapselt ist, läuft sie generell in einem separaten Thread. Um jedoch weitere CPU Kerne optimal auszulasten, werden innerhalb der 3D Engine außerdem viele weitere Jobs parallel berechnet.

Das geht schon beim Empfang der Daten los: Das Spiel schickt der Engine nacheinander, welche Objekte es wie und wo gerendert haben möchte. Zusätzlich hat unsere Engine noch eine eigene Liste von Objekten, deren Position in der Welt statisch ist. Beispielsweise Berge, Bäume, Gräser und Gebäude. All diese Objekte werden in Job-Pakete zusammengefasst. Solche Objekte bestehen für die Engine aber tatsächlich aus mehreren Teilobjekten: Basismodell, Effekte, Billboards, kleine Fähnchen, Zierobjekte, Bodenplatten und vieles mehr - alle mit ihren ganz eigenen Parametern. Da die Anno-Welt extrem detailliert ist, kommen jedes Frame tausende solcher Objekte auf den Bildschirm. Für all diese Teilobjekte werten die Worker-Threads nun die Parameter aus: Sie schauen, ob ein Objekt überhaupt gerendert werden soll, transformieren es richtig, wählen eine LOD-Stufe oder färben es ein.

Nachdem nun die Job-Pakete abgearbeitet sind, liegen der Engine riesige Listen mit Objekten vor, welche zunächst sortiert werden müssen. Diese Sortierung sorgt für eine minimale Anzahl an aufwendigen State Changes, die sonst die Grafikkarte ausbremsen. Dazu schicken wir dem Scheduler die Objekt-Listen, damit die Worker-Threads sie sortieren: Nach Shader, Textur, ob einzeln oder per schnellem Instancing, etc.

Während diese Sortierung läuft, schickt die Engine weitere Aufgaben an den Scheduler: Die Cloth-Simulation für die Fahnen, Stoffe und Schiff-Segel eignet sich sehr gut für Multi-Core Prozessoren, da jede Simulation unabhängig berechnet werden kann. Ebenso werden die Animationen und Partikel Effekte multi-threaded berechnet und aktualisiert. Für andere Objekte berechnen die Worker-Threads bestimmte Parameter vor, welche später an die Shader mitgegeben werden. Selbst die miteinander verschmelzenden Selektionskreise der Schiffe werden parallel zu den anderen Aufgaben berechnet.

Zu guter letzt wartet die Engine auf die Fertigstellung aller Jobs und sendet die Daten zur Darstellung an das Direct3D Device.

Inhaltsverzeichnis:
Entwicklertagebuch Anno 1404 - Einleitung (http://www.pcgameshardware.de/aid,688225/Anno-1404-Alle-zehn-Entwicklertagebuecher-bei-PC-Games-Hardware/Strategiespiel/News/?page=1)
Entwicklertagebuch Anno 1404 - Teil 1 (http://www.pcgameshardware.de/aid,688225/Anno-1404-Alle-zehn-Entwicklertagebuecher-bei-PC-Games-Hardware/Strategiespiel/News/?page=2)
Entwicklertagebuch Anno 1404 - Teil 2 (http://www.pcgameshardware.de/aid,688225/Anno-1404-Alle-zehn-Entwicklertagebuecher-bei-PC-Games-Hardware/Strategiespiel/News/?page=3)
Entwicklertagebuch Anno 1404 - Teil 3 (http://www.pcgameshardware.de/aid,688225/Anno-1404-Alle-zehn-Entwicklertagebuecher-bei-PC-Games-Hardware/Strategiespiel/News/?page=4)
Entwicklertagebuch Anno 1404 - Teil 4 (http://www.pcgameshardware.de/aid,688225/Anno-1404-Alle-zehn-Entwicklertagebuecher-bei-PC-Games-Hardware/Strategiespiel/News/?page=5)
Entwicklertagebuch Anno 1404 - Teil 5 (http://www.pcgameshardware.de/aid,688225/Anno-1404-Alle-zehn-Entwicklertagebuecher-bei-PC-Games-Hardware/Strategiespiel/News/?page=6)
Entwicklertagebuch Anno 1404 - Teil 6 (http://www.pcgameshardware.de/aid,688225/Anno-1404-Alle-zehn-Entwicklertagebuecher-bei-PC-Games-Hardware/Strategiespiel/News/?page=7)
Entwicklertagebuch Anno 1404 - Teil 7 (http://www.pcgameshardware.de/aid,688225/Anno-1404-Alle-zehn-Entwicklertagebuecher-bei-PC-Games-Hardware/Strategiespiel/News/?page=8)
Entwicklertagebuch Anno 1404 - Teil 8 (http://www.pcgameshardware.de/aid,688225/Anno-1404-Alle-zehn-Entwicklertagebuecher-bei-PC-Games-Hardware/Strategiespiel/News/?page=9)
Entwicklertagebuch Anno 1404 - Teil 9 (http://www.pcgameshardware.de/aid,688225/Anno-1404-Alle-zehn-Entwicklertagebuecher-bei-PC-Games-Hardware/Strategiespiel/News/?page=10)
Entwicklertagebuch Anno 1404 - Teil 10 (http://www.pcgameshardware.de/aid,688225/Anno-1404-Alle-zehn-Entwicklertagebuecher-bei-PC-Games-Hardware/Strategiespiel/News/?page=11)

Da ist also schon einiges los, das Spiel ist vermutlich das erste echte MultiCore Spiel ^^

Der Performance-Nachteil ist definitiv da. In jeder Anwendung mit wechselnder Last. Der Turbo kann das teilweise (über)kompensieren aber wenn man ohne Turbo arbeitet hat man definitiv einen Performanceverlust - und zwar einen der plötzlich und hart kommt, da der Thread erstmal steht bis die schlafenden Kerne wieder da sind.Tja, dann sollte man das mal nachmessen -wenn man denn kann .. siehe unten.

Link hab ich nicht parrat. Die APIC-Timer sind allerdings unzuverlässig. Daher gibts beim i7 den HPET (High Performane Event Timer). Es gibt hier irgendwo einen Thread (Windows 2008 R2 ist da das Thema) in dem die Unzulänglichkeiten des "alten" Timers durchgekaut werden.Ich werde mir mal den Thread dazu raussuchen. Klingt auf alle Fälle nicht so prickelnd, das würde die ganzen Messungen ad absurdum führen.

Alleine die Tatsache, dass es verschiedene timer gibt, die nicht exakt gleich arbeiten, verbietet schon eine Diskusion über kleine % Unterschiede bei Benchmarks Jo, da bin ich eh auch dagegen, da die Abstände teilweise arg witzlos sind, cb gibt z.B. die fps auf 2 Nachkommastellen genau an ... als ob sie so genau messen könnten.

Alles klar. Deshalb "rockt" der Crunchmaster-Prescott auch mit seinem hohen Takt und den schnellen ALUs.Lol, ach der liegt vorne ? Ja, das wäre dann erklärbar ;-)
Falls Du nen Link zu ner Vergleichstabelle hast, bitte posten bzw. PM (ist ja schon iweder OT ):)

ciao

Alex

[S940]

Der FarCry Flaschenhals wurde anscheinend mit der 32nm Generation behoben:
http://www.pc-max.de/sites/pc-max.de/files/graphs/cpu_s160_far_cry_2.png
http://www.pc-max.de/artikel/prozessoren/intel-core-i5-661/5464

Jetzt wäre es nur noch nett zu wissen, was es war ;-)

CB hat bei Ihrem i5 Test noch angegeben, wie groß das Savegame war, es sind 16 MB ... schon nicht wenig. Die Szenarios, in denen die Nehalems vorne liegen, sind 1MB bzw. 7 MB groß.

Das Ganze läßt natürlich nur einen groben Rückschluss auf den Speicherverbrauch zu, aber weniger RAM wird das 16MB Save sicherlich nicht benötigen :)
http://www.computerbase.de/artikel/hardware/prozessoren/2010/test_intel_core_i3-530_540_core_i5-661/24/#abschnitt_anno_1404__zusatztests

ciao

Alex

[Undertaker]

Wenn das PCGH Save weniger anspruchsvoll wäre, würden die PII dort nicht deutlich schlechter performen, als in dem großen CB-Save. Es bleibt äußerst mysteriös, was da los war. Interessant auch das Hardware.fr-Save:

http://www.hardware.fr/articles/780-12/intel-core-i5-i3-32nm.html

46k Einwohner, ähnliche fps-Region, Nehalem/Lynnfield wieder vorne.

[Gast]

46k Einwohner, ähnliche fps-Region, Nehalem/Lynnfield wieder vorne.
Nur 46k? wie uncool:


Wir nutzen eine von uns erstellte Karte in einem Endlos-Spiel mit einer Gesamtbevölkerung von knapp 82.000 Einwohnern, diversen Schifffahrtsrouten und regem Treiben auf nahezu allen Inseln der riesigen Karte.
(von computerbase)

[Ronny145]

Hier noch 2 weitere mit Far Cry 2. Wäre schon interessant zu wissen, was der Clarkdale anders macht. Bei Ht4u sind quasi alle mehr oder weniger GPU limitierten Benches für den Clarkdale besser.

http://www.abload.de/img/farcry2_2560dc6f.png

http://www.abload.de/img/farcry2rec8.png


http://ht4u.net/reviews/2010/intel_clarkdale_core_i3_core_i5/index25.php

[Undertaker]

Nur 46k? wie uncool:


Wir nutzen eine von uns erstellte Karte in einem Endlos-Spiel mit einer Gesamtbevölkerung von knapp 82.000 Einwohnern, diversen Schifffahrtsrouten und regem Treiben auf nahezu allen Inseln der riesigen Karte.
(von computerbase)

Die Einwohnerzahl ist isoliert betrachtet recht sekundär, mehr als ein paar Dutzend Personen siehst du eh nicht auf dem Screen. ;) Entscheidend ist da eher die Masse an Gebäuden samt zugehöriger Effekte (Rauch, Bewegungen etc). Und da scheint komischerweise das hardware.fr oder PCGH-Save anspruchsvoller als das CB-Save gewesen zu sein, wenn man nur auf die fps der Phenom II schaut.

@Ronny: Gerade bei HT4U finde ich sieht man gut, wie vorsichtig man solche Werte immer sehen muss. Ein Athlon II X3 mindestens 6fps vor sämtlichen anderen AMD-CPUs? Wohl kaum. Ich gehe nach wie vor davon aus, dass es im GPU-Limit keine klaren Leistungsunterschiede zwischen verschiedenen CPUs gibt. Das zeigen meine eigenen Messungen, andere Usertests oder in meinen Augen seriöse Reviews.

[S940]

@Wuge:
So wie es ausschaut ist es bei Anno kein Turbo Problem, cb hat jetzt nachgebencht:
http://www.computerbase.de/artikel/hardware/prozessoren/2010/test_intel_core_i3-530_540_core_i5-661/30/#abschnitt_anno_1404

Turbo bringt knappe 3 fps mehr, schadet also nicht. Damit bleibt im Anno Fall wirklich nur noch der Cache und die obskuren Timer übrig.

Die HPET Timer gabs aber schon beim S775, oder ? Denn im Testfeld ist auch noch ein Q9550 drin, der ist 3 fps schneller als ein gleichgetakteter i5 750. Danke Turbo läuft Letzterer mit mind. 2,8 GHz und ist somit mit dem Q9550 gut vergleichbar. In dem Fall bliebe dann nur nur noch der Cache als Erklärung übrig.

ciao

Alex

[Undertaker]

Wie im Luxx zu lesen war, will y33h@ Volker mal um das fragliche Save bitten. Komisch bleibt, dass die Phenom II in anderen stark fordernden Szenarien sehr viel stärker auf Regionen um ~30fps eingebrochen sind (Hardware.fr, PCGH), da scheint die von CB gefunden Stelle - falls korrekt vermessen - doch ein rechtes Unikat zu sein.

[Gast]

Die Cache-These ist Unsinn. Dann wäre Nehalem auch unter niedrigeren Auflösungen langsam.

[Undertaker]

Und auch nicht nur in einem einzelnen Save. ;) Korrekt.

[Gast]

Ich bin jetzt ohnehin so weit, CB nicht mehr ernstzunehmen. Ich meine, WTF:

http://images.anandtech.com/graphs/clarkdalelaunch_010310105346/21170.png

http://www.xbitlabs.com/images/cpu/clarkdale-review/fc2.png

http://www.3dcenter.org/dateien/abbildungen/far-cry-2-bench.png

[Ronny145]

Das sind doch nicht die gleichen Benchsequenzen, Hardware wird auch unterschiedlich sein.

[Gastronom]

Medium Quality bei Anandtech und Xbitlabs, dadurch wird die CPU weniger stark gefordert, nicht vergleichbar. *gähn* Ausserdem, wie wäre es mit einer Quellangabe?

BTW: So miese Werte wie bei Xbitlabs und Anandtech, sowohl was Performance als auch Stromverbrauch betrifft, haben AMDs CPUs nirgends. Ich halte die deutschen Seiten & Magazine grundsätzlich für glaubwürdiger als die englischen, alleine schon weile deutsche Nutzer/Leser kritischer sind, mehr Bewusstsein hinsichtlich Test-Methoden entwickelt haben und dadurch viel eher Dinge durchschauen und hartnäckig nachhaken.

[Wuge]

@Wuge:
So wie es ausschaut ist es bei Anno kein Turbo Problem, cb hat jetzt nachgebencht:
http://www.computerbase.de/artikel/hardware/prozessoren/2010/test_intel_core_i3-530_540_core_i5-661/30/#abschnitt_anno_1404

Turbo bringt knappe 3 fps mehr, schadet also nicht. Damit bleibt im Anno Fall wirklich nur noch der Cache und die obskuren Timer übrig.


Es kann durchaus sein, dass die zwar den Turbo deaktiviert haben, die Stromsparmechanismen (C-States) aber aktiv waren. Ist also nachwievor eine Möglichkeit.

These: Da Clarkdale nur 2 Kerne hat, die beide permanent genutzt werden, tritt der Fall eines C3/C6 dort nicht ein. Daher hat Clarkdale das Problem nicht.

[S940]

Die Cache-These ist Unsinn. Dann wäre Nehalem auch unter niedrigeren Auflösungen langsam.Ist er ja auch ... in der einen CB Szene die vermutlich den Cache überlastet. Würde also ganz gut passen.

Nur für den Thread hier passt es ganz genau genommen nicht. Ich hoffe auf einen gnädigen Mod :)

@Wuge:
Du meinst jetzt die FC2 Werte aus #334 (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=7752382#post7752382), oder ? Denn bei Anno sind die Werte des i7-870 (die ich im von Dir zitierten Absatz meinte) auch ok.
Für den FC2 Benchmark wären das mit dem C3/C6 aber eine gute Idee, ausschließen kann mans definitiv nicht - Zumindest nicht klar ist, ob mir oder ohne EIST etc. pp. gebencht wurde.

Falls Du doch CBs Anno Test meinst, bitte kurze Erläuterung, was beim Clarkdale besser läuft, mir fällt da nichts auf.

ciao

Alex

[Widerspruch in einem Satz]

Die Cache-These ist Unsinn. Dann wäre Nehalem auch unter niedrigeren Auflösungen langsam.

self owned...

1024x768 -> http://www.computerbase.de/artikel/hardware/prozessoren/2010/test_intel_core_i3-530_540_core_i5-661/23/#abschnitt_anno_1404

640 x 480 -> http://www.computerbase.de/artikel/hardware/prozessoren/2010/test_intel_core_i3-530_540_core_i5-661/24/#abschnitt_anno_1404__zusatztests

[Gast]

self owned...

1024x768 -> http://www.computerbase.de/artikel/hardware/prozessoren/2010/test_intel_core_i3-530_540_core_i5-661/23/#abschnitt_anno_1404

640 x 480 -> http://www.computerbase.de/artikel/hardware/prozessoren/2010/test_intel_core_i3-530_540_core_i5-661/24/#abschnitt_anno_1404__zusatztests

Du bist leider im falschen Thread.

[Gast]

Und, gibts schon was neues?^^

[Gast]

Und, gibts schon was neues?^^
Nachdem die Entwickler der beiden auffälligen Spiele weder den Soucecode offenlegen noch sonstwie Stellung nehmen, gibt es leider immer noch keine harten Fakten. :D

[Gast]

Liegt das Problem jetzt an der Hardware oder Software? :-/

[Lawmachine79]

Hier ist wieder so ein seltsames Ergebnis:
http://www.hexus.net/content/item.php?item=22622&page=10
In Far Cry, 1680x1050
Klar, der Unterschied ist gering, aber unter Messungenauigkeit lässt sich das nicht mehr erklären, unter 640x480 deutlich schneller als ein 965BE, in 1680x1050 dann langsamer - und sobald man ihn übertaktet etwa gleich schnell. Das Muster ist einfach ZU deutlich.

[y33H@]

Und mal wieder der interne FC2-Bench. Wie wäre es mal mit ingame oder einem anderen Spiel? Für FC2 interessiert sich keiner (mehr).

[S940]

Und mal wieder der interne FC2-Bench. Wie wäre es mal mit ingame oder einem anderen Spiel? Für FC2 interessiert sich keiner (mehr).
Jo FC2 hatten wir ja jetzt schon ein paar Mal :)

Hast Du was neues zu Anno ? Wenn ich mich recht erinnere wolltest Du Dir das CB Save besorgen, oder ?

ciao

Alex

[Coda]

Am Cache liegt es garantiert nicht. Wie kommt ihr darauf?

Die CPU-Last ist exakt die gleiche egal wie hoch die Auflösung ist - nur der Aspect Ratio hat darauf evtl. noch je nach Spiel einen Einfluss. Es liegt also sicher an etwas anderem als der CPU, sehr wahrscheinlich dem I/O-Subsystem.

[Odal]

pcie durchsatz ist beim nehalem hoch und latenz kann eigentlich gar nicht schlecht sein mit pcie controller direkt in der CPU ohne umwege über den chipsatz

[Undertaker]

Am Cache liegt es garantiert nicht. Wie kommt ihr darauf?

Die CPU-Last ist exakt die gleiche egal wie hoch die Auflösung ist - nur der Aspect Ratio hat darauf evtl. noch je nach Spiel einen Einfluss. Es liegt also sicher an etwas anderem als der CPU, sehr wahrscheinlich dem I/O-Subsystem.

Kann das von Spiel zu Spiel differieren? Interessanterweise gibt es auch immer mal wieder Fälle, wo der Phenom II im GPU-LImit scheinbar nicht an die fps des i7 herankommt.

http://www.legionhardware.com/articles_pages/cpu_scaling_with_the_radeon_hd_5970,19.html

[S940]

Am Cache liegt es garantiert nicht. Wie kommt ihr darauf?

Die CPU-Last ist exakt die gleiche egal wie hoch die Auflösung ist - nur der Aspect Ratio hat darauf evtl. noch je nach Spiel einen Einfluss. Es liegt also sicher an etwas anderem als der CPU, sehr wahrscheinlich dem I/O-Subsystem.
Natürlich ist die CPU Last exakt die gleiche, deswegen liegt der 965er ja auch bei 800x600 vorne. Was anderes wurde nie behauptet.

Schau Dir mal die Yorkfield Ergebnisse an ... der liegt bei 2,83 GHz noch vor dem K10 mit 2,8 GHz ... das kann ergo nur der L2 Cache sein, es sei denn Du hältst die FSB Architektur des Q9550 dem IMC & QPI der Nehalems für überlegen ;-)

Eventuell war das ganze auch nur fehlende Optimierung im Grafiktreiber, hab gerade die Cat 10.2 Ergebnisse bei CB gesehen, da legte Anno auf den CB i7 Testsystem sehr deutlich zu, eventuell hat AMD das jetzt auf die kleine L2 Größe optimiert:

http://www.computerbase.de/artikel/hardware/grafikkarten/2010/bericht_ati_catalyst_102/6/#abschnitt_anno_1404

ciao

Alex

[Undertaker]

Um diese unsinnige Cachedebatte mal abzuschließen:

http://techreport.com/r.x/cpu-roundup-2010q1/sandra-mem-bw.gif

http://www.abload.de/img/sandra-mem-bw6hdw.gif (http://www.abload.de/image.php?img=sandra-mem-bw6hdw.gif)

Selbst im Bereich um 512KB Datenmenge ist das Cachesystem des Nehalem/Lynnfield massiv überlegen. Einzig der Core 2, hier leider nur als 6MB Modell, kann sich im Bereich um ~4MB an für kurze Zeit an die Spitze setzen.

[Armaq]

Natürlich ist die CPU Last exakt die gleiche, deswegen liegt der 965er ja auch bei 800x600 vorne. Was anderes wurde nie behauptet.

Schau Dir mal die Yorkfield Ergebnisse an ... der liegt bei 2,83 GHz noch vor dem K10 mit 2,8 GHz ... das kann ergo nur der L2 Cache sein, es sei denn Du hältst die FSB Architektur des Q9550 dem IMC & QPI der Nehalems für überlegen ;-)

Eventuell war das ganze auch nur fehlende Optimierung im Grafiktreiber, hab gerade die Cat 10.2 Ergebnisse bei CB gesehen, da legte Anno auf den CB i7 Testsystem sehr deutlich zu, eventuell hat AMD das jetzt auf die kleine L2 Größe optimiert:

http://www.computerbase.de/artikel/hardware/grafikkarten/2010/bericht_ati_catalyst_102/6/#abschnitt_anno_1404

ciao

Alex
Sie haben im Grafiktreiber auf den kleineren L2Cache hinoptimiert?

[S940]

Sie haben im Grafiktreiber auf den kleineren L2Cache hinoptimiert?
Spräche denn irgendwas dagegen ? Dann bring die Zweifel bitte an und speiß uns hier nicht mit einem einzigen Satz ab :)
ATis JIT compiler ist auf alle Fälle eine hochkomplexe Angelegenheit, jedes (unterstützte) Spiel hat da eigene Codepfade, das Treiberpaket hat nicht umsonst um die 200 MB ...

[Ronny145]

das Treiberpaket hat nicht umsonst um die 200 MB ...


Der Treiber als Einzelpaket alleine ist keine 50 MB groß.

[HOT]

... was nichtsdestotrotz verdammt viel ist für einen blöden Treiber ;). Klar, man muss den CIM noch abziehen, aber der Treiber als solcher ist schon sehr gross.

[Spasstiger]

Beim S775 bremst selbst schon EIST geringfügig.
Geringfügig ist gut, kann durchaus mal 20-30% an der Performance ausmachen (nicht im Schnitt, aber momentan).
Für Benchmarks deaktiviere ich selbst C1E.
Das ist nicht nötig, da C1E ein idle-State ist. Wenn die CPU in diesen Zustand geht, dann würde sie sowieso in einen idle-State gehen, in dem sie keine Arbeit verrichtet.