ZFX + Developia

Spannende Details, von denen man hier immer wieder liest.

Ich mache mir inzwischen Sorgen um den Resourcen-Verbrauch.

Konsole hat geschrieben:Insgesamt 106 Resourcen mit einer Gesamtgröße von schätzungsweise 597009 kb.
6 Vertex-Eingabedeklarationen
15 VertexShader
15 PixelShader

29 VertexBuffer (4987 kb)
davon 24 im VideoRAM (4315 kb)
davon 26 dynamisch (4986 kb)
davon 5 offline (671 kb)

4 IndexBuffer (5 kb)
davon 3 im VideoRAM (5 kb)
davon 0 dynamisch (0 kb)
davon 1 offline (0 kb)

37 Texturen (592016 kb)
davon 34 im VideoRAM (586293 kb)
davon 0 dynamisch (0 kb)
davon 12 Renderziele (95152 kb)
davon 3 offline (5722 kb)

Ein bisschen viel für einen kleinen Indie-Shooter. Ich probiere wohl bei Gelegenheit nochmal aus, ob die Textur-Atlanten mit DXT5-Kompression noch vernünftig aussehen.

Habe ein Visual Studio 2010 und ein Visual Studio 2012 Projekt im gleichen Ordner. Die Namen der Pojektdatieen sind natürlich verschieden. Dennoch löschen beide Visual Studio Versionen bei einem Clean oder Rebuild auch die Builderzeugnisse des jeweils anderen Projektes, sie löschen aber nicht einfach grundsätzlich alles an Builderzeugnissen im gleichen Ordner, sondern nur die aus der gleichen Buildconfig, das allerding projektübergreifend.
WTF?
Habt ihr eine Idee, wie ich das behoben bekomme, ohne ein Projekt in einen anderen Ordner zu verschieben oder eine Buildconfig umzubenennen?

Den Buildoutput im 2010er Projekt in ein anderes Verzeichnis laufen lassen als im 2012er Projekt!? ;)

Der Grund dafür ist dass bei Clean einfach alle Dateien mit den in den Project Properties angegebenen Dateierweiterungen aus dem Outputverzeichnis geslöscht werden.
Deshalt ist dots Vorschlag wohl der einfachste Weg

