V
VikingGe
Guest
Phenom II - Was NB- und Kern-OC tatsächlich bringt: Benchmarks
Moin. Ich weiß nicht, ob ich damit im OC-Forum oder im Prozessoren-Forum vielleicht besser aufgehoben wäre, aber ich probiere es einfach mal hier.
Dass die Phenom II als Spiele-Prozessoren ihre besten Zeiten hinter sich haben, ist wohl kein Geheimnis. Auch, dass bei denen Übertakten der CPU/NB wohl irgendwie was bringt, hat sich herumgesprochen - so wirklich tolle Zahlen dazu findet man allerdings nur recht verstreut. Deswegen gibt es jetzt von mir mal einen Haufen Benchmarks. Dabei geht es konkret um zwei Fragen: Bringt das Übertakten überhaupt spärbare Vorteile oder ist die Architektur mittlerweile einfach zu schwach? Und stimmt die Behauptung, dass CPU/NB-OC mehr bringt als das Anheben des Kerntakts und hauptsächlich den Min-FPS hilft?
Um welche CPU geht es konkret?
Natürlich um mein Baby, einen 1090T von eher mäßiger Chipgüte:
Das Ding habe ich in vier verschiedenen Konfigurationen durch diverse Benchmarks gejagt:
- Kerntakt: 3.7 GHz - CPU/NB: 3.0 GHz - RAM: 1600 MHz CL9 (Alltags-OC)
- Kerntakt: 3.7 GHz - CPU/NB: 2.0 GHz - RAM: 1333 MHz CL7
- Kerntakt: 3.2 GHz - CPU/NB: 3.0 GHz - RAM: 1600 MHz CL9
- Kerntakt: 3.2 GHz - CPU/NB: 2.0 GHz - RAM: 1333 MHz CL7 (Standardtakt)
Falls sich jetzt irgendjemand fragt, warum der RAM bei 2.0 GHz CPU/NB nur auf 1333 MHz läuft: Ganz einfach, es ist schneller so. Man muss den Speichercontroller schon gewaltig übertakten, damit die 1600 MHz mit schwächeren Timings irgendwelche Vorteile bieten. Es gibt nicht ganz umsonst die Faustregel, den CPU/NB-Takt mindestens 3x so hoch einzustellen wie den realen RAM-Takt - bei 1600 MHz RAM-Takt wären das also 2.4 GHz.
Erläuterungen zu den Diagrammen
Am Ende der Diagramme befindet sich jeweils eine Tabelle mit wilden Prozentzahlen, die in drei Spalten angeordnet sind:
- stock: Relative Leistung zur Konfiguration mit Standardtakt.
- core: Relative Leistung nur durch Erhöhen des Kerntakts - also: Was bringen 3.7 GHz gegenüber 3.2 GHz bei festem CPU/NB-Takt?
- nb: Relative Leistung nur durch Erhöhen des CPU/NB-Takts
Theoretische Werte
Beginnen wir mal mit etwas Langweiligem: Bandbreitenwerten zu L3-Cache und RAM. Das sind genau die beiden Dinge, die am CPU/NB-Takt hängen - und auch die Dinge, in denen AMDs Architekturen einfach nicht gut sind. Hierbei wurde jeweils die Bandbreite mit einem einzelnen Thread und sechs Threads getestet.
Beim L3 werden die 50% quasi 1:1 in Bandbreite beim Lesen und Schreiben umgesetzt, im Single Thread-Modus immer noch über 40%. Das sollte für Spiele, die vom L3 traditionell durchaus profitieren können, doch schonmal nicht schlecht sein. Oder?
Die RAM-Werte sind ebenfalls eindeutig. Beim Lesen mit mehreren Threads limitiert mit übertakteter NB tatsächlich erstmals der RAM - dass nicht die vollen 25.6 GB/s erreicht werden, liegt wohl an zu kleinen TLBs, bei kleineren Blockgrößen und Non-Temporal Prefetching ist auch das kein Problem. Aber insgesamt wird auch das Streamen von Daten in den und aus dem RAM um ca. 40 bis 50% beschleunigt.
Hier zeigt sich allerdings auch, dass der Speichercontroller erst dann wirklich in die Gänge kommt, wenn mit vielen Threads gearbeitet wird. Mit einem einzelnen Thread ist gerade lesend aus dem RAM nicht viel zu reißen - ein Grund, warum Single Thread-Spiele extrem schlecht laufen werden, aber auch stark profitieren können.
Anwendungs- und theoretische Benchmarks
Zunächst ein paar Benchmarks von Alltagsanwendungen und eben dem Standardzeug, das man so verwendet, um zu zeigen, dass man denLängsten Schnellsten hat. Diese wurden allesamt unter Linux durchgeführt, einige davon mit selbst compilierten und auf die CPU optimierten Binaries. Muss daher nicht 1:1 auf andere Systeme übertragbar sein.
Cinebench R11.5
Cinebench war noch nie dafür bekannt, von der Speicherleistung abhängig zu sein, und so bewegen sich die Vorteile durch CPU/NB-Übertaktung erwartungsgemäß irgendwo zwischen einem und zwei Prozent - gerade mal ausreichend, um die Punktzahl messbar anzuheben. Dafür wird jedes MHz Kerntakt nahezu 1:1 in mehr Leistung umgesetzt.
bzip2
bzip2 ist in der Linux-Welt neben gzip eigentlich das Format für komprimierte Tar-Archive, leidet aber darunter, dass besonders die Standardimplementierung mit nur einem Thread äußerst langsam ist - da mit pbzip2 aber eine Version mit Multithreading verfügbar ist, wird diese auch eingesetzt.
Und hier wird es erstmals richtig interessant: Allein durch den hohen NB-Takt steigt die Performance um rund 10% beim Komprimieren, beim Entpacken um noch mehr - dadurch kann sich die Konfiguration mit übertaktetem Speichercontroller, aber nur 3.2 GHz Kerntakt vor die mit 3.7 GHz Kerntakt schieben. Und wenn beides übertaktet wird, stehen satte 26% mehr Leistung auf dem Papier - das lohnt sich!
FFmpeg + x264 + Vorbis
Hier wurde ein 4k-Video mitsamt Ton mit x264 und libvorbis transcodiert. Erstaunlicherweise zeigt sich der Prozess relativ unbeeindruckt von der höheren L3- und Speicherbandbreite - dabei wird besonders ersterer ganz ordentlich gefordert.
Trotzdem stehen hier am Ende dem 15% höheren Kerntakt immerhin 17% mehr Leistung gegenüber - nicht schlecht.
Dieser Benchmark hat mich fast in den Wahnsinn getrieben: Erst ließ sich x264 nicht dazu überreden, eine h.264-Rohdatei zu lesen, dann bin ich auf ffmpeg ausgewichen und stand vor dem Problem, dass selbst ein Würfel sinnvollere Ergebnisse für die Encoding-Dauer geliefert hätte. Brauchbare Ergebnisse gab es eigentlich nur direkt nach einem Neustart - weiß der Geier, warum.
MPlayer
Man könnte auf die Idee kommen, Videos abzuspielen, und wenn man da gerade keine Hardware-Beschleunigung zur Hand hat, braucht das mitunter einiges an CPU-Leistung. Verwendet wurde dasselbe Video wie oben zum Transcodieren.
Hier finden sich ähnliche Ergebnisse. Der CPU/NB-Takt hat zwar einen größeren Einfluss als noch beim Codieren, vorher, aber wirklich viel ist das nicht. Probleme bereitet wird das Video der CPU allerdings auch erst bei Taktraten unter 2.0 GHz.
Audio-Encoding
Vielleicht für die meisten Leute etwas relevanter als das Codieren von Videos ist das Codieren von Audio-Dateien, dafür werden hier Lame (MP3) und Flac mit jeweils starker Kompression benutzt. Es wird jeweils nur eine Datei codiert, sodass auch nur ein Kern belastet wird.
Jedes MHz Kerntakt wird zwar gern genommen, alles andere hat aber außerhalb der Messtoleranz kaum einen Einfluss auf die Leistung. Höchstens bei Flac mit 3.7 GHz Kerntakt könnte der NB-Takt einen winzigen Flaschenhals eliminieren - wobei, winzig ist eigentlich falsch, der Flaschenhals ist nicht viel Enger als der Rest der Flasche.
Blender
Mit Cinebench ist zwar streng genommen schon ein Raytracer in der Liste, aber Blender ist irgendwie alltagstauglicher als ein reiner Benchmark - getestet wurde mit einer leicht modifizierten Version dieser Szene. Unter anderem musste das Texture Mapping angepasst werden, weil sich die Interpretation der Koordinatenskalierung in Blender zwischenzeitlich geändert hat.
Performancetechnisch ist Blender so ein Grenzfall. Solange man am Kerntakt nichts macht, bringt auch der NB-Takt praktisch nichts - der höhere Kerntakt allein reißt allerdings auch keine Bäume aus. Erst, wenn beides übertaktet wird, gibt es einen deutlichen Schub, sodass die gesamte Szene nun in 96 Sekunden gerendert wird.
Compiler
Für Programmierer neben dem Texteditor sicherlich das wichtigste Werkzeug überhapt. In diesem Test dürfen sich zwei Compiler an Amarok 2.8.0 versuchen:
Vorweg: Clang ist ohne Zweifel der schnellere Compiler. Besonders, wenn man C++-Code mit vielen Templates und vielen Inline-Funktionen compiliert, kann er dem GCC um Faktor 2-3 davon laufen - für Test-Builds um einiges angenehmer als jedes Mal auf GCC zu warten.
Beide Compiler profitieren angenehm stark von mehr Takt - hauptsächlich vom Kerntakt, aber doch auch genug vom NB-Takt, um bei kombinierter Übertaktung um jeweils rund 20% zuzulegen. Absolut gesehen ist Clang damit 20 Sekunden eher fertig als bei Standardtakt, GCC sogar 25 Sekunden - das sind spürbare Unterschiede.
Spiele-Benchmarks
Das soll es mit Anwendungen jetzt auch gewesen sein. Die Ergebnisse waren allesamt irgendwo zwischen "ganz ordentlich" und "ernüchternd" - im Allgemeinen hat der CPU/NB-Takt nur einen mäßigen Einfluss auf die Anwendungsleistung, dafür schlägt in der Regel der Kerntakt voll durch. Schauen wir uns also mal einige Spiele an.
Als Grafikkarte dient meine GTX 670, die - außer in Valley, weil ich Valley unter Linux getestet habe - um 120 MHz übertaktet wurde und somit real zwischen 1175 und 1201 MHz läuft. Außerdem wurde der Speicher von 1500 auf 1750 MHz übertaktet.
Hinweis: Die jeweils verwendeten Benchmark-Szenen sind in den Diagrammen auf den Bildern beschrieben.
Unigine Valley
Technisch gesehen kein Spiel, könnte der Unigine-Benchmark schon zeigen, wohin die Reise geht. Hier sieht es nämlich auf einmal komplett anders aus: Im 720p-Lauf führen die beiden Konfigurationen mit erhöhtem NB-Takt und am Ende stehen beim kombinierten OC satte 23% mehr Leistung auf dem Papier. Einzig die minimalen FPS profitieren deutlich stärker vom Kerntakt. Wobei die in diesem Benchmark ohnehin mit Vorsicht zu genießen sind - erreicht werden sie ausschließlich zwischen den Szenen, und da ist der ganze Bildschirm schwarz.
In 1080p liegen die Konfigurationen alle sehr dicht beieinander - Grafiklimit lässt grüßen.
Das 720p-Ergebnis stützt allerdings schon die These, dass der NB-Takt in Spielen mehr bringen könnte als der Kerntakt - sind die 3.2/3.0 GHz am Ende wirklich stärker als die 3.7/2.0 GHz?
The Witcher 2
Beim Hexer gibt es für die 3.2/3.0-Konfiguration gleich einmal eine Klatsche, und zwar eine gewaltige. Sie verliert in 720p über 20% gegenüber Standardtaktraten - ein merkwürdiges, aber reproduzierbares Verhalten, das ich mir ehrlich gesagt nicht so richtig erklären kann.
Allerdings kann man damit auch die Kerntakt-Skalierung erklären. Denn allein die 500 MHz Kerntakt bringen schon 20% mehr Leistung - das ist mehr, als man bei dem Taktunterschied erwarten würde. Anscheinend mag es das Spiel nicht wirklich, wenn NB- und Kerntakt zu dicht beieinander liegen. Die 3.7/3.0-Konfiguration liegt allerdings mit einem Vorsprung von 31% gegenüber dem Standardtakt deutlich vorne.
In 1080p ergibt sich ein ähnliches Bild, nur, dass hier mit 3.7 GHz bereits das Grafiklimit erreicht ist und dort unabhängig vom NB-Takt praktisch absolut identische Frameraten erreicht werden. Mit 28 FPS ist hier die Framerate zwar auf einem niedrigen, aber immer noch gut erträglichen Niveau, was man von den 24 FPS, die mit Standardtakt erreicht werden, schon nicht mehr behaupten kann.
Thief
Und hier sehen wir einfach mal das komplette Gegenteil von dem, was Witcher 2 uns gezeigt hat. Nicht nur, dass die beiden Konfigurationen ohne NB-Takt-Erhöhung wirklich deklassiert werden - beide Male ein 20%iger Schub allein durch den hohen NB-Takt! - da das CPU-Limit an zwei Stellen des Benchmarks besonders heftig ist, macht sich das selbst in 1080p bemerkbar. Hier liegen die Ergebnisse zwar auch relativ dicht beieinander - die meiste Zeit über ist es eben doch die Grafikkarte, die da bremst - allerdings legen die minimalen FPS immer noch um knapp 30% und damit spürbar zu. Das hilft dann auch der Durchschnittsframerate auf die Sprünge.
Assassin's Creed 3
Dieses Spiel bietet nicht einmal eine Option, die Auflösung zu ändern, allerdings kommt das Spiel ohnehin nicht einmal in die Nähe eines Grafiklimits - deswegen habe ich auf 720p-Fummeleien in der Ini-Datei verzichtet und liefere nur 1080p-Werte.
Hier sieht es zunächst ähnlich aus wie beim Witcher, die 3.2/3.0 GHz-Konfiguration verliert klar - wenn auch bei weitem nicht so dramatisch. Die Kerntaktskalierung ist ordentlich, und erst bei 3.7 GHz Kerntakt kann dann auch der NB-Takt ein ordentliches Stück Leistung drauflegen - auch hier liegt die 3.7/3.0-Konfiguration weit vor dem Standardtakt, ein Schub, der bei dem Spiel mit dem ohnehin sehr niedrigen Leistungsniveau nicht nur spürbar, sondern auch dringend nötig ist. Langsam bürgert sich das mit den "30% mehr Spieleleistung" ein.
Crysis 3
Zumindest in 720p macht auch Crysis 3 da keine Ausnahme. Der NB-Takt bringt einiges, der Kerntakt noch einmal ungefähr das gleiche - und v.a. hilft der NB-Takt auch dabei, dass der Kerntakt skaliert.
Interessant ist auch, dass der Kerntakt bei übertaktetem Speichercontroller besser skaliert als er eigentlich dürfte - neben dem katastrophalen Ergebnis bei The Witcher 2 und dem Performanceverlust bei AC3 ein weiterer Hinweis darauf, dass unausgewogene Verhältnisse zwischen Kern- und NB-Takt der Performance durchaus schaden können.
In 1080p interessiert sich Crysis 3 dann aber gar nicht mehr für die Taktraten, hier könnte man sogar problemlos deutlich untertakten - oder eine weitaus stärkere Grafikkarte mit dem alten Phenom betreiben. Ein härteres Grafiklimit sieht man selten.
Sleeping Dogs
Wenn man ihn künstlich ins CPU-Limit drückt, wird auch der integrierte Benchmark von Sleeping Dogs um die inzwischen üblichen 30% schneller, aber hier bringt der Kerntakt deutlich mehr als der NB-Takt.
Ein CPU-Fresser ist das Spiel allerdings nicht, weder im integrierten Benchmark, noch unter realen Bedingungen - und so läuft es in 1080p durchgehend im Grafiklimit.
Skyrim
Irgendwie war mir ja schon klar, dass dieses Spiel allein schon aufgrund der Mods komplett aus der Reihe tanzen würde. Aber hier treffen einige Dinge aufeinander, die für Probleme sorgen:
- Die Frameraten sind absolut unterirdisch. Die Benchmarkszene ist relativ ähnlich zu der von PCGH, nahezu an derselben Stelle - es hat wohl einen Grund, dass sie ausgerechnet diese nehmen.
- Das Spiel hat teilweise mit heftigen Nachlade-Hängern zu kämpfen, wenn man sich dem Turm von Weißlauf nähert. Das passiert pro Benchmark-Lauf auch genau 1x. Auch nach der zehnten Wiederholung greift es immer noch wieder auf die Festplatte zu.
- Der VRAM der Grafikkarte ist chronisch überfüllt.
- Und die Szene ist selbst in 1080p noch zumindest teilweise CPU-limitiert, trotz ENB. Ein Umstand, den ich im Schnelltest nur im stark gemoddeten Einsamkeit wiederfinden konnte - ansonsten läuft es relativ ordentlich und die GPU ist selbst in 720p so stark am Ackern, dass man den Unterschied zwischen OC und nicht OC kaum zuverlässig messen kann, geschweige denn merkt.
Wirklich überraschend ist jetzt nur noch, dass bei 1080p - und auch wirklich nur da - die Min-FPS extrem einbrechen, wenn der NB-Takt nicht erhöht wird. Ich weiß nicht, woran das liegen könnte, und warum sich die Werte mit Übertaktung nahezu verdoppeln - allerdings ist auch das reproduzierbar und äußert sich darin, dass man mit Übertaktung ein deutlich flüssigeres Bild hat als ohne. Sofern man bei Frameraten im 20er-Bereich von "flüssig" reden kann.
Watch Dogs
Für Watch Dogs wurde bereits ein halbes Jahr vor Release ein unglaublicher CPU-Hunger prophezeit. Ganz bewahrheitet hat sich das nicht: Obwohl der alte Phenom weit von der magischen 60 FPS-Grenze entfernt ist und gerade bei Standardtakt schon gewaltig am Kämpfen ist - ein Pentium G3220 ist schneller - so fühlt sich das Spiel abgesehen von dem bekannten VRAM-Bug stets flüssig an. Selbst mit nur 2.2 GHz Kerntakt ist das Spiel trotz sehr niedriger Frameraten immer noch spielbar.
Überraschungen gibt es keine: Wieder liegt der Performancegewinn durch die Übertaktung bei etwa 30%, Kern- und NB-Takt skalieren jeweils etwa gleich stark. Und in 1080p hängt zumindest die stärkste Konfiguration im Grafiklimit.
Als Benchmarkszene musste der Gehweg unterhalb einer Hochbahn- bzw. CTA 'L'-Trasse herhalten: Ausgangspunkt war die südliche Treppe von der Station "Washington/Wells", von der aus 30 Sekunden lang auf der rechten Gehweg-Seite in Richtung Süden gelaufen wurde. Die Szene ist recht anspruchsvoll und bietet eigentlich alles, was das Benchmark-Herz begehrt: Viele Passanten, regen Autoverkehr, die Hochbahn selbst, ordentliche Sichtweite und zu guter Letzt eine Kreuzung, an der selbst die KI regelmäßig Unfälle baut.
Metro: Last Light
Bleibt noch Metro. Weil das Spiel kein freies Speichern ermöglicht und mit die Zwischensequenzen sonst immer viel zu lange dauern, habe ich auch hier den integrierten Benchmark genutzt - der allerdings ein sehr komisches Verständnis von Min-FPS hat. Diese treten nämlich komischerweise immer genau bei Frame 8 auf und liegen deutlich unterhalb dessen, was danach noch kommt.
Auffällig ist jedenfalls die ausnahmsweise sehr schlechte Skalierung. Kerntakt bringt fast gar nichts - abgesehen von den fragwürdigen Min-FPS, da dann aber auch richtig. Reine NB-Übertaktung hilft schon eher, aber die Leistungsvorteile sind unterdurchschnittlich.
Allerdings sei auch hier gesagt, dass in 1080p praktisch nur noch die Grafikkarte entscheidet, Min-FPS hin oder her. Für letztere hätte ich wohl doch besser einen Ingame-Benchmark laufen lassen...
PhysX war für beide Läufe aus, die Settings sollten einigermaßen spieletaugliche Frameraten liefern.
Fazit
15-20% mehr Leistung durchs Übertakten in Anwendungen - das liegt, wenn man sich die Verhältnisse ansieht (15% mehr Kerntakt, 50% mehr NB-Takt) durchaus im Bereich meiner persönlichen Erwartungen. Aber dass es in Spielen in CPU-limitierten Szenarien quasi durch die Bank richtige Leistungssprünge von rund 30% gibt, sobald CPU und CPU/NB übertaktet werden, ist schon irgendwie leicht krank. Denn damit wird Assassin's Creed 3 auf höchsten Einstellungen erst spielbar (Zwischensequenzen ruckeln trotzdem noch unerträglich - ernsthaft, was haben die Entwickler da verbrochen?), und Skyrim mit Mods sowie The Witcher 2 laufen stellenweise deutlich angenehmer.
Es lohnt sich also auf jeden Fall, den Phenom zu übertakten, und insbesondere, den NB-Takt anzuheben, wenn man denn spielt. Viel hilft aber nicht zwangsläufig viel: Wie man besonders an The Witcher 2, aber in abgeschwächter Form (z.B. durch merkwürdige Kerntaktskalierung) auch an anderen Benchmarks sieht, sind unausgewogene Konfigurationen wie 3.2 GHz Kerntakt mit 3.0 GHz NB-Takt einfach nicht gut und können auch mal ziemlich locker das Gegenteil von dem bewirken, was sie sollen.
Der optimale Kerntakt für die 3.0 GHz-NB liegt wahrscheinlich sogar eher im Bereich um 4.0 GHz herum, die meiner leider nicht mehr mit humanen Spannungen packt - auch wenn die VRMs durch meinen NH-C14 quasi aktiv gekühlt werden, braten wollte ich mein Board jetzt nicht.
Anmerkungen
- Bevor jemand nach TESO fragt: Ich spiele kein TESO. Die Beta lief aber ordentlich.
- Oder Battlefield 4: Sagt mir, wie ich Battlefield 4 benchen soll, wenn der Ort, an dem ich benchmarken will, permanent von Feinden kontrolliert wird
- Leider habe ich keine Vergleichs-CPU, anhand der man jetzt mal die Leistung vom übertakteten X6 einschätzen könnte. Aber wenn ich mal die Werte vom PCGH-Spieleindex nehme und da ganz naiv 25-30% auf den 1100T draufrechne, würde der irgendwo grob auf dem Niveau des kleinsten Haswell-i3 liegen - könnte sich sehen lassen. (Auch wenn ich weiß, dass die Aussagekraft eines Gesamtindex immer recht.... eingeschränkt ist)
- Zum HT-Link habe ich keine Benchmarks, aber dafür bestätigen Werte von Apfelkuchen, dass HT-Link-OC praktisch absolut nichts bringt.
- Mir ist aufgefallen, dass einzelne Prozentwerte in den Tabellen nicht stimmen. Passiert eben, wenn man zu blöd ist, Zahlen abzutippen - und zu faul, sich ein Script zu schreiben, was die Tabellen automatisch generiert.
Moin. Ich weiß nicht, ob ich damit im OC-Forum oder im Prozessoren-Forum vielleicht besser aufgehoben wäre, aber ich probiere es einfach mal hier.
Dass die Phenom II als Spiele-Prozessoren ihre besten Zeiten hinter sich haben, ist wohl kein Geheimnis. Auch, dass bei denen Übertakten der CPU/NB wohl irgendwie was bringt, hat sich herumgesprochen - so wirklich tolle Zahlen dazu findet man allerdings nur recht verstreut. Deswegen gibt es jetzt von mir mal einen Haufen Benchmarks. Dabei geht es konkret um zwei Fragen: Bringt das Übertakten überhaupt spärbare Vorteile oder ist die Architektur mittlerweile einfach zu schwach? Und stimmt die Behauptung, dass CPU/NB-OC mehr bringt als das Anheben des Kerntakts und hauptsächlich den Min-FPS hilft?
Um welche CPU geht es konkret?
Natürlich um mein Baby, einen 1090T von eher mäßiger Chipgüte:
Das Ding habe ich in vier verschiedenen Konfigurationen durch diverse Benchmarks gejagt:
- Kerntakt: 3.7 GHz - CPU/NB: 3.0 GHz - RAM: 1600 MHz CL9 (Alltags-OC)
- Kerntakt: 3.7 GHz - CPU/NB: 2.0 GHz - RAM: 1333 MHz CL7
- Kerntakt: 3.2 GHz - CPU/NB: 3.0 GHz - RAM: 1600 MHz CL9
- Kerntakt: 3.2 GHz - CPU/NB: 2.0 GHz - RAM: 1333 MHz CL7 (Standardtakt)
Falls sich jetzt irgendjemand fragt, warum der RAM bei 2.0 GHz CPU/NB nur auf 1333 MHz läuft: Ganz einfach, es ist schneller so. Man muss den Speichercontroller schon gewaltig übertakten, damit die 1600 MHz mit schwächeren Timings irgendwelche Vorteile bieten. Es gibt nicht ganz umsonst die Faustregel, den CPU/NB-Takt mindestens 3x so hoch einzustellen wie den realen RAM-Takt - bei 1600 MHz RAM-Takt wären das also 2.4 GHz.
Erläuterungen zu den Diagrammen
Am Ende der Diagramme befindet sich jeweils eine Tabelle mit wilden Prozentzahlen, die in drei Spalten angeordnet sind:
- stock: Relative Leistung zur Konfiguration mit Standardtakt.
- core: Relative Leistung nur durch Erhöhen des Kerntakts - also: Was bringen 3.7 GHz gegenüber 3.2 GHz bei festem CPU/NB-Takt?
- nb: Relative Leistung nur durch Erhöhen des CPU/NB-Takts
Theoretische Werte
Beginnen wir mal mit etwas Langweiligem: Bandbreitenwerten zu L3-Cache und RAM. Das sind genau die beiden Dinge, die am CPU/NB-Takt hängen - und auch die Dinge, in denen AMDs Architekturen einfach nicht gut sind. Hierbei wurde jeweils die Bandbreite mit einem einzelnen Thread und sechs Threads getestet.
Beim L3 werden die 50% quasi 1:1 in Bandbreite beim Lesen und Schreiben umgesetzt, im Single Thread-Modus immer noch über 40%. Das sollte für Spiele, die vom L3 traditionell durchaus profitieren können, doch schonmal nicht schlecht sein. Oder?
Die RAM-Werte sind ebenfalls eindeutig. Beim Lesen mit mehreren Threads limitiert mit übertakteter NB tatsächlich erstmals der RAM - dass nicht die vollen 25.6 GB/s erreicht werden, liegt wohl an zu kleinen TLBs, bei kleineren Blockgrößen und Non-Temporal Prefetching ist auch das kein Problem. Aber insgesamt wird auch das Streamen von Daten in den und aus dem RAM um ca. 40 bis 50% beschleunigt.
Hier zeigt sich allerdings auch, dass der Speichercontroller erst dann wirklich in die Gänge kommt, wenn mit vielen Threads gearbeitet wird. Mit einem einzelnen Thread ist gerade lesend aus dem RAM nicht viel zu reißen - ein Grund, warum Single Thread-Spiele extrem schlecht laufen werden, aber auch stark profitieren können.
Anwendungs- und theoretische Benchmarks
Zunächst ein paar Benchmarks von Alltagsanwendungen und eben dem Standardzeug, das man so verwendet, um zu zeigen, dass man den
Cinebench R11.5
Cinebench war noch nie dafür bekannt, von der Speicherleistung abhängig zu sein, und so bewegen sich die Vorteile durch CPU/NB-Übertaktung erwartungsgemäß irgendwo zwischen einem und zwei Prozent - gerade mal ausreichend, um die Punktzahl messbar anzuheben. Dafür wird jedes MHz Kerntakt nahezu 1:1 in mehr Leistung umgesetzt.
bzip2
bzip2 ist in der Linux-Welt neben gzip eigentlich das Format für komprimierte Tar-Archive, leidet aber darunter, dass besonders die Standardimplementierung mit nur einem Thread äußerst langsam ist - da mit pbzip2 aber eine Version mit Multithreading verfügbar ist, wird diese auch eingesetzt.
Und hier wird es erstmals richtig interessant: Allein durch den hohen NB-Takt steigt die Performance um rund 10% beim Komprimieren, beim Entpacken um noch mehr - dadurch kann sich die Konfiguration mit übertaktetem Speichercontroller, aber nur 3.2 GHz Kerntakt vor die mit 3.7 GHz Kerntakt schieben. Und wenn beides übertaktet wird, stehen satte 26% mehr Leistung auf dem Papier - das lohnt sich!
FFmpeg + x264 + Vorbis
Hier wurde ein 4k-Video mitsamt Ton mit x264 und libvorbis transcodiert. Erstaunlicherweise zeigt sich der Prozess relativ unbeeindruckt von der höheren L3- und Speicherbandbreite - dabei wird besonders ersterer ganz ordentlich gefordert.
Trotzdem stehen hier am Ende dem 15% höheren Kerntakt immerhin 17% mehr Leistung gegenüber - nicht schlecht.
Dieser Benchmark hat mich fast in den Wahnsinn getrieben: Erst ließ sich x264 nicht dazu überreden, eine h.264-Rohdatei zu lesen, dann bin ich auf ffmpeg ausgewichen und stand vor dem Problem, dass selbst ein Würfel sinnvollere Ergebnisse für die Encoding-Dauer geliefert hätte. Brauchbare Ergebnisse gab es eigentlich nur direkt nach einem Neustart - weiß der Geier, warum.
MPlayer
Man könnte auf die Idee kommen, Videos abzuspielen, und wenn man da gerade keine Hardware-Beschleunigung zur Hand hat, braucht das mitunter einiges an CPU-Leistung. Verwendet wurde dasselbe Video wie oben zum Transcodieren.
Hier finden sich ähnliche Ergebnisse. Der CPU/NB-Takt hat zwar einen größeren Einfluss als noch beim Codieren, vorher, aber wirklich viel ist das nicht. Probleme bereitet wird das Video der CPU allerdings auch erst bei Taktraten unter 2.0 GHz.
Audio-Encoding
Vielleicht für die meisten Leute etwas relevanter als das Codieren von Videos ist das Codieren von Audio-Dateien, dafür werden hier Lame (MP3) und Flac mit jeweils starker Kompression benutzt. Es wird jeweils nur eine Datei codiert, sodass auch nur ein Kern belastet wird.
Jedes MHz Kerntakt wird zwar gern genommen, alles andere hat aber außerhalb der Messtoleranz kaum einen Einfluss auf die Leistung. Höchstens bei Flac mit 3.7 GHz Kerntakt könnte der NB-Takt einen winzigen Flaschenhals eliminieren - wobei, winzig ist eigentlich falsch, der Flaschenhals ist nicht viel Enger als der Rest der Flasche.
Blender
Mit Cinebench ist zwar streng genommen schon ein Raytracer in der Liste, aber Blender ist irgendwie alltagstauglicher als ein reiner Benchmark - getestet wurde mit einer leicht modifizierten Version dieser Szene. Unter anderem musste das Texture Mapping angepasst werden, weil sich die Interpretation der Koordinatenskalierung in Blender zwischenzeitlich geändert hat.
Performancetechnisch ist Blender so ein Grenzfall. Solange man am Kerntakt nichts macht, bringt auch der NB-Takt praktisch nichts - der höhere Kerntakt allein reißt allerdings auch keine Bäume aus. Erst, wenn beides übertaktet wird, gibt es einen deutlichen Schub, sodass die gesamte Szene nun in 96 Sekunden gerendert wird.
Compiler
Für Programmierer neben dem Texteditor sicherlich das wichtigste Werkzeug überhapt. In diesem Test dürfen sich zwei Compiler an Amarok 2.8.0 versuchen:
Vorweg: Clang ist ohne Zweifel der schnellere Compiler. Besonders, wenn man C++-Code mit vielen Templates und vielen Inline-Funktionen compiliert, kann er dem GCC um Faktor 2-3 davon laufen - für Test-Builds um einiges angenehmer als jedes Mal auf GCC zu warten.
Beide Compiler profitieren angenehm stark von mehr Takt - hauptsächlich vom Kerntakt, aber doch auch genug vom NB-Takt, um bei kombinierter Übertaktung um jeweils rund 20% zuzulegen. Absolut gesehen ist Clang damit 20 Sekunden eher fertig als bei Standardtakt, GCC sogar 25 Sekunden - das sind spürbare Unterschiede.
Spiele-Benchmarks
Das soll es mit Anwendungen jetzt auch gewesen sein. Die Ergebnisse waren allesamt irgendwo zwischen "ganz ordentlich" und "ernüchternd" - im Allgemeinen hat der CPU/NB-Takt nur einen mäßigen Einfluss auf die Anwendungsleistung, dafür schlägt in der Regel der Kerntakt voll durch. Schauen wir uns also mal einige Spiele an.
Als Grafikkarte dient meine GTX 670, die - außer in Valley, weil ich Valley unter Linux getestet habe - um 120 MHz übertaktet wurde und somit real zwischen 1175 und 1201 MHz läuft. Außerdem wurde der Speicher von 1500 auf 1750 MHz übertaktet.
Hinweis: Die jeweils verwendeten Benchmark-Szenen sind in den Diagrammen auf den Bildern beschrieben.
Unigine Valley
Technisch gesehen kein Spiel, könnte der Unigine-Benchmark schon zeigen, wohin die Reise geht. Hier sieht es nämlich auf einmal komplett anders aus: Im 720p-Lauf führen die beiden Konfigurationen mit erhöhtem NB-Takt und am Ende stehen beim kombinierten OC satte 23% mehr Leistung auf dem Papier. Einzig die minimalen FPS profitieren deutlich stärker vom Kerntakt. Wobei die in diesem Benchmark ohnehin mit Vorsicht zu genießen sind - erreicht werden sie ausschließlich zwischen den Szenen, und da ist der ganze Bildschirm schwarz.
In 1080p liegen die Konfigurationen alle sehr dicht beieinander - Grafiklimit lässt grüßen.
Das 720p-Ergebnis stützt allerdings schon die These, dass der NB-Takt in Spielen mehr bringen könnte als der Kerntakt - sind die 3.2/3.0 GHz am Ende wirklich stärker als die 3.7/2.0 GHz?
The Witcher 2
Beim Hexer gibt es für die 3.2/3.0-Konfiguration gleich einmal eine Klatsche, und zwar eine gewaltige. Sie verliert in 720p über 20% gegenüber Standardtaktraten - ein merkwürdiges, aber reproduzierbares Verhalten, das ich mir ehrlich gesagt nicht so richtig erklären kann.
Allerdings kann man damit auch die Kerntakt-Skalierung erklären. Denn allein die 500 MHz Kerntakt bringen schon 20% mehr Leistung - das ist mehr, als man bei dem Taktunterschied erwarten würde. Anscheinend mag es das Spiel nicht wirklich, wenn NB- und Kerntakt zu dicht beieinander liegen. Die 3.7/3.0-Konfiguration liegt allerdings mit einem Vorsprung von 31% gegenüber dem Standardtakt deutlich vorne.
In 1080p ergibt sich ein ähnliches Bild, nur, dass hier mit 3.7 GHz bereits das Grafiklimit erreicht ist und dort unabhängig vom NB-Takt praktisch absolut identische Frameraten erreicht werden. Mit 28 FPS ist hier die Framerate zwar auf einem niedrigen, aber immer noch gut erträglichen Niveau, was man von den 24 FPS, die mit Standardtakt erreicht werden, schon nicht mehr behaupten kann.
Thief
Und hier sehen wir einfach mal das komplette Gegenteil von dem, was Witcher 2 uns gezeigt hat. Nicht nur, dass die beiden Konfigurationen ohne NB-Takt-Erhöhung wirklich deklassiert werden - beide Male ein 20%iger Schub allein durch den hohen NB-Takt! - da das CPU-Limit an zwei Stellen des Benchmarks besonders heftig ist, macht sich das selbst in 1080p bemerkbar. Hier liegen die Ergebnisse zwar auch relativ dicht beieinander - die meiste Zeit über ist es eben doch die Grafikkarte, die da bremst - allerdings legen die minimalen FPS immer noch um knapp 30% und damit spürbar zu. Das hilft dann auch der Durchschnittsframerate auf die Sprünge.
Assassin's Creed 3
Dieses Spiel bietet nicht einmal eine Option, die Auflösung zu ändern, allerdings kommt das Spiel ohnehin nicht einmal in die Nähe eines Grafiklimits - deswegen habe ich auf 720p-Fummeleien in der Ini-Datei verzichtet und liefere nur 1080p-Werte.
Hier sieht es zunächst ähnlich aus wie beim Witcher, die 3.2/3.0 GHz-Konfiguration verliert klar - wenn auch bei weitem nicht so dramatisch. Die Kerntaktskalierung ist ordentlich, und erst bei 3.7 GHz Kerntakt kann dann auch der NB-Takt ein ordentliches Stück Leistung drauflegen - auch hier liegt die 3.7/3.0-Konfiguration weit vor dem Standardtakt, ein Schub, der bei dem Spiel mit dem ohnehin sehr niedrigen Leistungsniveau nicht nur spürbar, sondern auch dringend nötig ist. Langsam bürgert sich das mit den "30% mehr Spieleleistung" ein.
Crysis 3
Zumindest in 720p macht auch Crysis 3 da keine Ausnahme. Der NB-Takt bringt einiges, der Kerntakt noch einmal ungefähr das gleiche - und v.a. hilft der NB-Takt auch dabei, dass der Kerntakt skaliert.
Interessant ist auch, dass der Kerntakt bei übertaktetem Speichercontroller besser skaliert als er eigentlich dürfte - neben dem katastrophalen Ergebnis bei The Witcher 2 und dem Performanceverlust bei AC3 ein weiterer Hinweis darauf, dass unausgewogene Verhältnisse zwischen Kern- und NB-Takt der Performance durchaus schaden können.
In 1080p interessiert sich Crysis 3 dann aber gar nicht mehr für die Taktraten, hier könnte man sogar problemlos deutlich untertakten - oder eine weitaus stärkere Grafikkarte mit dem alten Phenom betreiben. Ein härteres Grafiklimit sieht man selten.
Sleeping Dogs
Wenn man ihn künstlich ins CPU-Limit drückt, wird auch der integrierte Benchmark von Sleeping Dogs um die inzwischen üblichen 30% schneller, aber hier bringt der Kerntakt deutlich mehr als der NB-Takt.
Ein CPU-Fresser ist das Spiel allerdings nicht, weder im integrierten Benchmark, noch unter realen Bedingungen - und so läuft es in 1080p durchgehend im Grafiklimit.
Skyrim
Irgendwie war mir ja schon klar, dass dieses Spiel allein schon aufgrund der Mods komplett aus der Reihe tanzen würde. Aber hier treffen einige Dinge aufeinander, die für Probleme sorgen:
- Die Frameraten sind absolut unterirdisch. Die Benchmarkszene ist relativ ähnlich zu der von PCGH, nahezu an derselben Stelle - es hat wohl einen Grund, dass sie ausgerechnet diese nehmen.
- Das Spiel hat teilweise mit heftigen Nachlade-Hängern zu kämpfen, wenn man sich dem Turm von Weißlauf nähert. Das passiert pro Benchmark-Lauf auch genau 1x. Auch nach der zehnten Wiederholung greift es immer noch wieder auf die Festplatte zu.
- Der VRAM der Grafikkarte ist chronisch überfüllt.
- Und die Szene ist selbst in 1080p noch zumindest teilweise CPU-limitiert, trotz ENB. Ein Umstand, den ich im Schnelltest nur im stark gemoddeten Einsamkeit wiederfinden konnte - ansonsten läuft es relativ ordentlich und die GPU ist selbst in 720p so stark am Ackern, dass man den Unterschied zwischen OC und nicht OC kaum zuverlässig messen kann, geschweige denn merkt.
Wirklich überraschend ist jetzt nur noch, dass bei 1080p - und auch wirklich nur da - die Min-FPS extrem einbrechen, wenn der NB-Takt nicht erhöht wird. Ich weiß nicht, woran das liegen könnte, und warum sich die Werte mit Übertaktung nahezu verdoppeln - allerdings ist auch das reproduzierbar und äußert sich darin, dass man mit Übertaktung ein deutlich flüssigeres Bild hat als ohne. Sofern man bei Frameraten im 20er-Bereich von "flüssig" reden kann.
Watch Dogs
Für Watch Dogs wurde bereits ein halbes Jahr vor Release ein unglaublicher CPU-Hunger prophezeit. Ganz bewahrheitet hat sich das nicht: Obwohl der alte Phenom weit von der magischen 60 FPS-Grenze entfernt ist und gerade bei Standardtakt schon gewaltig am Kämpfen ist - ein Pentium G3220 ist schneller - so fühlt sich das Spiel abgesehen von dem bekannten VRAM-Bug stets flüssig an. Selbst mit nur 2.2 GHz Kerntakt ist das Spiel trotz sehr niedriger Frameraten immer noch spielbar.
Überraschungen gibt es keine: Wieder liegt der Performancegewinn durch die Übertaktung bei etwa 30%, Kern- und NB-Takt skalieren jeweils etwa gleich stark. Und in 1080p hängt zumindest die stärkste Konfiguration im Grafiklimit.
Als Benchmarkszene musste der Gehweg unterhalb einer Hochbahn- bzw. CTA 'L'-Trasse herhalten: Ausgangspunkt war die südliche Treppe von der Station "Washington/Wells", von der aus 30 Sekunden lang auf der rechten Gehweg-Seite in Richtung Süden gelaufen wurde. Die Szene ist recht anspruchsvoll und bietet eigentlich alles, was das Benchmark-Herz begehrt: Viele Passanten, regen Autoverkehr, die Hochbahn selbst, ordentliche Sichtweite und zu guter Letzt eine Kreuzung, an der selbst die KI regelmäßig Unfälle baut.
Metro: Last Light
Bleibt noch Metro. Weil das Spiel kein freies Speichern ermöglicht und mit die Zwischensequenzen sonst immer viel zu lange dauern, habe ich auch hier den integrierten Benchmark genutzt - der allerdings ein sehr komisches Verständnis von Min-FPS hat. Diese treten nämlich komischerweise immer genau bei Frame 8 auf und liegen deutlich unterhalb dessen, was danach noch kommt.
Auffällig ist jedenfalls die ausnahmsweise sehr schlechte Skalierung. Kerntakt bringt fast gar nichts - abgesehen von den fragwürdigen Min-FPS, da dann aber auch richtig. Reine NB-Übertaktung hilft schon eher, aber die Leistungsvorteile sind unterdurchschnittlich.
Allerdings sei auch hier gesagt, dass in 1080p praktisch nur noch die Grafikkarte entscheidet, Min-FPS hin oder her. Für letztere hätte ich wohl doch besser einen Ingame-Benchmark laufen lassen...
PhysX war für beide Läufe aus, die Settings sollten einigermaßen spieletaugliche Frameraten liefern.
Fazit
15-20% mehr Leistung durchs Übertakten in Anwendungen - das liegt, wenn man sich die Verhältnisse ansieht (15% mehr Kerntakt, 50% mehr NB-Takt) durchaus im Bereich meiner persönlichen Erwartungen. Aber dass es in Spielen in CPU-limitierten Szenarien quasi durch die Bank richtige Leistungssprünge von rund 30% gibt, sobald CPU und CPU/NB übertaktet werden, ist schon irgendwie leicht krank. Denn damit wird Assassin's Creed 3 auf höchsten Einstellungen erst spielbar (Zwischensequenzen ruckeln trotzdem noch unerträglich - ernsthaft, was haben die Entwickler da verbrochen?), und Skyrim mit Mods sowie The Witcher 2 laufen stellenweise deutlich angenehmer.
Es lohnt sich also auf jeden Fall, den Phenom zu übertakten, und insbesondere, den NB-Takt anzuheben, wenn man denn spielt. Viel hilft aber nicht zwangsläufig viel: Wie man besonders an The Witcher 2, aber in abgeschwächter Form (z.B. durch merkwürdige Kerntaktskalierung) auch an anderen Benchmarks sieht, sind unausgewogene Konfigurationen wie 3.2 GHz Kerntakt mit 3.0 GHz NB-Takt einfach nicht gut und können auch mal ziemlich locker das Gegenteil von dem bewirken, was sie sollen.
Der optimale Kerntakt für die 3.0 GHz-NB liegt wahrscheinlich sogar eher im Bereich um 4.0 GHz herum, die meiner leider nicht mehr mit humanen Spannungen packt - auch wenn die VRMs durch meinen NH-C14 quasi aktiv gekühlt werden, braten wollte ich mein Board jetzt nicht.
Anmerkungen
- Bevor jemand nach TESO fragt: Ich spiele kein TESO. Die Beta lief aber ordentlich.
- Oder Battlefield 4: Sagt mir, wie ich Battlefield 4 benchen soll, wenn der Ort, an dem ich benchmarken will, permanent von Feinden kontrolliert wird
- Leider habe ich keine Vergleichs-CPU, anhand der man jetzt mal die Leistung vom übertakteten X6 einschätzen könnte. Aber wenn ich mal die Werte vom PCGH-Spieleindex nehme und da ganz naiv 25-30% auf den 1100T draufrechne, würde der irgendwo grob auf dem Niveau des kleinsten Haswell-i3 liegen - könnte sich sehen lassen. (Auch wenn ich weiß, dass die Aussagekraft eines Gesamtindex immer recht.... eingeschränkt ist)
- Zum HT-Link habe ich keine Benchmarks, aber dafür bestätigen Werte von Apfelkuchen, dass HT-Link-OC praktisch absolut nichts bringt.
- Mir ist aufgefallen, dass einzelne Prozentwerte in den Tabellen nicht stimmen. Passiert eben, wenn man zu blöd ist, Zahlen abzutippen - und zu faul, sich ein Script zu schreiben, was die Tabellen automatisch generiert.
Zuletzt bearbeitet:
