Intelligente Cachennutzung bei Core 2 Quads?

XAlexanderX

Enthusiast
Thread Starter
Mitglied seit
12.01.2008
Beiträge
3.938
Wie intelligent wird der Cache der Core 2 Quads genutzt?


Angenommen man kauft einen Q9400, nutzt den zum Spielen, aber es wird vom Game nur ein DualCore unterstützt. Liegen dann 2 Kerne brach, aber deren Cache nicht? D.h., haben die anderen beiden den vollen Cache zur Verfügung und man damit quasi einen E8200 im Einsatz? Oder funktioniert das leider nicht so und man werkelt quasi mit einem E7300 herum?

Oder hängt es davon ab welche beiden Kerne das Spiel (zufällig) nutzt? Wenn 1+2 sich 3 MB teilen und 3+4 die anderen 3MB, dann könnte man bei Dualcoreunterstüzung theoretisch 1 und 3 auslasten, damit sie je 3MB zur Verfügung haben. Aber erfolgt die Lastverteilung automatisch so intelligent?

Noch schwieriger wird es, wenn man leichte Zugriffe auf die zusätzlichen 2 Kerne hat, da im Hintergund diverse Anwendungen ein wenig Last produzieren, oder weil das Game wenige Aufgaben doch an einen weiteren Kern abgeben kann. Wenn diese Anwendungen den Cache nicht brauchen, können sich dann die beiden Kerne, die vom Game genutzt werden bedienen? Oder liegt der Cache dann brach?

---------- Beitrag hinzugefügt um 16:42 ---------- Vorheriger Beitrag war um 13:17 ----------

Hat sich noch nie jemand diese Frage gestellt?
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Oder hängt es davon ab welche beiden Kerne das Spiel (zufällig) nutzt? Wenn 1+2 sich 3 MB teilen und 3+4 die anderen 3MB, dann könnte man bei Dualcoreunterstüzung theoretisch 1 und 3 auslasten, damit sie je 3MB zur Verfügung haben.
Jup, so schaut es aus.

Aber erfolgt die Lastverteilung automatisch so intelligent?
Hängt vom Thread Scheduler des Betriebssystems ab. Ich würde mal vermuten, der Windows Thread Scheduler macht das nicht. Es gibt ja nicht nur Vorteile. Wenn zB Kern 1 und 3 genutzt werden, steht zwar insgesamt mehr Cache zur Verfügung. Dafür dauert die Kommunikation zwischen beiden Kernen länger, da dies nicht mehr über einen gemeinsamen Cache erfolgen kann, sondern über den deutlich langsameren FSB abgewickelt werden muss.
 
Also bei den ersten Multicore Prozessoren war es so das nicht der ganze Cache genutzt werden konnte,
denn ein Pentium D besteht nur aus zwei zusammen geklebten Pentium 4s,
ein Core2Quad Q6xxx ist nichts anderes als zwei Core2Duos.

Seit Penryn (also Q9xxx) ist es möglich das ein Kern den kompletten Cache nutzen kann wenn dies nötig ist.
Oder das sich zwei Kerne den Cache teilen usw.
 
ein Core2Quad Q6xxx ist nichts anderes als zwei Core2Duos.

Seit Penryn (also Q9xxx) ist es möglich das ein Kern den kompletten Cache nutzen kann wenn dies nötig ist.
Oder das sich zwei Kerne den Cache teilen usw.

Ein Penryn besteht ebenfalls aus zwei zusammengeklebten dualcores. Ich sehe keinen grund wieso es da anders funktionieren sollte als bei den 65nm quadcores.
 
Naja es hies damals als die dinger rausgekommen sind das es halt möglich ist das ein Kern auf den ganzen chache zugreifen kann.
 
Fehlanzeige. Ein direkter Zugriff aller Kerne auf den Last Level Cache (wie beim i7 oder Phenom) ist beim Penryn nicht möglich.
 
Zuletzt bearbeitet:
Ja kann es das dann auch wirklich?
 
ich hatte die frage hier mal gestellt :)
ich denke es ist leider nicht möglich bei den core2quads, dh man werkelt dann auf obiges beispiel bezogen, mit einem e7x00.
gruß
 
Jup, so schaut es aus.


Hängt vom Thread Scheduler des Betriebssystems ab. Ich würde mal vermuten, der Windows Thread Scheduler macht das nicht. Es gibt ja nicht nur Vorteile. Wenn zB Kern 1 und 3 genutzt werden, steht zwar insgesamt mehr Cache zur Verfügung. Dafür dauert die Kommunikation zwischen beiden Kernen länger, da dies nicht mehr über einen gemeinsamen Cache erfolgen kann, sondern über den deutlich langsameren FSB abgewickelt werden muss.

grübel grübel.....

Falls der Zufall entscheidet, dann hat man u.U. Kern 1 und 3 im Einsatz und so je 3 MB zur Verfügung. Aber zugleich den Nachteil, dass die Kerne per FSB miteinander kommunizieren, was wieder Geschwindigkeitseinbußen mit sich bringt. Da dürfte von dem Cachevorteil von vielleicht 5% (E8xxx vs E7xxx) nichts über bleiben, oder?

Und falls der Zufall nicht entscheidet, dann ist eher zu erwarten, dass zuerst auf die beiden Kerne zugegriffen werden soll, die über den Cache kommunizieren, richtig?

Summa summarum würde das bedeutet, dass man "auf obiges Beispiel bezogen, mit einem e7x00" werkelt, wenn nur 2 Kerne unterstützt werden. :shake:
 
Falls der Zufall entscheidet, dann hat man u.U. Kern 1 und 3 im Einsatz und so je 3 MB zur Verfügung. Aber zugleich den Nachteil, dass die Kerne per FSB miteinander kommunizieren, was wieder Geschwindigkeitseinbußen mit sich bringt. Da dürfte von dem Cachevorteil von vielleicht 5% (E8xxx vs E7xxx) nichts über bleiben, oder?
Hängt ganz von der Anwendung und vom Einsatzgebiet ab.
 
würde mich mal interessieren wieviel kommunikation zwischen den kernen überhaupt passieren muss bei diversen spielen. meine intuition sagt mir, dass das relativ wenig ist, aber ne systematische analyse wäre interessant.
 
Soweit ich weiß, kommunizieren Sie über den Level 3 Cache (Phenom) und falls dieser nicht vorhanden ist über den Chipsatz, oder?
 
@ mGa

Es geht doch um S775. Dass Phenom & Nehalem einen shared L3 haben ist uns denk ich allen bewußt.

Das FSB-Problem des S775 ist weit weniger dramatisch als angenommen. Wenn zwei Threads mit einander kommunizieren, tun Sie dies ohnehin über den Arbeitsspeicher. Eine direkte Kern-zu-Kern-Kommunikation via FSB gibt es nicht. Man hat nur den Nachteil, dass nicht alle Kerne auf die gecachten Speicherbereiche zugreifen können. Das kann allerdings auch mal von Vorteil sein.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh