Zum 3DCenter Forum
Inhalt




Speicher-Skalierung auf dem Athlon 64 X2 (AM2)

1. November 2006 / von Madkiller (Benchmarks) & Leonidas (Text) / Seite 1 von 4


   Einleitung

Als AMD am 23. Mai diesen Jahres die Sockel-AM2-Architektur einführte, wurde weniger ein Update der AMD-Prozessoren vorgenommen, als vielmehr ein Update der die AMD-Prozessoren unterstützenden Plattform. Der hauptsächlichste Unterschied zwischen den Prozessoren der Sockel AM2 und 754/939 liegt schließlich weniger in der bei letzteren vorhandenen Technologien Pacifica (Virtualisierung) und Presidio ("Sicherheitslösung"), sondern vielmehr im veränderten Speichercontroller der Sockel-AM2-Modelle: Während dis bisherigen K8-basierenden Prozessoren noch mit DDR1 arbeiten, ist der Speichercontroller der AM2-basierenden Prozessoren nunmehr in der Lage, DDR2-Speicher anzusteuern.

Mit DDR2-Speicher wurden in erster Linie deutlich höhere Taktfrequenzen auch im offiziellen Betrieb möglich, während bei DDR1-Speicher zwar die Overclocking-Gemeinde oftmals mit recht hohen Speichertaktraten operierte, der normale OEM-PC allerdings aufgrund der Standardisierungs-Politik des Speicherstandisierungs-Gremiums JEDEC auf DDR1/400 und damit einem Speichertakt von (physikalisch) 200 MHz festsaß. Mittels des DDR2-Speichercontrollers der AM2-basierenden Prozessoren konnte diese Grenze eindrucksvoll durchbrochen werden, inzwischen sind sogar deutlich höhere Speichertaktungen als "nur" DDR2/800 im Markt erhältlich und über die AM2-basierenden Prozessoren ansteuerbar.

Damit darf natürlich erneut die Frage nach der Speicherskalierung auf den neuen AM2-basierenden Prozessoren gestellt werden - ganz besonders, da es bei DDR2-Speicher derzeit eine breite Spanne an verschiedenen Taktungen gibt, genauso wie diese Speicher auch mit höchst unterschiedlichen Speicher-Timings ausgeliefert werden. Das Ziel dieses Artikels liegt somit darin, zu ermitteln, wie (gleichgetaktete) AM2-basierenden AMD-Prozessoren auf unterschiedliche DDR2-Speicher unter Spielen reagieren - sowohl bezüglich der Taktraten als auch der Speichertimings.

Hierzu wurden wie schon im letzten Prozessoren-Vergleich verschiedene Messungen unter zweifellos CPU-limitierten Settings vorgenommen (Auflösung 800x600, kein AA und kein AF), um allein den Ausschlag zu messen, welche die CPU in Zusammenspiel mit dem Speicher zu leisten im Stande ist. Genauso zweifellos nicht wurde damit die Performance unter realen Einsatzbedingungen vermessen - dies ist ein theoretischer Vergleich über die Leistungsfähigkeit von verschiedenen Speicherkonstellationen, kein Test der absoluten Praxis.

Dieser Artikel setzt sich damit natürlich derselben Kritik aus, welche schon der zitierte vorhergehende Artikel "Intel Core 2 Duo vs. AMD Athlon 64 X2" abbekam: Die erzeugten Zahlen entsprechen nicht der (vermeintlichen) Realität in Spielen, wo die Performance-Unterschiede zwischen den Prozessoren (und für diesen Artikel die Performance-Unterschiede zwischen den Speicherkonstellationen) durch häufig vorkommende Grafikkarten-Limitierungen (vermeintlich) deutlich geringer ausfallen als von uns ausgemessen. Unserer Meinung nach liegt in der Forderung nach realitätsgebundenen Benchmarks bei CPUs allerdings ein genereller Irrtum vor, welchen wir - da er für diesen Artikel genauso zutrifft - hiermit näher erläutern wollen:

 

Wenn man bisher (auch wir!) für Prozessoren-Vergleiche aus Gründen der Realitätsnähe unter Spielen auch zu realitätsnahen Bildqualitätssettings griff, sprich üblichen hohen Auflösungen samt dem Einsatz des anisotropen Filters und Anti-Aliasing, so ging man hierbei davon aus, daß die geringen beim Test von Timedemos noch entstehenden Unterschiede zwischen den einzelnen getesteten CPUs schlicht an der bei den gewählten Bildqualitätssettings langsam einsetzenden Grafikkarten-Limitierung liegen. Und wenn sich in den Timedemo-Tests dann gar keine Unterschiede mehr zwischen verschiedenen CPUs einstellen wollten, war dies schließlich auch eine Aussage: Vollkommen Grafkkarten-limitiert, keine schnellere CPU nötig.

Mittels der Arbeit an den drei Artikeln "Average fps - wirklich das Maß aller Dinge?", "Timedemos - Das Maß aller Dinge?" und "Timedemos - Das Maß aller Dinge? Part 2" können wir hierzu jedoch eine Reihe neuer Erkenntnisse in den Ring werfen, welche diese früheren Benchmark-Maßgebungen deutlichst hinterfragen. Als erstes steht dabei die simple Erkenntnis im Raum, daß Timedemos insbesondere für CPU-Vergleiche denkbar ungeeignet sind, da mit diesen in aller Regel wichtige CPU-gebundene Berechnungen nicht ausgeführt, welche aber im realen Gamer-Alltag zweifellos eine Rolle spielen. Konkret führen die allermeisten Timedemos keine Berechnungen zur K.I., dynamischen Physik und anderen dynamischen Effekten aus, da Timedemos nur starre Aufzeichnungen eines bereits abgelaufenen Spielgeschehens darstellen und demzufolge diese Berechnungen bereits bei der Aufnahme des Timedemos abgelaufen sind.

Für die Performance-Ermittlung von Grafikkarten mag dies womöglich (in Standardfällen) noch tragbar sein, bei der Performance-Ermittlung von CPUs passt es dann allerdings überhaupt nicht mehr: Durch die fehlenden CPU-Berechnungen bei einem Timedemo kann das ganze Ergebnis verfälscht sein, im einfachsten Fall tritt aber zumindestens die CPU-Limitierung (möglicherweise deutlich) früher ein als im Gamer-Alltag. Konkret kann also durchaus der Fall eintreten, daß ein bestimmtes Timedemo unter hohen Bildqualitätssettings keinerlei Unterschiede zwischen verschiedenen CPUs zeigt, die selbe Sequenz im realen Spieleralltag aber durchaus auf diese verschiedenen CPUs reagiert - weil es im realen Spieleralltag schlicht mehr für die CPU zu berechnen gibt als bei einem Timedemo-Durchlauf derselben Szene.

Der zweite wichtige Grund gegen Timedemos bei CPU-Vergleichen liegt darin begründet, was Timedemos im eigentlichen sind: Eine Aneinanderreihungen von mehreren Sequenzen, welche für sich selber entweder CPU- oder Grafikkarten-limitiert sind. Gerade wenn ein Timedemo bei einem CPU-Vergleich unter hohen Bildqualitätssettings dann doch noch die eine oder andere Differenz zeigt, ist man geneigt, dieser Differenz zu glauben und die getesteten CPUs entsprechend zu bewerten. Dabei basiert die Höhe der ermittelten Differenz jedoch maßgeblich auf einem Zufall: Und zwar, wie viele CPU-limitierte Sequenzen das benutzte Timedemo zufälligerweise hat: Sind es deren viele, erscheint das gesamte Timedemo als mehr CPU-limitiert, umgedreht mehr Grafikkarten-limitiert.

Hier kommt dann noch erschwerend hinzu, daß die meisten Timedemos eher für Grafikkarten-Messungen aufgenommen wurden und werden. Die Anzahl der CPU-limitierten Sequenzen in diesen Timedemos ist dann wirklich klarer Zufall - und wenn, dann werden diese gar eher denn vermieden. Um diesen Zufall ausgleichen zu können, müsste man schon mit einer gewissen Anzahl an Timedemos aus unterschiedlichen Leveln des jeweiligen Spiels operieren. Dies macht aber kaum jemand und somit ist es bei Timedemo-Vergleichen wirklich dem Zufall überlassen, wann die CPU-Limitierung aufhört. Ein wirkliches Ausmessen des jeweiligen Spiels und dessen vorhandener Charakteristik bezüglich Grafikkarten- und CPU-Limitierung ist dies natürlich nicht.

Als Alternative zu Messungen mit Timedemos bieten sich wie gesagt Messungen mit Savegames an. Diese haben die vorbeschriebenen zwei Nachteile nicht mehr: Zum einen werden bei einem Savegame generell alle im Gamer-Alltag anzutreffenden Berechnungen ebenfalls ausgeführt und zum anderen entfällt der Punkt, daß ein Savegame eine Ansammlung unterschiedlicher Sequenzen ist, die konkrete CPU-Abhängigkeit also maßgeblich durch Zufall definiert wird. Daraus ergibt sich jedoch auch ein weiterer Punkt, welcher gegen CPU-Benchmarks unter zwingend realitätsnahen Bedingungen spricht: Savegames sind gewöhnlich zu kurz, um mehrere Sequenzen zeigen zu können und damit eine Abfolge von CPU- und Grafikkarten-limitierten Frames. Savegames sind in den allermeisten Fällen entweder CPU- oder Grafikkarten-limitiert, einen "Durchschnitts-Run" (wie noch bei Timedemos möglich) gibt es hier zumeist nicht.

