ZFX + Developia

CodingCat hat geschrieben:Bachelorarbeit gerade noch fertig bekommen. Jetzt darf ich wieder implementieren. ;)

(Ich weiß noch nicht, wie es mit Veröffentlichen aussieht, bei Interesse einfach PM ...)

Cool! Glueckwunsch! :) Worum gehts denn? :)

Na darum. ;)

Ich wollte nur einmal sagen, dass Visual Studio 2012 Ultimate jetzt auf DreamSpark Premium (vormals: MSDNAA) verfügbar ist. Um auf diesen Post noch einmal einzugehen: Windows 8 Enterprise wird es nicht auf DreamSpark Premium geben, nur Windows 8 Pro. Anders lautende Aussagen Microsofts bezogen sich auf ELMS-Administratoren.

Bastel an einer Text-Transformation-Language und glaube dass das sinnvoll sein könnte. Besonder für so kleine Command-Shell-Aufrufe um Dateinamen automatisiert zu ändern oder Textinhalte einfacher zu ersetzen. Spaß macht es auf jeden Fall. :)

Krishty hat geschrieben:

eXile hat geschrieben:

Krishty hat geschrieben:Gamma-korrigiertes Dithering von 24-Bit-Texturen auf 16 Bits, fick ja! Wer braucht schon 32 Bits …

Wird das irgendein komisches R5G6B5-Format wie in den guten alten Tagen?

Sogar ganz genau das (DXGI_FORMAT_B5G6R5_UNORM).

Krishty hat geschrieben:Waaaaaaaaaaaartet. Warum gibt es von dem Format keine sRGB-Version? Will mich Microsoft total verarschen?!

OMFG es wird noch schlimmer: Das ist ja erst ab Windows 8 unterstützt. Von allen Direct3D-11-kompatiblen RGB-Formaten sind die DXTs die einzigen, die 16-Bit-Farben unterstützen?! I can't even

Jaja, falscher Thread. Aber ich habe eben einen Bug in meiner nun nutzlosen 24-zu-16-Bit-Dithering-Funktion korrigiert und dieser unbenutzbare Abfall sieht jetzt noch besser aus als vorher.

Eine Hälfte ist R8G8B8, die andere R5G6B5:

Seit meine Transformationen auf die minimal nötigen Arten von Abbildungen reduziert sind (nur Quaternions für Rotationen, nur Vektoren für Verschiebungen, Matrizen erst, wenn Skalierung ins Spiel kommt), flitzt das durch die CPU wie nix. Kürzer geworden ist der Maschinentext zwar nicht – das liegt aber daran, dass VC++ vorher für jeden Matrix-Rückgabewert einen memcpy()-Aufruf durchgeführt und die wenigsten Funktionen geinlinet hatte. Jetzt sind die einzigen Funktionsaufrufe, die ich noch entdecken kann, die an sincos.

So, ich habe das Verarbeiten der Ray Hits nochmal in einen extra Pass geschoben, um zu verhindern, dass wenige Treffer viele Schnitttest-Threads blockieren. Zusammen mit perfekt kohärent und ziemlich kompakt (3 uints) gespeicherten Strahlen, bin ich jetzt bei ca. 114 ms Frame-Zeit (Kompaktierung brachte 20 ms, Auslagerung der Hits 10 ms).

Dafür ist das ganze jetzt äußerst instabil, weil selbst der nVidia-Treiber die Pipeline-Abhängigkeiten nun offenbar nicht mehr richtig erkennt. Völlig unberechenbar treten hässliche Race-Condition-Artefakte auf und verschwinden auch wieder. Sieht ganz danach aus, als würden von vorangehenden Passes abhängige Passes gestartet, bevor die vorangehenden abgeschlossen sind.

Pro-Tipp: Keine 27 Debug-CPU-Readbacks pro Frame im Programm vergessen. Nochmal müde 6 ms (krass, so wenig!).

Meine Bachelorarbeit ist inhaltlich fertig. 7 Kapitel in 46 Seiten, insgesamt 56 Seiten pdf. Morgen nochmal Typos und Grammatik checken, dann Bildsetzung optimieren. Freitag drucken, Montag Abgabe.

Wenn jede Formel die Anzahl der Leser halbiert, bekomme ich gerade mal so einen homöopathischen Leser :D

