Performancereport Windows XP gegen Vista, Teil 1
Performancereport Windows XP gegen Vista
Ein ewiger Streit – XP vs. Vista! Läuft Windows Vista nun langsamer oder nicht? – Ist Windows XP noch immer das bessere System für Spiele? Die Einen sind felsenfest davon überzeugt, dass Vista spürbare Performanceeinbußen mit sich bringt. Die Anderen halten mit Benchmarks dagegen. Tatsächlich gibt es relativ viele Print- und Onlinemagazine, sowie haufenweise Spieler, die sich genau mit diesem Thema beschäftigt haben.
Dieser Performance-Vergleich hat also schon regelrecht Volkssport-Charakter. Das 3DCenter will hier natürlich ebenfalls mitmischen und mit weiteren Spiele-Benchmarks mehr Stoff für Diskussionen liefern. Allerdings haben wir uns zum Ziel gesetzt, etwas aufwändiger und etwas anders für Zündstoff zu sorgen.
[2]Performanceverlust in Comanche4 [3]
Wir glauben, dass sich gelegentlich Performance-Tests durch grundlegende Probleme mitunter ausmanövrieren, sich die Antwort auf viele Fragen quasi selbst verwehren. Um das zu beweisen und die dritte Seite der Medaille zu finden, müssen wir frech sein. Wir werden ungewohnte Methoden ausprobieren und Hinweisen folgen, die sonst jeden Zeitrahmen für ein normales Review sprengen. Und gerade weil wir je nach Situation eigene Regeln aufstellen, um hoffentlich korrekte Ergebnisse zu erzielen, kann dieser Artikel kein (noch) Prototyp für zukünftige Tests sein.
Vielmehr wird sich die Suche nach der Antwort über drei Teile ziehen. In diesem ersten Teil soll die eigentliche Problematik erforscht werden. Neben der Veranschaulichung unserer Sichtweise des Begriffs "Benchmarking" beinhaltet das auch eine nähere Betrachtung von Vista und erste Performanceeinschätzungen. Teil 2 und 3 des Artikels werden sich anschließend ausschließlich den Benchmarks bzw. dem Fazit zuwenden.
[4]
Das Benchmarkmonster
Das Benchmarkmonster
Wer schon jetzt die ersten großen Vergleiche erwartet, muss sich noch ein wenig gedulden. Wie bereits angedeutet, sind die eingesetzten Methoden etwas ungewöhnlich, bzw. auf den ersten Blick unübersichtlich. Üblicherweise kommen einheitliche Balkendiagramme oder einzelne Messwerte zum Einsatz. Die Masse an verschiedenen Spielen oder Anwendungen führt dann zu einer großen Aneinanderreihung von, mehr oder weniger nützlichen, Ergebnissen. Für die Interpretation sind Werte und Leser dann oftmals selbst zuständig. Anstelle einer einheitlichen und leichter erfassbaren Präsentation wollen wir daher Erklärungen und Diskussionen selbst diese Aufgabe übertragen. Ob dieser Ansatz Erfolg hat, wird sich erst mit der letzten Seite zeigen müssen.
Die nächsten Minuten wird sich der Artikel vor allem mit dem Begriff "Benchmarking" befassen. Wir finden, dass dieses Wort so viele Möglichkeiten, Fehler und Unsicherheiten enthält, dass man den Leser zuerst eingehend an die eigene Sichtweise heranführen sollte. Sichtweise deswegen, weil keine Benchmark-Methode korrekt oder gar perfekt sein kann. Ein wenig lässt sich die Sache mit der Unschärferelation vergleichen, zumindest wenn man unverschämt ist. Denn auch hier gibt es zwei Zustände, die sich gegenseitig ausschließen. Entweder erhält man hohe Genauigkeit und zuverlässige Werte, oder man schrumpft den Zeitbedarf auf ein effizientes Maß. Beides zusammen ist der vergebliche Wunschtraum gar vieler Redakteure.
Timedemos und Durchschnittswerte
Eines der bisher größten Probleme, mit denen jeder Artikel zu kämpfen hat, sind Timedemos. Diese unglaublich beliebten, unkomplizierten Hilfsmittel, waren über Jahre hinweg die einzige Methode, um CPUs oder Grafikkarten zu testen. Freilich hat Anfang der 90er keiner einen Gedanken an praxisfremde Testumgebung oder spezifische Treiberoptimierungen verschwendet. Selbst als erste Zweifel aufkamen, war die Versuchung immer noch sehr groß: Programmaufruf, kurz warten, Ergebnis notieren und fertig.
Wo genau liegt nun das Problem bei üblichen Timedemos? Nicht alle, aber viele Timedemos vernachlässigen gegenüber der eigentlichen 3D-Darstellung fundamentale Bereiche des eigenen Spiels. Es kann sich dabei um die "KI" von Bots, Einheiten in Strategiespielen oder um die Input-Routinen des Benutzers handeln. Auch die Berechnung des Sounds fällt oftmals in diese Kategorie. Sogenannte "Flybys" setzen sogar noch einen drauf: Entlang vorgegebener Bahnen wird eine Demo abgespielt, der meist jeglicher Bezug zum Spielgeschehen selbst fehlt. Kaum besser: Introsequenzen in der Spiele-Engine.
Aber warum regen wir uns auf? Schließlich interessieren doch nur vergleichbare Werte bei CPU- oder GPU-Benchmarks, und da scheint es doch egal, wie diese entstanden sind? Prinzipiell richtig, allerdings verlieren sich somit wichtige Informationen zur benötigten CPU, sowie des echten Spielgefühls auf der genutzten Hardware. Wie dieses Problem aussehen könnte, wollen wir anhand des nächsten Diagramms erläutern (wer mehr Beispiele sehen will, kann sich die verschiedenen früheren Performancereports auf 3DCenter zu Gemüte führen).
[5]Forderndes Comanche4-Timedemo [6]
Zu sehen ist der Frameverlauf eines Comanche4-Timedemos. Da Comanche4 schon einige Jahre auf dem Buckel hat, ist ein Ergebnis von 98,6 Frames pro Sekunde wenig verwunderlich. Die interessieren aber wahrscheinlich eh keinen mehr, sobald man den bösen Einbruch in der Mitte bemerkt hat. Um es vorwegzunehmen, das ist kein Fehler. Hier gerät selbst Intels 3-GHz-Monster in Bedrängnis und liefert kurzzeitig nur noch 34 fps. Halb so wild möchte man denken, schließlich bewegt sich der Rest auf sehr hohem Niveau. Alles prima also! Allerdings haben wir rein zufällig auch eine Szene aus dem eigentlichen Spiel anzubieten.
Steht das Diagramm jetzt Kopf? Tatsächlich hat dieses Diagramm mit dem ersten nur den Namen des Spiels und die Auflösung gemein. Über knappe 30 Sekunden haben wir ein paar Raketen in die Bäume gefeuert und uns ein wenig auf und ab bewegt. Das alleine genügt, um die Ergebnisse des Timedemos quasi umzukehren. Und hier wurde nicht annähernd so viel an Effekten und Geometrie gezeigt, wie es bei richtigen Kämpfen im Spiel vorkommen kann und wird. Werte unter 40 fps sind also nicht nur einmalig, sondern durchaus über längere Zeit im Spiel vertreten. Und zur Erinnerung, wir reden hier über einen 3 GHz Intel Core 2 Duo. Aus dem ersten Diagramm lässt sich das alles nicht erahnen. Schlimmer noch, wer nur den Durchschnitt von 98,6 bzw. 76,4 fps angibt, erzeugt beim Leser einen völlig falschen Eindruck.
Durch Beobachtungen wie diese ist 3DCenter der Meinung, dass Timedemos nur noch sehr eingeschränkt zu gebrauchen sind. Vertrauen sollte man nur noch den Timedemos, von denen man um die Ähnlichkeit zum Spielgeschehen weiß. Oder aber, wenn man genau vor Augen hat, was man erreichen will. So ist der reine Vergleich zweier Grafikchips für die Abschätzung der Antialias-Leistung wohl noch über eine Timedemo durchführbar. Kommt die CPU ins Spiel, sieht die Sache aber schnell anders aus. Das spiegelt sich auch im Durchschnittswert (average-fps) wider, welcher kaum Aussagen zum Ablauf der Demo machen kann.
Was ist die Alternative? Es gibt durchaus Situationen, in denen eine Timedemo ausreicht. Wichtig ist, diese genau zu kennen. Denn liegt man mit der Timedemo richtig, gewinnt man einen unschätzbaren Zeitvorteil gegenüber den folgenden Methoden. Mittels Savegames werden dagegen echte Spielszenen nachgespielt und über Fraps aufgezeichnet. Das ist sicherlich der erste lobenswerte Schritt, den einige Tester mitgegangen sind. Allerdings sollte man dann nicht über die Durchschnittswerte stolpern! In der Praxis liegt der Mehraufwand weit höher als bei Timedemos. Neben der Suche nach geeigneten Stellen für jede gewünschte Situation muss der Tester jeden unnatürlichen Framerateneinbruch erkennen und aussortieren. So ein Test kann im Grunde nicht ohne die vollständige Aufmerksamkeit des Testers vonstatten gehen.
[4]
Frameverläufe
Frameverläufe
Die selektive Betrachtung von Frameratenverläufen ist eine andere Methode, die bisher viel zu selten Einsatz gefunden hat. Prinzipiell ist diese selektive Betrachtung nichts anderes, als was wir in den letzten beiden Diagrammen sehen konnten. Anhand aufgezeichneter Frameratenverläufe wird eine längere Szene im Spiel oder Timedemo analysiert. Durch Vergleiche und verschiedene Einstellungen können somit ungleich mehr Informationen gewonnen werden.
Anstelle des einzelnen Minimums rückt die Gesamtheit aller Werte in den Vordergrund. Im letzten Diagramm lässt sich somit nicht nur erkennen, dass die 150 fps Spitze eher die Ausnahme sind, sondern dass der Spieler in der Regel mit Werten zwischen 30- und 60 fps rechnen kann. Kennt man die ausgewählte Szene, lassen sich zudem Reserven und Schwächen von CPU und GPU relativ gut abschätzen.
Mit folgendem Diagramm lässt sich einer der weiteren Vorteile demonstrieren.
Dabei zeigt der blaue Verlauf die uns bereits bekannte Timedemo aus Comanche4, nutzt jetzt allerdings eine höhere Auflösung. Am prinzipiellen Verlauf ändert sich wenig, limitiert doch die CPU in nahezu jeder Situation. Würde man beide Verläufe übereinander legen, ließe sich auch genau dies erkennen.
Wir haben uns allerdings für den neuen roten Verlauf entscheiden, welcher die gleiche Timedemo mit 16xQ-Antialiasing und Supersampling-Transparenz-Einstellung zeigt. Innerhalb weniger Sekunden lässt sich nun erkennen, wo die Grafikkarte schlapp macht (siehe die ersten 9 Sekunden) oder die CPU noch immer den Miesepeter spielt (z.B. 15.-21. Sekunde). Als großen Pluspunkt vermerken wir also neben der Gesamtbetrachtung die direkte Vergleichbarkeit von Timedemos und Ergebnissen.
Diese Methode hat allerdings auch ihre Schwierigkeiten – damit meinen wir nicht den leider viel zu hohen Aufwand für den Redakteur. Es ist sicherlich sofort aufgefallen, dass der blaue Verlauf früher endet. Zugleich tritt der schwere Einbruch auf unter 40 fps viel früher ein. Dies liegt an der Eigenheit des Comanche4-Timedemos, die Szene mit voller Framerate abzuspielen. Logischerweise erreicht es spezifische Punkte damit eher und endet früher. Erfreulich ist, dass in diesem Fall relevante Stellen im Ablauf relativ einfach im Kopf übereinandergelegt werden können.
Mit etwas Übung und Glück lässt sich sogar eine statische Verzögerung festlegen, und die schnellere Demo im Diagramm später starten. Das funktioniert allerdings nur in den wenigen Fällen, in denen viele Stellen identische Performance aufweisen, so gut wie hier:
Durch die hier eingefügte Konstante (schwarz) bei 120 fps verliert man zwar etwas an Vergleichskraft, was die ersten Sekunden betrifft, erreicht dafür allerdings eine gute Übereinstimmung im Rest der Demo. Jetzt fällt auch ohne Übung sofort auf, dass nach dem ersten Drittel der Demo nahezu ausschließlich die CPU limitiert. Es liegt sicherlich an der Engine von Comanche4, trotzdem ist die Sache eigentlich ein Armutszeugnis für die CPU. Was vielleicht noch auffällt: Die recht holprige Anfangsphase wirkt im blauen Verlauf arg geglättet. Dieser Effekt ist typisch für Stellen, an denen die CPU nichts zu sagen hat. Allerdings ist der Effekt in der Regel nicht so extrem ausgeprägt wie hier.
In wenigen Schritten haben wir so eigentlich die ganze Timedemo analysiert. Ob man nun mit verschiedenen Taktraten, Sound oder Auflösungen experimentiert, ist relativ egal. Mit dem bisherigen Wissen lässt sich entweder jeder Verlauf abschätzen oder unerwartete Ergebnisse zumindest erklären. Wiederholt man das Ganze noch mit der Szene aus dem eigentlichen Spiel, hätte Comanche4 als Benchmark jedes Geheimnis eingebüßt. Aber es geht uns ja um Windows Vista und nicht um Hubschrauber-Simulationen.
[4]
Das Gesamtbild
Das Gesamtbild
Manche mögen an dieser Einführung in Verlaufsdiagramme nichts neues entdecken. Zu Beginn sprachen wir jedoch von neuen Methoden und selbst erstellten Regeln. Das war in den letzten Minuten dann auch der Fall. So wie diese Einführung soll der Test aussehen. Wichtige Diagramme, die für Verständnis und Erkenntnis nötig sind, sollen nicht einfach im Raum stehen. Wann immer möglich, soll der Leser an der Diskussion teil haben können. Dazu gehört auch, dass Gedankengänge deutlich werden. Warum wurde dieser Benchmark ausgeführt, welche Schlussfolgerungen zieht der Autor daraus, wie kommt er auf die Idee, den Test nun mit diesen Einstellungen zu tätigen?
Oftmals ist "Benchmarking" nur eine Ansammlung von Standard-Applikationen mit Standard-Auflösungen/Einstellungen und kopierten Texten zur Erklärung des Programms. Dabei sollten Resultate und Schlussfolgerungen im Vordergrund stehen, das benutzte Programm entweder im voraus erklärt oder während des Tests analysiert werden. Unwichtige Ergebnisse haben im Test nichts zu suchen und können allenfalls als Beweis für später zurückgehalten werden. Warum den Leser mit unnötigen Diagrammen überhäufen? Eine Rechtfertigung dazu im Textteil des Artikels sollte genügen.
Sicherlich setzt das ein hohes Maß an Vertrauen in den Autor voraus. Allerdings gilt die berechtigte Frage, ob dies nicht sowieso schon der Fall ist? Muss der Leser bei Timedemo und Durchschnittswerten, selbst bei der Auswahl an Savegames, nicht vollstes Vertrauen in den Autor legen? Vielleicht entsteht Vertrauen, wenn der Leser nicht nur im Fazit an den Gedanken des Autors teilhaben kann. Dies ist unsere Philosophie für die folgenden Seiten. Wir hoffen, dass neben dem Ergebnis auch der eigentliche Weg dahin deutlich wird. Und letztlich hoffen wir, damit auch Vertrauen und Glaubwürdigkeit zu gewinnen.
Der Testablauf
Bevor es losgeht, müssen wir noch den einen oder anderen Punkt erläutern. Da uns der Performancevergleich zwischen Windows XP und Windows Vista interessiert, soll uns jedes funktionierende Mittel recht sein. Egal ob dies nun Durchschnittswerte, Timedemos oder echte Spielszenen sind. Hat sich eine Methode für uns im Test als gut und vernünftig bewiesen, sind deren Nachteile in allen anderen Bereichen logischerweise völlig vernachlässigbar. Wichtig ist nur, dies auch begründen zu können.
Der überwiegende Anteil an Tests wird zwar durch Verlaufsdiagramme dargestellt, der Durchschnittswert sollte trotzdem immer mit angegeben werden. Zum einen um darzustellen, ob und wie weit dieser Wert daneben liegt, zum anderen lässt sich damit ab und an ein langwieriger und komplizierter Vergleich einsparen.
Zum Schluss sollten wir noch über den "leicht unübersichtlichen" Teil reden. Nicht alle Diagramme werden so einfach und schnell erfassbar sein wie im Diagramm zu Comanche4. Hier eines der schöneren Beispiele:
Nicht erschrecken, selbst dieses Durcheinander hat Zweck und Aussagekraft. Auf die Beschriftung wurde speziell verzichtet. Der Trick besteht darin, den abstrakten, aber wichtigen Anteil auszufiltern. Wir sehen drei vermeintlich unterschiedliche Abläufe. Daher sollte man gar nicht erst versuchen, die Diagramme übereinander zu legen, es wird schlicht und einfach nicht funktionieren. Was sagt uns das Chaos? Zum einen verhalten sich alle drei Diagramme nahezu identisch. Sobald man nicht mehr einzelne Punkte, sondern den Verlauf als Ganzes betrachtet, ist das relativ gut zu sehen. Ohne erkennbare Vor- oder Nachteile liegen sie alle drei zwischen 30fps und 60fps.
Wir werden später sehen, dass diese relativ gleichmäßige Suppe auf eine starke GPU-Limitierung hindeutet. Im speziellen handelt es sich um unterschiedliche Durchläufe des gleichen Levels mit hoher Auflösung und Anti-Aliasing. Interessant ist der Durchschnitt von 42 fps, den alle gleichsam erreichen. Zusammen ergeben beide Informationen ein rundes Bild, der Durchschnitt alleine verrät jedoch nichts mehr über die Szene selbst. Für alle weiteren Diagramme werden wir, der Übersichtlichkeit zuliebe, meist nur zwei Verläufe zusammen darstellen und werden zudem immer den Durchschnitt angeben.
[4]
Die Vista-Problematik
Die Vista-Problematik
Microsoft sieht Windows Vista als einen revolutionären Schritt. In vielen Bereichen, wie Sicherheit und Treibermodellen, ist er das auch. Manche Benutzer sehen in Windows Vista dagegen oftmals das Anti-Windows. Nervige Schutzabfragen, Treiberproblematik und hohe Systemanforderungen werden als Gründe angeführt. Durch Probleme wie diese ist der Nachfolger von Windows XP bisher nicht so erfolgreich, wie er sein könnte.
Ganz besonders schwer liegt Vista wohl der Stein im Magen, auf dem groß "Spiele" steht. Sicherlich, man besitzt mit DirectX10 ein exklusives Feature, mit dem der Vorgänger nicht aufwarten kann. Diesen Trumpf konnte Vista bisher jedoch nicht ausspielen. Ganz im Gegenteil: Viele Spiele mit DirectX10-Support werden erst einmal langsamer. Ob wegen zusätzlichen Effekten oder Implementierungsdetails ist ja auch egal. Sehr negativ wirken sich aber immer wiederkehrende Meldungen aus, dass Vista auch bei anderen Spielen Performanceeinbußen mit sich bringt. Und dem gehen wir nach!
Generell besteht die Annahme, dass Windows Vista ohne vorherige Entschlackung mit angezogener Handbremse läuft. Eine Vielzahl von Diensten, Prozessen und Hintergrundaktivitäten soll der Performance entgegenwirken und Usern auf den Geist gehen. Dem liegt ein wahrer Kern zugrunde. Zum einen werden in Windows Vista schon von Beginn an mehr Dienste gestartet, als es bei Windows XP der Fall ist. Zum anderen ist Windows Vista weit aggressiver, was Untätigkeit des Nutzers betrifft. Wenn gerade nichts zu tun ist, findet Vista etwas passendes zu tun. Nur muss dies zwingend schlecht sein?
Als Beispiel wollen wir einige oft vorgetragene Performancebremsen vorstellen und deren Einfluss abschätzen.
• Windows Vista Such-Index
Der Such-Index geht wohl als eines der "bösartigsten" Features in die Windows-Geschichte ein. Im Prinzip soll dieser Dienst Suchanfragen beschleunigen. Um den schnellen Zugriff auf Suchergebnisse zu gewährleisten, muss Windows Vista zuerst einen entsprechenden Index aufbauen. Langanhaltende Festplattenaktivität ohne ersichtlichen Grund können also durchaus vom Such-Index verursacht werden. Nun kann und sollte der Index nicht alle Daten auf dem PC umfassen. In der Systemsteuerung->System->Index-Optionen kann angepasst werden, welche Ordner im Index enthalten sein sollen.
Wie wirkt sich die Indexerstellung auf die Performance aus? Es ist durchaus richtig, dass die Erstellung sehr viel Zeit in Anspruch nehmen kann. Auch ist die Festplatte währenddessen quasi im Dauereinsatz. Allerdings nur, wenn keine Benutzeraktivität festgestellt wird. Dann fährt die Indexerstellung einen Gang zurück. Einen Performanceunterschied merkt der User in der Regel nicht. Insbesondere Spiele sollten vom Index nicht gestört werden. Natürlich kann der Dienst deaktiviert werden. Notebook-User mit einem Auge auf der Akkuanzeige oder User, die sich von längerer Festplattenaktivität gestört fühlen, könnten davon profitieren.
• Speicherverbrauch (Superfetch)
Wenn Vista ein großes Manko besitzt, ist es sicherlich die Speicheranforderung. Allerdings ist die Sache nicht so extrem wie gerne geschildert. Man sollte unterhalb der 1-GB-Grenze keine Wunder erwarten. Die panikartigen Hilferufe von Usern mit 2 GB Speicher, bei denen schon ab Start mehr als 1 GB "verbraucht" sind, sollte man aber etwas differenziert sehen. Auch auf dem Desktop des Autors (4 GB) werden nach dem Start bereits 1,5 GB Speicher als "belegt" angezeigt. Futsch, weg und für Spiele unerreichbar ist der aber mitnichten. Vielmehr arbeitet ein weiterer Vista-Dienst im Hintergrund aktiv daran, häufig benutze Dateien spekulativ in den Speicher zu laden.
Mit relativ hoher Wahrscheinlichkeit ist das nächste aufgerufene Spiel/Programm damit schon zu Teilen verfügbar. Verfolgen lässt sich z.B. nach dem Beenden von Crysis. Die Anzeige für den belegten Hauptspeicher liegt dann bei ca. 450 MB und steigt in den nächsten Sekunden wieder auf 1,5 GB an. Auch diese Funktion lässt sich deaktivieren, ein Performancegewinn ist eher unwahrscheinlich. Trotzdem stimmt es natürlich, dass eine frische Windows-Vista-Installation mehr Speicher für Dienste und Programme benötigt als, dies bei Windows XP der Fall ist.
• Aero-Oberfläche (3D-Beschleunigt)
Schon seit Windows XP sagt man sich, je weniger "Eye-Candy" desto besser. Bei Windows-Vista hat das User-Inferface noch einmal einen Schritt hin zu mehr Effekten und Funktionalität getätigt, inzwischen auch mit Beschleunigung durch eine DirectX9-fähige GPU. Dieses Aero muss bestimmt Performance kosten? Täte es auch, würde es während des Spiels weiter berechnet und im Hintergrund dargestellt werden. Tatsächlich verfällt Aero während einer Vollbildanwendung in einen Schlafzustand und zehrt damit nicht an der Grafikleistung.
Dieses Diagramm soll den Performancegewinn bei völlig deaktivierten Spielereien aufzeigen. Windows Vista erinnert dann wieder an die Oberfläche von Windows 2000. Einen wirklichen Performancegewinn erzielt man jedoch nicht. Man möge uns übrigens die geschwärzten Stellen verzeihen. Dem Diagramm begegnen wir sicher wieder, wollen allerdings nicht gleich vorgreifen. Zum Einsatz kam das Comanche4-Timedemo, die Werte sind in Frames pro Sekunde angegeben.
• Performanceverlust durch fehlende Soundbeschleunigung (kein Directsound)
Einer der Hauptkritikpunkte an Windows-Vista aus Spielersicht war/ist sicherlich die fehlende Unterstützung für DirectSound. Spiele, die vor dem Release von Vista auf den Markt kamen und kein OpenAL unterstützen, müssen auf Hardware-Beschleunigung verzichten. Das ist zwar ärgerlich, allerdings kein entscheidender Performancefaktor. Zum einen setzten die meisten PCs im Fachhandel auf schwächeren Onboad-Sound, zum anderen helfen Creative Labs und Realtek mit Wrappern nach.
Interessant ist nun die Frage, ob Vergleiche zwischen Vista und XP noch gültig sind, wenn beide auf unterschiedliche Soundbeschleunigung setzen? Bei OpenAL ist die Frage hinfällig. EAX und DirectSound bietet Vista dagegen gar nicht erst an. Hier könnten Benchmarks ins Straucheln kommen. Einen praktischen Vergleich liefert Unreal Tournament 2004. Hier gibt es neben einer CPU-berechneten Soundschnittstelle (Safe), auch Software-A3D und in der 64-Bit Version ausschließlich OpenAL.
Mit Primeval und Dria werden zwei Timedemos aus Unreal Tournament 2004 bezeichnet, die für unsere Zwecke hier völlig ausreichend sind. Die Differenz bezieht sich jeweils auf den Basiswert in der Tabelle (No Audio). Ohne Soundberechnung oder bei einfachen Berechnungen über die CPU (Safe) zieht Windows Vista offenbar gleich. Raumklang per Software oder OpenAL zeigen dann aber bereits einen messbaren Unterschied zugunsten von Windows XP. Dieser Auszug bestätigt sich auch bei weiteren Messungen. Inwiefern sich dieser geringe Unterschied in verschiedenen Spielen manifestiert, ist außer in UT2004 kaum abzuschätzen und wird in den großen Topf "Performanceverlust Ja/Nein?" fallen.
• Andere andauernde Festplattenaktivitäten
Wenn die Festplatte auch nach der Indexerstellung oder bereits gefülltem spekulativem Cache rattert, dann können andere Programme dafür verantwortlich sein. Mitunter sind die aber weit kritischer zu sehen. In Windows Vista ist standardmäßig eine Festplatten-Defragmentation per Task-Scheduler eingeplant. Die funkt mitunter auch schon einmal bei einem Spiel dazwischen. Gleiches gilt für den Microsoft-Defender, der gut und gerne dann einen System-Scan ausführt, wenn der Tester seinen Benchmark startet (und 3DCenter-Redakteure testen generell nur Nachts, zwischen 2 und 3 Uhr, zur Task-Scheduler "prime-time"). Beides ist allerdings deaktivierbar. Auch automatische Updates im Hintergrund oder Pop-Up-Fenster von Virenscannern beim Definitions-Update sind Störenfriede. Das gilt aber nicht nur für Windows Vista und sollte für jeden Benchmark beachtet werden.
[4]
Windows XP vs. Vista in Zahlen
Windows XP vs. Vista in Zahlen
Wir haben beinahe den Punkt erreicht, auf den der erste Teil dieser Artikel-Serie bisher hingearbeitet hat. Wir vergleichen Windows XP und Windows Vista, mit dem Ziel, die Frage nach der besseren Spieleplatform zu beantworten.
Der Herausforderer:
Auf der einen Seite wird Windows Vista SP1 in der 64-Bit-Version stehen. Wir sind der Meinung, dass ein 32-Bit Betriebssystem keine Zukunft hat und daher nicht mehr ausgewählt werden sollte. Inzwischen hat sich die Treibersituation entspannt und ältere Software läuft meist problemlos auf dem 64-Bit-System. Aktuelle Entwicklungen hin zu 4 GB Hauptspeicher, selbst in Fertig-PCs, lassen keine andere sinnvolle Empfehlung zu. Geld in eine 32-Bit-Version von Windows Vista zu investieren ist verlorenes Geld, hat man keine triftigen Gründe (z.B. Spezialhardware ohne 64-Bit Vista-Treiber). Als Besonderheit anzusehen ist die Notwendigkeit, 32-Bit-Software über die sogenannte WoW64-Schnittstelle zu betreiben. Der Benutzer bekommt davon jedoch nichts mit, während 32-Bit-Aufrufe für das 64-Bit-Windows übersetzt werden.
Die Vernachlässigten:
In einigen Benchmarks werden wir zudem Ergebnisse der 32-Bit-Versionen von Windows XP und Windows Vista beifügen, um einen Performanceunterschied zu den 64-Bit-Brüder festzustellen.
Der Platzhirsch:
Der Part des Titelverteidigers darf Windows XP x64 SP2 übernehmen. Wenig verbreitet, ist es trotzdem das stabilste und ausgereifteste Windows XP. Als direkter Konkurrent für Vista x64 ist es ideal, da somit auch 64-Bit-Benchmarks und 4 GB Speicher genutzt werden können. Auch hier kann 32-Bit-Software nur über den Umweg WoW64-Layer ausgeführt werden. Zwischen Windows XP in der 32-Bit- und 64-Bit-Variante herrscht generell kein Performanceunterschied. Wir erlauben uns daher den Fokus auf XP x64 zu legen und mit den beiden nachfolgenden Tabellen unsere Behauptung zu beweisen.
Die Testsysteme:
Wir haben uns für zwei Testsysteme entschieden, um sowohl das Mainstream- als auch das gehobene Segment abzudecken. Insbesondere das schwächere AMD-System soll die Suche nach Performanceunterschieden erleichtern. Sehr schnelle Systeme könnten die Testergebnisse verzerren oder für schwächere Systeme unnütze Werte liefern. Alle Betriebssysteme haben den Avira Antivir Virenscanner mit Background-Scanner aktiviert. Zudem nutzen alle Vista-Systeme die Sidebar, welche mit dem CPU-Meter-Gadget bestückt ist, um Windows Vista etwas der üblichen Zusatzbelastung aufhalsen. Für die Aufnahme der Diagramme kommt Fraps zum Einsatz.
Warum sich Spiele in der Auflistung befinden, sollte keinen mehr vor Rätsel stellen. Warum aber die Applikationen? Sie werden uns helfen, ein paar wichtige Dinge im Voraus klarzustellen. Zuerst natürlich ob es prinzipielle Geschwindigkeitsunterschiede zwischen XP und Vista gibt. Zweitens, wie sehr sich die zusätzlichen Hintergrundaktivitäten in Vista auf die Performance auswirken. Und drittens, ob es Unterschiebe bei Anwendungen mit Multi-Threading, also hier die Unterstützung für zwei Kerne, gibt. Stellt sich bereits hier ein gravierender Unterschied ein, so wären die Auswirkungen sicherlich auch in Spielen zu spüren.
Wer ist also schneller – und warum?
[4]
XP vs. Vista: Kreiszahl "Pi", Music-Encoding und Raytracing
XP vs. Vista: SuperPi
Den Vortritt hat ein geradezu urtümliches Programm namens SuperPi. Die Suche nach Primzahlen steht hierbei im Vordergrund. Optimierungen auf moderne Architekturen wird man dagegen vergeblich suchen – weder für Windows Vista oder Windows XP, noch für spezifische CPU-Features wie MMX oder SSE. Der Anteil an Gleitkommaberechnungen beträgt ca. 30%, der Rest verteilt sich auf Integer-, Sprungvorhersage und Speicheroperationen. Dementsprechend schlecht ist die erreichte Leistung pro Takt (IPC) auf beiden CPUs. Dieser Mix hat sich interessanterweise gut bewährt, um die Performance in Spielen vorherzusagen. Gemessen wird die Zeit zur Berechnung der 1-Millionsten Stelle hinter dem Komma der Kreiszahl "Pi". Verwendet wurde die original Software, nicht eine der modifizierten Versionen mit genauerer Zeitangabe.
[25]SuperPi 1.1 [26]
Unserem ersten Kandidaten scheint das verwendete Betriebssystem herzlich egal zu sein. Die zusätzlichen Umwege über die WoW64-Emulation sind nicht zu spüren. Windows Vista in der 32-Bit-Version erreicht exakt die gleichen Ergebnisse. Auch Sidebar und Aero-Desktop in Vista scheinen keine Nachteile mit sich zu bringen. Allerdings nutzt SuperPi nur einen der beiden Kerne, somit steht ein weiter für den Rest des Systems zur Verfügung.
XP vs. Vista: WPrime
WPrime nutzt beide Kerne m Test, um schnell und effektiv Wurzeln von größeren Zahlenmengen zu berechnen . In diesem Fall werden anscheinend nur sehr wenige Gleitkommaberechnungen durchgeführt. Eine mäßige IPC hat es mit SuperPi gemein.
[27]Wprime32 1.53 [28]
Etwas sticht sofort ins Auge: Es ist der unerwartete Vorsprung, den Windows Vista hier herausarbeiten kann. Vista liegt trotz Sidebar, Aero und all dem Rest leicht vorne. Warum genau, bleibt ungeklärt, allerdings existiert auch hier keinen Unterschied zwischen Vista64 und Vista32.
XP vs. Vista: Lame MP3-Encoder
Als nächstes soll eine Wav-Datei ins MP3-Format kodiert werden. Der bekannte Encoder Lame steht dafür jeweils als 32-Bit- und als auch 64-Bit Version zur Verfügung. Gemessen wird die Zeit bis zur Fertigstellung im "–-Extreme"-Profil. Multi-Threading ist in dieser Version nicht enthalten. In der 32-Bit-Version kommen auf drei Anteile x87 Gleitkomma, 1 Anteil SIMD-Code in Form von MMX und/oder 3DNow. Die 64-Bit-Version wartet mit dem gleichen Verhältnis von skalarem SSE2 (ersetzt x87) zu SIMD-SSE2 auf.
[29]Lame Encoder 3.98 [30]
Keine Unterschiede zwischen Windows XP und Windows Vista: Die 64-Bit-Versionen sind allerdings durchgehend um einige Sekunden langsamer. Da dieser Effekt auf beiden CPUs zu beobachten war, kann man wohl von ungünstigen Compiler-Optimierungen ausgehen.
XP vs. Vista: NeroAAC-Encoder
Der NeroAAC-Encoder erstellt AAC-konforme Dateien, wie sie für iTunes zum Einsatz kommen. Als relativ neuen Codec erwarten wir neben modernen Optimierungen auch Multi-Threading und SSE2-SIMD. Zwei Versionen stehen zur Verfügung: Die Standard-Variante und eine spezielle SSE-Variante. Allerdings nutzt auch erstere schon SSE/2 für ein Drittel der Gleitkommaberechnungen. Nur die "SSE-Version" setzt zusätzlich auf Multi-Threading, ist allerdings im Intel-Compiler mit dem speziellen Intel-Profil erstellt worden. Ein Testlauf auf dem K8-Prozessor war somit nicht möglich.
[31]Nero AAC-Encoder 1.1.34.2 [32]
Auch hier das bekannte Bild: Alle Betriebsysteme mit identischer Performance. Die Intel-only-Version des Encoders bringt trotz Multi-Threading kaum Vorteile. Langsam zeichnet sich ab, dass diesen recht simplen Programmen die Umgebung reichlich egal scheint. Weder zeigen die 64-Bit Systeme über WoW64 Performanceverluste, noch scheinen die aufgeblähten Vista-Systeme Nachteile zu besitzen.
[4]
XP vs. Vista: Cinebench und vorläufiges Fazit
XP vs. Vista: Cinebench_R10
Cinebench basiert auf der Animationssoftware Cinema4D und soll die Rendering-Leistung verschiedener Systeme messen. Neben zwei CPU-Tests (Single- und Multi-Core) gibt es auch einen OpenGL GPU-Test. Zusätzlich liegt eine 64-Bit-Variante vor. Bekannt oder berüchtigt ist Cinebench, da es in der aktuellen x86-Version eventuell Compileroptimierungen für Intel-CPUs aktiviert, die anderen CPUs vorenthalten werden. Für unsere Tests hat dies jedoch keine Auswirkungen.
[33]Cinebench 10 x86 & x64 [34]
Die Rohleistung scheint absolut identisch. Interessant ist jedoch das Ergebnis des OpenGL-Tests. Vista liegt hier ohne ersichtliche Gründe zurück. Ein Gegentest mit Crystalmark wiederum bescheinigt Vista eine dramatisch höhere OpenGL-Leistung. Es kommt wohl im speziellen auf die Implementierung an und soll uns nicht weiter beunruhigen.
Fazit
Egal zu welcher Schlussfolgerung wir oder jemand sonst kommen mögen, Windows Vista wird wohl lange Zeit benötigen, um sich wirklich zu etablieren. Dabei steht es eigentlich gar nicht so schlecht um Microsofts "Sorgenkind". Viele User scheinen die Oberfläche zu mögen, die zusätzlichen Features zu begrüßen und viele Nachteile wohlwollend hinzunehmen. Dabei muss jeder für sich entscheiden, welche Nachteile das sind. Wir für unseren Teil haben entschieden, dass diese nicht in der Anwendungsperformance durch pure Rechenleistung selbst liegen. Keiner unserer Low-Level Benchmarks konnte uns vom Gegenteil überzeugen. Mitunter werden sich sicherlich Anwendungen in Vista schneller oder langsamer ablaufen, weniger Speicher zu längeren Ladezeiten führen und das ein oder andere Programm die Zusammenarbeit verweigern. Generell weniger Leistung könnte man Vista somit nicht vorwerfen. Wie sich Vista allerdings in komplexeren Anwendungen gibt, soll nicht unser Anliegen sein.
Über alle Tests hinweg stellt sich heraus, dass die 32-Bit- und 64-Bit-Versionen von Vista, wenn überhaupt, in unseren CPU-lastigen Anwendungen nur minimal auseinander liegen, 64-Bit-Code natürlich ausgenommen. Dieses Verhalten konnte auch schon mit Windows XP und Windows XP x64 beobachtet werden und spricht für die effiziente Einbindung der WoW64-Schnittstelle zur Emulation einer 32-Bit-Umgebung.
Überrascht hat uns der Einfluss zusätzlicher Dienste und Hintergrundaktivitäten, bzw. eigentlich dessen Ausbleiben. Vista ließ sich nichts zu Schulden kommen, obwohl zusätzlich Sidebar und Echtzeit Gadget angezeigt wurden. Erst vor kurzem hat AMD ein Tool vorgestellt (AMD Fusion), welches unnötige Dienste in Vista auf Knopfdruck deaktivieren kann. Das Ausbleiben relevanter Performancegewinne bestätigt unsere eigene Einschätzung: Die Grundleistung bleibt trotz zusätzlichem Ballast erfreulich hoch. Dafür darf man auch Respekt empfinden, ohne dass einem das Betriebsystem selbst sonderlich gefallen muss.
Allerdings ist unsere dreiseitige Medaille damit noch nicht fertig. Der Ausgangspunkt unserer Diskussion fand sich in der Gaming-Performance von Windows-Vista. Dass Vista ausgerechnet hier Federn lassen muss, wollen dann Teil 2 und 3 des Artikels aufzeigen.
[4]
Verweise:
[1] https://www.3dcenter.org/users/blackbirdsr
[2] https://www.3dcenter.org/dateien/abbildungen/1_1.png
[3] https://www.3dcenter.org/abbildung/performanceverlust-comanche4-teaser
[4] http://www.forum-3dcenter.org/vbulletin/showthread.php?t=437517
[5] https://www.3dcenter.org/dateien/abbildungen/2_0.png
[6] https://www.3dcenter.org/abbildung/abbildung-1-forderndes-comanche4-timedemo
[7] https://www.3dcenter.org/dateien/abbildungen/3_0.png
[8] https://www.3dcenter.org/abbildung/abbildung-2-tatsaechliche-szene-aus-dem-spiel
[9] https://www.3dcenter.org/dateien/abbildungen/4.png
[10] https://www.3dcenter.org/abbildung/abbildung-3-vergleich-mit-16xq-transparenz-antialiasing
[11] https://www.3dcenter.org/dateien/abbildungen/5.png
[12] https://www.3dcenter.org/abbildung/abbildung-4-das-diagramm-laesst-sich-uebereinander-legen
[13] https://www.3dcenter.org/dateien/abbildungen/6.png
[14] https://www.3dcenter.org/abbildung/abbildung-5-ueberlagertes-diagramm-der-beiden-durchgaenge
[15] https://www.3dcenter.org/dateien/abbildungen/7.png
[16] https://www.3dcenter.org/abbildung/chaos
[17] https://www.3dcenter.org/dateien/abbildungen/8.png
[18] https://www.3dcenter.org/abbildung/tabelle-2-einfluss-der-aero-oberflaeche-von-windows-vista
[19] https://www.3dcenter.org/dateien/abbildungen/9.png
[20] https://www.3dcenter.org/abbildung/tabelle-3-verluste-durch-soundberechnung-differenz
[21] https://www.3dcenter.org/dateien/abbildungen/XP32_3.png
[22] https://www.3dcenter.org/abbildung/abbildung-6-vergleich-xp-32-bit-mit-xp-64-bit
[23] https://www.3dcenter.org/dateien/abbildungen/XP32_2.png
[24] https://www.3dcenter.org/abbildung/tabelle-4-vergleich-32-bit-xp-mit-64-bit-xp-und-vista
[25] https://www.3dcenter.org/dateien/abbildungen/10.png
[26] https://www.3dcenter.org/abbildung/superpi-11
[27] https://www.3dcenter.org/dateien/abbildungen/11.png
[28] https://www.3dcenter.org/abbildung/wprime32-153
[29] https://www.3dcenter.org/dateien/abbildungen/12.png
[30] https://www.3dcenter.org/abbildung/lame-encoder-398
[31] https://www.3dcenter.org/dateien/abbildungen/13.png
[32] https://www.3dcenter.org/abbildung/nero-aac-encoder-11342
[33] https://www.3dcenter.org/dateien/abbildungen/15.png
[34] https://www.3dcenter.org/abbildung/cinebench-10-x86-x64