Dies zwingt den CPU-Tester, welcher Savegames für Spiele-Tests verwenden will, jedoch automatisch zu einer Entscheidung: Will er wirklich die CPU ausmessen, hat er nur die Wahl, sich entsprechende CPU-limitierende Settings herauszusuchen. Einen Mittelweg wie noch bei Timedemos völlig normal, ist bei Savegames eher selten zu finden. Die Alternative wäre dann nur noch, alles unter realitätsnahen hohen Bildqualitätssettings zu vermessen und darauf zu hoffen, daß das eine oder andere dabei verwendete Savegame hier trotzdem noch reagiert. Dabei entsteht aber in jedem Fall ein hoher Schnitt an unbrauchbarer Arbeit - viele Messungen werden Grafikkarten-limitiert enden und haben damit dann nur Zeit gekostet, führen jedoch zu keinerlei Ergebnissen für den CPU-Test.

Verhindern kann man dies nur, wenn man bewußt CPU-limitierte Settings für seine Vergleiche wählt. Dann hat man natürlich wirklich nur die CPU am Werken und bekommt keine Informationen über die im realen Spielealltag im Schnitt zu erwartende Performance. Daß ein CPU-Vergleich eine solche Betrachtung für eher Grafikkarten-limitierte Spiele allerdings überhaupt liefern muß, kann man durchaus für einen gewissen Gedankenfehler halten: Denn dies würde davon ausgehen, daß die CPU auch unter diesen Spielen ein entscheidendes Element bei der Spieleperformance ist - was jedoch nicht zutrifft, dies ist der Job der Grafikkarten. Die CPU wird vielmehr (bis auf gänzlich CPU-limitierte Spiele) zumeist nur in einigen Extrem-Situationen gefordert: Wenn größere Level-Teile nachgeladen werden müssen, wenn besonders viele Gegner oder Objekte zu sehen sind und ähnliches.

Diese wenigen extrem CPU-limitierten Szenen sind zum einen nicht typisch für das komplette Spiel, insofern kann man mit einem Benchmark (ob Timedemo oder Savegame), welcher möglichst den Normalzustand des Spiels oder aber einen längeren Ablauf im Spiel darstellen will, diese extrem CPU-limitierten Szenen auch niemals zufriedenstellend abbilden. Zum anderen aber stellen diese extrem CPU-limitierten Szenen in den allermeisten Fällen auch diese Szenen im Spiel mit den absolut niedrigsten Frameraten dar. Somit gibt es gleich zweierlei Anlaß, speziell nur diese extrem CPU-limitierten Szenen auszumessen: Erstens sind es sowieso die einzigen Szenen, wo eine konsequente CPU-Limitierung vorherrscht, und zum anderen enthält das Messergebnis dann einen praktischen Nutzen für den Endanwender, welcher mit diesem bewußt gegen CPU-basierte Slowdowns in Spielen vorgehen kann.

Gerade aus dieser Erkenntnis heraus, daß die CPU in aller Regel für die langsamsten Szenen in einem Spiel verantwortlich ist, ansonsten unter entsprechend hohen Bildqualitätssettings zumeist recht wenig (bis gar nichts) zur Performance-Steigerung beitragen kann, zwingt unserer Meinung nach generell zu Messungen in klar CPU-limitieren Umfeld. Ob es dabei unbedingt Messungen unter 800x600 und ohne AA/AF sein müssen, wie derzeit von uns praktiziert, ist sicherlich streitbar - möglicherweise sind die benutzten Savegame-Sequenzen selbst unter höheren Auflösungen noch CPU-limitiert. Klar ist aber, daß das Ziel von Performance-Vergleichen von CPUs unter Spielen immer in den Extremen liegen sollte, nicht (wie bei Grafikkarten) im Normalen.

Anzumerken wäre hier noch ein spezieller Effekt von bewußt CPU-limitiert ausgeführten Benchmarks, welcher auch die Kritik an den Messungen unter 800x600 zusätzlich entkräftet: Zwar stellen die dort gewonnenen fps-Zahlen zweifellos keine Durchschnitts-Werte dar, die konkret ausgemessene Szene wird jedoch, wenn sie unter der jeweils vorhandenen Hardware auch unter höheren Auflösungen noch CPU-limitiert ist, prinzipiell die gleichen fps-Werte auswerfen. Dies hängt damit zusammen, daß CPU-Limitierungen nicht mit steigender Auflösung höhere oder niedriger Anforderungen an die Hardware stellen, sondern Auflösungs-unabhängig immer dieselben. Ein unter 800x600 ohne AA/AF ausgemessener CPU-limitierter fps-Wert wird also durch alle höheren Auflösungen und Bildqualitätssettings hindurch identisch bleiben, so lange bis irgendwann mit steigenden Settings die CPU-Limitierung von einer Grafikkarten-Limitierung verdrängt wird.

 

Nachdem dies geklärt ist, wollen wir noch kurz ein Blick auf das Testsystem werfen, welches grob folgende Hardware umfaßt:

  • AMD Athlon 64 X2 4600+ (Windsor-Core, 2.4 GHz)
  • Abit KN9 SLI (nVidia nForce 570 SLI)
  • 2x 1 GB OCZ "Platinum XTC Revision 2" DDR2/800 (Ratings: 4-4-4-15 @ DDR2/800)
  • Creative Audigy2 (Sound-Details waren auf Maximum mit EAX 5.1)
  • Sapphire Radeon X1900 XT 512MB auf 625/725 MHz, Catalyst 6.9 (A.I. low)
  • Microsoft Windows XP Home, Service Pack 2 (inklusive DirectX 9.0c)
  • Benchmark-Settings: 800x600 auf maximalen Details ohne Anti-Aliasing und anisotropen Filter

Das genaue Testsystem kann auch hier nachgeschlagen werden, es ist zum vorhergehenden Prozessoren-Vergleich identisch. Ebenfalls aus diesem Vergleich entstammen die für unsere Messungen benutzten Savegames aus den Spielen Age of Empires III, Half-Life 2: Episode 1, The Elder Scrolls IV: Oblivion und Titan Quest. Wieder hinzugekommen ist zudem der Actionkracher F.E.A.R., nachdem unsere neuen Testsysteme mit nunmehr 2 GB Speicher das Spiel endlich ohne (Benchmarks weitgehend unbrauchbar machende) Nachladeruckler darstellen können ;).

Den vorgenannten OCZ-Speicher haben wir dabei auf folgenden unterschiedlichen Settings getestet:

  • 2000 MHz CPU-Takt, 5er RAM-Teiler = 400 MHz Speichertakt (DDR2/800) @ 5-5-5-15-2T
  • 2600 MHz CPU-Takt, 9er RAM-Teiler = 289 MHz Speichertakt (DDR2/578) @ 5-5-5-15-2T
  • 2600 MHz CPU-Takt, 8er RAM-Teiler = 325 MHz Speichertakt (DDR2/650) @ 5-5-5-15-2T
  • 2600 MHz CPU-Takt, 8er RAM-Teiler = 325 MHz Speichertakt (DDR2/650) @ 5-5-5-15-1T
  • 2600 MHz CPU-Takt, 8er RAM-Teiler = 325 MHz Speichertakt (DDR2/650) @ 4-4-4-12-1T
  • 2600 MHz CPU-Takt, 8er RAM-Teiler = 325 MHz Speichertakt (DDR2/650) @ 3-3-3-9-1T
  • 2600 MHz CPU-Takt, 7er RAM-Teiler = 371 MHz Speichertakt (DDR2/742) @ 5-5-5-15-2T
  • 2600 MHz CPU-Takt, 6er RAM-Teiler = 433 MHz Speichertakt (DDR2/866) @ 5-5-5-15-2T
  • 2600 MHz CPU-Takt, 5er RAM-Teiler = 520 MHz Speichertakt (DDR2/1040) @ 5-5-5-15-2T

Wie zu sehen, treffen die wenigstens der angesetzten Speichertakte die Ideale der verschiedenen am Markt erhältlichen Speichertaktungen (DDR2/533, DDR2/667, DDR2/800 usw). Dies hängt allerdings damit zusammen, wie aktuelle AMD-Prozessoren den Speichertakt bilden: Der Speichertakt wird aus einer Division des CPU-Taktes durch einen ganzzahligen RAM-Teiler erzeugt, womit in den seltensten Fällen der maximal mögliche Speichertakt laut der Spezifikation des jeweils verwendeten Speichermoduls ausgenutzt wird. Insofern entsprechen die verwendeten "krummen" Speichertakte vollkommen der anzutreffenden Realität bei AM2-basierenden PC-Systemen.

Vorab sei an dieser Stelle noch der Firma Sapphire für die unkomplizierte Stellung von Testsamples für unsere neuen Teststationen gedankt.






Kommentare, Meinungen, Kritiken können ins Forum geschrieben werden - Registrierung ist nicht notwendig Weiter / Next

Shortcuts
nach oben