Ein paar Opteron DC Reviews

Dresdenboy

Redaktion
☆☆☆☆☆☆
Mitglied seit
28.10.2003
Beiträge
3.090
Renomée
203
Standort
Berlin
http://www.firingsquad.com/hardware/colfax_dual_opteron/

Weniger bekannte Software wurde hier getestet. Aber es soll noch ein zweites FS-Review zum DC-Opteron kommen.

http://www.tecchannel.de/hardware/1670/index.html
Umfangreich und gut gemacht (obwohl sehr werbelastig). Für Vergleichswerte das 840/840XE-Review: http://www.tecchannel.de/hardware/1658/index.html

Ein paar Server-Benchmark-Ergebnisse von HP (der erste Link ist schön übersichtlich aus dem Aceshardware-Forum mit Quelle):
http://aceshardware.com/forums/read_post.jsp?id=115128221&forumid=1
http://biz.yahoo.com/bw/050421/206151.html?.v=1
(SAP-Benchmark-Ergebnisse)
 
Ab gestern kann man die Intel-CPUs nicht mehr als die besten Video-Encoding-Chips empfehlen.
 
Interessant, wenn auch nicht unbedingt am objektivsten, sind auch die Benchmarks auf der AMD Homepage, insbesondere folgende:

97033.jpg

97037.jpg


Hier geht es zu AMD:
http://www.amd.com/us-en/Processors/ProductInformation/0,,30_118_8796_8800,00.html
 
Ein Thema kann wieder ganz heiß aufgekocht werden - Cache Kohärenz

Einleitend einen Kurzen Ausschnit aus dem Doppelkorn-Thread:
http://www.planet3dnow.de/vbulletin/showpost.php?p=1807222&postcount=95

HenryWince schrieb:
@rkinet
> Es gibt ja auf jeden Fall die Cache-Coherenz-Information, also benötigt eine CPU neue Daten / Programmcode und er liegt bei der Nachbar-CPU im Cache, so wird er wohl dort abgeholt.

Nope, in den meisten Fällen eben nicht! Nur wenn die Nachbar-CPU die Daten in ihrem Cache bereits modifiziert hat bekommt sie via Snooping mit das jemand diese Daten aus dem Speicher benötigt. Damit die Koherenz gewährleistet bleibt gibt es nun zwei Möglichkeiten:

1) die CPU die die modifizierten Daten hat (CPU1) schreibt sie in den Hauptspeicher zurück und erst dann darf die anfragende CPU (CPU2) die Daten von dort lesen.
Bei CPU1 geht der Cachline zustand dann von Modified auf Shared, bei CPU2 von Invalid auf Shared. Dieses Verfahren nennt sich MESI.

2) CPU1 schickt die Daten direkt an CPU2. Bei CPU1 geht der Cacheline zustand von Modified auf Owned, bei CPU2 von Invalid auf Shared. Das ist MOESI.


> Benötigt CPU-1 Daten, die schon im Cache der CPU-2 vorliegen, dürfte hierüber ein Abgleich erfolgen, oder ?

Nur für modifizierte Daten. Das unmodifizierte Daten nicht übertragen werden liegt daran, dass die Cache-Coherenz-Information generell per Broadcast übertragen werden. Wenn die Daten in mehreren Caches liegen, wer soll sich dann "melden" und die Daten liefern?

Für Details zu MOESI empfehle ich "AMD64 Architecture Programmer’s Manual Volume 2: System Programming" ab Seite 199.

Hier das entsprechende Dokument:
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf

Und hier ein Aussschnitt aus dem Dokument(Seite 201 oben):

"When an external master has a cache read-miss or write-miss, it probes the other mastering devices to determine whether the most recent copy of data is held in any of their caches. If one of the other mastering devices holds the most recent copy, it provides it to the requesting device. Otherwise, the most recent copy is provided by main memory."

Wenn ich nichts missverstanden habe stehen diese Sätze im Gegensatz zu dieser Aussage:

>Nur für modifizierte Daten. Das unmodifizierte Daten nicht übertragen werden liegt
>daran, dass die Cache-Coherenz-Information generell per Broadcast übertragen
>werden. Wenn die Daten in mehreren Caches liegen, wer soll sich dann "melden"
>und die Daten liefern?

