Anti-Jammer-Thread

[dot]

in der Tat...

[Schrompf]

Ich habe soeben mit dem eigenen Headset ein Kotzgeräusch eingesungen. Das ist für eine winzige Nebenhandlung im letzten Splatter-Level und erstmal nur als Platzhalter gedacht, der vielleicht oder vielleicht auch nicht vom Sounder durch was "Richtiges" ersetzt wird. Absurder Mist... Ich mag meinen Job :-)

[Thoran]

Ich habe soeben mit dem eigenen Headset ein Kotzgeräusch eingesungen.

Wie hast du den Würgreiz provoziert ? ;)

[Artificial Mind]

Der Ausdruck "-100 * (90000 / (90000 + distance2(vec2(0, 0), vec2(x, z)))) + y + 90"
wird jetzt von unserem Expressionsystem aus einem String in eine Zwischen-Bytecode-Repräsentation gebracht und dann per AsmJit auf nativen Code plattformunabhängig jit-kompiliert.
Es sind noch bestimmt 50% der Anweisungen unnötige movs, trotzdem braucht eine Auswertung nur noch 15ns. Zum Vergleich: nativer gcc Code für diesen Ausdruck braucht 19ns, die Auswertung des Zwischen-Bytecodes (quasi Interpretation) braucht 1027ns.

[CodingCat]

Es sind noch bestimmt 50% der Anweisungen unnötige movs, trotzdem braucht eine Auswertung nur noch 15ns. Zum Vergleich: nativer gcc Code für diesen Ausdruck braucht 19ns, die Auswertung des Zwischen-Bytecodes (quasi Interpretation) braucht 1027ns.

Hervorragend! Aber was generiert gcc da für Code? Probleme mit Aliasing?

[Artificial Mind]

Wir haben mal den Code verglichen, der gcc lädt noch relativ viel aus dem Ram (sowas wie Konstanten) und außerdem springt er noch recht wild zwischen GPR, x87-Registern und XMM-Registern umher. Wir haben eigentlich komplett XMM (auch wenn wir nur den ss-Modus nutzen) und ganz selten mal GPR (z. B. für die sign-Funktion)

[eXile]

Ich habe das auch mal ausprobiert.

Ein Teil der Instruktionslast bei euch im GCC liegt wohl daran, dass ihr die Datenfelder vom vec2 nicht an für SSE-Instruktionen genehmen Grenzen ausrichtet. Wenn man das Alignment einstellt, kommt schon erheblich besserer Text raus, aber immer noch nicht optimaler.

Wenn man das wohl vollständig optimieren möchte, muss man wohl so etwas wie die DirectXMath machen, und sich einen XMVECTOR-Vektor bauen, welcher direkt die Daten in SSE-Registern vorhält.

[Artificial Mind]

Wir generieren ja unsere SSE-Instruktionen jetzt selbst, also brauchen wir das gcc-Verhalten gar nicht optimieren. Der richtig performancekritische Teil ist die Terrain-Generierung und dort wird unser jitting genutzt. Wenn das jitting komplett funktioniert fangen wir mit statischer Analyse an. Instruction-level constant folding, reaching definitions analysis auf unserem Bytecode. Dann wahrscheinlich nochmal eigene Registerallokation inklusive mov-Optimierung auf dem SSE-Code, danach vektorisieren der SSE-Instructions (momentan nutzen wir halt nur "ss", aber wenn man das "ps" mindestens zur Hälfte ausgelastet bekäme wäre das schon cool). Am Ende Instruction Reordering fürs SSE-pairing.

Viel mehr können wir dann nicht mehr machen, oder?
(Abgesehen von noch mehr statischer Analyse auf unserem Zwischencode ;) )

NACHTRAG: Das ist unser momentaner SSE-Code für den Ausdruck von oben: http://pastebin.com/VtB43DUY (btw: distance2 ist ohne sqrt, das "2" steht für Quadrat. Sqrt selber würden wir einfach mit einer SSE-Instruktion machen.)

[eXile]

Ich sehe gerade, dass die test-Funktionen aus meinem Quelltext oben gar keine calls generieren; eine jede der test-Funktionen sieht tatsächlich optimal optimiert aus (ja, lacht nur).

Ich habe mich eigentlich an dem hier gewundert:

Es sind noch bestimmt 50% der Anweisungen unnötige movs, trotzdem braucht eine Auswertung nur noch 15ns. Zum Vergleich: nativer gcc Code für diesen Ausdruck braucht 19ns

Wenn aber der GCC für solchen oder vergleichbaren Quelltext (wie wir nun gesehen haben) so guten Text produziert; wie unglaublich gut ist dann euer Text, als dass er noch einmal 4 ns schneller ist? Ich wüsste einfach nicht, was man noch optimieren sollte.

Ich meine, ohne sqrt gibt euch der GCC:

Code: Alles auswählen

test(float, float, float):
	movss	xmm3, DWORD PTR .LC0[rip]
	addss	xmm1, DWORD PTR .LC1[rip]
	xorps	xmm2, xmm3
	mulss	xmm2, xmm2
	mulss	xmm0, xmm0
	addss	xmm2, DWORD PTR .LC2[rip]
	addss	xmm2, xmm0
	movss	xmm0, DWORD PTR .LC3[rip]
	divss	xmm0, xmm2
	addss	xmm1, xmm0
	movaps	xmm0, xmm1
	ret
.LC0:
	.long	2147483648
	.long	0
	.long	0
	.long	0
.LC1:
	.long	1119092736
.LC2:
	.long	1202702336
.LC3:
	.long	3406386240

Und da ist meiner Meinung nach so ziemlich das Ende der Fahnenstange erreicht.

[Artificial Mind]

Die 19ns waren ohne volle Optimierung vom gcc, deswegen ist das noch etwas geschummelt: http://pastebin.com/crqAzQjC
Die vec2-Arithmetik ist aus der glm Lib, da müsste man nochmal gucken inwieweit die geinlined wird im Release build.
Der test3-Text aus deinem Link sieht ziemlich optimal aus, beim Pairing bin ich mir noch etwas unsicher (auch inwieweit man da wirklich drauf achten muss bei out-of-order execution).
Und ich steck auch noch nicht tief genug in SSE drin um zu beurteilen was die beste Art ist, Konstanten in xmm-Register zu bekommen.

[Schrompf]

Mich würde interessieren, was ihr da treibt? Warum jittet ihr überhaupt? Dass ihr den Compiler damit überholt, halte ich für völlig ausgeschlossen. Ich bin da von vornherein von einem Fehler ausgegangen. Und gegen gcc im Debug Build zu vergleichen ist ja eigentlich nur ein Fehler.

[Artificial Mind]

Mich würde interessieren, was ihr da treibt? Warum jittet ihr überhaupt? Dass ihr den Compiler damit überholt, halte ich für völlig ausgeschlossen. Ich bin da von vornherein von einem Fehler ausgegangen. Und gegen gcc im Debug Build zu vergleichen ist ja eigentlich nur ein Fehler.

Unser Terrain basiert ja auf einer impliziten Funktion. Dies soll aber nachher durch Modder gegeben werden und kann beliebig aussehen. Also haben wir ein Node-Expression-System (vergleichbar mit Blender Nodes nur noch nicht so hübsch mit GUI) das auch noch Nodes für beliebige Ausdrücke bereitstellt, als Strings. Punkt ist: dieses System wir für das Terrain millionenmal ausgewertet. Verstehst du nun, warum wir jitten müssen? Der GCC-Vergleich ist auch nur "ground truth", wir könnten es nicht mal damit kompilieren wenn wir es wollten (muss ja portabel sein und man will seinen Spielern ja auch nicht zumuten gcc installiert zu haben).