Artificial Mind hat geschrieben: Wenn jede Formel die Anzahl der Leser halbiert, bekomme ich gerade mal so einen homöopathischen Leser :D

Hehe, ach, wer liest schon Bachelorarbeiten? Eigentlich nur die, die sie Bewerten müssen und die, die beim Korrekturlesen helfen. Dann mit viel Glück noch 1-2 interessierte Freunde. Meine ist zwar auch offiziell über die Uni Homepage veröffentlicht worden, aber wirklich interessieren tut das wohl doch keinen. Aber darum geht es bei Bachelorarbeiten ja auch eigentlich gar nicht.

Ein paar Multiplikationen nach außen gezogen und mix benutzen anstatt selbst zu interpolieren, bringt dermaßen Performance, das glaubt ihr nicht.

Jonathan hat geschrieben:

Artificial Mind hat geschrieben: Wenn jede Formel die Anzahl der Leser halbiert, bekomme ich gerade mal so einen homöopathischen Leser :D

Hehe, ach, wer liest schon Bachelorarbeiten? Eigentlich nur die, die sie Bewerten müssen und die, die beim Korrekturlesen helfen. Dann mit viel Glück noch 1-2 interessierte Freunde. Meine ist zwar auch offiziell über die Uni Homepage veröffentlicht worden, aber wirklich interessieren tut das wohl doch keinen. Aber darum geht es bei Bachelorarbeiten ja auch eigentlich gar nicht.

Ich habe tatsächlich mal eine gelesen, weil ich für ein Projekt Infos zu dem behandelten Thema brauchte.

Eigentlich nur die, die sie Bewerten müssen

... und die lesen sie auch nur "diagonal" :lol:

Krishty hat geschrieben:main.cpp(168): warning C4723: potential divide by 0

Besagte Warnung entsteht nur bei LTCG und findet irgendwo in einer 100 Zeilen langen Initialisierungsliste statt. Und selbstverständlich zeigt Visual C++ bei Initialisierungslisten alle Fehler an der öffnenden Klammer des K’torrumpfes an. Stückweise auskommentieren geht nicht, weil die meisten Elemente keine Standardk’toren haben und LTCG dann garnicht erreicht wird. (Siehe auch: Compiler, die nur mit POD was taugen, 5. Auflage, Denn fick dich, darum! Verlag.)

Ist in Visual C++ 2012 behoben.

Visual C++ 2012 x86 kompiliert meinen 2010er-Text problemlos (obwohl ich so brutale Vergewaltigungen reingedrückt habe wie die Ausnahmebehandlung der C++-Laufzeitbibliothek zu ersetzen). Die resultierende Datei läuft auf den ersten Eee-PC-Blick problemlos, scheinbar nicht langsamer als die mit 2010 kompilierte Version und ist 5 % kleiner. Ich werde mir den Maschinentext mal genauer ansehen um sicherzustellen, dass das eine positive Veränderung ist; nächste Woche werde ich dann die x64-Version testen.

Vielleicht war ich mit meiner Wolkendiagrammeinschätzung ja tatsächlich ein wenig vorschnell.

Nachtrag: Die x86-Version ist auf dem Eee mindestens 10 % schneller geworden.

Noch einer: Ich finde kaum noch FPU-Anweisungen; abgesehen von 64-Bit-Ganzzahl-zu-double-Konvertierungen fließt nun alles durch die SSE-Register. Vektorisiert wird immernoch nicht im geringsten, aber dafür scheinen die Fälle, in denen Visual C++ 2010 endlos oft Werte auf den Stapel zurückgeschoben und sofort wieder geladen hat, verschwunden zu sein. Alles viel sauberer und mit minimalem Stapeleinsatz.

Mein System ist atypisch, zu langsam für Benchmarks, und voll von Störfaktoren – aber ganz grob scheint sich die Leistung darauf in der Praxis um 5–20 % verbessert zu haben.

Mit dem Disassembly habe ich große Probleme – es zeigt mir Text doppelt und dreifach an; manchmal ohne passenden Quelltext, manchmal mit hunderten Zeilen davon zwischen einzelnen Befehlen; wenn ich pop- und ret-Mnemonics am Funktionsende erreiche, wird das Debuggen erst extrem langsam und dann schaltet der Debugger automatisch in den Ausführungsmodus.