Es muss nur noch die Definition von most recent geklärt werden:

- Invalid—A cache line in the invalid state does not hold a
valid copy of the data. Valid copies of the data can be either
in main memory or another processor cache.

- Exclusive—A cache line in the exclusive state holds the most
recent, correct copy of the data. The copy in main memory is
also the most recent, correct copy of the data. No other
processor holds a copy of the data.

- Shared—A cache line in the shared state holds the most
recent, correct copy of the data. Other processors in the
system may hold copies of the data in the shared state, as
well. The copy in main memory is also the most recent,
correct copy of the data (since no other processor holds it in
owned state).

- Modified—A cache line in the modified state holds the most
recent, correct copy of the data. The copy in main memory is
stale (incorrect), and no other processor holds a copy.

- Owned—A cache line in the owned state holds the most
recent, correct copy of the data. The owned state is similar to
the shared state in that other processors can hold a copy of
the most recent, correct data. Unlike the shared state,
however, the copy in main memory can be stale (incorrect).
Only one processor can hold the data in the owned state—all
other processors must hold the data in the shared state.

Meiner Meinung nach können alle Cache Lines markiert mit M O E S von Cache zu Cache transferiert werden.

Wieso will ich an dieser Stelle nochmal nachhaken?
Weil mir dieser Benchmark so gut gefällt:

povray.gif

gefunden hier: http://techreport.com/reviews/2005q2/opteron-x75/index.x?pg=6

Der grüne Balken stellvertretend für drei Threads hat meine besondere Aufmerksamkeit erregt. Eigentlich für eine Dual-Prozessor-Konfiguration Gift.
Im schlimmsten Fall wird der Thread 3 von Core0 zu Core1 hin und her verschoben.

Beim Dual-Opteron 248 sieht man das bei 4 Threads keine "Verschiebe-Verluste" Auftreten - bei drei Threads aber sehr wohl.

Der Pentium D 840 leidet stärker unter den 3 Threads als der Dual-248 - wegen MESI
Der Pentium XE840 kann wegen der 4 logischen Kerne punkten - selbst bei drei Threads.

Der Opteron 175 verliert beim Thread-Ping-Pong beinahe nichts, da das SRI mit Core-Takt läuft und weil Cache-Lines von Core zu Core verschoben werden können.

Grüße,
Tom
 
http://techreport.com/reviews/2005q2/opteron-x75/index.x?pg=2

MESI-MESI-MOESI Banana-fana...
In order to understand the impact of AMD's dual-core chip design and system architecture, we should briefly discuss cache coherency. This scary sounding term is actually one of the bigger challenges in a multiprocessor system. How do you handle the fact that one CPU may have a certain chunk of data in its cache and be modifying it while another CPU wants to read it from memory and operate on it, as well? Assuming you don't run from the room screaming in fear at the complexity of it all, the answer is some sort of cache coherency protocol. Such a protocol would store information about the status of data in the cache and offer updates to other CPUs in the system when something changes.

Intel's Xeons use a cache coherency protocol called MESI. MESI is an acronym that stands for the various states that data in the CPU's cache can be flagged as: modified, exclusive, shared, or invalid. Let's tackle them completely out of order, just to be difficult. If a CPU pulls a chunk of data into cache and has not modified it, the data will be flagged as Exclusive. Should another CPU pull that same chunk of data into its cache, the data would then be marked as Shared. Then let's say that one of the processors were to modify that data; the data would be marked locally as Modified, and the same chunk on the other CPU would be flagged as Invalid.

Simple, no?

