ZFX + Developia

Verfasst: **23.02.2017, 13:15**

Ja, oder frische T-Shirts^^

Verfasst: **24.02.2017, 15:02**

Air und Stage3D. Schöne Sache eigentlich, schön Low-Level und trotzdem überschaubar.
Ganz toll: DirectX9 wird aktiviert, höchstes angefordertes Profil (Standard Extended) wird angenommen, Player 21. Laut Referenz funktionieren damit Instance-Buffer. Laut Fehlermeldung kennt meine Plattform das nicht. [Fault] exception, information=Error: Error #3708: Feature not available on this platform. Dann müsste er aber doch schon beim Profil aussteigen, für was gibts die denn sonst ... *grrr* :evil:

Verfasst: **25.02.2017, 22:46**

Ich habe ein Array von Funktionszeigern. 50 Stück, also 400 B (auf x64). Das könnte man auf 50 % reduzieren, wenn der Compiler nur den Abstand zum Anfang der EXE (oder des Textabschnitts) speichern würde. (In meinem Fall sogar auf 25 %, weil die EXE nicht größer als 65536 * Call Alignment ist).

Tut er aber natürlich nicht, und wenn ich das selber ausrechne, ist es keine constexpr. Ist doch alles scheiße.

Edit: Eigentlich meide ich switch, weil VC da furchtbaren Code produziert. In diesem Fall könnte ein Jump Table vom Compiler aber kompakter werden. Mal testen.

Edit: Great Success: Visual C++ erzeugt eine 4-B Offset Table. Huge Failure: Nur für die Hälfte der cases. Die andere Hälfte erhält Inline-Kopien der aufzurufenden Funktionen.

Edit: Nein, Epic Fail: Visual C++ erzeugt eine 4-B Offset Table. Gemäß der Tabelle wird gesprungen. Und zwar zu einer von 50 Kopien à „rufe X auf“, die sich nur in X unterscheiden.

Verfasst: **26.02.2017, 00:52**

*sigh*

void IndexList::addIndex(UInt4B i) {
assert(i < 65536);
*myIndices.end++ = UInt2B(i);
}

void IndexList::addTriangle(UInt4B a, UInt4B b, UInt4B c) {
addIndex(a);
addIndex(b);
addIndex(c);
}

void IndexList::addQuad(UInt4B a, UInt4B b, UInt4B c, UInt4B d) {
addTriangle(a, b, c);
addTriangle(a, c, d);
}

wird zu

mov rax,qword ptr [rbx+18h]
mov word ptr [rax],dx
add qword ptr [rbx+18h],2
mov rax,qword ptr [rbx+18h]
mov word ptr [rax],cx
add qword ptr [rbx+18h],2
mov rax,qword ptr [rbx+18h]
mov word ptr [rax],r8w
add qword ptr [rbx+18h],2
mov rax,qword ptr [rbx+18h]
mov word ptr [rax],dx
add qword ptr [rbx+18h],2
mov rax,qword ptr [rbx+18h]
mov word ptr [rax],r8w
add qword ptr [rbx+18h],2
mov rax,qword ptr [rbx+18h]
mov word ptr [rax],r9w
mov qword ptr [rbx+18h],rax

(Ja, wirklich! Ich habe MIT Optimierung kompiliert!)

Also nochmal von Hand:

void IndexList::addQuad(UInt4B a, UInt4B b, UInt4B c, UInt4B d) {
assert(a < 65536);
assert(b < 65536);
assert(c < 65536);
assert(d < 65536);

auto it = myIndices.end;
*it++ = UInt2B(a);
*it++ = UInt2B(b);
*it++ = UInt2B(c);
*it++ = UInt2B(a);
*it++ = UInt2B(c);
*it++ = UInt2B(d);
myIndices.end = it;
}

mov rax,qword ptr [rbx+18h]
mov word ptr [rax],r9w
mov word ptr [rax+2],cx
mov word ptr [rax+4],r10w
mov word ptr [rax+6],r9w
mov word ptr [rax+8],r10w
mov word ptr [rax+0Ah],cx
add rax,0Ch
mov qword ptr [rbx+18h],rax

Ist jetzt noch nicht einmal was Geschwindigkeitskritisches, aber … wie kann man das verkacken?! 20× Speicher statt 8×? Ich dachte, der Bug wäre seit Visual Studio 2015 weg. Jedenfalls tritt er *viel* seltener auf als mit VS 2013.

ich bin echt an einem Punkt, an dem es produktiver wäre, direkt Assembler zu schreiben.

Verfasst: **26.02.2017, 02:19**

