Dual Core Itanium und Opteron doch mit 2 x L2 Cache

[CrazyIvan]

http://www.zdnet.de/news/hardware/0,39023109,39125355,00.htm

Waren wir hier nicht zumindest beim K8 immer von nem gemeinsamen Cache ausgegangen? Hätte einen geshareten Cache mit doppelter Größe der Single-Cores besser gefunden. Diese statische Zuteilung ist vielleicht einfacher zu implementieren, kostet aber mit Sicherheit Performance...

[BlackBirdSR]

http://www.zdnet.de/news/hardware/0,39023109,39125355,00.htm

Waren wir hier nicht zumindest beim K8 immer von nem gemeinsamen Cache ausgegangen? Hätte einen geshareten Cache mit doppelter Größe der Single-Cores besser gefunden. Diese statische Zuteilung ist vielleicht einfacher zu implementieren, kostet aber mit Sicherheit Performance...

Eigentlich gab es schon vor einigen Monaten die bestätigung, dass jeder Kern seinen eigenen Cache erhält.
Ob bei einer 2x64Bit breiten Cacheanbindung die Performance so toll ausfällt weiss ich nicht so recht.

[Muh-sagt-die-Kuh]

Das Hauptproblem eines geteilten Caches ist die Redundanz von Daten und die damit verbundenen, unnötigen Speicherzugriffe. Die Frage ist, welchen Anteil diese haben bzw. welchen Vorteil man durch einen vereinigten Cache mit seiner deutlich komplexeren Zugriffslogik erreicht.

Gibt es noch einen anderen Aspekt, wieso Performance verloren gehen könnte?

[BlackBirdSR]

Das Hauptproblem eines geteilten Caches ist die Redundanz von Daten und die damit verbundenen, unnötigen Speicherzugriffe. Die Frage ist, welchen Anteil diese haben bzw. welchen Vorteil man durch einen vereinigten Cache mit seiner deutlich komplexeren Zugriffslogik erreicht.

Gibt es noch einen anderen Aspekt, wieso Performance verloren gehen könnte?

Beim K8 werden beide Kerne über den SRQ angebunden.
Also Kern-L1-L2-SRQ-L2-L1-Kern
Bei einem shared Cache würde das dann so aussehen:
Kern L1-L2-SRQ-L1-K8

Könnte etwas Performance kosten.. neben der Frage ob das so überhaupt implementierbar ist.

[CrazyIvan]

Ich sehe die Statik der Zuweisung als Nachteil. Bei separaten Caches haben die Threads der beiden Cores immer genau die Hälfte des Gesamtcaches. Bei einem geshareten Cache könnte dies dynamisch mit den Anforderungen der Threads geändert werden. Davon würde man sicherlich in vielen Situationen profitieren.

[Muh-sagt-die-Kuh]

Ich sehe die Statik der Zuweisung als Nachteil. Bei separaten Caches haben die Threads der beiden Cores immer genau die Hälfte des Gesamtcaches. Bei einem geshareten Cache könnte dies dynamisch mit den Anforderungen der Threads geändert werden. Davon würde man sicherlich in vielen Situationen profitieren.Das ist eine mögliche Auswirkung, die andere ist, dass man sich ein Thrashing-Problem einhandeln kann.

[Gast]

Das ist eine mögliche Auswirkung, die andere ist, dass man sich ein Thrashing-Problem einhandeln kann.

Meinst Du damit das gegenseitige Wegnehmen von Cache-Segmenten zweier Threads? Das sollte doch mit nem Prioritätsmanagement hinzubekommen sein. Wie hat IBM das eigentlich gelöst?

[CrazyIvan]

Der Gast war ich.

[Muh-sagt-die-Kuh]

Meinst Du damit das gegenseitige Wegnehmen von Cache-Segmenten zweier Threads? Das sollte doch mit nem Prioritätsmanagement hinzubekommen sein. Wie hat IBM das eigentlich gelöst?Ja, das meine ich, sprich sehr viele Conflict-Misses weil eine höhere Wahrscheinlichkeit besteht, dass 2 oder mehrere (4 beim Power5) Threads um ein Set konkurrieren. Dieses Miss-Sorte lässt sich nun aber durch eine höhere Assoziativität mindern und genau das macht IBM beim Übergang vom Power4 zum Power5 auch.

Ich persönlich bin eher der Meinung, dass beide Ansätze sich nicht viel geben...Vergleichswerte wäre natürlich was schönes, ich hab aber noch keine gefunden.

