Veröffentlicht auf 3DCenter.org (http://www.3dcenter.org)

Startseite > Performancereport Windows XP gegen Vista, Teil 2

Performancereport Windows XP gegen Vista, Teil 2

Freitag, 19. Dezember 2008
 / von BlackBirdSR [1]
 

Performancereport Windows XP gegen Vista, Teil 2

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

Kommentare - Registrierung ist nicht notwendig [4]

XP vs. Vista: Comanche4

Freitag, 19. Dezember 2008
 / von BlackBirdSR [1]
 

XP vs. Vista: Comanche4

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.

Comanche4 Timedemo XP vs Vista [5]
Abbildung 1: Peformanceverlust unter Vista64 in Comanche4

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:

  • AMDs K8
  • AMDs HD2900XT bzw. den Catalyst-Treiber
  • Probleme mit der Soundberechnung
  • 2 Kerne
  • Powermanagement (CnQ)
  • Hintergrundanwendungen
  • Das Timedemo selber
  • Vista 64-Bit
  • Vista an sich

• 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.

Comanche4 Timedemo XP vs. Vista Intel [6]
Abbildung 2: Peformanceverlust auch auf Intel-System und Vista32 messbar

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.

< [7]
Abbildung 3: In-Game Vergleich zwischen XP64 und Vista64

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:

[8]
Tabelle 1: Vergleich verschiedener Settings, AMD-System
Affinity = Spiel an einen Kern binden (0 oder 1)
Priority = Spiel wird vom Betriebsystem bevorzugt (high) mit CPU-Zeit versorgt
[9]
Tabelle 2: Vergleich verschiedener Settings und Vista32, Intel-System
Affinity = Spiel an einen Kern binden (0 oder 1)
Priority = Spiel wird vom Betriebsystem bevorzugt (high) mit CPU-Zeit versorgt

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.

[10]
Tabelle 3: Sondertests in Vista
Virtualization = Einstellung im Task-Manager
Power-Management Max. = kein Absenken der Taktraten bei geringer Last
Classic Gui = Deaktivierung von Aero sowie aller optischen Verschönerungen

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.

[11]
Tabelle 4: Comanche4, Vergleiche für Single- und Dual-Core, AMD-System

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.


Kommentare - Registrierung ist nicht notwendig [4]

XP vs. Vista: Unreal Tournament 2004

Freitag, 19. Dezember 2008
 / von BlackBirdSR [1]
 

XP vs. Vista: Unreal Tournament 2004

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:

[12]
Abbildung 4: Peformanceverlust für Vista64 in UT2004 auf AMD-System
[13]
Abbildung 5: Ähnlich großer Performanceverlust für Vista64 auf Intel-System

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:

[14]
Abbildung 6: Performanceverlust Vista64 auf AMD-System
[15]
Abbildung 7: Ähnlich großer Performanceverlust für Vista64 auf Intel-System

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:

[16]
Abbildung 8: Vergleich UT2004 32-Bit und 64-Bit Version auf XP64 AMD-System
[17]
Abbildung 9: Vergleich 32-Bit und 64-Bit Version auf XP64 Intel-System

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:

[18]
Abbildung 10: Vergleich 32-Bit und 64-Bit Version auf Vista64 AMD-System
[19]
Abbildung 11: Vergleich 32-Bit und 64-Bit Version auf Vista64 Intel-System

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.

[20]
Abbildung 12: Vergleich UT2004 32-Bit XP64 und 64-Bit Vista64 AMD-System
[21]
Abbildung 13: Vergleich UT2004 32-Bit XP64 und 64-Bit Vista64 Intel-System

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.

[22]
Abbildung 14: Vergleich Vista32 und Vista64 Intel-System

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.

[23]
Tabelle 5: Vergleich XP64 und Vista64 bei Software-Rendering
Safe = Software Sound
A3D = Software 3D-Sound

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.

[24]
Tabelle 6: Vergleich XP64 und Vista für Null-Video und Software- vs. OpenAL-Audio
Safe = Software Sound
OpenAL = HW Sound

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.


Kommentare - Registrierung ist nicht notwendig [4]

XP vs. Vista: 3DMark 200x

Freitag, 19. Dezember 2008
 / von BlackBirdSR [1]
 

XP vs. Vista: 3DMark 200x

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:

[25]
Tabelle 7: 3DMark2001 XP64 und Vista64 HW T&L vs. SW T&L, 640x480
AMD – HD2900XT 2GB DDR-400

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.

[26]
Tabelle 8: 3DMark2001 XP64 und Vista64 HW T&L vs. SW T&L, 640x480
Intel – Nvidia 8800GTS 640 4GB DDR2-750

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.

[27]
Tabelle 9: 3DMark2001 mit GPU-Limitierung, wenn möglich. XP64 und Vista64, 1680x1050 8xAA
AMD und Intel-System

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.

[28]
Tabelle 10: 3DMark2003, Vergleich XP64 und Vista64 HW- und SW-Vertex Shader, 640x480
AMD – HD2900XT 2GB DDR-400

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.

[29]
Tabelle 11: 3DMark2003, Vergleich XP64 und Vista64 HW- und SW-Vertex Shader, 640x480
Intel – Nvidia 8800GTS, 4GB DDR2-750

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.

[30]
Tabelle 12: 3DMark2006 XP64 und Vista64 SW-Vertex Shader nicht sinnvoll, 640x480
AMD- und Intel-System

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.

[31]
Tabelle 13: 3DMark2006 XP64 und Vista64 ähnliche Ergebnisse für Durchlauf mit 1600x1200
AMD- und Intel-System

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.

[32]
Tabelle 14: 3DMark2001 Single- und Dual-Core Einbruch nur für XP64, 640x480
AMD – HD2900XT 2GB DDR-400

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:

[33]
Tabelle 15: 3DMark2001 Single- und Dual-Core Kein Einbruch für XP64, 640x480
Intel – Nvidia 8800GTS 4GB DDR2-750

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:

[34]
Tabelle 16: 3DMark 2001 und 2006 Gleichstand für Vista32 und Vista64
Intel – Nvidia 8800GTS 640 4GB DDR2-750
[35]
Tabelle 17: 3DMark2003 SW- und HW-Vertex Shader Gleichstand für Vista32 und Vista64
Intel – Nvidia 8800GTS 640 4GB DDR2-750

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.


Kommentare - Registrierung ist nicht notwendig [4]

XP vs. Vista: Red Alert 3

Freitag, 19. Dezember 2008
 / von BlackBirdSR [1]
 

XP vs. Vista: Red Alert 3

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.

[36]
Abbildung 15: Durchgehender Performanceverlust für Vista64 auf AMD-System

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:

[37]
Abbildung 16: Durchgehender Performanceverlust für Vista64 auf AMD-System

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.

[38]
Abbildung 17: Ähnlicher Verlauf bei 1.2 GHz CPU-Takt, AMD-System

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.

[39]
Abbildung 18: Vergleich für Single-Core, AMD-System

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.

[40]
Abbildung 19: Vergleich XP64 Single-Core vs. Vista64 Dual-Core, AMD-System

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.

[41]
Abbildung 20: Identische Performance für alle Betriebsysteme auf Intel-System
Performance insgesamt niederiger im Vergleich zum AMD-System
[42]
Abbildung 21: Identische Performance für alle Betriebsysteme auf Intel-System
Performance insgesamt niederiger im Vergleich zum AMD-System

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.

[43]
Abbildung 22: Identische Peformance für alle Betriebsysteme auf Intel-System
Performance in 800x600 endlich höher als AMD-System bei 1280x1024
[44]
Abbildung 23: Identische Peformance für alle Betriebsysteme auf Intel-System
Performance in 800x600 endlich höher als AMD-System bei 1280x1024

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.

[45]
Abbildung 24: Kein Einbruch unter XP64 für Single-Core, Intel-System
[46]
Abbildung 25: Kein Einbruch unter Vista64 für Single-Core, Intel-System

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.

[47]
Abbildung 25: Identische Performance für alle Betriebsysteme, Intel-System
3 GHz vs 2 GHz, minimale Unterschiede bei Vista64

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 ...

[48]
Abbildung 26: Mittlere Einbrüche für XP64, schwere bei Vista64 feststellbar, Intel-System
Single-Core 2 GHz

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.


Kommentare - Registrierung ist nicht notwendig [4]

Fazit und Ausblick auf Teil 3

Freitag, 19. Dezember 2008
 / von BlackBirdSR [1]
 

Fazit und Ausblick auf Teil 3

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.


Kommentare - Registrierung ist nicht notwendig [4]
  • Performancereport

Quellen-URL: http://www.3dcenter.org/artikel/performancereport-windows-xp-gegen-vista-teil-2

Verweise:
[1] http://www.3dcenter.org/users/blackbirdsr
[2] http://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] http://www.3dcenter.org/dateien/abbildungen/C4_1.png
[6] http://www.3dcenter.org/dateien/abbildungen/C4_2.png
[7] http://www.3dcenter.org/dateien/abbildungen/C4_3.png
[8] http://www.3dcenter.org/dateien/abbildungen/C4_4.png
[9] http://www.3dcenter.org/dateien/abbildungen/C4_5.png
[10] http://www.3dcenter.org/dateien/abbildungen/C4_6.png
[11] http://www.3dcenter.org/dateien/abbildungen/C4_7.png
[12] http://www.3dcenter.org/dateien/abbildungen/UT2004_1.png
[13] http://www.3dcenter.org/dateien/abbildungen/UT2004_2.png
[14] http://www.3dcenter.org/dateien/abbildungen/UT2004_3.png
[15] http://www.3dcenter.org/dateien/abbildungen/UT2004_4.png
[16] http://www.3dcenter.org/dateien/abbildungen/UT2004_5.png
[17] http://www.3dcenter.org/dateien/abbildungen/UT2004_6.png
[18] http://www.3dcenter.org/dateien/abbildungen/UT2004_7.png
[19] http://www.3dcenter.org/dateien/abbildungen/UT2004_8.png
[20] http://www.3dcenter.org/dateien/abbildungen/UT2004_9.png
[21] http://www.3dcenter.org/dateien/abbildungen/UT2004_10.png
[22] http://www.3dcenter.org/dateien/abbildungen/UT2004_11.png
[23] http://www.3dcenter.org/dateien/abbildungen/UT2004_12.png
[24] http://www.3dcenter.org/dateien/abbildungen/UT2004_13.png
[25] http://www.3dcenter.org/dateien/abbildungen/3DMark_1.png
[26] http://www.3dcenter.org/dateien/abbildungen/3DMark_2.png
[27] http://www.3dcenter.org/dateien/abbildungen/3DMark_3.png
[28] http://www.3dcenter.org/dateien/abbildungen/3DMark_4.png
[29] http://www.3dcenter.org/dateien/abbildungen/3DMark_5.png
[30] http://www.3dcenter.org/dateien/abbildungen/3DMark_6.png
[31] http://www.3dcenter.org/dateien/abbildungen/3DMark_7.png
[32] http://www.3dcenter.org/dateien/abbildungen/3DMark_8.png
[33] http://www.3dcenter.org/dateien/abbildungen/3DMark_9.png
[34] http://www.3dcenter.org/dateien/abbildungen/3DMark_10.png
[35] http://www.3dcenter.org/dateien/abbildungen/3DMark_11.png
[36] http://www.3dcenter.org/dateien/abbildungen/RA3_1.png
[37] http://www.3dcenter.org/dateien/abbildungen/RA3_2.png
[38] http://www.3dcenter.org/dateien/abbildungen/RA3_3.png
[39] http://www.3dcenter.org/dateien/abbildungen/RA3_4.png
[40] http://www.3dcenter.org/dateien/abbildungen/RA3_5.png
[41] http://www.3dcenter.org/dateien/abbildungen/RA3_6_0.png
[42] http://www.3dcenter.org/dateien/abbildungen/RA3_7.png
[43] http://www.3dcenter.org/dateien/abbildungen/RA3_8.png
[44] http://www.3dcenter.org/dateien/abbildungen/RA3_9.png
[45] http://www.3dcenter.org/dateien/abbildungen/RA3_10.png
[46] http://www.3dcenter.org/dateien/abbildungen/RA3_11.png
[47] http://www.3dcenter.org/dateien/abbildungen/RA3_12.png
[48] http://www.3dcenter.org/dateien/abbildungen/RA3_13.png