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.