[Ikon]

Meinst Du damit das gegenseitige Wegnehmen von Cache-Segmenten zweier Threads? Das sollte doch mit nem Prioritätsmanagement hinzubekommen sein. Wie hat IBM das eigentlich gelöst?

Thread-Management ist Sache des OS.

[CrazyIvan]

Thread-Management ist Sache des OS.

Das ist mir schon klar, aber wie M-s-d-K richtig erkannt hat, ging es mir um was anderes.

@ Muh-sagt-die-Kuh
Vergleichswerte könnte wohl nur eine CPU liefern bei der mal wahlweise beides einstellen kann. Allerdings wirds das wohl nie geben...

[Muh-sagt-die-Kuh]

@ Muh-sagt-die-Kuh
Vergleichswerte könnte wohl nur eine CPU liefern bei der mal wahlweise beides einstellen kann. Allerdings wirds das wohl nie geben...Das wohl nicht, mir würde es aber schon reichen, wenn die intel, AMD oder IBM ihre Simulationsergebnisse rausrücken würden ;)

[Leonidas]

http://www.zdnet.de/news/hardware/0,39023109,39125355,00.htm

Waren wir hier nicht zumindest beim K8 immer von nem gemeinsamen Cache ausgegangen? Hätte einen geshareten Cache mit doppelter Größe der Single-Cores besser gefunden. Diese statische Zuteilung ist vielleicht einfacher zu implementieren, kostet aber mit Sicherheit Performance...


War aber eigentlich relativ klar. Besonders bei Intel, wo DualCore schließlich ein klassischer Schnellschuß ist.

[BlackBirdSR]

War aber eigentlich relativ klar. Besonders bei Intel, wo DualCore schließlich ein klassischer Schnellschuß ist.

Ich würde den IA64 DualCore jetzt nicht als Schnellschuss sehen.
Schließlich steckt da einiges an Entwicklungszeit drinn, und fertig ist er ja auch schon seit einiger Zeit.

Bei AMD war es aufgrund der Architekture einfach klar.

[icemanemp]

Da es sich hier nicht um eine offiziele Bestätigung handelt, kann man ja noch hoffen! Schon seit Jahren wurde doch gesagt, das der K8 auf Dual bzw. mehrfach CPU-Fähigkeit ausgelegt wird (von irgendeinem AMD-Mitarbeiter...), obwohl der Chip noch in der Entwicklung war...
Wäre jetzt wirklich schwachsinn, wenn sie diesen Vorteil naja nicht gerade zu nichte machen würden, aber jedenfalls die Vorteile schmälern.
Wie sieht es den aus mit der Anbindung zwischen den beiden CPU-Cores, wie schnell müsste die den sein, das dort kein Performanceverlust entsteht... oder seh ich es falsch? Ist nicht die Anbindung zwischen den beiden Kernen der Flaschenhals? Oder nur der doppelt gepflegte Cache?

[BlackBirdSR]

Da es sich hier nicht um eine offiziele Bestätigung handelt, kann man ja noch hoffen! Schon seit Jahren wurde doch gesagt, das der K8 auf Dual bzw. mehrfach CPU-Fähigkeit ausgelegt wird (von irgendeinem AMD-Mitarbeiter...), obwohl der Chip noch in der Entwicklung war...
Wäre jetzt wirklich schwachsinn, wenn sie diesen Vorteil naja nicht gerade zu nichte machen würden, aber jedenfalls die Vorteile schmälern.
Wie sieht es den aus mit der Anbindung zwischen den beiden CPU-Cores, wie schnell müsste die den sein, das dort kein Performanceverlust entsteht... oder seh ich es falsch? Ist nicht die Anbindung zwischen den beiden Kernen der Flaschenhals? Oder nur der doppelt gepflegte Cache?

Ich finds lustig,
da gibt es weder Benchmarks, noch Anhaltspunkte wie sich die ein oder andere Wahl auswirkt.
Und schon wird davon gesprochen, dass AMD sich Chancen verspielt, weil man den Cache nicht shared.

Der K8 wurde von Anfang an so ausgelegt. AMD wird schon wissen was man tut.

[backfisch]

AMD hat heute zwei in 90-Nanometer-Technik gefertigte Dual-Core-Opterons vorgestellt. Link (http://www.heise.de/newsticker/meldung/50540)