Thema: Realstorm

[BlackBirdSR]

Benchmark: Realstorm
Rendering: Nutzt ausschließlich CPU für alle Berechnungen
http://www.realstorm.de/realstorm/data/RealStorm_Bench2004.exe
http://www.realstorm.com/



Vor einiger Zeit gab es ja einen Thread für Realstorm Benchmarks:
http://www.forum-3dcenter.org/vbulletin/showthread.php?p=1464134#post1464134

Ich habe damals angefragt, wie es mit SSE2 und 64Bit aussieht, und warum diese und jene CPUs sich so verhält. Es gab natürlich auch eine Antwort.
Da wir nun endlich ein passendes Forum dafür haben:


Zur Engine an sich:
-------------------
Der Code den ich benutze (ich bin der Programmierer der Engine) ist reiner
C-Code, bis dato sind keine Assembler Elemente enthalten, also weder
Optimierungen fuer SSE, SSE2, 64Bit, HyperThreading oder
Herstellerspezifische Optimierungen.
Wir benutzen zur Zeit den Intel Compiler 4.5 und Visual-C6. Diese
Compilerkombination hat fuer uns die beste Performance ergeben (auch wenn
die Versionen schon relativ alt sind). Als Compilereinstellungen wird für
Pentium II und kompatible der Code generiert.

Wuerden spezifische Prozessoroptimierungen mehr Performance bringen?
--------------------------------------------------------------------
Ich gehe davon aus, dass man mit Prozessorspezifischen Optimierungen das
eine oder andere % an Performance in der RealStorm Engine gewinnen koennte,
doch in dem Falle unserer Engine wären die Unterschiede nicht sehr gross.
(Erklaerung folgt spaeter). Ein weiteres Problem fuer uns (mich) ist, dass
die Engine ein "Hobby"-Projekt ist, und von daher nur begrenzte Zeit in die
Engine einfliessen kann (was ich persoenlich sehr bedauerlich finde)

Was sind die Performance-"Fresser" bei RealStorm?
-------------------------------------------------
Generell habe ich zwei Probleme bei der Programmierung und Strukturierung
der Engine.
(a)
Die Optimierungen der Engine verschlingen ein Unmenge an Speicherplatz fuer
Tabellen, die fuer jedes Bild neu generiert werden muessen.
Ein Beispiel: Pro Pixel liegen insgesamt 80 Byte Buffer ab (jeweils 32Bit
Float Werte fuer Licht R,G,B; Texture X,Y, Position X,Y,Z; etc)
Durch diesen Gesamtspeicherbereich (bei 640x480 Pixel sind das 24MB) muss
die Engine 3Mal vollständig pro Bild durchlaufen (Adaptive Subsampling in 3
Passes), was den Datencaches wenig foerderlich ist ;-) (Adaptive Supsampling
in 3 Passes)
Noch ein Beispiel:
Es gibt eine Tabelle derart "byte SchattenObjObj[MAXOBJ][MAXOBJ]", bei
MAXOBJ=5000 liegt hier eine Tabelle von 25MB ab, die fuer jedes Bild
generiert wird, und bei der bei der Schattenberechnung nur bedingt linear
zugegriffen werden kann, das mag der Datencache leider auch nicht ;-)

(b)
Die Inneren Schleifen sind aufgrund der Komplexitaet und der Anzahl der
Primitiven (Mathematische Polygone zweiter Ordnung wie Kugeln, Zylinder,
Ellipsoide,etc) und der ingesamt verwendeten 9 Texturebene (3 davon
procedural) leider vom Code her sehr gross, so dass es auf einigen
Prozessoren dazu kommt, das der L1_Instruction Cache zu klein ist.
Das macht die Innerloops dann leider nicht so schnell, wie ich es gerne
haette, aber auch eine Optimierung auf spezielle Prozessortypen wuerde
dieses Problem leider nicht loesen.

Es gibt also kurz gesagt zwei Schwachstellen im Code:
- zu grosse Tabellen -> L2-Data Cache Misses
- zu langer Code in den inneren Schleifen -> L1-Instruction Cache Misses