Mir ist gerade klargeworden, dass man einem Kegel keine Smooth Normals verpassen kann. Shhhhhhhhiiiiit. Ich dachte vorher wie selbstverständlich, man könnte alles mit Dreiecken erschlagen :(

Nachtrag: Ach, da war doch noch was! Trapeze texturieren. Das geht ja auch nicht mit Dreiecken. Der Kegel ist sozusagen ganz viele Trapeze mit Oberkante Nullbreite.

Ich steig dann mal auf Wellengleichungen um oder so. Hatte Zudo ja gerade erst erklärt. Dann habe ich zumindest echtes DoF.

Verfasst: **26.02.2017, 14:44**

Hast du bei dem obrigen Optimierungs-Fail mal getestet, ob es hilft, const-refereces zu übergeben? "const Uint4B& a" ?

Verfasst: **26.02.2017, 15:31**

Keine Veränderung. Warum denn? Es kann IMO höchstens schlimmer werden, weil Referenzen Aliasen können, aber Kopien nicht …

Verfasst: **26.02.2017, 21:05**

Krishty hat geschrieben:Mir ist gerade klargeworden, dass man einem Kegel keine Smooth Normals verpassen kann. Shhhhhhhhiiiiit. Ich dachte vorher wie selbstverständlich, man könnte alles mit Dreiecken erschlagen :(

Man könnte natürlich einen entsprechenden Shader verwenden, der die exakte Kegelnormale aus einer interpolierten Parametrisierung berechnet...

Verfasst: **26.02.2017, 21:10**

Der könnte ja sogar mit dem normalen Shader identisch sein, weil die Parametrisierung die nicht-normalisierte Normale ist. Der Schock ist aber eher, dass Gouraud Shading schon bei einem so simplen Fall an die Grenzen kommt.

Verfasst: **26.02.2017, 21:14**

Achso, das Problem ist nur bei Gouraud Shading...das wundert mich jetzt ehrlich gesagt nicht wirklich, immerhin ist Gouraud Shading effektiv eine schlechte first-order Approximation einer nichtlinearen Funktion, die an der Spitze des Kegels nicht differenzierbar ist...

Verfasst: **01.03.2017, 22:40**

Microsoft spammt jetzt ohne Opt-Out.

Microsoft hat geschrieben:This message from Microsoft is an important part of a program, service, or product that you or your company purchased or participate in.

und man darf ihnen trotzdem keinen Ziegelstein durch's Fenster werfen.

Verfasst: **02.03.2017, 00:58**

Hab durch Zufall das gerade mit dem Kegel noch gesehen.
Aber so ganz begreife ich nicht, was das Problem dabei ist. Wenn man nur Dreiecke für die Seite benutzt, dann hat man natürlich Schrott, was die Normalen angeht. Aber das ist für mich so, wie wenn man sich darüber beklagt, dass man mit 20 Dreiecke keine runde Kugel hinbekommen kann.
Ich hab jetzt auch nur den Artikel mal "angeklickt" ohne wirklich zu lesen.

Also wenn man kurz vor der Spitze nochmal die Dreiecke splittet, dann ist das doch in Ordnung... die Spitze ist dann die gemittelte normale von allen Seiten... also zeigt sie in die Richtung, in die auch der Kegel zeigt. Ich bin damit sehr zufrieden, weil ich dafür nichts extra anpassen muss, keine Spezialshader oder dergleichen. Und so krasse Spitzen hat man doch in Wirklichkeit kaum.

So sehen die "Spitzen" bei dem Drachen aus...
Krallen und Hörner...

Vielleicht nochmal Wireframe...

Verfasst: **04.03.2017, 23:38**

Visual C++ ist jetzt richtig kaputt. Im Sinne von

static const int fooArray[] = { 1, 2, 3 };

enthält bei Ausführung völlig zufällige Werte oder zeigt auf gesperrten Speicher. Bis irgendwann heute nachmittag ging’s noch, aber jetzt sind alle Konstanten fratze (inklusive Strings). Visual Studio neu gestartet, Windows neu gestartet, Memtest, alles ohne Erkenntnis. Ich kann nichts selber kompilierters mehr ausführen.

: fml.png (6.23 KiB) 2483 mal betrachtet

Verfasst: **06.03.2017, 17:53**

Krishty hat geschrieben:Visual C++ ist jetzt richtig kaputt. Im Sinne von

static const int fooArray[] = { 1, 2, 3 };

enthält bei Ausführung völlig zufällige Werte oder zeigt auf gesperrten Speicher. Bis irgendwann heute nachmittag ging’s noch, aber jetzt sind alle Konstanten fratze (inklusive Strings). Visual Studio neu gestartet, Windows neu gestartet, Memtest, alles ohne Erkenntnis. Ich kann nichts selber kompilierters mehr ausführen.

fml.png

Das kommt davon, dass du so viel damit zumspielst. Installiere am besten Windows neu und lösche alle alten Einstellungen .

Verfasst: **06.03.2017, 21:03**

Ich habe einen großen Code-Block gelöscht, in dem eine Konstruktion à

union { char a[]; struct { int x; } b; } data = { { 0xAA, 0xBB, 0xCC, 0xDD } };

vorkam, und das hat das Problem gelöst. Ich bin drauf gekommen, weil der Fehler nur in Translation Units vorkam, die einen bestimmten Header nutzten. Mehr noch: In dem Müll, der in den Strings stand, konnte ich andere Strings wiederfinden, nur unglücklich verschoben.

Ich schließe daraus, dass der 32-Bit-Visual C++-Compiler

alle konstanten Daten nacheinander in ein großes Array schreibt
für jeden konstanten Pointer einen Offset in dieses Array speichert
bei variable-sized members innerhalb von unions das Offset falsch oder garnicht hochzählt
dadurch alle späteren Konstanten falsche Werte enthalten.

Ich hatte keinen Nerv, es auf einen simplen Fall zu reduzieren, und kein 64-Bit-System zum Testen zur Verfügung – das würde aber wie gespuckt passen auf das „der Compiler war für 32 KiB RAM entworfen und kennt deshalb nur die letzten fünf Zeilen“-Verhalten, das sie Ende 2016 nach 30 Jahren endlich aus dem 64-Bit-Compiler rausgeschmissen haben. Ich denke also nicht, dass der 64-Bit-Compiler betroffen ist oder dass Microsoft Anstrengungen unternehmen würde, das noch zu fixen (weil der 32-Bit-Compiler eh weggeschmissen und durch die 64-Bit-Codebase ersetzt wird).

Verfasst: **07.03.2017, 19:57**

Das hier gehört verboten (aus Assimp):

Code: Alles auswählen

        throw std::invalid_argument("Cannot parse string "
                                    "as real number: does not start with digit "
                                    "or decimal point followed by digit.");

Habe diesen Fehler bekommen und wollte herausfinden, was an der Datei nicht stimmt, aber

keine Zeilenangabe (schlecht)
wenn der Fehler im Logger ankommt, befinde ich mich im catch-Block und der gesamte Parsing-Fortschritt ist bereits weggeschmissen (noch schlechter) – Yay Exceptions!
also durchsuche ich den Quelltext nach „Cannot parse string as real number“ und finde kein einziges Ergebnis weil der scheiß String mittendrin getrennt wurde (GANZ schlecht)

Fun fact: Dieser Beitrag verfassen ging schneller als das lokalisieren des Fehlers

Verfasst: **08.03.2017, 02:50**

ich weiß nicht, obs in den Jammer-Thread aufgrund des Ausmaßes oder in den Anti-Jammer-Thread aufgrund des endlichen Leaks gehört.

Vault 7 ist auf WikiLeaks draußen. Have fun.
Ich würde empfehlen, sobald ihr nach Hause kommt, die Hauptsicherung zu ziehen und die mobilen Geräte das Klo hinunter zu spülen.
Womit man dann WikiLeaks browst hab ich noch nicht rausgefunden :-D

Verfasst: **08.03.2017, 09:23**

Der im .NET integrierte PRNG ist hart scheiße. Ich habe einen randomisierten Optimierungsalgorithmus. Dieser findet bei 1.000.000 Runden mit dem internen RNG eine Lösung mit einem Optimum von 17 Zellen, verwende ich jetzt einen alternativen PRNG, finde ich schon mit 10.000 (und wahrscheinlich weniger) Runden eine Lösung mit 16 Zellen.

Microsoft, SCHÄME DICH!

Verfasst: **08.03.2017, 11:00**

MasterQ32 hat geschrieben:Der im .NET integrierte PRNG ist hart scheiße. Ich habe einen randomisierten Optimierungsalgorithmus. Dieser findet bei 1.000.000 Runden mit dem internen RNG eine Lösung mit einem Optimum von 17 Zellen, verwende ich jetzt einen alternativen PRNG, finde ich schon mit 10.000 (und wahrscheinlich weniger) Runden eine Lösung mit 16 Zellen.

Microsoft, SCHÄME DICH!

Ein bisschen Kontext und Nachforschung:

Der Algorithmus von .NET System.Random ist ein Subtractive Generator, welche einen besseren Ruf haben als Congruential Generators.
Der Source Code kann hier nachgeguckt werden: https://referencesource.microsoft.com/# ... 10694e64ca
Die Parameter stammen aus Numerical Recipes in C (2nd Ed.) von Knuth.
Die Periode ist ziemlich groß, wesentlich größer als 1.000.000.

Ich vermute die haben nur deswegen keinen Mersenne Twister genommen weil der zu viel State hat und die Laufzeit ein wenig unpredictable ist.

Dein "alternativer PRNG" sieht zwar an sich nett aus, aber "Der im .NET integrierte PRNG ist hart scheiße" ist glaube ich unfundiert.

Bzgl deiner Anekdote: hast du mal verschiedene Seeds probiert und geguckt wie stark die Abhängigkeit davon ist?

Verfasst: **08.03.2017, 21:11**

Ich hab am Anfang gar keine fixen Seeds verwendet, zudem hab ich noch ältere Erfahrungen mit System.Random (Pathtracer-Samplegenerierung) und da hatte ich sogar sichtbare Pattern im Bild. Zudem, wenn du dir zufällige Binärzahlen samplest (also .Next() % 2) erhälst du eine Verteilung von (66%*0/33%*1), was auch nicht so sonderlich optimal ist.

Der Algorithmus, den ich gepostet habe, ist von George Marsaglia, welcher die DIEHARD Tests erstellt hat und erfüllt eben auch alle diese Tests.

Verfasst: **08.03.2017, 22:38**

MasterQ32 hat geschrieben:Ich hab am Anfang gar keine fixen Seeds verwendet, zudem hab ich noch ältere Erfahrungen mit System.Random (Pathtracer-Samplegenerierung) und da hatte ich sogar sichtbare Pattern im Bild. Zudem, wenn du dir zufällige Binärzahlen samplest (also .Next() % 2) erhälst du eine Verteilung von (66%*0/33%*1), was auch nicht so sonderlich optimal ist.

Passiert das auch, wenn du Next(2) verwendest?

Verfasst: **08.03.2017, 22:56**

Guter Einwand, tut es nicht. Trotzdem wundert mich, warum ich bei 1 Mio Läufe trotzdem nicht einmal eine Permutation erzeuge, welche der andere schon bei 10k Läufen erzeugt

Verfasst: **08.03.2017, 23:35**

MasterQ32 hat geschrieben:Guter Einwand, tut es nicht. Trotzdem wundert mich, warum ich bei 1 Mio Läufe trotzdem nicht einmal eine Permutation erzeuge, welche der andere schon bei 10k Läufen erzeugt

Von welchem "radomisierten Optimierungsalgorithmus" reden wird denn hier?

[Übrigens ist Next(max) offenbar implementiert als (int)([Zufallszahl zwischen 0 und 1]*max) und das war auch mein Stand wie man das machen sollte, wenn man keine fancypants Random-Klasse zur Hand hat. Keinesfalls mit %. Aber das nur am Rande]

Verfasst: **09.03.2017, 11:06**

Von welchem "ra[n]domisierten Optimierungsalgorithmus" reden wird denn hier?

Einem Assembler, welcher für die Anordnung des Code Flows einen randomisierten Block Allocator verwendet

Verfasst: **09.03.2017, 14:57**

Bin ich leider nicht im Thema. Hast du einen Link? Normalerweise lohnt sich die Art von Randomisierung, um die es hier geht, nur dann, wenn der verwendete Algorithmus eine eingebaute Tendenz zu mehr Struktur hat. Ich denke da z. B. an simulated Annealing. Wenn das so ist sollte die Abhängigkeit vom verwendeten RNG und oder seed bzw. allgemein der verwendeten Sequenz sehr gering sein. Dass das für dich ein Problem ist deutet eigentlich stark auf ein Problem an deinem Ende. Deine Schilderung wirkt im Gegenteil so, als hätte der vermeintlich bessere RNG durch "Glück" die "richtige" Sequent getroffen und das ist normalerweise nicht das was man will, sondern man will im Average Case gut sein.

Verfasst: **09.03.2017, 21:07**

DerAlbi hat geschrieben:Vault 7 ist auf WikiLeaks draußen. Have fun.
Ich würde empfehlen, sobald ihr nach Hause kommt, die Hauptsicherung zu ziehen und die mobilen Geräte das Klo hinunter zu spülen.

… und Notepad++ zu aktualisieren: https://notepad-plus-plus.org/news/note ... issue.html

Verfasst: **09.03.2017, 22:17**

Pfff danke. Das hab ich in allen VMs.
Es wäre interessant welchen Hash oder was auch immer die DLL von der CIA hat. Hab Notepad++ geupdated und die DLL wird offensichtlich normal geladen... aber aaaaalter was für dreckige Assis.
Ich frage mich, ob man die Verklagen kann. Prinzipiell kann man denen einen erhöhten Stromverbrauch in Rechnung stellen. Einfach pauschal. Generalverdacht gegen mich? Generalverdacht gegen CIA/NSA! Generalverdacht ist ja ganz modern jetzt, hab ich gehört.

Hahahaha,
https://wikileaks.org/ciav7p1/cms/page_20251107.html
Internet Explorer ist nicht dabei :-D
Die erwischen echt krass meine Software...
Ich hab: VLC, Skype, Notrpad++, FixoitReader, 7zip, IrfranView, Chrome/FireFox... mega.

Verfasst: **10.03.2017, 00:05**

Er so:

in meinem Kopf so:

Bild

Ein Array von Bäumen aus Zeigern umschichten? Wenn es DAS ist, was mein Browser die ganze Zeit macht, will ich keinen mehr haben.

Luckily reserving space in the vector constructor works, so we're okay for now.

Ja, läuft!

Verfasst: **10.03.2017, 00:32**

Alexander Kornrumpf hat geschrieben:Bin ich leider nicht im Thema. Hast du einen Link?

Leider nein, das zu lösende Problem kennen zur Zeit nur mein Betreuer und ich, werde aber wohl demnächst mal einen Thread dazu aufmachen und ein bisschen aus dem Nähkästchen plaudern, was die Programmierung einer "völlig anderen" Computerarchitektur angeht.

Dass das für dich ein Problem ist deutet eigentlich stark auf ein Problem an deinem Ende.

Ich habe einen Assembler, welcher "guten" Code ausspucken soll, also Code, der möglichst wenig Blöcke (Eine Aneinanderreihung von bis zu 11 Befehlen) verwendet. Die Position eines Blockes entscheidet stark über den Inhalt in diesem Block und alle diesen referenzierende Blöcke, also der totale Dependency-Wahnsinn. Denn durch die Inhaltsänderung eines davon abhängigen Blockes ändern sich wieder die Inhalte aller davon abhängigen Blöcke (rinse and repeat!). Das ganze lässt sich meiner aktuellen Einschätzung nur optimal lösen, in dem man alle Möglichkeiten durchprobiert. Oder man löst das Ganze eben etwas abkürzt und probiert zufällige Permutationen und behält die beste.

Verfasst: **10.03.2017, 08:27**

MasterQ32 hat geschrieben: Das ganze lässt sich meiner aktuellen Einschätzung nur optimal lösen, in dem man alle Möglichkeiten durchprobiert. Oder man löst das Ganze eben etwas abkürzt und probiert zufällige Permutationen und behält die beste.

Sowas in der Art habe ich befürchtet und ich möchte argumentieren, dass du hier einen Denkfehler machst. Wenn du sonst nichts über das Problem weißt, ist es egal ob du 10.000 zufällige Permutationen ausprobierst oder die 10.000 ersten Permutationen nach einem System (lexikographisch o. ä.). Die Wahrscheinlichkeit dass die "richtige" oder "eine gute" darunter ist, ist gleich. Einsichtig, wenn man drüber nachdenkt? Wenn du einen RNG gefunden hast unter dessen ersten 10.000 Permutationen eine gute ist, aber nicht sagen kannst warum, dann hast du im Grunde nicht sehr viel erreicht.

Damit randomisierte Suche überhaupt Sinn macht, braucht es irgendeine Art von Struktur im Suchraum, welcher der Algorithmus (mit etwas Unschärfe, dafür der Zufall) folgen kann. Wenn durch einen unglaublichen kosmischen Zufall die Struktur deines Suchraums auf die Struktur eines bestimmten PRNG passt, dann würde ich alles andere stehen und liegen lassen und DAS weiter untersuchen, denn es ist mit Sicherheit interessanter als was auch immer du eigentlich vorhattest. Ist aber schwer vorstellbar, wesentlich wahrscheinlicher ist es, dass du einfach einen Glückstreffer gelandet hast und auf anderen Instanzen das Problems genauso lange brauchst wie der andere PRNG. Oder dass doch ein bug in deinem Code ist.

Das Standardvorgehen, unterstellt, obiges Wunder wäre nicht geschehen, wäre dass du mal darüber nachdenkst was du über die Struktur deines Suchraums weißt und mit dieser Information simulated annealing oder einen genetischen Algorithmus oder einen Ameisenalgorithmus o. ä. fütterst.

ZFX + Developia

Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread