Seit der Einführung der K10-Kerne im September 2007 produzieren AMDs Fabriken zwei äußerlich und namentlich zwar verwandte, innerlich jedoch grundverschiedene Kerne.

Seit der Einführung der K10-Kerne im September 2007 produzieren AMDs Fabriken zwei äußerlich und namentlich zwar verwandte, innerlich jedoch grundverschiedene Kerne. Denn während die X3 und X4-Prozessoren der Phenom-Serie schon auf dem K10 basieren und zumindest letztere am 8. Januar durch den "K10.5" Phenom II ersetzt werden, liegt sämtlichen Dual-Core Prozessoren noch das schon über fünf Jahre alte K8-Design zugrunde.

Um eine Ablösung der mittlerweile doch recht betagten Rechenknechte gibt es schon lange Spekulationen. So machte ursprünglich ein auf dem K10-Kern basierender, jedoch nativer, Dual-Core Prozessor mit dem Codenamen "Kuma" als Schreckgespenst die Runde, wurde jedoch komplett ergebnis- und, in bester AMD Firmentradition, kommentarlos wieder eingestampft. Gerüchten, die von einem Entwicklungsstopp des Dual-Core Phenoms berichteten, trat man noch im Juni 2008 in Person von AMD-Sprecher Jake Whitman energisch entgegen. Ihm zufolge sei die Entwicklung keineswegs eingestellt und man plane weiterhin die Einführung eines Dual-Core Prozessors namens "Kuma". Dieser stehe jedoch in keinerlei Verbindung mit dem Phenom, es handelt sich dabei um eine Neuentwicklung mit eigener Belichtungsmaske. Weitere Details blieb man der interessierten Öffentlichkeit allerdings schuldig.

Keine drei Monate später tauchte dann plötzlich ein mysteriöser AMD Athlon X2 6500 auf, den niemand zuvor auf dem Plan hatte. Die Gerüchteküche überschlug sich mit wilden Spekulationen und die Händler schürten die Unklarheiten mit falschen Angaben zum Prozessor - mal war die TDP falsch angegeben, mal die Größe des L3-Caches. Woher dieser Prozessor jedoch kam, was es mit dem seltsamen Namen auf sich hat und wann er endlich verfügbar sein sollte wurde nicht bekannt, denn auch hierzu gab es von AMD wieder mal keinen Kommentar (wer ein wiederkehrendes Muster in AMDs PR-Abteilung erkennt hebe die Hand). Wir konnten unter vorgehaltener Hand aus sicherer Quelle einige Details klären, jedoch stellten sich auch diese letztendlich nicht als 100%ig korrekt heraus. Ende September gelang es den Kollegen von Expreview einen AMD Athlon X2 6500 zu ergattern und zu testen, aber so wirkliche Antworten auf das Wie und Warum dieser CPU gab es auch hier nicht. Mittlerweile ist zumindest eines klar: den AMD Athlon X2 6500 wird es in dieser Form in Europa und in den USA nicht geben, lediglich auf dem asiatischen Markt wird diese CPU erhältlich sein.

Jetzt hätten wir zugegebenermaßen gerne mit Jake Whitman gesprochen, dem AMD-Sprecher, der die Verwandtschaft zwischen Kuma und Phenom noch vor fünf Monaten bestritten hatte. Denn seit wenigen Wochen brodelt die Gerüchteküche erneut und zauberte kürzlich die X2 7000-Serie hervor. Seit der Einführung der X3-Serie ist klar, dass prinzipiell auch Dual-Core Ableger mit zwei deaktivierten Kernen produziert werden könnten. Und genau einen solchen haben wir Ende November von AMD auf den "Dragon Days" ergattern können.

[break=Kuma im Detail: X4-2]
Dabei handelt es sich um einen AMD Athlon X2 7750 Prozessor, womit sich die Gerüchte zum neuen Nummernschema bestätigen:
  • K10 mit vier Kernen: Phenom X4 9xxx
  • K10 mit drei Kernen: Phenom X3 8xxx
  • K10 mit zwei Kernen: Athlon X2 7xxx
X2


Zur Einführung am heutigen 15. Dezember wird es vorerst drei Modelle geben. Der von uns getestete X2 7750 Black Edition mit 2x 2,7 GHz ist das neue Dual-Core Flaggschiff. Im Fahrwasser werden der X2 7550 mit 2x 2,5 GHz und der X2 7450 mit 2x 2,4 GHz mitgezogen. Allen gemeinsam sind der 2x 512KB große L2-Cache und der gemeinsam genutzte 2MB große L3-Cache, über einen offenen Multiplikator verfügt wie gehabt nur die Black Edition.

Kuma Kuma
Einmal dank Cool'n'quiet heruntergetaktet, einmal bei vollem Takt


Es handelt sich hierbei um einen Agena mit zwei deaktivierten Kernen. Da dieser als Topmodell lediglich 2,6 GHz erreichte, ist es umso erstaunlicher, dass das Flaggschiff der neuen X2-Serie schon von Beginn an höher taktet. Zwar sind die mit dem K8-Kern erreichten 3,2 GHz des Athlon 64 X2 6400+ noch reine Illusion, jedoch scheint die Deaktivierung der Kerne zusätzliche Reserven freizuschalten. Ob wir jedoch einen über 3 GHz schnellen K10-basierten X2 sehen werden, steht noch in den Sternen. Eine Ankündigung höher getakteter Modelle gibt es bis dato noch nicht. Möglich ist also, dass die heute veröffentlichten Kuma-Prozessoren lediglich als Lückenfüller herhalten müssen, bis X2-Ableger des schnelleren Phenom II verfügbar sein werden. Übrigens sollen diese eine Neuentwicklung mit eigener Maske sein und keine teildefekten Phenom II Prozessoren mit deaktivierten Kernen. Mal schauen, wie lange man diesmal bei dieser Version der Geschichte bleibt.

Abgesehen von den zwei deaktivierten Kernen verfügt der Kuma über keine weiteren Einschränkungen und besitzt somit sämtliche Features des fehlerkorrigierten B3-Steppings aktueller Phenom-Prozessoren. Dies bedeutet logischerweise somit auch, dass er im Bereich der Dual-Core Prozessoren eine echte Neuerung einführt: offizielle Unterstützung für DDR2-1066. Zwar kann man auch heute schon mit K8-Prozessoren auf vielen Mainboards DDR2-1066 aktivieren, mangels korrektem Speicherteiler war dies jedoch nicht immer möglich.

Kuma Kuma
Einmal mit DDR2-800, einmal mit DDR2-1066


Auch ansonsten entspricht der Kuma direkt den Agena: Unterstützung für Hypertransport 3.0, zusätzliche SSE-Befehle mit der Implementierung von SSE4a, die verbesserte 128-bit SSE-Einheit, doppelte Breite der Cache-Anbindung, ein Speichercontroller, der sowohl Ganged (128-bit) als auch Unganged (2x 64-bit) beherrscht, eine längere Instruction Queue (32 Byte), einen 48 Einträge großen TLB und die verbesserte Sprungvorhersage, der insbesondere aufgrund des L3-Caches eine enorm wichtige Rolle zukommt. Mehr dazu jedoch später.

X4-2 = X1+1?
Die Gemeinsamkeiten zwischen einem K8-basierten X2-Prozessor und seinem K10-basierten Kollegen beschränken sich somit größtenteils auf die Anzahl der Kerne. Am gravierendsten unterscheiden sich die zwei in Ihren Entwicklungsansätzen. Denn während der K8 ursprünglich eine Single-Core Entwicklung war, von der 2005 mit der Einführung der ersten X2-Prozessoren lediglich zwei Stück auf ein Die gesteckt und intern verbunden wurden, hat der K10 Kerne im Überfluss und muss im Falle des X3 auf einen, im Falle des X2 auf zwei davon verzichten. Mit anderen Worten: während der K8 für möglichst hohe Leistung eines einzelnen Kerns entwickelt und optimiert wurde (wo nur ein Kern ist muss dieser schließlich besonders schnell sein), lag das Hauptaugenmerk beim K10 auf einer möglichst effizienten Zusammenarbeit mehrerer Kerne.

Das bedeutet also wiederum im Umkehrschluss, dass die Optimierungen der K10-Architektur, von denen die Quad-Core Phenoms profitieren, bei Reduzierung um zwei Kerne unter Umständen verpuffen könnten. Auch das Gegenteil ist möglich, nämlich dass einzelne Punkte, die bei drei oder vier Kernen noch einen Flaschenhals bilden, bei Reduzierung auf zwei Kerne plötzlich den Prozessor weiter beschleunigen.

Die Rechnung fängt also wieder bei Null an. Wir dürfen auf keinen Fall von der vorhandenen Wissensbasis über Triple- und Quad-Core K10-Prozessoren auch ungeprüft und unbedacht auf Dual-Core K10-Prozessoren schließen.

Ein gutes Beispiel hierfür ist der L3-Cache.

[break=Der Segen des L3-Caches]
Wir hatten in der Vergangenheit schon öfters den L3-Cache der aktuellen Phenom-Prozessoren bemängelt. Hauptkritikpunkt war die mit zwei Megabyte für vier Kerne unzureichende Größe.

Wird ein Speicherzugriff durchgeführt, vergehen mehrere hundert Taktzyklen bis die angeforderten Daten parat stehen. In der Zwischenzeit steht die Berechnung, die auf diese Daten angewiesen ist, still. Eine moderne out-of-order Architektur beschäftigt sich derweil mit anderen Befehlen. Jeder Speicherzugriff kostet also unnötig viele Strafzyklen und stellt bei modernen Prozessoren mit langer Pipeline ein worst-case Szenario dar. Zugriffe auf den Cache dauern hingegen in der Regel nur wenige (L1-Cache) bis wenige Dutzend (L2-Cache) Taktzyklen. Ziel muss also sein, Zugriffe auf den Speicher tunlichst abzufangen und idealerweise komplett zu vermeiden. In einem solchen Idealfall lägen also sämtliche Daten bei Anforderung bereits im Cache und könnten von dort schnell eingelesen werden. Konkreter gesagt sind die Daten im Idealfall nicht nur im Cache, sondern befinden sich bereits in den Registern.

Genau diese Aufgabe erfüllt in modernen Prozessoren die Sprungvorhersagelogik. Deren Aufgabe ist es, bei bedingten Sprüngen (if A then B else C) die Wahrscheinlichkeit des einen und andere Ausgangs zu berechnen und anschließend eine Vorhersage darüber zu treffen, welche der beiden (oder mehreren) Möglichkeiten am wahrscheinlichsten ist (ein Skeptiker würde sagen: versuchen zu erraten, wo es lang geht). Auf Basis dieser Vorhersage werden die Daten rechtzeitig im Cache abgelegt, so dass sie quasi sofort zur Verfügung stehen. Liegt die Logik jedoch daneben, dann tritt bereits erwähnter GAU ein - die Berechnung legt eine Vollbremsung ein und wartet geduldig mehrere hundert Taktzyklen lang, bis sich der langsame Speicher bequemt, endlich die Daten zu liefern. Schlechte und unzuverlässige Sprungvorhersagen können also nicht durch größere Caches ausgeglichen werden, sondern stellen eine inhärente Schwachstelle dar.

Die zweite Aufgabe einer mehrstufigen Cache-Infrastruktur besteht darin, bereits einmal benötigte Daten vorzuhalten, damit sie bei einem erneuten Zugriff nicht erst wieder zeitaufwändig geladen werden müssen. Statistisch gesehen ist die Wahrscheinlichkeit recht hoch, dass einmal benötigte Daten innerhalb kürzester Zeit erneut benötigt werden. Dieses Phänomen wird als Lokalitätseigenschaft eines Computerprogramms bezeichnet, die nichts weiter aussagt, als dass in einem bestimmten Zeitabschnitt nur auf einen sehr kleinen Bereich aller insgesamt verfügbaren Speicherzellen zugegriffen wird. Dabei wird zwischen zeitlicher (temporaler) und örtlicher (spatialer) Lokalität unterschieden. Dass Lokalität überhaupt existiert ist wiederum auf die sequentielle Natur von Algorithmen und Computerprogrammen zurückzuführen. Ein Prozessor kann an dieser Stelle von größeren Caches enorm profitieren, denn je mehr schneller Cache-Speicher zur Verfügung steht, desto später müssen bereits gepufferte Daten verworfen werden. Man könnte nun also zu der logischen Schlussfolgerung verleitet sein, dass die zwei Megabyte L3-Cache der K10-Architektur allein dadurch, dass sie zusätzlichen Pufferspeicher zur Verfügung stellen, bereits der Performance zugute kommen. Doch leider hat jede Medaille eine Kehrseite.

[break=Der Fluch des L3-Caches]
Stellen wir uns ein typisches und regelmäßig auftretendes Problem eines Mikroprozessors vor: die Recheneinheiten benötigen externe Daten, die Sprungvorhersage hat jedoch versagt und die falschen Daten vorgeladen. Extern ist hierbei alles, was noch nicht in den Registern liegt, denn nur darauf können die Befehlseinheiten rechnen. Es vergehen also zunächst X Taktzyklen bis die Logik feststellt, dass die Daten nicht im L1-Cache liegen. Anschließend vergehen weitere Y Taktzyklen bis die Logik feststellt, dass die Daten auch nicht im L2-Cache liegen. Bis zu diesem Punkt ist es völlig irrelevant, ob sich das Szenario auf einem K8 oder einem K10 abspielt. Ab der dritten Stufe trennen sich die Wege. Denn der K8 greift nun sofort und ohne weitere Umwege auf den Speicher zu und beginnt die zeitaufwändige Besorgung der Daten. Der K10 muss hingegen zuvor erst noch im L3-Cache nachschauen, ob die benötigten Daten vielleicht hier liegen. Da in unserem Beispiel eine falsche Sprungvorhersage Schuld an dem GAU ist, braucht der Prozessor Z Taktzyklen um festzustellen, dass die Daten auch nicht im L3-Cache liegen. Der Zugriff auf den Speicher beginnt also nicht wie beim K8 nach X+Y Taktzyklen, sondern nach X+Y+Z Taktzyklen. Da der L3-Cache im Vergleich zum L2- und L1-Cache deutlich langsamer arbeitet, kann dieser Fall also zu einem spürbaren Performanceverlust führen.

Kuma
Speicherlatenzen bei DDR2-800

Kuma
Zugriffszeiten auf die jeweils einzelnen Speicherstufen

Kuma
Aufaddierte Zugriffszeiten auf die aufeinanderfolgenden Speicherstufen


Verglichen mit AMDs aktuellem 2,7 GHz schnellen Athlon 64 X2 5200+ (G2-Stepping) in demselben Mainboard bei DDR2-800 sieht dies folgendermaßen aus:

Kuma

Kuma


Letzten Endes bedeutet diese Auflistung eines: bei einem "cache miss" vergehen beim K8 133 Taktzyklen, bis der Zugriff auf den Arbeitsspeicher erfolgt und die Daten geladen werden. Beim K10 sind dies mit 259 Taktzyklen fast doppelt so viele.

[break=Fluch oder Segen?]
Die Frage ist nun, was man gegen diese dem L3-Cache immanente erhöhte Latenz unternehmen kann. Den Cache zu deaktivieren ist keine Lösung, dann lägen die Latenzen zwar wieder auf "normalem" Niveau, jedoch wären die Vorteile der dritten Cache-Stufe passé. Aufmerksame Leser erinnern sich sicherlich an folgende Aussage aus unserem Shanghai-Review:
    Die erste augenscheinliche Veränderung erfuhr der L3-Cache, der um 4 MB erweitert wurde und nun 6 MB groß ist. Die Größe des L3-Caches gleicht das Problem dieser zusätzlichen Cache-Stufe aus: die erhöhte Latenz. Denn diese liegt im Vergleich zu einem System mit nur zweistufigem Cache deutlich höher, da die dritte Stufe ebenfalls abgefragt werden muss bevor auf den vergleichsweise langsamen Arbeitsspeicher zurückgegriffen wird.

Eine Möglichkeit ist also den Cache so groß wie möglich zu gestalten. Da der L3-Cache von allen aktivierten Kernen eines X2, X3 oder X4-Prozessors geteilt wird, können Daten, die von einem Kern in den Cache geschrieben wurden, von einem anderen von den Latenzen abgesehen verzögerungsfrei gelesen werden. Die folgenden zwei Aussagen sind also gleichbedeutend:
  • Je größer also der L3-Cache, desto höher ist die Wahrscheinlichkeit, dass eine Information noch nicht zu Gunsten einer neueren überschrieben wurde und erneut aus dem Speicher gelesen werden muss.
  • Je weniger Kerne gleichzeitig auf den L3-Cache zugreifen, desto höher ist die Wahrscheinlichkeit, dass eine Information von einem beliebigen Kern noch nicht zu Gunsten einer neueren überschrieben wurde und aus dem Speicher gelesen werden muss

Auf den Kuma gemünzt bedeutet dies also, dass die Reduzierung um zwei Kerne effektiv einer Verdopplung des verfügbaren L3-Caches pro Kern entspricht und beide Aspekte gleichzeitig greifen. Was wir also beim Phenom bemängelt haben und beim Shanghai und Phenom II als positiv erachten, gilt somit auch für den Kuma: zusammen mit der im Vergleich zum K8 verbesserten Sprungvorhersage kann die effektive Vergrößerung des L3-Caches im direkten Vergleich mit dem Phenom X4 in Fällen, die von der generellen Anwesenheit einer dritten Cachestufe profitieren, zu einer höheren pro-Kern-Leistung führen. In allen anderen Fällen dürfte die effektive Vergrößerung zumindest die Latenzverluste ausgleichen.

Einen ganz anderen Aspekt, an den wir in unseren theoretische Überlegungen nicht gedacht hatten, haben uns dann noch die Benchmarks vor die Nase gehalten: im Vergleich zum single-threaded Modus liefen einige Benchmarks im multi-threaded Modus mehr als doppelt so schnell. In der Theorie dürfte hier jedoch nur eine Beschleunigung um maximal den Faktor 2x möglich sein.

Kuma

Kuma

Besonders beeindruckend war die Beschleunigung von Cinebench um den Faktor 2,25x, also einer Steigerung um 125%. Auch 7-Zip glänzt mit 2,18x, was einer Steigerung um 118% entspricht.

Um dies zu verstehen ist zunächst ein kleiner Ausflug in die Theorie des Multiprocessing nötig. 2002 habe ich das Phänomen des Locking bereits einmal erklärt, im Zuge des Doping für CPUs Artikels:
    Multi-Prozessor Kernel von Betriebssystemen müssen grundsätzlich einige zusätzliche Befehle implementieren, die beispielsweise den Arbeitsspeicher vor parallelen Zugriffen schützen, um die Datenkonsistenz zu wahren. Greift ein Mikroprozessor in einem SMP-System auf den Arbeitsspeicher zu, so wird zunächst der Zugriff auf diesen für alle weiteren, vorhandenen Mikroprozessoren gesperrt und dem wartenden Mikroprozessor der exklusive Zugriff gewährt. Anschließend muss der Arbeitsspeicher wieder für alle Prozessoren freigegeben werden.
    Das Problem an diesem Prozedere ist, dass der dabei entstehende Overhead gigantisch ist. Im schlimmsten Fall kann es vorkommen, dass alle Prozessoren eines SMP-Systems sich für die Dauer des Speichersperrvorgangs im Stillstand befinden. Im Normalfall betrifft dies jedoch lediglich den auf den Arbeitsspeicher zugreifenden Mikroprozessor.
An dieser Situation hat sich seit 2002 nichts grundlegendes geändert, bis auf die Tatsache, dass Multiprozessorsysteme heute die Regel sind, während sie 2002 noch Exotenstatus genossen. Das Locking spielt also heutzutage eine viel wichtigere Rolle als anno dazumal. Und an genau dieser Stelle kommt der L3-Cache ins Spiel und kann auf zweierlei Arten für eine zusätzliche Beschleunigung bei multi-threaded Anwendungen über die reine Existenz des zweiten Kerns hinaus sorgen.

