Windows XP oder Windows Vista? – Wer stand nicht selbst schon vor dieser Frage. Nach mehrmonatiger Reifezeit steht Vista nun auch bei uns auf dem Prüfstand. Für viele User ist die Entscheidungsfrage eher darauf gestützt, wie gut man sich mit dem „Look and Feel“ von Vista anfreunden kann. Für einen gar nicht so kleinen Anwenderkreis ist aber auch die Performance ausschlaggebend. Verschiedene Tests widersprechen sich und stiften Verwirrung. Nun sind wir an der Reihe, Verwirrung zu stiften oder sogar ein paar neue Klarheiten zu finden.
Im vorangehenden Teil [2] des Artikels wurden bereits einige Performancebetrachtungen zu Vista selbst durchgeführt. Hauptsächlich kamen dabei synthetische Benchmarks und rechenlastige Multimedia-Programme zum Einsatz. Am Ende des Artikels mussten wir Vista uneingeschränkt zugestehen, dass Windows XP keinen noch so kleinen Vorteil verbuchen kann.
Etwas bodenständiger haben sich die Kollegen von HT4U.net Vista genähert (siehe HT4U Windows Vista Performance Check [3]). Dort konnte man unsere Ergebnisse teilweise bestätigen, zumindest was den synthetischen Bereich betrifft. HT4U setzt jedoch auch auf komplexere Anwendungen, die neben reiner Rechenarbeit auch Zugriffe auf Speicher und Festplatte fordern. Insbesondere bei Spielen und Archiv-Operationen konnte man teils große Unterschiede feststellen. Wir wollen mit dem zweiten Teil des Artikels ebenfalls in diese Richtung einstimmen. Verlassen wir also das Anwendungsfeld und lassen die Spiele beginnen.
Die Testsysteme: | ||
---|---|---|
AMD-System | Intel-System | |
AMD Athlon 64 X2 2.4 GHz (K8 Manchester, 512K L2, 90nm, SSE3) nVidia nForce4 Ultra 2x1 GB DDR400 ATI Radeon HD 2900 XT 512MB mit Catalyst 8.8 Creative Audigy2 Maxtor 160 GB/7200 SATA beQuiet Straight Power 700W Windows Vista x64 SP1 Windows XP x64 SP2 |
Intel Core 2 Duo 3.0 GHz (Conroe, 375 MHz FSB, 4MB L2, 65nm, SSSE3) Intel 975X 2x2 GB DDR2/750 nVidia GeForce 8800 GTS 640MB mit Forceware 177.92 Creative Audigy2 Maxtor 160 GB/7200 SATA beQuiet Straight Power 700W Windows Vista x64 SP1 (in Abbildungen Vista64) Windows Vista x86 SP1 (in Abbildungen Vista32) Windows XP x64 SP2 (in Abbildungen XP64) |
Software |
---|
Comanche 4 Unreal Tournament 2004, 32-Bit und 64-Bit 3DMark2001, 3DMark2003 und 3DMark2006 Command and Conquer: Red Alert 3 |
Uns ist aus dem ersten Teil bekannt, dass Comanche4 nahezu vollständig CPU-limitiert ist. Die Engine nutzt DirectX8 und unterstützt kein Multi-Threading. Der Anteil an Gleitkommaberechnungen liegt überraschend niedrig, wobei kein SSE/2 zum Einsatz kommt. Nachdem wir festgestellt haben, dass Windows Vista ebenso schnell rechnet, sollten sich hier keine Überraschungen ergeben. Beginnen wir mit der Timedemo auf dem 2.4 GHz Athlon 64 X2 und der Radeon HD 2900 XT.
Hier erwischt es Windows Vista also zum ersten Mal. Wir müssen gestehen, dass dieses Ergebnis für uns nicht unerwartet kommt, haben wir Comanche4 doch gerade deswegen ausgewählt. Vista64 ist XP64 hier durchgehend um ca. 40% unterlegen. In diesem Fall sogar so weit, dass der Spielfluss bereits spürbar leidet. Nur woran liegt es?
Folgende Möglichkeiten kommen in Frage:
• Comanche4 reagiert allergisch auf:
• Spezifische Treiberoptimierungen greifen unter Vista nicht.
Glücklicherweise können wir die ersten beiden (K8, 2900XT) und den drittletzten Punkt (Vista64) relativ schnell überprüfen. Das folgende Diagramm zeigt die gleiche Szene auf dem Intel Core2 Duo mit 3 GHz, nVidia Geforce 8800 GTS und zusätzlich Vista 32-Bit.
Es ändert sich nicht wirklich etwas. Noch immer liegt Vista64 mit ca. 40% im Rückstand. Zusätzlich aber zeigt das Diagramm, dass selbst Vista32 auf diesem Niveau rangiert. Damit können wir wohl CPU, GPU, ATI-Treiber und 64-Bit als mögliche Ursachen von der Liste streichen.
Vielleicht rächt sich hier der Einsatz einer Timedemo? Wie wir im ersten Teil gesehen haben, liegen die Werte im eigentlichen Spiel viel niedriger. Also legen wir über unser bereits bekanntes Diagramm mit Vista64 noch einmal die gleiche Szene in XP64 aufgenommen.
Immer noch Fehlanzeige! Die Timedemo liefert korrekte Ergebnisse. Uns bleiben also noch die Soundberechnung, Probleme mit der Verteilung bei MultiCore-CPUs, das Powermanagement oder ein ganz anderes Problem mit Vista. Da wir wissen, dass die Timedemo nützliche Werte liefert, verzichten wir auf die Spielszene. Zusätzlich sehen wir, dass bei einem Rückstand von 40% das Problem auch an den Durchschnittswerten erkannt werden kann. Zur besseren Übersicht geben wir den Rest mit reduziertem Informationsgehalt an und suchen nach einer Lösung.
Ob die Soundberechnung schuld ist, lässt sich sehr einfach durch Abstellen im Benchmark selbst ergründen. Ob Vista Probleme mit der Verteilung des Spiels auf zwei Kerne hat, wo das Spiel nur einen nutzen will, lässt sich durch Festlegen auf einen Kern aufzeigen. Hintergrundanwendungen kann man hingegen durch das Hochsetzen deren Priorität beikommen und schließlich kann man abweichende Optimierungen für Multi-Threading im Grafiktreiber durch Deaktivierung eines Kerns auf die Schliche kommen. Und hier der Lohn unserer Mühen:
Seit Vista findet sich im Task-Manager eine "Virtualisierungs"-Option. Dahinter verbergen sich allerdings keine so tiefgreifenden Maßnahmen wie VMWare oder VirtualPC sie einsetzen. Der Anwendung wird mit dieser Option lediglich der Zugriff auf geschützte Daten und Registry-Bereiche verwehrt. Ein schneller Benchmark zeigt den nicht vorhandenen Performanceeinfluss.
Seit einiger Zeit ist bekannt, dass AMDs teils sehr aggressive Powermanagement-Features im Phenom, zusammen mit Microsofts Arbeitsverteilung auf vorhandene Kerne, Leistung kosten kann. Bei Phenom können das gut und gerne zwischen 10% und 15% sein. Abhilfe schafft nur die Deaktivierung von Cool`n Quiet 2. Für uns stellt sich die Frage, ob Ähnliches nicht schon beim K8 und auch Core2 möglich ist. Auftreten würde dieser Effekt dann freilich nur unter Vista. Die Ergebnisse sprechen jedoch eine andere Sprache, K8 und Core2 sind in diesem Fall die Powermanagement-Einstellung in Windows herzlichst egal.
Man sieht schon, es hat fast alles nichts gebracht. Egal ob Comanche4 nun an einen Kern gebunden wird, ohne Soundberechnung losfliegt oder die Priorität erhöht wird, die Performance ändert sich nicht wesentlich. Gleiches gilt, wie schon gesehen, für die Deaktivierung von Aero und die manuelle Einstellung des Powermanagements auf maximale Stufe. Einzig im Fall, dass man Windows eines Kerns beraubt, schafft es Vista näher heranzukommen. Tatsächlich verliert Vista in diesem Fall keinerlei Performance, während Windows XP64 stark einbricht. Dies könnte ein Indiz dafür sein, dass Multi-Threading-Optimierungen in den Treibern von ATI und nVidia unter XP64 besser funktionieren, als dies unter Vista der Fall ist. Allerdings liegt Vista selbst dann noch zwischen 20% und 30% zurück.
Können wir diesen Einbruch mit nur einem Kern verifizieren? Zum Test belasten wir einen der K8-Kerne mit Gleitkommaberechnungen, die vollständig im Cache ablaufen (der getrennte L2-Cache im K8 erlaubt das ohne größere Performanceeinbrüche). Wir teilen jeweils Comanche4 und diesem Programm einen Kern zu und starten den Benchmark.
Das sieht doch sehr interessant aus: Sobald der zweite Kern unter Windows XP64 beschäftigt ist, fällt Comanche4 sofort auf die Performance der SingleCore-Konfiguration zurück. Vista64 lässt das alles kalt, die Gleitkommaberechnungen lasten den zweiten Kern vollständig aus, ohne an der Performance des Benchmarks etwas zu ändern. Ein ähnliches Ergebnis erhält man übrigens auch für den Core-2-Prozessor und die nVidia-Karte. Vista64 verliert keinerlei Performance, während Windows XP64 absackt, wenn auch nicht so stark wie beim K8.
Allerdings kann dies alleine nicht die Lösung des Problems sein. Zum einen liegt das Core-2-System dann immer noch mit 137fps zu 100fps in Führung, zum anderen verliert Vista bei nur einem Kern plötzlich überproportional, falls Sound berechnet werden muss. Treiberoptimierung und Sound tragen sicher einen Teil bei, vollständig gleichziehen kann Vista64 aber auch ohne diese Hemmschuhe noch lange nicht. Eine vollständige Erklärung für diesen Effekt bleiben wir dem Leser vorerst schuldig.
Der nächste Titel hat ebenfalls bereits einige Jahre auf dem Buckel. Er besitzt allerdings den großen Vorteil, sowohl als 32-Bit- als auch als 64-Bit-Version vorzuliegen. Zudem wurde UT2004 aufgrund eines zufällig gefundenen, aber sehr interessanten Puzzlestücks ausgewählt. Zum Einsatz kommen zwei aufgenommene Botmatches, die allerdings als Timedemo immer identisch ablaufen. Das ist sicherlich kein guter Ansatzpunkt, um Spielbarkeit zu bewerten, hat sich aber erneut für unsere Zwecke als dienlich erwiesen. Beide Demos sind ausschließlich CPU-limitiert. Den folgenden Unterschied erkennt man also ohne Probleme und aufwändige Testverfahren:
Abgesehen von der absoluten Performance, absolvieren beide Systeme die Demo nahezu identisch. Auch den ca. 15-20% Rückstand von Windows Vista auf Windows XP teilen sich beide. Die zweite Demo zeigt ein ähnliches Verhalten:
Auch hier sind es ca. 15-20% Rückstand. Der Einbruch im blauen Verlauf des Core-2-Systems ist untypisch, scheint aber kein Messfehler zu sein. Er bleibt trotzdem ohne Folgen für den weiteren Vergleich. Nun hätte dieser Spiele-Dinosaurier in diesem Artikel nichts verloren, wenn es nicht ein paar besondere Erkenntnisse zu holen gäbe. Betrachten wir zunächst die 64Bit-Versionen der Dria-Demo unter Windows XP64 auf beiden Systemen:
Die Verläufe ähneln sich sehr, obwohl die 64-Bit-Version etwas höhere Werte erreicht. Warum das Core-2-System hier besonders stark profitieren kann, ist unklar – aber so interessant es auch ist, ohne Bedeutung für diesen Vergleich. Viel mehr erstaunte uns der Verlauf der 64-Bit Versionen auf Windows Vista64:
Auf Vista64 zeigen die 64-Bit Varianten plötzlich einen unerwartet starken Performancezuwachs. Die Mehrleistung von teils 20% liegt weit über dem, was man von einem 64-Bit Spiel, selbst im Optimalfall, erwarten könnte. Auch der Primeval-Demo ergeht es gleich. Dabei macht es keinen Unterschied, ob K8 oder Core 2, der Performanceanstieg ist durch die Bank messbar. Oder sollte man besser sagen, dass in Wirklichkeit der Performanceverlust der 32-Bit Variante unter Vista64 allgegenwärtig ist. Denn überraschenderweise erhält man folgendes Bild, wenn die 32-Bit Version unter XP64 und die 64-Bit Version auf Vista64 übereinandergelegt werden.
Jetzt wird eindeutig klar, dass Vista64 nicht überproportional durch 64-Bit zulegt, sondern überproportional bei 32-Bit verliert. Als erster Gedanke kam uns WoW64 in den Sinn. Sollte diese nötige Emulationsstufe auf Windows Vista64 mehr Leistung verschwenden, als es bei Windows XP64 der Fall ist?
WoW64 (Win32 emulation on 64-Bit Windows) ist ein Softwarelayer, welcher 64-Bit Windows-Systemen ermöglicht, eine 32-Bit Applikation auszuführen. Über spezielle DLLs werden die Aufrufe und Funktionen der 32-Bit Programme abgefangen und abgeändert. Dazu gehört z.B. die Umleitung von Zugriffen auf Systemdateien und der Registry in speziell für 32-Bit Prozesse vorgesehen Bereiche, aber auch die Umschaltung der CPU-Modi in den 32-Bit Kompatibilitätsmodus und zurück in den echten 64-Bit Modus. Sobald WoW64 übernommen hat, läuft die Anwendung nach eigener Auffassung in einer vollständigen 32-Bit Umgebung.
Das Ganze kostet natürlich etwas mehr Rechenzeit als die direkte Ausführung. Allerdings hat sich bei XP64 gezeigt, dass die Vorteile des 64-Bit Systems für das Betriebssystem, z.B. mehr Register, meist jeden Performanceverlust wieder wett machen können. Also warum sollte dies auf Windows Vista64 anders aussehen? Nun kommen auch die ganzen Applikationen zum Tragen, welche wir im ersten Teil getestet hatten. Hier zeigten sich keinerlei Verluste, obwohl alle 32-Bit Programme über WoW64 laufen mussten. Es ist daher sehr unwahrscheinlich, dass es sich hier um ein Problem von WoW64 handelt.
Dies lässt sich zudem überprüfen: Läge es wirklich an WoW64, dürften diese Verluste in der 32-Bit-Variante von Vista nicht auftreten. Schließlich handelt es sich hierbei um ein reines 32-Bit-System, welches über keinen WoW64-Layer verfügt und nur x86 32-Bit Code ausführen kann.
Die Sache mit WoW64 ist eine Sackgasse. Das Problem muss tiefer liegen, immerhin setzt es sich über zwei weitgehend unterschiedliche Systeme hinweg in Szene. Einige Ideen und Ansatzpunkte haben wir noch. Allerdings wechseln wir hierzu, wie schon bei Comanche4, auf Tabellen und Durchschnittswerte über. Die Timedemos sind konstant und die Unterschiede groß genug, dass wir uns das leisten können.
So wissen wir aus der vorherigen Betrachtung von UT2004, sowie den Comanche4-Benchmarks, dass die Soundberechnung teils verantwortlich sein kann. Bei UT2004 haben wir im speziellen das Problem, dass nur die 64-Bit-Version OpenAL unterstützt, während im Original neben dem Software-Modus auch hardwarebeschleunigte 3D-Modi zur Verfügung stehen. Wir haben uns einmal für den "Safe"-Modus entschieden, bei dem die Soundberechnungen rein in Software und auf einem minimalen Maß laufen. Zudem nehmen wir noch den Software 3D-Modus (Software A3D) hinzu. Auf die HW-Modi verzichten wir, da die Ergebnisse unter Vista damit an Unsicherheit gewinnen. Es bleibt dann die Frage, was Vista genau macht, wenn HW-3D-Sound von UT2004 gefordert wird.
Beginnen werden wir mit einem weiteren Vorzug von UT2004: Dem Software-Rendering-Modus. Damit lassen sich Treiber, GPU und damit verbundene Teile im Betriebssystem umgehen. Erwarten sollte man demnach ähnliche Ergebnisse wie in den Applikation.
Software-Rendering ist nicht schön und nicht schnell, liegt aber in Vista und XP gleichauf. Die Kontrahenten geben sich hier fast nichts. Die geringen Unterschiede sind zu vernachlässigen und sehen in der Dria-Demo ähnlich aus. Alle vorherigen UT2004-Diagramme im Artikel wurden entweder mit OpenAL oder "Safe-Audio" für die 32-Bit-Variante erstellt. Die Audio-Komponente kann nicht für den großen Unterschied verantwortlich sein.
Neben dem Software-Renderer bietet UT2004 glücklicherweise noch die Möglichkeit, die Ausgabe auf den Pfad "Null" umzuleiten. Die CPU rechnet dann so schnell wie möglich, die Ausgabe geht nicht über den Umweg Grafiktreiber und GPU. Nach den bisher gesammelten Informationen erwarten wir dann eigentlich ebenfalls identische Werte zwischen XP und Vista.
Zu sehen sind Benchmarks der Dria-Timedemo auf beiden Systemen. Der jeweils dritte Benchmark, mit "Null" in der Bezeichnung, verweist dabei auf die eben besprochene Methode. Die erste Erkenntnis ist, dass Vista prinzipiell etwas mehr an Leistung verliert, wenn Soundberechnungen gefordert werden – egal ob es sich dabei um Software- oder OpenAL-Aufrufe handelt. Die zweite und wichtigere Erkenntnis: Ohne das Grafiksubsystem ist die Performance zwischen XP und Vista wieder auf beiden Systemen identisch, gleiches gilt für die Primeval-Demo. Und schließlich können wir noch feststellen, dass Vista64 in der 64-Bit Variante von UT2004 auch mit HW-Rendering gleichziehen kann.
Wir stehen also an dem Punkt, an dem wir den Unterschied eindeutig dem Grafiksubsystem von Vista zuordnen müssen. Der nette Trick mit der Beschäftigung eines der Kerne, wie in Comanche4, bringt hier gar nichts. Die Timedemo läuft unter XP unbeeindruckt davon ab.
Am Ende kommt nur ein Unterschied in Frage: Die 64-Bit-Variante von UT2004 ist ausschließlich auf einen speziell hierfür erstellten DirectX9-Renderpfad angewiesen. Die 32-Bit-Variante muss dagegen auf DirectX8 zurückgreifen. Leider scheitern Vergleichstests mit OpenGL an einigen Bugs und alle verfügbaren DirectX9-Renderpfade für die UT2004 32-Bit sind nicht annähernd so schnell, wie das DirectX8-Gegenstück.
Das Fazit muss demnach lauten, dass UT2004 durch den DirectX8-Renderpfad in Vista an Performance verliert und zwar CPU-Performance. Auf das gleiche Phänomen trafen wir bereits zuvor, ohne einen Gedanken daran zu verschwenden. Denn auch Comanche4 nutzt den DirectX8-Pfad und verliert beim Übergang auf Vista an Performance.
Welches Tool nutzt man, will man mehrere Renderpfade in einem Programm vergleichen? Hier bietet sich der 3DMark an. Auch wenn die Serie sonst relativ wenig Aussagekraft im Alltag besitzt, finden sich hier verschiedene DirectX-Pfade und Shader-Modelle vereint.
Für den Übergang DirectX7 zu DirectX8 setzen wir 3DMark2001 ein. Als letzter 3DMark legt er besonders viel Wert auf die CPU-Leistung. Alle neueren Modelle bestechen durch sukzessiv geringere CPU-Last bei Durchläufen und setzen im Gegenzug auf spezielle CPU-Tests. Im 3DMark2001 besteht zudem die Möglichkeit, Transform & Lighting (T&L) per Software oder Hardware zu berechnen, die Nachfolger erlauben Software-Vertex-Shading.
Den Übergang DirectX8 zu DirectX9 übernimmt der Nachfolger 3DMark2003. Der erste Test läuft noch über DirectX7, Test 2+3 setzen auf DirectX8 und Test 4 auf DirectX9 Shader Model 2. Den finalen Part übernimmt 3DMark2006 mit ausschließlichem Fokus auf DirectX9. Alle Benchmarks wurden, bis auf wenige Ausnahmen, mit einer Auflösung von 640x480 durchgeführt, da uns hier nur die CPU-Leistung, sofern überhaupt gefordert, interessiert. Die Ergebnisse überraschen in vielerlei Hinsicht:
Wie wir erwartet hatten, zeigt sich beim sehr alten 3DMark2001 ein massiver Unterschied. Die Ergebnisse mit HW-T&L, welches seit langem schon über die Vertex-Shader läuft, liegen unter Vista64 ähnlich stark zurück wie es bei Comanche4 oder UT2004 der Fall ist. Übernimmt die CPU alleine die Berechnung der Geometrie, so normalisieren sich die Ergebnisse etwas.
Ein Gegencheck auf dem Intel-System zeigt vergleichbar schlechte Ergebnisse für Vista64 im Fall der HW T&L-Emulation durch die Vertex-Shader. Interessanterweise kann sich Vista im bei Software-T&L besser behaupten.
Nach allen bisherigen Benchmarks gehen wir davon aus, dass hohe GPU-Last die Rückstände nahezu verschwinden lässt. Daher erhöhen wir genau jene und hoffen auf Bestätigung.
Dies ist hier nicht ganz der Fall, zwei der High-Detail Levels wehren sich vehement dagegen. 3DMark2001 ist allerdings so alt, dass die Werte schon aufgrund der modernen Treiber und GPUs mit etwas Vorsicht zu genießen sind. Wechseln wir daher zu 3DMark2003 und in die Welt von DirectX8.
Nun geraten wir etwas in Erklärungsnot. Vista64 gewinnt eins der Demos mit HW Vertex-Shading und liegt beim Rest nahezu gleichauf. Ein ähnliches Bild findet man im Fall, dass die CPU alleine rechnen darf – nur verliert Vista hier den DirectX7-Test "Wings". Den ersten CPU-Test (ebenfalls "Wings" ohne HW-Vertex-Shader) verliert es dann dementsprechend in beiden Fällen. So richtig um die Ohren fliegt uns die Sache aber auf dem Intel-System.
Nun holt Vista64 im DirectX7-Demo stark auf und erringt zudem einen beachtlichen Vorsprung im DX9-Demo und dem dazugehörigen CPU-Test 2. Hier spielen sicherlich die Grafiktreiber eine entscheidende Rolle, zusammen mit der höheren CPU-Leistung des Core 2 Prozessor. Für das schnellere System geht diese Runde definitiv an Vista64. Überraschend muss man sagen, da wir eigentlich ein anderes Ergebnis erwartet hätten.
Mit 3DMark2006 gehen wir endgültig den Schritt hin zu DirectX9 und weg von der CPU-Leistung als bestimmendes Merkmal.
Die Unterschiede verschwinden erwartungsgemäß. Auf dem AMD-System mit der schwächeren CPU zeigt sich ein Rückstand in den CPU-Tests, was mit den bisherigen Erkenntnissen im Einklang steht. Die weitaus schnellere Core-2-CPU zeigt dagegen keine Engpässe. Den Leistungsabfall der bisherigen Tests kann man mit 3DMark2006 nicht mehr nachstellen.
Denken wir zurück an Comanche4: Dort untersuchten wir den Einfluss von DualCore-Systemen auf die Performance. Unter XP64 war bei nur einem Kern ein deutlicher Abfall zu erkennen, es verlor einen großen Brocken seines Vorsprungs. Vista64 schien der Wegfall eines Kerns dagegen kaum zu stören, ein Anzeichen für schlechte Nutzung des zweiten Kerns. Rein aus Interesse wollen wir die gleiche Strategie bei 3DMark2001 fahren, welcher als einziger Benchmark große Nachteile für Vista64 aufzeigt.
Man muss nicht groß kommentieren, was hier erneut passiert. XP64 liegt zwar mit einem Kern noch immer vor Vista, hatte sich aber bisher durch den DualCore knappe 15% Mehrleistung dazu gezaubert. Vista findet sich dagegen erneut in der unvorteilhaften Position, weder wirklich Nutzen aus dem zweiten Kern zu ziehen, noch nah genug an XP64 heranzukommen. Das Ergebnis wäre klar und die Welt einfach zu verstehen, wenn nicht das Intel/nVidia-System etwas dagegen hätte:
Nun weist zwar Vista64 Verluste in zwei Szenen auf, dafür kümmert sich XP64 nicht um den Verlust eines Kerns. Am Endergebnis, dass Vista64 noch immer zu weit im Rückstand liegt, ändert das erst recht nichts mehr. Generell scheint das Core-2-System stabiler auf künstliche Leistungsbremsen zu reagieren, als das für den spürbar gealterten K8 der Fall ist. Warum Vista64 genau jetzt eine Ausnahme macht, bleibt aber ein Rätsel.
Wer Ergebnisse zu Vista32 vermisst, der findet hier eine kleine Auswahl. Die Performance war aber zu nahezu jeder Zeit vergleichbar mit Vista64:
Insgesamt waren wir sehr überrascht von den Ergebnissen, die 3DMark uns hier präsentiert hat. Zu Beginn, mit Edition 2001, fühlten wir uns mehr als bestätigt. Je exklusiver sich der Fokus auf die Rendertechnik und GPU-Effekte verschob, desto verschwommener wurde jedoch unser Bild. Ab dem 3DMark2003 gibt sich Vista64 keine Blöße mehr und das ist auch genau das, an was man sich aus den vielen Launch-Reviews des neuen Microsoft-Betriebssystems erinnert.
Eine gesicherte Erklärung hierfür gibt es nicht. Vielleicht wirken hier die sorgfältigen Optimierungen der Treiber auf 3DMark und im Gegenzug dessen Optimierung auf DirectX. Auf der anderen Seite zeigt gerade das System mit der weitaus schnelleren Core-2-CPU auch weniger Rückstand. So oder so, die wichtige Erkenntnis, die es mitzunehmen gilt, lautet: Es gibt Beispiele, in denen Vista64 keinen Rückstand aufweist – und wo einer ist, da existieren mehr.
Aus den vorherigen Ergebnissen könnte man folgern, dass moderne Spiele und Engines diese Probleme gar nicht erst aufweisen. Comanche4 und UT2004 sind nun nicht gerade die jüngsten Titel, gleiches gilt für den 3DMark2001. Um diesen Artikel nicht als Nostalgie-Center zu beenden, schließen wir mit dem brandneuen Command & Conquer: Red Alert 3. Strategiespiele legen traditionell mehr Wert auf CPU-Leistung als viele Ego-Shooter dies tun. Sobald sich viele Einheiten über Wegfindung und Kollisionsabfrage streiten, Partikeleffekte den Bildschirm überdecken und die KI unermüdlich ihre Skripts überprüft, gehen selbst starke Rechner in die Knie.
Wir wollen zwei dieser stressigen Szenen mit Fraps insgesamt 30 Sekunden auf den Zahn fühlen, wobei nur die ersten Sekunden wirklich Action zeigen. Der Rest besteht aus Sound, vielen Einheiten, Wegfindung und Kollisionsabfrage. Den Anfang macht, wie immer, das AMD-System mit der Radeon HD 2900 XT. Als Auflösung haben wir uns für 1280x1024 entschieden, wobei weder Antialiasing noch anisotroper Filter zum Einsatz kommen. Alle Details stehen auf "High", Vsync wurde deaktiviert. Aber auch so läuft Red Alert 3 bei knapp 30 fps in einen gewollten Begrenzer.
Gleich der erste Durchgang bescheinigt Vista64 eine derbe Schlappe. Der Einbruch im ersten Drittel ist hier viel ausgeprägter, so dass der Spieler definitiv einen Slowdown bemerkt. Im Spielverlauf sind solche Szenen häufig anzutreffen. XP64 fällt nicht ganz so tief und trifft kurz darauf auf den Begrenzer, welchen Vista64 gar nicht erst erreicht.
In Szene 2 geht es noch etwas härter zur Sache, so dass nun auch unter XP64 die CPU spürbar an ihre Grenzen gelangt:
Ein ähnliches schlechtes Ergebnis für Vista64, wobei man hinzufügen muss, dass beide Verläufe schwer einbrechen und der Unterschied am kritischsten Punkt relativ gering ausfällt. Insgesamt dürfte und wird ein Spieler die Unterschiede zwischen den Betriebssystemen sehr wohl spüren. Aus purem Interesse können wir noch mögliche GPU-Limitierung entfernen und die CPU bei 1.2 GHz betreiben.
Die Unterschiede fallen naturgemäß etwas geringer aus, da die Frameraten nun recht niedrig angesetzt sind. Das vorläufige Ergebnis bleibt allerdings, dass schwächere CPUs unter Vista64 ordentlich schwitzen müssen. Dies schreit nahezu nach einem Vergleich mit nur einem Kern, den wir an dieser Stelle auch gern antreten wollen.
Vista64 rutscht mit einem Kern endgültig in einen Performancebereich, in dem wenig Spaß aufkommen will. Ein Reduzieren der Detailstufe ist unabwendbar. XP64 kann sich dagegen behaupten und liefert einen etwas zähen, aber vertretbaren Spielfluss.
Nun haben wir in Beispielen zuvor bereits bemerkt, dass XP64 anscheinend größeren Nutzen aus einem zusätzlichen Kern ziehen kann. Inwiefern dies unter Red Alert 3 der Fall ist, wollten wir mit einem weiteren Diagramm überprüfen. Das Resultat wirft kein gutes Licht auf Vista64.
Demnach reicht XP64 ein einzelner Kern, um mit dem Zweikern-K8 in Vista64 gleich zu ziehen. Zwar gewinnt auch Vista durch DualCore, jedoch bei weitem nicht vergleichbar viel. Der Umstieg auf eine DualCore-CPU mit ähnlicher Taktrate und Vista64 dazu würde sich in diesem Spiel als völlige Geldverschwendung herausstellen. Überhaupt liegt Vista in jeder denkbaren Konstellation weit zurück und beeinträchtigt das Spielgefühl erheblich.
Im nächsten Schritt wollten wir daher wissen, wie sich Red Alert 3 und Vista bei einer weitaus schnelleren CPU verhalten. Das Intel/nVidia-System durchläuft die gleichen Benchmarks und beschert uns gleich die nächste Überraschung.
Zwei Tatsachen fallen sofort auf: Zum einen sind die Unterschiede zwischen allen drei Testsystemen geradezu vernachlässigbar, zum anderen erreicht das Testsystem die 30-fps-Marke nicht. Am oberen Ende liegt man ein gutes Stück hinter dem K8 und der HD2900XT, am unteren Ende erreicht man nur minimale Vorteile. Ein kurzer Gegentest mit 800x600 Bildpunkten zeigt, das die 8800GTS hier tatsächlich ein Limit erreicht. Dabei kommen weder Bildverbesserungen, noch die maximale Detailstufe zum Einsatz. Ein Treiberwechsel brachte auch keine Besserung.
Bei 800x600 läuft zwar auch das Intel-System in den Frameratenbegrenzer, am Gleichstand zwischen XP64 und den beiden Vista-Versionen ändert dies aber nichts. Hinzu kommt ein weiteres Phänomen hinzu, das wir so nicht erwartet hätten. Um den Einfluss einer langsameren CPU zu simulieren und den Nutzen einer DualCore-CPU abzuschätzen, wird erneut ein Kern deaktiviert.
Wir sind uns der einschläfernden Gefahr bewusst, die durch die Abbildung immer gleicher Diagramme entsteht. Allerdings lässt uns das Intel-System keine Wahl: Red Alert 3 läuft so schnell wie zuvor. Dies hätten wir eben nicht erwartet, fallen die Unterschiede bei K8 und Radeon doch so gravierend aus. Mit Hinblick auf die ebenfalls überraschenden Ergebnisse im 3DMark2001, könnte man zur Erkenntnis gelangen, DualCore-Optimierungen spielen hier keine Rolle. Sollten die Performancevorteile auf die AMD-Platform beschränkt bleiben? Aber welchen Sinn ergäbe dies?
Nun wollen wir nicht einfach ohne weiteres hinnehmen, dass Vista64 auf dem Intel-System keine Performanceunterschiede aufweist und zudem die Reaktion der beiden Betriebssysteme auf den simulierten SingleCore ausbleiben. Wir gehen aufgrund der bisherigen Ergebnisse davon aus, dass Vista definitiv irgendwo zwischen CPU und GPU an Leistung verliert.
Unsere nächste Idee entstammt zu Teilen bereits dem Nachfolger dieses Artikelteils. Demnach kann der Core 2 die anfallenden Leistungsverluste eventuell durch schiere Rechenleistung verstecken. Je moderner und GPU-lastiger die Engine, desto geringer der Effekt. Mit lediglich 2 GHz sollen Core 2 und 8800GTS die Tests also erneut durchlaufen. Der vorherige Durchlauf mit 3 GHz dient dabei als Vergleichswert.
Schon wieder langweilig? – Der grüne Verlauf soll Abwechslung fürs Auge erzeugen, denn wir hätten ihn uns auch genau so gut sparen können. Allenfalls Vista64 in rot, zuckt mit 2 GHz ganz minimal. Eigentlich kaum der Rede wert, wäre da nicht ...
Und da passiert es – ganz plötzlich und ohne erkennbare Andeutungen in all den vorherigen Tests: Auch das Intel/nVidia-System zieht also seinen Nutzen aus dem zweiten Kern. XP64 schwächelt am kritischen Punkt kurz, findet dann aber den Weg zurück zum Begrenzer. Auf Vista64 geht dem Core 2 dagegen die Puste aus. Der Unterschied im Spielgeschehen ist deutlich zu spüren, der Frameratenbegrenzer unerreicht. Bis zu diesem Punkt konnte der Core 2 also jederzeit genug Leistung aufbringen, um den Effekt zu kaschieren. Gäbe es die Begrenzung nicht, der Unterschied wäre vielleicht schon in den ersten Benchmarks zu erkennen gewesen, wenn auch nie zu spüren.
Die letzten Überlegungen bilden die Basis für unser zweites Fazit. Über drei ganz unterschiedliche Spiele und der 3DMark-Serie haben wir teils gravierende Leistungsverluste für Vista 32-Bit und 64-Bit feststellen müssen. Dabei scheint es egal, ob nun rein AMD oder Intel/nVidia. Allerdings zeigt sich deutlich, dass das wesentlich schwächere AMD-System weitaus stärker unter den Verlusten zu leiden hat. Dies geht so weit, dass selbst ältere Titel mit hoher CPU-Last ins Straucheln kommen können. Den Core 2 lässt dies insofern kalt, dass wir in Red Alert 3 geradezu ins Extreme gehen mussten, um ihm etwas Performance abzuringen. Hier wirkt Vista für den einen User (K8) wie ein Downgrade, während der andere (Core 2) gar nicht nachvollziehen kann, warum man sich denn aufregt.
Die 3DMark-Serie zeigt sich dagegen von ihrer verwirrenden Seite. Was prinzipielle Unterschiede zwischen Renderpfaden aufzeigen sollte, endet in einem relativ respektablen Ergebnis für Windows Vista. Dabei ist es wieder die langsamere CPU, welche groß Federn lassen muss. Immerhin zeigen sich im 3DMark2001 die inzwischen lieb gewonnen 20-30% Verluste für Vista. Insbesondere fällt auf, wie gut sich Vista ohne HW-T&L wieder fangen kann. Für die Jahre danach ist unklar, warum die Unterschiede verschwinden, es dürfte jedoch am starken Fokus auf die GPU-Peformance liegen.
Immerhin zeigen Comanche4 und Unreal Tournament 2004 ganz deutlich, was passiert, wenn die CPU zur Zwangsarbeit verdonnert wird. Die fehlenden GPU-Limits lassen den Unterschied zwischen XP und Vista in jeder Situation klar erkennen. Zudem lässt sich nach diesen Ergebnissen auch eine Schwäche für Soundberechnungen in Vista attestieren. Allerdings nur einige Prozent und mit zunehmender Unterstützung für OpenAL auch vernachlässigbar. Ganz klar überrascht hat uns die Performance der DirectX9-Variante der 64-Bit UT2004-Benchmarks. Im Zusammenspiel von 64-Bit DirectX, 64Bit-Anwendung und OpenAL konnte Vista den Rückstand in diesem einen Spiel vollständig wett machen.
Es gibt also Unterschiede zwischen Vista und XP, je nach dem, wie schnell die Schaltzentrale des PCs ihre Arbeit verrichtet. Ob nun eine AMD- oder nVidia-Karte Dienst verrichten, scheint gar nicht so wichtig zu sein. Auch gibt es keinen konkreten Ansatzpunkt für eine eindeutige Erklärung der beobachteten Effekte. Klar ist nur eines: Wer potentiell langsamere Systeme mit Vista betreibt, muss durchaus mit spürbaren Performanceverlusten rechnen. Besitzer von HighEnd-Systemen merken dies gar nicht erst und werden, aufgrund von Meßmethoden wie Average-fps und Timedemos, eventuell nicht einmal einen Unterschied messen können. Spürbar verlangsamt hat sich kein getesteter Titel auf dem Core-2-System. Was das im Zeitalter von 2.6 GHz+ CPUs und 4 Kernen bedeutet, dürfte klar sein.
Ob und wie sich das auf ganz aktuelle Titel auswirkt, werden wir im dritten Teil des Artikels betrachten. Red Alert 3 ist nicht unbedingt das beste Beispiel, um moderne Engines zu vertreten. Im Test von HT4U hat sich bereits angedeutet, dass weitere aktuelle Titel Verluste aufweisen. Ebenso aufgefallen ist den Kollegen das teils absonderliche Verhalten von Spielen mit DX10-Renderpfad. Zur Debatte steht also, wie gut sich K8 und Core 2 in den wirklich komplexen Zusammenhängen zwischen CPU und GPU bei aktuellen Ego-Shootern behaupten – ja man muss schon fast sagen, wie gut sie sich gegen Vista behaupten.
Verweise:
[1] https://www.3dcenter.org/users/blackbirdsr
[2] https://www.3dcenter.org/artikel/performancereport-windows-xp-gegen-vista-teil-1
[3] http://ht4u.net/reviews/2008/windows_vista_performancecheck/
[4] http://www.forum-3dcenter.org/vbulletin/showthread.php?t=441485
[5] https://www.3dcenter.org/dateien/abbildungen/C4_1.png
[6] https://www.3dcenter.org/dateien/abbildungen/C4_2.png
[7] https://www.3dcenter.org/dateien/abbildungen/C4_3.png
[8] https://www.3dcenter.org/dateien/abbildungen/C4_4.png
[9] https://www.3dcenter.org/dateien/abbildungen/C4_5.png
[10] https://www.3dcenter.org/dateien/abbildungen/C4_6.png
[11] https://www.3dcenter.org/dateien/abbildungen/C4_7.png
[12] https://www.3dcenter.org/dateien/abbildungen/UT2004_1.png
[13] https://www.3dcenter.org/dateien/abbildungen/UT2004_2.png
[14] https://www.3dcenter.org/dateien/abbildungen/UT2004_3.png
[15] https://www.3dcenter.org/dateien/abbildungen/UT2004_4.png
[16] https://www.3dcenter.org/dateien/abbildungen/UT2004_5.png
[17] https://www.3dcenter.org/dateien/abbildungen/UT2004_6.png
[18] https://www.3dcenter.org/dateien/abbildungen/UT2004_7.png
[19] https://www.3dcenter.org/dateien/abbildungen/UT2004_8.png
[20] https://www.3dcenter.org/dateien/abbildungen/UT2004_9.png
[21] https://www.3dcenter.org/dateien/abbildungen/UT2004_10.png
[22] https://www.3dcenter.org/dateien/abbildungen/UT2004_11.png
[23] https://www.3dcenter.org/dateien/abbildungen/UT2004_12.png
[24] https://www.3dcenter.org/dateien/abbildungen/UT2004_13.png
[25] https://www.3dcenter.org/dateien/abbildungen/3DMark_1.png
[26] https://www.3dcenter.org/dateien/abbildungen/3DMark_2.png
[27] https://www.3dcenter.org/dateien/abbildungen/3DMark_3.png
[28] https://www.3dcenter.org/dateien/abbildungen/3DMark_4.png
[29] https://www.3dcenter.org/dateien/abbildungen/3DMark_5.png
[30] https://www.3dcenter.org/dateien/abbildungen/3DMark_6.png
[31] https://www.3dcenter.org/dateien/abbildungen/3DMark_7.png
[32] https://www.3dcenter.org/dateien/abbildungen/3DMark_8.png
[33] https://www.3dcenter.org/dateien/abbildungen/3DMark_9.png
[34] https://www.3dcenter.org/dateien/abbildungen/3DMark_10.png
[35] https://www.3dcenter.org/dateien/abbildungen/3DMark_11.png
[36] https://www.3dcenter.org/dateien/abbildungen/RA3_1.png
[37] https://www.3dcenter.org/dateien/abbildungen/RA3_2.png
[38] https://www.3dcenter.org/dateien/abbildungen/RA3_3.png
[39] https://www.3dcenter.org/dateien/abbildungen/RA3_4.png
[40] https://www.3dcenter.org/dateien/abbildungen/RA3_5.png
[41] https://www.3dcenter.org/dateien/abbildungen/RA3_6_0.png
[42] https://www.3dcenter.org/dateien/abbildungen/RA3_7.png
[43] https://www.3dcenter.org/dateien/abbildungen/RA3_8.png
[44] https://www.3dcenter.org/dateien/abbildungen/RA3_9.png
[45] https://www.3dcenter.org/dateien/abbildungen/RA3_10.png
[46] https://www.3dcenter.org/dateien/abbildungen/RA3_11.png
[47] https://www.3dcenter.org/dateien/abbildungen/RA3_12.png
[48] https://www.3dcenter.org/dateien/abbildungen/RA3_13.png