Core 2 Quad - Vorteile durch größeren Cache?

[Spasstiger]

Die Core-2-Quad-Modelle verfügen ja über 2*4 MB L2-Cache.
Bringt das im Dual-Core-Betrieb einen Vorteil gegenüber einem Core 2 Duo?
Wird die Rechenlast so auf die Kerne verteilt, dass der Cache möglichst redundanzfrei arbeitet oder kann der gesamte Cache nur bei intensiver Nutzung von mindestens drei Kernen gewinnbringend genutzt werden?

Wenn jemand Benchmarks hat von z.B. einem Core 2 Duo E6600 gegen einen Core 2 Quad Q6600 @ Dual-Core, immer her damit.

[Gast]

Er kann schneller sein, muss aber nicht.

Der Cache kann zwar genutzt werden, aber er ist nur dann vom Vorteil, wenn nicht die gleichen Daten für beide Kerne vorgehalten werden müssen.

[Gast]

Dazu müsste man selber die Affinitäten setzen. Out of the box gehts nicht bzw nur mit viel Glück.

[Gast]

Herr Spasstiger,

ihre Frage erübrigt sich.
Der Core 2 Quad hat 2x*4MB Cache...Soll heissen: Für je 2 Cores 4MB!
Werden aber nur 2 Cores genutzt, können nur 4MB genutzt werden.

Das wird sich erst beim Yorkfield ändern, der einen shared-cache für alle 4 cores hat!

[Neomi]

Werden aber nur 2 Cores genutzt, können nur 4MB genutzt werden.

Falsch. Es gibt 6 verschiedene Kombinationsmöglichkeiten, zwei Cores zu nutzen (0+1, 0+2, 0+3, 1+2, 1+3, 2+3). Bei nur 2 dieser Möglichkeiten teilen sich beide Cores den Cache.

[AnarchX]

Das wird sich erst beim Yorkfield ändern, der einen shared-cache für alle 4 cores hat!

Hat er nicht:
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=345792

[Spasstiger]

Herr Spasstiger,

ihre Frage erübrigt sich.
Der Core 2 Quad hat 2x*4MB Cache...Soll heissen: Für je 2 Cores 4MB!
Werden aber nur 2 Cores genutzt, können nur 4MB genutzt werden.
:rolleyes:
Meine Frage ist entstanden, weil es eben genau so nicht ist. Bei Anwendungen, die nur von zwei Cores profitieren, sind trotzdem immer alle Cores im Wechsel aktiv. Und deshalb auch meine Frage, ob die CPU die Befehle so verteilt, dass der Cache möglichst redundanzfrei genutzt wird.

[PatkIllA]

:rolleyes:
Meine Frage ist entstanden, weil es eben genau so nicht ist. Bei Anwendungen, die nur von zwei Cores profitieren, sind trotzdem immer alle Cores im Wechsel aktiv. Und deshalb auch meine Frage, ob die CPU die Befehle so verteilt, dass der Cache möglichst redundanzfrei genutzt wird.
Das Aufteilen der Befehle zwischen den Cores (und damit bei der aktuellen Intelarchitektur auch indirekt auch des Caches) ist Sache des Betriebssystem. Nur innerhalb eines DualCores kann die CPU was machen und da wird im L2 Cache Redundanz vermieden. Es wäre allerdings interessant zu wissen, ob der Scheduler es berücksichtig und Anwendungen, die nicht mehr als zwei Kerne nutzen auch auf einen Kern verteilt. Ich glaube aber nicht.

[Spasstiger]

Ok, der Standardtenor geht also eher in die Richtung, dass der größere Cache im Dual-Core-Betrieb kaum bis gar keine Vorteile bringt und die Vorteile eher zufälliger Natur sind. Cacheredundanz wird wohl eher nicht gezielt verhindert (dass das OS dies tut, kann ich mir nicht vorstellen, dazu müsste das OS ja den internen Aufbau des Prozessors kennen, also welche Kerne sich einen Cache teilen).

[Zool]

Der Standard-Threadscheduler von XP kann nicht zwischen verschiedenen CPUs oder Dualcores unterscheiden. Eine entsprechende Zuweisung auf eines diskrete CPU oder Kern muß das Programm oder ein entsprechendes Tool machen.

Bei Vista wird das wohl nicht viel anderes sein.

[Wuge]

Der Scheduler v Vista ist zumindest in Sachen SMT/SMP recht dumm. Da kommt es schonmal vor, dass 2 Threads auf einem Kern laufen und der andere fast nichts zutun hat.

[Gast]

aus cache-sicht ist das ganze sogar eher ein nachteil, wenn ein thread von einer cpu auf die nächste geschoben wird (die am anderen DIE sitzt) ist in deren cache normalerweise nichts brauchbares für den thread und die daten müssen erstmals aus dem RAM geladen werden.

weiters greifen bei einer multithreaded-anwendung höchstwahrescheinlich mehrere threads auf gleiche speicherbereiche zu, dann wäre es günstig wenn diese am gleichen DIE ausgeführt werden und damit auf den gleichen cache zugreifen könnten.

profitieren könnte evtl. 2 unterschiedliche anwendungen von denen eine auf DIE 1 und die andere auf DIE 2 ausgeführt wird. dann hat jede den vollen cache zur verfügung und die anwendungen können sich die daten nicht gegenseitig aus dem cache kicken (wobei das bei 16-facher assoziativität sowieso nicht sehr wahrscheinlich ist)

weiters braucht es für cache-effiziente speicherzugriffe überhaupt nur recht kleine mengen an cache (weshalb beispielsweise auch GPUs mit sehr wenig cache auskommen, da deren zugriffe sehr gut vorhersehbar und damit effizient sind), eine große menge an cache hilft in erster linie bei ineffizienten speicherzugriffen, weil dann mehr oder weniger zufällig mal doch das eine oder andere datum doch noch im cache ist.

[DerRob]

Der Standard-Threadscheduler von XP kann nicht zwischen verschiedenen CPUs oder Dualcores unterscheiden. Eine entsprechende Zuweisung auf eines diskrete CPU oder Kern muß das Programm oder ein entsprechendes Tool machen.
hmm, der scheduler von xp x64 (bzw. server 2003) scheint schon etwas "intelligenter" zu sein, als der von xp x32. eine anwendung, die nur einen core nutzt, belegt auch nur einen core zu nahezu 100%, und wird nicht zwischen beiden cores hin und her geschoben.
ob jetzt aber der scheduler erkennt bzw. weiß, welche cores zusammen hängen, und die threads entsprechend verteilt, bezeifel ich mal. möglich wäre es sicherlich, aber je nach anwendung wohl mehr oder weniger sinnvoll...