Zum Resultbrowser
-----------------
Wir arbeiten gerade an einer neuen Version, die auch die Erkennung von
Athlon64,FX und den neuen Pentium4 Prozessorkernen korrekt durchfuehrt.
Diese wird dann dem neuen Benchmark beigelegt sein, "RealStorm Radiosity
Bench2005". (<- pssst :-)
Wir wollen uns in dem neuen Benchmark Dingen widmen, die auch mit den
neuesten Grafikkarten nicht realisierbar sind, also wirkliche Volume Lights
(Weichschatten) und Realtime Radiosity). Hier kann man sicher keine 30fps
erwarten, aber dafuer hat man einen rechenintensiven und schoen anzusehenden
Prozessor-Benchmark.


Grüße aus Kiel,

Michael Piepgras
Engine Programming
www.realstorm.com

[StefanV2]

Hm, das erklärt die Pentium 4 Ergebnisse im Benchmark Thread mehr als eindeutig.

Andererseits, wenn man gemein ist, würd man behaupten, das man (unwissendlich) für AMD optimiert hat ;-)

Dennoch find ichs gut, das der Junge nicht zu viel Zeit in Optimierungen gesteckt hat, ein Profil, das SSE(2) nutzt, wär aber nicht schlecht gewesen...

[BlackBirdSR]

Andererseits, wenn man gemein ist, würd man behaupten, das man (unwissendlich) für AMD optimiert hat ;-)



Sorry aber der Teil des Posts ist pure Flamerei.
Denn genauso hat man für den PentiumPro, II, III und PentiumM optimiert.
Aber das hast du nicht erwähnt.


Dennoch find ichs gut, das der Junge nicht zu viel Zeit in Optimierungen gesteckt hat, ein Profil, das SSE(2) nutzt, wär aber nicht schlecht gewesen...

Da bin ich mir nicht so sicher...
Auf der einen Seite ist es natürlich gut, dass ein benchmark nicht bis aufs letzte optimiert wird, und somit fern ab der Realität lebt.
Auf der anderen Seite erwarte ich nicht, dass sich solch ein Renderingverfahren ohne große Optimierungen wirklich performant einsetzen lässt.

Gespannt wäre ich allerdings auf eine Version für IA64. Ist wohl leider fern ab des Machbaren. Allerdings hätte jener nicht nur die Leistung, sondern auch den benötigten Cache.

[StefanV2]

Sorry aber der Teil des Posts ist pure Flamerei.
Denn genauso hat man für den PentiumPro, II, III und PentiumM optimiert.
Aber das hast du nicht erwähnt.

Richtig, womit meine Aussage wäre, das, wenn der Code P6 optimiert ist, er allen Architekturen außer dem P4 gut schmeckt, was aber in der Natur der Architekturen selbst liegt


Da bin ich mir nicht so sicher...
Auf der einen Seite ist es natürlich gut, dass ein benchmark nicht bis aufs letzte optimiert wird, und somit fern ab der Realität lebt.
Auf der anderen Seite erwarte ich nicht, dass sich solch ein Renderingverfahren ohne große Optimierungen wirklich performant einsetzen lässt.

Gespannt wäre ich allerdings auf eine Version für IA64. Ist wohl leider fern ab des Machbaren. Allerdings hätte jener nicht nur die Leistung, sondern auch den benötigten Cache.
Richtig, so einen Benchmark, der für nichts wirklich optimiert ist, sprich P6, der zeigt recht deutlich, wie gut/schlecht die Architekturen denn nun genau sind, wobei das Benchmarkergebnis meiner Meinung nach etwas detaillierter hätte sein können aber das wäre dann eher schwerlich zu realisieren und auch aufwändiger, außterdem würd man dann keine Demo schreiben sondern einen Benchmarkprogramm...

Eine IA64 Version wäre IMO nicht so interessant aber eine x86-64 Version, einmal mit 32bit Binarys und einmal mit 64bit Binarys.