The processor with the Invalid data in its cache (CPU 0, let's say) might then wish to modify that chunk of data, but it could not do so while the only valid copy of the data is in the cache of the other processor (CPU 1). Instead, CPU 0 would have to wait until CPU 1 wrote the modified data back to main memory before proceeding—and that takes time, bus bandwidth, and memory bandwidth. This is the great drawback of MESI.

AMD sought to address this problem by making use of a cache coherency protocol called MOESI, which adds a fifth possible state to its quiver: Owner. (MOESI is used by all Opterons and was even used by the Athlon MP and 760MP chipset back in the day.) A CPU that "owns" certain data has that data in its cache, has modified it, and yet makes it available to other CPUs. Data flagged as Owner in an Opteron cache can be delivered directly from the cache of CPU 0 into the cache of CPU 1 via a CPU-to-CPU HyperTransport link, without having to be written to main memory.

That alone is a nice enhancement over MESI, but the dual-core Opterons take things a step further. In the dual-core chip, cache coherency for the two local CPU cores is still managed via MOESI, but updates and data transfers happen through the system request interface (SRI) rather than via HyperTransport. This interface runs at the speed of the CPU, so transfers from the cache on core 0 into the cache on core 1 should happen very, very quickly. Externally, MOESI updates from a pair of cores in a socket are grouped in order to keep HyperTransport utilization low.

Again, this is quite the contrast with Intel's dual-core implementation, which remains on Smithfield almost exactly like a pair of Xeons on two sockets. MESI updates are communicated over the front-side bus. There is no alternative internal on-chip data path.

Interestingly, the ability of the two cores to pass data quickly to one another seems to offer a compelling enough performance benefit that, from what I gather, AMD's guidance to OS vendors has been to give priority to scheduling threads on adjacent cores first before spinning off a thread on a CPU core on another socket. That's despite the fact that there's additional memory bandwidth available on the second socket.
 
tja, wir hatten hier mal die diskussion um die cache kohärenz, unter anderem weil ich vertrat, man könne die l2-caches zusätzlicher cpus/cores in opteron-systemen als l3-cache für jede andere cpu ansehen. ich ließ mich damals eines besseren belehren und auch jetzt mag ich wegen der kompetenz von henrywince nicht entscheiden, wer hier nun irrt, er oder techreport. vielleicht verstehe ich es auch nur falsch und es bestand nie ein widerspruch *noahnung*

aber, so wie ich es verstehe,sehe ich es schon so, daß das moesi-protokoll eben doch dafür sorgt, daß die l2-caches die gleiche oder ähnliche wirkung haben, wie zusätzlicher l3-cache: die zugriffe und änderungen verschiedener cores auf identische daten laufen nur im cache ab mit der schönen folge, daß kein zugriff über den memory-controller auf das ram notwendig ist. genau wie mocad_tom es benennt: thread-ping-pong!

dies erklärt nicht nur die angegeben grafik gut und warum die amd dual-cores so schön skalieren, sondern es erklärt auch, warum amd keine zwingende notwendigkeit sah, die bandbreite zum ram zu erhöhen. das diese wirkung in dual-core über sri ungleich höher ist als bei den dual-systemen über htr ist klar.

edit:
müßte man diesen effekt nicht mit linpack "sehen" können?

http://techreport.com/reviews/2005q2/opteron-x75/index.x?pg=5
 
Treverer schrieb:
edit:
müßte man diesen effekt nicht mit linpack "sehen" können?

http://techreport.com/reviews/2005q2/opteron-x75/index.x?pg=5

Du bräuchtest eine Art Helper-Thread, hier wurde das mal ganz kurz angerissen:

"To Weber's second point, the use of helper threads (compiler or application generated threads that go out and work on prefetching useful data into cache before it's requested) will also improve single core performance. Intel has been talking about using helper threads since before Hyper Threading, but there is no idea of when we can expect real world implementation of helper threads at this point. "
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2387
Hier wäre es für Dual-Core interessant.

Vielleicht kann auch nur das SRI die States M O E S von Cache zu Cache transferieren. cc-HTr hingegen nur die States M & O.

Das SRI muss bei einer Dual-Sockel-Dual-Core-Konfiguration schließlich auch die Kohärenz/das Snooping beider Caches nach draussen hin verwalten, sprich ausreichend große Pfade werden ja vorhanden sein.

Hier eine Aussage von Jonathan Seckler - AMD senior product manager
http://hardware.gamespot.com/Story-ST-x-1653-x-x-x
"The way things happen is that requests come in, and this system request interface will arbitrate, and the caches are going to communicate. The communication for the CPU to check to see if this cache is using the information or not, that's all at the speed of the processor. There's no front-side bus. It's not going across the front-side bus and checking and then coming out and back. It's right there. It's natively there, and it's going to be a huge performance benefit, and that's on top of our natural AMD 64 performance benefit."

Gut auch dieser Bench:
doom3.gif


Der Dual-Opteron 248 kann aus den zwei Threads keine Vorteile mitnehmen, während der 175 doch deutlich gewinnt. Anhand der CPU-Auslastung kann man erkennen, das sich die Spiele-Schmieden wohl dafür entschieden für Hyperthreading noch einen zweiten kleineren Thread mitlaufen zu lassen - der aber wohl sehr intensiv in der Thread-Synchronisation ist.

Grüße,
Tom
 
ja, das ist natürlich ein wichtiger gravierender unterschied zum richtigen l3-cache, daß natürlich nur die daten im cache liegen, die ein thread anforderte, welcher auf dem entsprechenden core lief. und linpack läuft ja nun wohl nur auf einen core, so daß kaum erfolgreich daten gefunden werden können im anderen core. dies hatte ja auch henrywince bereits damals angedeutet, als er bezweifelte, daß so etwas häufig vorkäme.

die idee mit dem helper thread, welcher also nur dazu da ist, den cache mit den richtigen daten zu füllen, ist mir dabei ein wenig suspekt, denn er liefe ja auch, wenn in wirklichkeit andere threads die rechenleistung brauchen würden, oder? stelle ich mir auch relativ schwer vor: wenn ich schon soweit parallellisieren kann, daß der "helper-thread" funktioniert, wieso soll nicht gleich die ganze anwendung parallellisiert werden können?

ich denke, so etwas müßte in hardware realisiert werden und wäre wohl die aufgabe der prefetching-einheit (oder einer zusätzlichen prefetching einheit). diese müßte eben auch daten in den cache des jeweils anderen cores liefern können. so ein prefetching des prefetching wie bei der nforce4 intel version...

ist es so, daß immer erst die invalild cache-lines ersetzt werden durch neue daten? und wenn keine invalid wären, dann zuerst die "ältesten", am längsten ungenutzen? wie stellt man fest, wie alt die daten sind? und vor allem: gibt es counter, an denen erkennbar ist, wie "voll" ein cache wäre? denn erst dann gebe so ein pre-prefetching doch einen sinn: denn unbenutzen cache des anderen core füllen mit daten, die im "lokalen" l2-cache noch nicht liegen. aber vielleicht erübrigt sich dies auch alles mit einem regulären l3-cache (off-die), von dem ich immer noch überzeugt bin, daß amd ihn bringen sollte als nächstes für ihre server prozessoren, um in leistungs-regionen vorzustoßen, wie sie power5 und itanium haben. nur: wie sehe solch ein l3-cache modell bei den opterons aus? müßte der memory-controller nicht wieder raus? oh: spekulations-alarm :-)
 
Treverer schrieb:
müßte der memory-controller nicht wieder raus? oh: spekulations-alarm :-)
Wieso sollte der IMC raus, nur weil du ein zusätzliches Cache-Level einbaust? Der Zugriff auf Daten läuft dann eben so: L1 - L2 - L3 - IMC
Sobald die gewünschten Daten gefunden sind, stoppt die CPU den Suchvorgang. Es wird eben eine weitere Cache-Ebene vor dem IMC abgefragt. Ich sehe da kein Problem (ok, es fehlt mir auch eines an technischen Details... ;) ).
 
Starcraftfreak schrieb:
Wieso sollte der IMC raus, nur weil du ein zusätzliches Cache-Level einbaust? Der Zugriff auf Daten läuft dann eben so: L1 - L2 - L3 - IMC
Sobald die gewünschten Daten gefunden sind, stoppt die CPU den Suchvorgang. Es wird eben eine weitere Cache-Ebene vor dem IMC abgefragt. Ich sehe da kein Problem (ok, es fehlt mir auch eines an technischen Details... ;) ).

tja, ich gehe mal davon aus, daß ein l3 cache sicher nicht on die und mit vollem takt läuft. deswegen:

l1 + l2 on die bei vollem takt verbunden mit einem l3, welcher wiederum mit dem ram verbunden wäre. und wo bleibt der memory controller? genau, wie bei dir eben auch direkt beim l3, welcher aber wie gesagt nicht mehr on die wäre und auch mit geringerem takt liefe. eben genau so, wie früher der l2 beim athlon und beim piii als slot...
 
Zurück
Oben Unten