3 Tage Research Aufwand und ein halber Tag Codingaufwand -> Meine Binarysize ist um 80%(!) geschrumpft.

Hm, was hast du da so gemacht? Wobei ich sagen muss, dass die Binarysize mir quasi vollkommen egal ist. Selbst wenn es 2 MB sind, das sind auch nur eine handvoll Texturen. Solange es schnell genug läuft, ist die Größe mir egal. Aber interessant ist es natürlich trotzdem.

Jonathan hat geschrieben:Wobei ich sagen muss, dass die Binarysize mir quasi vollkommen egal ist. Selbst wenn es 2 MB sind, das sind auch nur eine handvoll Texturen.

Wenn das 1,8 MB statische Daten sind, okay. Aber ich habe angefangen (auch hier ohne pauschalisieren zu wollen), die Größe des Maschinentextabschnitts als gröbstes Maß für Komplexität zu nutzen.

Selbst, wenn der größte Teil davon nicht in den Arbeitssatz einfließt (also keine Leistungsauswirkung zur Laufzeit hat), bedeutet es immernoch, dass überkomplexe Dateiformate genutzt werden, große Frameworks eingebunden wurden, viele Abhängigkeiten existieren, und der Text an sich sehr komplex ist (viele Funktionen, und außerdem welche mit hoher Eigenkomplexität – sonst würden sie weniger Text benötigen, wären geinlinet worden, und hätten die Größe eher verringert).

Komplexität ist wiederum ein ziemlich sicheres Maß dafür, welche Qualität man von der Software erwarten kann. Wenn ich ein 4-Megabyte-Monster von EXE vor mir sehe, bereite ich mich mental schon beim Start auf die ersten Bugs vor.

Muss kein Kausalzusammenhang sein, aber zumindest korreliert die Größe meiner Erfahrung nach ganz gut mit der Qualität – sei es Zufall; entropisches Gesetz; oder, dass die Entwickler kleiner Software erfahrener sind, mehr auf Maschinentext achten und bessere Vorstellungen von Effizienz haben.

Ich hätte eher behauptet, dass die Größe eines Programmes direkt mit der Fehlermenge darin korreliert, egal was die Leute von außen an "Komplexität" oder "Qualität" reindeuten.

Dafür dürfte kaiserludi das perfekte Gegenbeispiel sein: Er hat ein paar Zeilen geändert, und jetzt ist das Programm 80 % kleiner. Ich wette aber, dass es nicht 80 % weniger Fehler enthält und auch von der Zustands- und Datenmenge her nicht 80 % weniger komplex geworden ist.

Ist halt imo nur zur sehr groben Einschätzung geeignet.

Die Größe vor einiger Zeit auf 5MB explodiert. Jetzt ist ssie bei etwa 1MB. Ein Kollege hat eine Factoryklasse geschrieben, die in mehrfach verschachtelten Switches, die gegenseitig Templaefunktionen aufrufen aus serialisierten Datenströmen Instanzen einer Containerklasse mitverschiedenen Templateargumenten erzeugt hat:Ergebnis: 72 Factoryfunktionen, 360 so erzeugte Permutationen des Containers und dieser wiederum haben noch tausende Hilfstemplatepermutationen erzeugt.
Habe jetzt die Factoryklasse rausgeworfen und die APIaufrufe zu ihr durch Konstrukutoraufrufe zur Non-tempalte Basisklasse des Containers ersetzt. Das aufwendigste daran war, diese Basisklasse so umzubauen, dass sie die nötigen Nutzdaten, die bisher nur das Subklassentempalte kannte, selbst bereithält, wenn ihr Konstruktor direkt aufgerufen wird, aber möglichst geringen OVerhead zu erzeugen, wenn man Subklassen von ihr erzeugt: Der sprignende punkt ist: Die Subklassen erzeugen den betroffenen Teil der Nutzlast aus den Templateparametern und können ihn daher statisch halten, während er in der Basisklasse in jeder Instanz gehalten werden muss. Bei Runtimegenerics habe ich also nun etwas Overhead im Vergleich zu Compiletimegenerics, aber das ist weit akzeptabler als dieser gewaltige Codebloat. Immerhin wir die Lib auch von Mobile Apps eingesetzt, die über mobile Netzte heruntergeladen werden.

Clangs Fehler und Warnungen sind exzellent. Ich habe vorher strikt Visual C++'s Art verteidigt, jedem Fehler eine ID zuzuordnen, nach der man googeln kann -- aber Clangs Meldungen sind einfach so deutlich, ausführlich, und manchmal auch mit Verbesserungsvorschlägen unterlegt, dass ich bisher nie irgendwas nachschlagen musste. Es sei jedem ans Herz gelegt, das mal auszuprobieren.

Beispiele:

• Bei Fehlern in Headern wird der genaue Pfad durch die Header-Struktur angezeigt, so dass man weiß, von wo was #includeiert wird.
• Bei Fehlern mit typedefs werden die Originalnamen angezeigt, deren Alias der auslösende Bezeichner ist.

Boah die Initialisierungsreihenfolge von K'tor-Initialisierungslisten wird durch Clang überwacht ... so perfekt ... Visual C++ scheißt da einfach drauf

Was ich auch lustig fand waren die Vorschläge für ähnlich lautende sichtbare Bezeichner wenn ich mich mal bei einem vertippt hab. Meistens hat er auch wirklich die richtigen vorgeschalgen :)

Krishty hat geschrieben:[*]Bei Fehlern in Headern wird der genaue Pfad durch die Header-Struktur angezeigt, so dass man weiß, von wo was #includeiert wird.

Macht GCC aber auch.

Ansonsten stimme ich dir zu, dass Clang ein geiler, verständlicher und schneller Compiler ist. Und die LLVM ist sowieso die Zukunft des Compilerbaus. (Aber das LLVM-Team ist ziemlich beschäftigt, weshalb die noch nicht alle meine possible-optimization-bugs gefixt haben)

Frage am Rande: hast du Clang-Binaries genommen oder kompiliert?

antisteo hat geschrieben:Frage am Rande: hast du Clang-Binaries genommen oder kompiliert?

Ich habe für Visual C++ gepatchte 3.2-Binaries heruntergeladen.

Diese Erkenntnis ist absolut banal, aber ich habe gerade eben erst festgestellt, dass die Aufteilung von Header Files und Source Files in entsprechende Header- und Source-Ordner der IDE der gröbste Unfug überhaupt ist. Seit Jahren suche ich mich im Solution Explorer tot, wann immer ich zwischen Header- und Modul-Datei wechseln muss. Dabei ist die Lösung so naheliegend, beide in den selben Solution-Ordner und schon liegen gleichnamige Dateien direkt beieinander. Ich glaube meine Produktivität hat sich gerade verdoppelt.

Gute Sache! Evtl. kannst Du Deine Produktivität nochmal verdoppeln, in Du Dir mal eins der kleinen Code-Snippets ergoogelst, die auf Tastendruck zwischen Header und Source umschalten. Kommt auch mit Visual Assist mit (Alt+O) und ist dort mein persönlicher Held geworden.

Vielleicht wäre das ja auch eine Lösung für Psycho's Translator. Einfach in der IDE das ganze geschickt beieinander anzeigen und durch Automatisierung unterstützen ohne wirklich im Quellcode rumzubasteln. Netbeans und Co. können für C++ übrigens wohl einen großen Teil der Visual Assist Funktionalität von Haus aus. Aber ich programmiere einfach zu wenig C++ um euch das Zeug wirklich schmackhaft machen zu können...

www.typescriptlang.org/

Glaubt man fast nicht, dass es von Microsoft ist - eine freie Lizenz und überall Unix-Pfade verwendet...
Aber IMO eine gute Erweiterung für JavaScript, um ein bisschen Ordnung zu halten (ich schreibe sonst die Typen immer in die Kommentare. Jetzt kann ich es im Code tun)

Okay; Visual Studio 2012 macht meinen x64-Text tatsächlich 7 % schneller. Hübsch.

Ziemlich viele coole Neuerungen im Beta Release von NetBeans, wer JavaScript programmiert sollte sich das mal anschauen: http://wiki.netbeans.org/NewAndNoteworthyNB73
Für C++ Programmierer vielleicht ganz interessant: Memory usage improvements - requires 2x less memory for big projects; Parser speed and scalability improvements :)