Erstens ist die Wahrscheinlichkeit, dass der andere Kern die Daten bereits abgerufen hat und nun in einer der Cache-Stufen immer noch vorhält höher, je mehr Cache insgesamt verfügbar ist. Natürlich gilt dies auch für die Aussage "je mehr Prozessoren, desto wahrscheinlicher hat ein beliebiger die Daten bereits abgerufen, aber desto wahrscheinlicher hat ein anderer diese auch bereits wieder überschrieben." Benötigt Prozessor 0 Daten, die Prozessor 1 bereits geladen hat, dann können diese aus dem Cache geladen und verwendet werden - die zweite Berechnung läuft um ein vielfaches schneller ab, als die erste. Zweitens kommt hinzu, dass mit steigender Cache-Größe auch die Wahrscheinlichkeit sinkt, dass beide Prozessoren gleichzeitig auf den Speicher zugreifen müssen und einer der beiden aufgrund des oben beschriebenen Lockings Wartezyklen einlegen muss. Denn je größer der Cache, desto wahrscheinlicher hat entweder der andere Prozessorkern, oder die Sprungvorhersage die nötigen Daten bereits geladen. Dieser Effekt tritt vor allem dann verstärkt auf, wenn beide Prozessoren mit quasi identischen Aufgaben beschäftigt sind, wie dies beispielsweise beim Cinebench R10 der Fall ist. Läuft hingegen auf jedem Kern ein separater Thread mit separaten Rechenaufgaben und unterschiedlichen Speicherbereichen der nötigen Daten, dann kann sich diese Situation im Extremfall sogar ins Gegenteil verkehren. Die einzelnen Prozessoren müssen jedes Mal im L3-Cache nachschauen, nur um festzustellen, dass der andere Prozessor die nötigen Daten bereits überschrieben und durch eigene ersetzt hat.

Im Falle eines Dual-Core scheint ein 2MB großer L3-Cache ausreichend, um genau diesen Effekt auszulösen. Ab dem dritten Prozessor kehrt die Situation dann wieder ins Umgekehrte, unser Review des Phenom X3 Prozessor bescheinigt dem Phenom X3 eine Beschleunigung um den Faktor 2,73x. Ein Phenom X4 liegt noch bei einem Faktor von etwa 3,6x. Eine reine Vergrößerung des L3-Caches bringt in den letzten beiden Fällen übrigens nur bedingt Abhilfe, da in dem Fall der umgekehrte zweite Effekt greift und das Gesamtsystem ausbremst: je mehr Prozessoren vorhanden sind, desto wahrscheinlicher ist es, dass einer davon einen Speicherzugriff durchführt und den Speicher dadurch für alle anderen blockiert.

[break=Mit 95W zur Nebenkostenerhöhung]
Ernsthafte Kritik wird sich AMD ob der Verlustleistung gefallen lassen müssen. Alle drei derzeit verfügbaren Kuma-Prozessoren verfügen über eine TDP von 95 Watt. Während ein derart hoher Energiebedarf für Triple- und Quad-Core Prozessoren die Regel darstellt (immerhin liegt die TDP des aktuell schnellsten AMD Quad-Core Prozessors Phenom X4 9950 bei stolzen 140 Watt), ist er für Dual-Core Prozessoren inakzeptabel. Da wir bei unseren Messungen sowohl auf ein anderes Messgerät, als auch auf andere Komponenten (Mainboard, Speicher, Grafikkarte, Netzteil) setzten, sind die Ergebnisse nicht mit denen aus bisherigen Reviews vergleichbar.

Kuma
Idle bei ruhendem Desktop und aktiviertem CnQ; Volllast bei Cinebench xCPU


So genehmigt er sich auch im Leerlauf 15 Watt mehr als ein X2 5200+ mit 65 Watt TDP. Unter Volllast waren es gar über 30 Watt mehr. Unserer Meinung nach in Zeiten, in denen 65 Watt TDP bei Dual-Core eher die Regel denn die Ausnahme sind und selbst 45 Watt Prozessoren in großen Zahlen verfügbar sind, unhaltbar. Und somit dürfte der hohe Energiebedarf auch viele Käufer zurecht abschrecken. Ein Athlon 64 X2 5600+ mit 2x 2,9 GHz und einer TDP von 65 Watt ist nicht nur etwa gleich schnell, wenn nicht schneller, als unser hier getesteter X2 7750, sondern auch günstiger und deutlich energieeffizienter.

Nun stellen sich viele Leser mit Sicherheit die Frage, warum ein in 65nm gefertigter X2 5200+ eine um 30W niedrigere TDP hat, als ein in 65nm gefertigter X2 7750 mit identischer oder gar niedrigerer Taktfrequenz (lasst uns nicht vergessen, dass auch der 2,4 GHz schnelle X2 7450 in der TDP-Klasse 95W einsortiert ist). Der Grund für diese exorbitant hohen Werte ist der Bereich des Prozessors, der nicht direkt CPU-Kern ist, also beispielsweise Speichercontroller, L3-Cache, externe Kommunikationslogik, etc., bei Intel als Uncore-Bereich bekannt. Da dieser beim Kuma und Phenom identisch ist, benötigt er auch die gleiche Menge an Energie. Im Verhältnis Core vs. Uncore bedeutet die Abschaltung zweier Kerne jedoch eine Verschiebung zu Ungunsten des Uncore-Bereichs, so dass dieser deutlich stärker ins Gewicht fällt.

Ich halte es im Übrigen für bedenklich, dass auch ein Phenom X3 eine TDP von 95 Watt aufweist - trotz einem Kern mehr als der X2. Zumindest theoretisch besteht also die Möglichkeit, dass AMD die einzelnen Kerne nicht komplett thermisch deaktivieren kann und diese weiterhin Energie in Wärme umwandeln. Rechnerisch ergäbe sich eine Leistung von 15W pro Kern und etwa 65W für den Uncore-Bereich und das halte ich für äußerst unrealistisch. Die Ingenieure täten also gut daran, dem Kuma (und dem X3 am besten gleich mit) schnellstmöglich etwas Zurückhaltung und Sparsamkeit anzugewöhnen.

[break=Übertaktbarkeit]
Optimistisch gingen wir an die Übertaktbarkeit des Prozessors, denn theoretisch sollten mehr als der Phenom-übliche Durchschnitt von 3,2 GHz möglich sein. Schließlich galt auch schon beim X3: je weniger Kerne übertaktet werden müssen, desto niedriger ist die Wahrscheinlichkeit, dass ein schlechter Kern alle anderen ausbremst. Im Falle unseres X2 hat uns jedoch leider das Mainboard einen Strich durch die Rechnung gemacht. Unser Referenzboard, das Gigabyte GA-MA790FX-DQ6, konnten wir für den Test nicht verwenden, da Gigabyte sich trotz intensiver Bemühung nicht imstande sah, uns für den Test ein funktionierendes Beta-BIOS zur Verfügung zu stellen. Somit mussten wir auf das Asus M3A-H/HDMI ausweichen, welches den Kuma mit dem neuesten BIOS 1102 problemlos erkannte. Einziger Haken: eine manuelle Erhöhung der VCore war leider nicht möglich, da der maximal einstellbare Wert von 1,300V um 0,025V unter dem Standardwert des Prozessors lag. Stellten wir die VCore hingegen auf "Auto", dann lagen komischerweise zwischen 1,408V und 1,424V an. Dabei handelte es sich nicht um das Asus-typische Anheben der Vcore sobald übertaktet wird, sondern um ein anderes Phänomen - selbst bei Standardeinstellungen lag die Vcore deutlich zu hoch.

Kuma


Dank offenem Multiplikator konnten wir den Rechner problemlos mit 3.200 MHz booten. Belasten lies er sich damit jedoch nicht, der Absturz folgte in der Regel nach wenigen Sekunden. Stellte man den Multiplikator jedoch eine halbe Stufe runter, war urplötzlich stabiler Betrieb möglich. Und nachdem das System unsere Stabilitätstests mit 3.100 MHz anstandslos durchlaufen hat, haben wir uns entschlossen, sämtliche Benchmarks auch bei dieser Taktfrequenz durchzuführen und sie unseren interessierten Lesern nicht vorzuenthalten. Diese hohe Taktfrequenz bewältigte der Prozessor übrigens auch bei Standardspannung von 1,325V anstandslos.

[break=Das Testsystem im Überblick]
Folgendes System kam für diesen Test zum Einsatz:
  • Prozessor:
    • AMD Athlon X2 7750 "Kuma"
    • AMD Athlon X2 5200+ "Brisbane"
  • Mainboard: Asus M3A-H/HDMI (BIOS 1102)
  • Arbeitsspeicher: 2x 2 Gbyte OCZ PC2-6400 (5-5-5-15 2T @ DDR2-800, 5-5-5-18 2T @ DDR2-1066)
  • Grafikkarte: Diamond Radeon HD 3850/512
  • Netzteil: Seasonic 650HT Active PFC F3
  • Festplatte: Seagate ST3250410AS (SATA, 7.200 u/min, Betriebssystem)
  • Betriebssystem: Windows XP 64-bit (SP2)
  • Energiemessgerät: PeakTech 9024


Vorwort zu den Benchmarks
Aufgrund der Tatsache, dass es sich hier um keinen vollständigen Test den Richtlinien unserer Mainboardreviews entsprechend handelt, sondern diesmal der Prozessor im Fokus unseres Interesses lag, haben wir uns dazu entschlossen, keinen Wert auf Vergleichbarkeit mit bisherigen Ergebnissen zu legen. Zum einen hätte dies die Tests unnötig verkompliziert, zum anderen hätte uns die Tatsache, dass der Prozessor in unserem Referenzmainboard Gigabyte GA-MA790FX-DQ6 nicht erkannt wurde, dieses Vorhaben ohnehin zunichte gemacht.

[break=Everest Memory Benchmark, 7-Zip]
Everest von Lavalys hat sich in letzter Zeit zu einem populären Benchmark entwickelt. Viele nutzen ihn, die Versionsabhängigkeit ist nicht so ausgeprägt wie bei SiSoft Sandra und auch bei uns im Forum lassen sich viele Vergleichswerte finden. Aus diesem Grund nutzen wir den integrierten Memory-Benchmark von Everest, um den Speicherdurchsatz beim Lesen, Schreiben und kopieren, sowie die Speicherlatenz zu messen. Dabei kommt die Programmversion 4.50 mit Build 1.336 zum Einsatz.

Kuma Benchmarks Kuma Benchmarks Kuma Benchmarks


Kuma Benchmarks

Kuma Benchmarks

Kuma Benchmarks

