ZFX + Developia

Er ist ja auch nicht mehr trivial in dem Sinne, dass er sich wie der default verhält, denn den default copy-consturctor kann man man eben über das public interface aufrufen, deinen nicht. Von daher ist es gar nicht möglich, als benutzer deinen Klasse mal eben eine Kopie per copy-constructor zu machen, da du in der public API der Klasse quasi keinen copy constructor zu Verfügung stellst, auch keinen trivialen, also müsste ein imaginäres __has_copy(myclass) zu false auswerten (ob du intern einen hast, ist ein Implementationsdetail) und entsprechend ist es völlig korrekt, dass __has_trivial_copy(myclass) zu false auswertet

Naja, ich hatte die Sache etwas abgekürzt. Da es um protected ging, ging es natürlich auch um abgeleitete Klassen. Aber auch __has_trivial_copy(myderived) wertet zu false aus, selbst, wenn myderived überhaupt nichts definiert.

Hmm, das würde man dann in der Tat nur erwarten, wenn sich deine Implementation vom default unterscheidet.

Und wo wir schon dabei sind, ich will eine Möglichkeit, virtuelle Methodenaufrufe nur einmal aufzulösen und das Ergebnis für direkte Sprünge zwischenzuspeichern. Jetzt löst mir dieses unfähige Ding von Visual C++ in einer Schleife 100.000 Mal denselben virtuellen Aufruf mit demselben Bezugsobjekt neu auf, und die virtuelle Tabelle belegt vollkommen nutzlos die ganze Zeit wertvollen Cache-Speicher.

Wie wärs mit einem Methodenzeiger?

Ich dachte bisher, dass Methodenzeiger immer fest an die zugehörige Klasse gebunden wären. Erst auf deinen Hinweis hin sehe ich, dass der Compiler auch void (iface::*mthd)() const = static_cast<void (iface::*)() const>(&virt::foo); akzeptiert. Großartig, jetzt muss ich nur noch rausfinden, ob das standardisiert ist. :-)

Wenn es ein entsprechendes foo in iface gibt, dann is das wohldefiniert. Ich denk das Problem ist, dass er sich dann erst wieder nur den vtable Offset merken wird. Ein Aufruf kommt dann also dem normalen virtual call gleich :|

Selbst wenn, in diesem Fall kapiert der Optimizer in meinem Trivialbeispiel sofort, dass es sich immer um dieselbe Funktion handelt, und optimiert sämtliche überflüssige Lookups weg. Wie das dann im Jungle aussieht, weiß ich erst später.

Siehe zwei Posts tiefer.

Cool, gut zu wissen :)

Bah, da habe ich vorhin etwas unachtsam drübergeschaut. Tatsächlich werden mit virtuellem Methodenzeiger aus einem Sprung zwei Sprünge. Der Compiler emittiert eine extra vcall-Funktion, die dann zu allem Überfluss auch noch den V-Table-Lookup macht, bevor sie in die eigentliche Methode springt. :shock:

lol, ok das war wohl nichts xD

Es ist mir jetzt schon vier mal in den letzten zwei Tagen passiert, dass Visual Studio sich nach Beenden der Anwendung aufgehängt hat. Irgendwas verfängt sich beim Umbau vom Debug- zum Entwicklungskontext und sorgt dafür, dass das ganze Ding mitten im Rendern der Quelltext-Seite in einer Endlosschleife verschwindet. Hatte das schonmal jemand? Weiß jemand, was man dagegen tun kann?

Ach die Deutschen sind halt ein Jammer-Volk.

Fällt euch eigentlich auf, dass ihr die ganze Zeit über proprietäre Softwarelösungen jammert? Ich muss zugeben, wenn ich über OpenSource jammere, schmeißt mir gleich der Entwickler des bejammerten Softwarestücks entgegen, dass ich es ja ändern könnte. Will man vielleicht gar nicht für gewisse Dinge verantwortlich sein, um stattdessen darüber jammern zu können?