gcc im Debug ist quasi die Mindestqualität (guck dir http://pastebin.com/crqAzQjC an. Soo schlimm ist es nicht, auch wenn es natürlich ziemlich weit von optimal entfernt ist).
Andersherum ist gcc 4.8 mit O3 und fast-math auch etwas sehr hoch gegriffen, ist aber ein guter Wert für das was erreichbar ist. gcc 4.6 mit O1 würde ich als realistischer einschätzen.
Wenn du dir unseren Code anguckst dann sind wir bereits jetzt (mit "naiver" Kompilation) gar nicht so weit weg von was brauchbarem.

Naja TL;DR: Die Ausdrücke sind User-Input, werden aber millionenfach ausgewertet => JIT.

[Schrompf]

Glaub ich Dir ja, keine Sorge. Ich war primär neugierig, wofür Du eine JIT brauchst. Und ich wollte halt nicht so recht glauben, dass Du damit den GCC schlagen kannst. Ich kenne mich nur mit dem VC++-Compiler aus, aber bei dem ist zwischen Debug und Release ungefähr Faktor 20 an Unterschied. Sprich: der Debug-Build ist wirklich mit einem JIT erreichbar, der Release dagegen... glaube ich nicht. Daher mein Interesse.

[Artificial Mind]

Tschuldigung wenn ich etwas negativ klang, war nicht so gemeint. Bei GCC ist der Unterschied zwischen Release und Debug nur ca. 3 bis 5, bei VC++ ist der auch nicht so groß wenn man kein Iteratordebugging hat. (Trivia: Unser Projekt läuft auf meiner Monster-CPU mit VC11 im Release auf 200fps, mit VC11 im Debug auf 5fps - STL)

Ich bin zuversichtlich dass wir im Endeffekt (nach unseren Optimierungen) verdammt nah an die Release-Performance drankommen, da wir ja nur ein sehr kleines Subset an Features nutzen. Zum Beispiel gibt es bei uns weder Pointer noch Aliasing noch structs noch ints noch benutzerdefinierte Schleifen, es sind im Grunde nur arithmetische Ausdrücke die auf beliebigdimensionalen float-Tensoren arbeiten. Die Tensoren haben statische Typisierung und werden beim Kompilieren ausgerollt, danach bleiben nur noch float-Instruktionen über. Das Problem ist damit echt überschaubar. Sobald das System komplett läuft (momentan hängen wir an einer "Illegal Instruction" innerhalb eines 40k Instruction Ausdrucks ;) ) kann ich ja weiter berichten. Wenn wir auf Faktor 2 oder 3 an Release rankommen würde mir das sogar schon reichen.

[Artificial Mind]

So, gibt neue Ergebnisse für den obigen Ausdruck:

Unser JIT: 11ns
GCC 4.7 im Release: 10ns

Der Test ist ungefähr so aufgebaut: GCC Explorer
(Die Random-Aufrufe werden nochmal separat gemessen und danach rausgerechnet)

Ich denke damit sind wir im Bereich wo der Ram-Zugriff der limitierende Faktor ist. Bin zufrieden für heute.

[Krishty]

Mein Font-Renderer hat Leerzeichen zum Zeichnen geschickt. Schön, dass ich nach so vielen Monaten immernoch kleine Verbesserungsmöglichkeiten finde.

[Krishty]

Ich überlge, in meiner CRT bestimmte globale Variablen in eigenen Threads zu initialisieren. Anstatt dass so seriell Dateien geöffnet, Registry gelesen, und GPU-Kontext angefordert wird, geschähe das zumindest auf Makroebene parallel. Die entsprechenden Variablen wären speziell markiert.

Ich frage mich, inwieweit das überhaupt was bringen würde. Weil Windows außer dem GPU-Kontext alles cachet, ist der wahrscheinlich die eine einzige langsame Sache auf die letztendlich alles andere warten würde. Außerdem würde es RAII an sich in Frage stellen.

Sooo. Ich habe heute einen Prototypen hingehackt und ins nächste Projekt kommt das definitiv rein – dann werden Renderer, Dateisystem, Eingabesystem, und Klangausgabe nebenläufig initialisiert. Und alles, was ich sonst noch so finde. Mit RAII ist nichts kollidiert; es sind „normale“ globale Variablen und für den Rest des Programms sieht ihre Lebenszeit normal aus.

Ich hasse es, wenn Programme nicht sofort auf dem Bildschirm erscheinen.

[Schrompf]

Ja, da bin ich mit Dir. Schön, dass es so einfach ging!

[Krishty]

Als ich heute morgen meinen PC aus dem Stand-By geweckt habe, war mein Spiel automatisch pausiert. So Malheurs wie, dass mittendrin der Bildschirmschoner anspringt (weil Windows dafür nur Tastatur- und Mauseingaben kontrolliert; aber nicht Joysticks und Lenkräder), habe ich ebenfalls ausgeschlossen.

Vielleicht poste ich dieses Wochenende eine kurze Zusammenfassung der ganzen Energieverwaltung; ich weiß nur nicht, ob sich mit Windows RT und dem ganzen Windows 8-Kram irgendwas zu stark geändert hat …

[CodingCat]

C++14 Best Of

Abgenickt:

• Variable templates ala "template <typename T> int foo<T> = ..."
• Run-time sized arrays on the stack got in as well. Very mild controversy there, but in the end it was pretty much unanimous.
• Third controversial issue, std::dynarray, got voted in as well.

Zur Debatte?

• "auto f(int i) { if (i < 1) return 1; else return f(i-1) * i; }" will likely be valid C++14
• C++14 will also likely include binary literals like 0b101010. Maybe we should call it C++0b1110?

Nebenbei ist clang soeben C++11-complete geworden. Das entsprechende Release wird im Sommer erwartet.

[Krishty]

C++14

Run-time sized arrays on the stack got in as well.

[Artificial Mind]

Ich habe jetzt meinen eigenen funktionierenden C++11-kompatiblen Preprozessor fertig geschrieben. Berechnet auch direkt die Byterepräsentationen aller ppNumber- und String/Char-Literale (auch user defined strings/chars).

Auf meinem Weg zum eigenen C++11-Kompiler steht also wahrscheinlich als nächstes die C++-Syntax-Analyse an. Ich freu mich schon :)

[Helmut]

Run-time sized arrays on the stack got in as well.

Pff, ich seh's schon kommen. Leute werden Benutzereingaben ohne Längenbegrenzung so auf dem Stack speichern und sich dann über DoS Attacken wundern. Vielleicht sogar Sicherheitslücken, wenn das Programm irgendwie versucht Stack Overflow Exceptions zu recovern.

[Schrompf]

Bin nicht ganz sicher, ob das Material für den Jammer-Thread oder für Anti-Jammer ist. Ich habe gerade einen Bug im Splatter-Lichtshader gefixt, bei dem die fiktive Höhe eines Pixels nur für die Schattenberechnung, aber nicht für Attenuation und die Spotlight Cone verwendet wurde. Der Fix hat das komplette Erscheinungsbild des Spiels subtil verändert. Manche Dinge sehen jetzt einfach nur "richtig" aus, andere dagegen sehen jetzt aus wie reinkopiert.

Leider ist die Erstellung ordentlicher Relief Maps zu allen Grafiken eine ziemlich mühsame Arbeit, die sich mein Grafiker größtenteils erspart hat. Bisher hat man das nur an den bisweilen seltsamen Schatten-Silhouetten gesehen, die bei uns ja eh relativ weichgezeichnet erscheinen. Jetzt sieht man es aber auch im Licht jedes Scheinwerfers, dass die Höhen nur wie in einem billigen NormalMap-Generator aus der Farbtextur abgeleitet wurden.

Nuja, ich muss eh vor Release nochmal über alle Grafiken drüber. Das ist dann nur ein weiterer Posten auf der ewig wachsenden Liste.

[Edit] Damit das noch etwas anti-jammeriger klingt: Das letzte Level ist fertig, inklusive Musikdynamik, Speicherpunkten und allen Dialogen und Verzweigungen. Es ist noch nicht sonderlich hübsch, weil es noch vom Grafiker aufpoliert wird, aber es funktioniert und hat ein paar coole Szenen. Und inzwischen habe ich auch ein grobes Konzept für den Bosskampf entwickelt und bastle gerade fröhlich an der ersten Phase des Kampfes.

[kimmi]

Innerhalb einer Woche das neue Haus gestrichen und teil-tapeziert, umgezogen, die alte Wohnung renovieren lassen und über die Hälfte aller Kisten verstaut. Und nun wieder arbeiten. Sprich: ich sehe gerade mal keine neue Kiste :).

Guß Kimmi

[Krishty]

Visual C++ erkennt mit /fp:precise, dass sich -x + y zu y - x optimieren lässt. Das ist … überraschend und beruhigend. Ich hatte die Hoffnung längst aufgegeben …

[Aramis]

Irgendjemand hat Videos von den ersten 8 Levels von Entropy auf Youtube gepostet (in der Xbox-Fassung, mit entsprechender Qualitaet). Irgendwie komisch das zu sehen, aber durchaus spassig :-)

Ich glaube, danach hat er aufgegeben.

[youtube]7JEOv5lanmM[/youtube]

[Chromanoid]

Hehe, zumindest ich hab mich da wieder gefunden. :D

[Schrompf]

Großartig!

[kimmi]

Wie wahr :) ...