Sehr verwundert hat uns die schlechten Memory Write Ergebnisse des Kuma-Prozessors, die wir nicht gänzlich erklären können. Da der Brisbane diese Symptome nicht zeigte und wir kein zweites Mainboard hatten, dass den Kuma korrekt erkannt und unterstützt hätte, müssen wir eine Erklärung vorerst schuldig bleiben. Es ist jedoch gut möglich, dass die schlechten Werte auf den frühen Status der Kuma-Unterstützung seitens der Mainboardhersteller zurückzuführen sind. Oder aber es handelt sich, ähnlich wie auch schon bei einer älteren Version von SiSoft Sandra, um ein Problem mit dem Benchmark selber. In diesem Fall würde es bedeuten, dass die Software nicht imstande ist, die Möglichkeiten der Hardware voll zu nutzen.

Auf den an dieser Stelle gewohnten Benchmark WinRAR müssen wir leider aufgrund massiver Schwankungen verzichten. So war mal der übertaktete X2 7750 fast doppelt so schnell wie der unübertaktete, im nächsten Durchlauf hingegen wieder langsamer, dafür war der X2 5200+ um ein vielfaches schneller als alle anderen Testkandidaten. Stattdessen setzen wir diesmal auf 7-Zip, welches durchweg konstante Werte zu liefern vermochte.

Kuma Benchmarks

Kuma Benchmarks

Hier bietet sich das erwartete Bild. Der Kuma kann sich in der Pro-Kern-Leistung leicht absetzen, im Multi-CPU Test ist der Abstand noch größer. Den Grund hierfür liegt in der bereits erläuterten zusätzlichen Beschleunigung durch den L3-Cache.

[break=Xmpeg, Avidemux/H.264]
Wenn es um Video-Encoding bzw. -Decoding geht, so gibt es unzählige Variationen und Ausgestaltungen von Software. Viele Programme und noch mehr Codecs lassen dem Enduser die Qual der Wahl. Dabei ist die Nutzung der Ressourcen genauso vielfältig wie die Software selbst: Einige Programme bzw. Codecs können maximal einen Prozessorkern ansprechen, andere wiederum nehmen alles, was sie an Leistung bekommen können - schwer, dabei einen Querschnitt abzubilden.

Wir haben mit der Wahl von XMPEG in Verbindung mit dem XviD-Codec sowie Avidemux in Verbindung mit dem H.264-Codec versucht, diesen Querschnitt abzubilden. Während XMPEG mit dem aktuellen XviD-Codec kaum mehr als einen Prozessorkern beansprucht, nutzt Avidemux dank H.264-Codec jede zur Verfügung stehende Ressource. In beiden Fällen wandeln wir je ein Referenz-Video um und messen dabei die benötigte Zeit.

Benchmarks Kuma

Benchmarks Kuma

Und auch hier kann sich der Kuma in beiden Disziplinen deutlich vom Brisbane absetzen. Während Xmpeg (Xvid) nicht vom schnelleren Speicher profitiert, macht dies bei Avidemux immerhin vier Sekunden aus. Prozentual betrachtet sind die Zuwächse unter anderem auch aufgrund der kurzen Gesamtlaufzeit beider Tests enorm - 20% Zugewinn im Xmpeg-Benchmark, 15% in Avidemux. Die Videoencodierung scheint sehr stark vom L3-Cache und der schnelleren SSE-Einheit zu profitieren, denn SSE4a-Optimierungen, die lediglich dem Kuma und nicht dem Brisbane zugute gekommen wären, kamen nicht zum Einsatz.

[break=Povray, Cinebench R10 (x CPU)]
Der Punkt Rendering darf in so einem Test natürlich auch nicht fehlen. Für diesen Bereich nutzen wir 2 Programme, die unterschiedliche Anwendungsgebiete haben. Auf der einen Seite kommt POV-Ray zum Einsatz. Dabei handelt es sich um ein Raytracer-Programm, welches im Benchmark-Modus eine vorgefertigte 3D-Szene berechnet. Gemessen wird die dafür benötigte Zeit. Auf der anderen Seite nutzen wir das bekannte Renderprogramm Cinebench in der aktuellen Version R10. Cinebench basiert auf der Cinema 4D-Software von Maxon und liegt in einer 64 Bit-Version vor, welche wir natürlich nutzen. Wir lassen den Benchmark hintereinander erst auf einem Prozessorkern und dann auf allen Kernen laufen und notieren die jeweiligen Ergebnisse. Die Ergebnisse des Testlaufs auf einem Prozessor befinden sich auf der nächsten Seite.

Benchmarks Kuma

Benchmarks Kuma

Im Rendering erwarten uns keine Überraschungen. Der Prozessor profitiert auch hier enorm von seinem L3-Cache und den SSE-Optimierungen, jedoch gar nicht vom schnelleren Arbeitsspeicher: Sechs Sekunden im Povray-Benchmark und über 1.000 Punkte bei Cinebench R10 (x CPU) sprechen eine deutliche Sprache. Die erneute Takterhöhung auf 3.100 MHz ist noch mal deutlich sichtbar.

[break=SuperPi, Cinebench R10 (1 CPU)]
Der Cinebench R10 (1 CPU) Benchmark läuft im Gegensatz zum (x CPU) Benchmark auf nur einem Kern und eignet sich somit sehr gut, um sowohl die pro-Kern-Leistung eines Prozessors, als auch die mögliche Beschleunigung durch Einsatz des zweiten Kerns zu testen.