Will man vielleicht gewisse Dinge garnicht selber entwickeln, um sie stattdessen verwenden zu können? Troll dich. Nee darfst bleiben; das geht gerade noch als höchst subjektiver Jammer-Post durch.

Das Kreuzprodukt ist für Gleitkommaarithmetik wirklich eine der katastrophalsten Rechenoperationen überhaupt. Während ich mir beim Skalarprodukt sicher sein kann, dass das Ergebnis selten mehr als 1 ULP vom Sollwert abweicht; und auch Matrixmultiplikationen gemessen am Rechenaufwand noch relativ zielsicher sind; geht es beim Kreuzprodukt regelmäßig in die Hunderttausenden ULPs. Alles, wo ein Kreuzprodukt drin vorkommt, reißt grundsätzlich aus der Fehlerstatistik aus. Bah.

Krishty hat geschrieben:Alles, wo ein Kreuzprodukt drin vorkommt, reißt grundsätzlich aus der Fehlerstatistik aus.

Das ist nicht verwunderlich, weil – wie man ja in der Formel für das R³-Kreuzprodukt sieht – in jeder Komponente Auslöschung auftritt. Ich habe mal das ganze als unitäre Abbildung aufgeschrieben (das Kreuzprodukt ist ja nichts anderes als eine Rotation um 90° um eine Achse), und vereinfacht (unter den Standardannahmen eines Orthogonalsystems). Die schlechte Nachricht ist, dass genau die Formel des Kreuzprodukts rauskommt, und da dass eine unitäre Abbildung ist, wird es numerisch gesehen kaum ein stabileres Verfahren geben. (Für allgemeinere Systeme macht man ja ein Gram-Schmidt-Verfahren via QR-Zerlegung, und das stabilste Verfahren dafür benutzt Givens-Rotationen, und das sind halt unitäre Abbildungen.) Das deckt sich auch mit der folgenden Aussage:

http://www.cs.berkeley.edu/~wkahan/MathH110/Cross.pdf, Seite 11 hat geschrieben:Therefore these bilinear forms and other matrix products should be computed carrying somewhat more precision than in the data provided that this extra-precise arithmetic runs at some adequate speed.

D.h. wenn du in single-precision arbeitest, kannst du auf double-precision hochsatteln:
http://code.google.com/p/skia/issues/detail?id=443

Numerische Analyse ist kein exotischer Randfall. Nur ist sie extrem hässlich, und beißt einem immer wieder in den Hintern.

Oh und noch ein Nachtrag:

Krishty hat geschrieben:und auch Matrixmultiplikationen gemessen am Rechenaufwand noch relativ zielsicher sind

Kreuzprodukte sind Matrixmultiplikationen.

eXile hat geschrieben:Oh und noch ein Nachtrag:

Krishty hat geschrieben:und auch Matrixmultiplikationen gemessen am Rechenaufwand noch relativ zielsicher sind

Kreuzprodukte sind Matrixmultiplikationen.

Du hast recht. Habe mich schon kurz nach dem Abschicken gefragt, was zur Hölle ich da geschrieben hatte …

eXile hat geschrieben:Die schlechte Nachricht ist, dass genau die Formel des Kreuzprodukts rauskommt, und da dass eine unitäre Abbildung ist, wird es numerisch gesehen kaum ein stabileres Verfahren geben.

Ja, das habe ich schon befürchtet – die Suche nach Kreuzprodukt und Präzision verhieß nichts Gutes. Es ist wirklich schade, dass ich keine Zeit habe, solche Veröffentlichungen wie die von dir verlinkte zu lesen … dann würde ich mit der ganzen Chose deutlich weniger im Wald stehen.

Auswandern, Heiraten, Umziehen und das Bad der Oma renovieren, alles gleichzeitig, ist anstrengend Zumindest beim Bad nervt keine dumme Behörde...

Gleicher Zip-Algo, gleiche Kompressionsstärke, aufs Byte genau identische Ausgangsgröße der Ordner. Die eine Zip ist aber mehr als 1kb größer als die andere.
Einziger Unterschied der Ausgangsdaten: Die Versionsnummer wurde um 1 hochgezählt.
Anscheinend lässt sich unabhängig vom Inhalt ein Ordner mit dem Namensteil 3.0.0.0 deutlich besser komprimieren als einer mit 3.0.0.1
:shock:

TortoiseSVNs Rechtschreibkontrolle für Log Messages kann kein britisches Englisch, nur amerikanisches...

kaiserludi hat geschrieben:Gleicher Zip-Algo, gleiche Kompressionsstärke, aufs Byte genau identische Ausgangsgröße der Ordner. Die eine Zip ist aber mehr als 1kb größer als die andere.
Einziger Unterschied der Ausgangsdaten: Die Versionsnummer wurde um 1 hochgezählt.
Anscheinend lässt sich unabhängig vom Inhalt ein Ordner mit dem Namensteil 3.0.0.0 deutlich besser komprimieren als einer mit 3.0.0.1
:shock:

Hab jetzt nicht genau im Kopf wie der ZIP Algo aufbebaut ist, aber laut Wiki enthält er u.U. auch eine Huffman-Codierung. Heißt je nach Tokenization kann da schon ein anderer Kodierungsbaum herauskommen (vorrausgesetzt jede Datei besitzt nun auch einen kompletten Pfad anstelle relative Ordnerbezüge in der internen Dateitabelle).

Aber trotzdem ist 1KB schon ziemlich extrem, oder nicht? Werden Dateinamen überhaupt mit komprimiert? Ich bin mir ziemlich sicher, dass es zumindest eine Variante von ZIP-Dateien gibt, wo die einzelnen Dateien des Archivs jeweils mit Header hintereinander im Archiv liegen, der Header ist aber nicht komprimiert, und enthält neben dem Dateinamen und anderen Daten noch einen Offset, um zur nächsten Datei zu springen, damit man nicht immer alle Daten entpacken muss.

Habe mal in die zips reingeschaut und die komprimierte Größe ist in manchen Unterordnern 1-2kb größer geworden in anderen 1-2kb kleiner, das 1kb größer unterm Strich komm nur daher, weil größer leicht häufiger vor kam als kleiner...
Sind schon ein paar hundert Dateien in über hundert Unterordnern, von daher könnte das, wenn absolute Pfade abgespeichert werden, natürlich sich schon summieren.

Im Endeffekt ist das 1kb in diesem Fall auch eher egal bei einer Größe des Archivs von 16,7MB, aber das es einen Unterschied macht, finde ich generell gesehen dann schon unschön.

kaiserludi hat geschrieben:TortoiseSVNs Rechtschreibkontrolle für Log Messages kann kein britisches Englisch, nur amerikanisches...

Gehört das nicht in den Anti-Jammer-Thread? :P

Zum Thread: transparente Geometrien zeichnen ist so grausam für die Architektur einer Engine >.< eigentlich müssten alle Faces aller transparenten Objekte in einen Buffer und dann in der richtigen Reihenfolge gezeichnet werden

Wenn zwei Dreiecke sich durchdringen, dann reicht nichtmal das ;)

Jo klar, eigentlich müssten alle Dreiecke geprüft werden, ob sie sich schneiden und dann bei Bedarf splitten ... in einer dynamischen Umgebung ... Wann loest Raytracing nochmal den Rasterizer ab? :D

Alles was man eigentlich bräuchte, wäre ein Buffer der alle Fragmente jedes Pixels speichert und eine programmierbare Output Merger Stage :P

Kann man sich natürlich heutzutage alles selbst basteln, ist aber nicht grad besonders billig was die Performance betrifft...

Order-independent Transparency mittels k-Buffer bzw. für definiertes Verhalten eher mittels stencil-routed A-Buffer könnte helfen. Damit wärst du sogar schon DX10-kompatibel. In DX11 ginge natürlich auch OIT mittels verketteten Fragmentlisten, welche auch in dots Video zum Einsatz kommen dürfte.

Das sieht echt cool aus, aber bestimmt nicht OGL 3.3-kompatibel^^

Nope. In OpenGL ohne herstellerabhängige Extensions im Moment afaik überhaupt nicht machbar.