Das C++11 Tech Preview für Visual Studio 2012 war ein "Fake", es wird kein entsprechendes VC12-Update geben. Stattdessen sehen wir die Änderungen in Visual Studio 2013, und wenn wir Pech haben, werden die CTP-Features auch schon die Flaggschiff-Änderungen für dieses Release. :(

Ich hasse es, sowas zu beanstanden, aber: Bitte schreib VC 2012 statt VC12. Sonst kommen wir mit den Versionsnummern (11 für Visual Studio 2012) vollends durcheinander :(

Ich habe eben in Chromes Adressleiste nach The Daily WTF gesucht und das hier angezeigt bekommen:


Die URL begann mit google.de/sorry. WTF?! Ich surfe hier über HSPA und kann mein gesamtes Datenvolumen einsehen. Ich emittiere nichts Ungewöhnliches. Oh shit – ist das etwa die NS

Was meinen die denn mit "Ihrem Netzwerk"? Vielleicht einen ganzen IP Adressbereich?

Ach wie schön ist es doch, wenn man sich durch 3d Party Code kämpfen muss, der seine magic values mit /* Haha. guess what it is */ kommentiert.

Die Visual C++ CRT hat mit Visual Studio 2010 begonnen, die Listen der globalen Konstruktoren und Destruktoren durch EncodePointer() und DecodePointer() zu verschleiern. WTF?! Ich meine: Jeder Prozess ist voll von Zeigern. Durch Address Space Layout Randomization liegen die K’toren und D’toren sowieso immer an unterschiedlichen Adressen. Warum muss man sie noch zusätzlich obfuscaten?!

Wiedemauchsei: Die Hauptwirkung davon ist, dass Programme seit Visual C++ 2010 nicht mehr Windows 2000-kompatibel sind. Man kann sich die nötigen Dummy-Funktionen recht schnell im Assembler selber zusammentüfteln (der C++-Compiler ist keine Option, weil Sonderzeichen in den Namen vorkommen), aber … bah ist das kompliziert. Die meisten sehen das als blanke Schikane um die Leute von Windows 2000 wegzukriegen.

Anti-Jammer-Anteil: Jetzt bin ich Windows 2000-kompatibel.

Neues Haswell-System gekauft mit Intel 4670k. Windows 7 installiert, alle Treiber und Updates stundenlang installiert. Compiler angeschmissen, nach 2 Minuten Arbeit 90 Grad auf der CPU. System schaltet sich sicherheitshalber selber aus.

Computer geht zurueck. WTF Intel?

WTF

Ich versuche seit 15 Minuten, mit Wischl Schtutjo ein Win32-Projekt anzulegen – aber ich finde einfach keine einzige <windows.h> auf dem System, die sich ohne Fehler einbinden lässt

Warum muss ich das überhaupt einstellen?

WTF

Ich hab' den Kreditrahmen für die Kreditkarte zu niedrig angesetzt. Der Rahmen ist ausgeschöpft und ich muss jetzt einen Monat warten, bis das endlich mit dem Konto verrechnet wird und ich weitermachen kann.
Dabei wollte ich doch mein Adwords-Konto wieder aufladen, um meine Youtube-Karriere für Trash-Comedy aufzubauen (http://www.youtube.com/watch?v=UXd0xBR5JrA)

Hattest du denn auf ZFX nicht genug Zuschauer?

Argh, meine Radeon 7970 zeigt lustige Rechtecke ueberall. Verreckt also. Nach drei Monaten Nutzung ;( Mal sehen, wie der XFX-Kundensupport so ist ...

40 Minuten gearbeitet. Sechs Schleifen von Zählern zu Iteratoren geändert, davon außerdem vier Schleifen von for zu do-while. Dadurch 23 Anweisungen gespart und 80 B Maschinentext. Langsam wird es krankhaft.

Krishty hat geschrieben:40 Minuten gearbeitet. Sechs Schleifen von Zählern zu Iteratoren geändert, davon außerdem vier Schleifen von for zu do-while. Dadurch 23 Anweisungen gespart und 80 B Maschinentext. Langsam wird es krankhaft.

Mir kommt dein Optimierer immer noch spanisch vor. Wieso ist ein Iterator-Makro (theor. Klasse auf dem Stack etc.) so viel schneller als eine For-Schleife, auf die ja die Compiler noch eher getrimmt sein müssten?
Letzendlich müssten doch beide Varianten in den gleichen Zwischencode münden (was es aber bei zahlreichen deiner Beispiele nicht tut) und am Ende auch der Maschinencode ähnlich klein werden. Oder hat der MS Compiler keinen einheitlichen Zwischencode? (bzw. lässt nicht immer alle Passes über den gesamten Code laufen...)

antisteo hat geschrieben:Wieso ist ein Iterator-Makro (theor. Klasse auf dem Stack etc.) so viel schneller als eine For-Schleife, auf die ja die Compiler noch eher getrimmt sein müssten?

Als Iterator benutze ich einen nackten Zeiger. Aus

    for(int j = 0; j < 100; ++j) {
        foo(array[j]);
    }

wird

    for(auto it = array; it < array + 100; ++it) {
        foo(*it);
    }

was zwei statt drei Register verbraucht; daher die Platzersparnis.

antisteo hat geschrieben:Letzendlich müssten doch beide Varianten in den gleichen Zwischencode münden (was es aber bei zahlreichen deiner Beispiele nicht tut) und am Ende auch der Maschinencode ähnlich klein werden. Oder hat der MS Compiler keinen einheitlichen Zwischencode? (bzw. lässt nicht immer alle Passes über den gesamten Code laufen...)

Das Problem an Visual Studio ist die Abwärtskompatibilität: Weil er noch aus einer Zeit stammt, in der Compiler nicht viel mehr als direkte Übersetzung gemacht haben, sind Transformationen wie if-else-zu-switch (und umgekehrt) nicht vorhanden, damit der Programmierer entscheiden kann, was in seinem Fall schneller ist. Ich vermute, dass der Programmierer im Fall der Schleifen die Wahl haben soll zwischen Decoding-Last (Zähler) und ALU-Last (Iterator). Das war IIRC auch deren Argument gegen Single-Call Site Inlining – da du selbst mit Profiling kaum Möglichkeit hast, dem Compiler Dinge mitzuteilen wie hier brauche ich jetzt mehr ALU-Leistung oder hier bitte keine Lokalität, ist ihnen ein unselbstständiger Compiler mit kalkulierbarer Maschinentexterzeugung wohl lieber als ein selbstständiger, der sich unaufhaltsam falsch entscheidet. Einfach alles zu transformieren würde wohl viel alten Code langsamer machen; und stänkern würden genau die Leute, die ihn schon von Hand optimiert haben, weil wer anders nie misst.

Du kannst ja mal ausprobieren, ob Clang die Schleifen derart transformiert.

Dann könnt man aber doch eine Compileroption einbauen: Ist sie aus (Default) dann hält sich er Compiler mit solchen Optimierungen zurück, ist sie an, dann führt er sie selbstständig durch.

Krishty hat geschrieben:Du kannst ja mal ausprobieren, ob Clang die Schleifen derart transformiert.

Die LLVM/der Clang hat bei meinem letzten Versuch noch sehr viel Zwischencode aus den Makros generiert, der am Ende dafür gesorgt hat, dass der Inline Threshold zu klein war und dass generell die Passes in der Reihenfolge, wie sie im Pass Manager waren, nicht ausgereicht haben, aus dem Iterator-Makro (std::vector) wieder einen normalen Zeigerzugriff zu machen. Wenn man den Optimierer aber 2 mal über den Code laufen lässt, kommt das Optimum heraus. Das ist ein Kritikpunkt, den ich an LLVM habe, dass die Passes fest vorgeeben sind und nicht wiederholt werden, wenn z.B. BBs zusammengeflickt werden. Das Optimum aus meiner Sicht wäre ja, dass konstant berechnende Programme gleich im Compiler ausgeführt werden und nur der Runtime-Teil in Code gepresst wird. Das brauche ich, weil ich sehr viel unnötige (=situationsbezogene) Logik einer dynamischen Programmiersprache immer mitkompiliere und darauf hoffe, dass die LLVM das schnell macht (also mein Compiler-Frontend nur Code-Schnipsel zusammenstecken muss). Das funktioniert aber von Version zu Version besser.

Welche Makros? Warum std::vector? Ich dachte, es ginge darum, ob LLVM Zähler zu Iteratoren (oder umgekehrt) optimiert?

Krishty hat geschrieben:Welche Makros? Warum std::vector? Ich dachte, es ginge darum, ob LLVM Zähler zu Iteratoren (oder umgekehrt) optimiert?

std::vector::iterator und so...
Oder worauf willst du hinaus?

Naja generell dass man Code entweder bequem (mit Templates) schreiben kann oder jede Anweisung handcraftet mit dem Hintergedanken, dass der Compiler eh nicht gut mit den Templates umgehen kann.

Mit Iteratoren meinte ich nicht STL-Iteratoren. Auch Zeiger mit Zeigerarithmetik sind schon Iteratoren über die Arrays, auf die sie zeigen (siehe Quelltextschnippsel); das geht schon in völlig Template-losem C. STL-Iteratoren zu Zeigern optimieren schafft AFAIK auch Visual Studio seit einigen Versionen (aber die nutzen für optimierte Kompilate unterschiedlichen Quelltext).

Ich hab' mal dein Codebeispiel durch den Clang gejagt und die Variante mit den Arrays generiert kürzeren Code, während die Iteratoren mehr Stack brauchen. Der Code für Arrays braucht 0x25 Bytes, während die Iteratoren 0x27 Bytes brauchen.

Hier ist mein Testfall mit Zähler:

    static size_t const COUNT = 1000;
    auto array = new int[COUNT];
    int sum;
    int i = 0;
    do {
        sum += array;
    } while(++i < COUNT);
    auto volatile forceEffect = sum;
   
und hier mit Iterator:

    static size_t const COUNT = 1000;
    auto array = new int[COUNT];
    int sum;
    auto it = array;
    do {
        sum += *it;
    } while(++it < array + COUNT);
    auto volatile forceEffect = sum;

Der Maschinentext, den Visual C++ für die Version mit Zähler erzeugt:

    mov r8d,dword ptr [sum]
    xor ebx,ebx
    mov edx,ebx
main+24h:
    add r8d,dword ptr [rax]
    inc edx
    lea rax,[rax+4]
    movsxd rcx,edx
    cmp rcx,3E8h
    jb main+24h
   
Visual C++ legt also einen seperaten Iterator an – Datenverarbeitung läuft via Iterator im Instruction Decoder; Branching nebenläufig via Zähler in der ALU.
Nun für die mit Iterator:

    mov ecx,dword ptr [sum]
    lea rdx,[rax+0FA0h]
    nop word ptr [rax+rax]
main+30h:
    add ecx,dword ptr [rax]
    add rax,4
    cmp rax,rdx
    jb main+30h

Blanker Iterator ohne nebenläufigen Zähler ausschließlich auf der ALU, darum kompakterer Text. Hier wäre interessant zu wissen, warum add rax,4 statt lea rax, rax+4 emittiert wurde.

Clang habe ich nicht hier; ich habe deshalb Clang 3.0 vom GCC Explorer genommen. Ist veraltet, aber das einzige, was ich finden konnte. Hier der Maschinentext für die Version mit Zähler:

    movl   $1, %ecx
    jmp    .LBB0_1
.LBB0_2: # %._crit_edge
    movl   (%rax,%rcx,4), %esi
    incq   %rcx
.LBB0_1: # =>This Inner Loop Header: Depth=1
    addl   %esi, %edx
    cmpl   $1000, %ecx # imm = 0x3E8
    jne    .LBB0_2

Clang benutzt ausschließlich einen Zähler; sowohl für Adressierung als auch für Branching.
Und hier mit Iterator:

    leaq   4(%rax), %rcx
    leaq   4000(%rax), %rax
    jmp    .LBB0_1
.LBB0_2: # %._crit_edge
    movl   (%rcx), %esi
    addq   $4, %rcx
.LBB0_1: # =>This Inner Loop Header: Depth=1
    addl   %esi, %edx
    cmpq   %rax, %rcx
    jb    .LBB0_2

Also überführt Clang bis Version 3.0 keine Zählschleifen zu Iteratorschleifen; Visual C++ schon, was mich jetzt wirklich verblüfft hat. Allerdings nutzt Visual C++ dann Zähler und Iterator gemeinsam, weshalb die Textgröße so steigt. Ich bin überfragt, ob Zähler zusätzlich zu Iteratoren noch höhere Leistung bringen oder eher ausbremsen – hier spielen Branch Prediction, Prefetching, ALU-Last, Decoding-Last und Textgröße rein. Wäre toll, wenn das jemand mit einem vernünftigen Benchmark erforschen könnte.

Schade, dass meine Uni keinen Lehrstuhl für Compilerbau hat. Sonst könnte ich das Thema dort absolvieren, das ganze Benchmarken, ein Paper rausbringen und dann mit dem Paper die LLVM-Leute davon überzeugen, Variante XYZ zu verwenden.

emplace_back() verleitet die Leute zu emplace_back(new T(...)) für Containers von unique_ptr<T>, wie ich eben in einer fremden Codebasis feststellen musste. new sollte tatsächlich nicht mehr aufgerufen werden.

VC 2013 ist da, genauso hässlich und schlecht wie seine Vorgänger.

Aber … 5000 neue APIs!

Cross-Quote aus dem Sehenswerte-Videos-Sammelthread:

CodingCat hat geschrieben:Massive virtual textures for games: Direct3D Tiled Resources (Hinweis auf 11.2-Features?)

DXGI 1.3 Improvements
Direct3D 11.2 Features
D3D11_FEATURE_DATA_D3D11_OPTIONS1

Das ist jetzt eher wenig berauschend. Benötigt übrigens „Windows 8.1 Preview“.