Benchmarks Kuma

Der Kuma profitiert von seinem L3-Cache, kann sich vom Brisbane jedoch nur knapp absetzen. Erst im (x CPU) Benchmark steigt der Abstand massiv an - ein Umstand, den wir simultanen Speicherzugriffen der beiden rechnenden CPUs zu verdanken haben (siehe Seite 5 - Fluch oder Segen?).

SuperPi, ein äußerst beliebter single-threaded Benchmark, eignet sich hervorragend, um den Umgang mit älterem Code zu testen. Das Programm aus dem Jahr 1995 berechnet die Zahl Pi bis zur angegebenen Zahl an Stellen, für unseren Benchmark berechneten wir die erste Million Nachkommastellen.

Benchmarks Kuma

Die knapp 34 Sekunden des Brisbane unterbietet der Kuma knapp, die Übertaktung wirkt sich wie erwartet sehr stark auf das Ergebnis aus. Vom L3-Cache profitiert der Kuma hingegen gar nicht - die Routine ist offenbar klein genug, um komplett in den L1- und L2-Cache des rechnenden Kerns zu passen.

[break=Fazit]
Als ich den Kuma überraschenderweise Ende November in die Hand gedrückt bekam, war ich zugegebenermaßen zunächst etwas ratlos. Ein Prozessortest auf Planet 3DNow!, da können wir ja eigentlich fast nur verlieren. Schneidet der Prozessor gut ab, dann heißt es gleich "klar doch, ist ja eine AMD-nahe Seite". Schneidet der Prozessor schlecht ab, dann pendeln die Vorwürfe zwischen "ihr seid doch alle gekauft" und "ihr hab keine Ahnung" (was auch übrigens der Hauptgrund dafür ist, dass wir sehr lange Zeit kein Intel-Vergleichssystem hatten). Nichtsdestotrotz entschieden wir uns nach kurzer interner Beratung zumindest für einen Kurztest, ähnlich dem letzten Aufbäumen des K8-Kerns.

Zwölf Seiten später sind wir nun alle deutlich schlauer - ich weiß, dass ich einen Kurztest einer CPU, die noch dazu eine neue Architektur (ok, relativ neu... zumindest als Dual-Core) darstellt, nicht durchführen kann, ohne mich in tiefgründiger Theorie zu verhaspeln. Vor allem dann, wenn sich aufgrund der geänderten Zusammenstellung aus Cache-Stufen, Speichercontroller und Anzahl der Kerne architekturbedingte Besonderheiten ergeben, die nicht unerwähnt bleiben sollten. Und Ihr wisst, dass der Kuma Licht und Schatten in sich vereint. Aus dem ursprünglich mit zwei Tagen Arbeit angesetzten Kurztest mit vielleicht zwei, drei Benchmarks ist eine ausführliche Architekturanalyse geworden und auf eine mir unerklärliche Art und Weise hat sich auch die Anzahl der Benchmarks vervielfacht. Den Aspekt "zwei Tage Arbeit" lasse ich lieber ganz außen vor, denn dass diese Einschätzung trotz aller Erfahrung äußerst naiv war, das gehört nicht zu den Dingen, die ich erst durch diesen Test gelernt habe.

The Good:
Das hat uns gefallen
  • Performance durchweg höher als beim K8
  • L3-Cache beschleunigt insbesondere Anwendungen mit mehreren gleichlaufenden Threads
  • Gutes Undervolting-Potenzial - 3,1 GHz waren auch mit auf 1,300V reduzierter Kernspannung problemlos prime-stable möglich

The Bad:
Das hat uns weniger gefallen
  • Unterstützung bisher noch von keinem Mainboard-Hersteller offiziell angekündigt
  • Trotz nur zweier Kerne deckelt der Prozessor wie für den K10 üblich bei etwa 3.100 MHz
  • Obwohl mit dem Phenom II ein neues dreistelliges Ratingmuster eingeführt wird (ein Schelm, wer bei der Ähnlichkeit zwischen Core i7 und Phenom II Namen was Böses denkt...), das auch für zukünftige Triple-Core und Dual-Core Phenom II basierte Prozessoren gelten soll, bleibt AMD bei den Athlon-Prozessoren weiterhin auf Kurs des großen Konfuzius Totalus. So gibt es den X2 nun in fünf verschiedenen Geschmacksrichtungen: als BE-2000, als 4000e/5000e, als mysteriöse 6000-Serie, als neue 7000-Serie und nicht zuletzt mit dem allseits bekannten Plus-Ratings als 4x00+/5x00+/6x00+. Welches Schweinderl hätten's denn gern?

The Ugly:
Das hat uns sehr gestört
  • 95W TDP sind im Jahr 2009 für einen Dual-Core nicht zeitgemäß.
  • Der zumindest zu Beginn überzogen hohe Preis - seinen Exotenstatus lässt sich der K10 gut bezahlen
  • Ein Jahr zu spät - der richtige Zeitpunkt für die Einführung wäre vor einem Jahr gewesen und nicht weniger als einen Monat vor Einführung des Quad-Core Nachfolgers. Setzen, Sechs.


...weitere Artikel
...diesen Artikel im Forum diskutieren