ZFX + Developia

Wie zur Hölle ist das denn passiert? (Und was zur Hölle soll eine virtual init()-Methode? :P)

(Noch mehr zu vermeiden als init()-Methoden sind nur virtuelle init()-Methoden.)

Diskussion zu Winkelgenauigkeit und schneller Trigonometrie ausgelagert in [C++] Schnellers sin/cos/tan.

@Cat Hab den Code ein paar Monate lang nicht mehr angefasst. Sieht aber so aus, als koennte man das komplett in den ctor verlagern: *smile*
Vermutlich ein ueberbleibsel eines Tests.

Bin mal wieder schockiert wie langsam die std Streams in Punkto Parsen sind. Habe für meine Projektarbeit einen .OBJ loader (nicht optimiert natürlich) geschrieben und mir das Sponza Modell ausgesucht.

Plain text:
Debug: ~80s
Release: ~16s

Dann hab ich das ganze mal in ein binäres Zwischenformat gespeichert, sodass ich nur noch dieses Format laden muss anstelle des ganzen parsens.

Binary:
Debug: ~0.8s
Release: ~0.06s

Ich mein ich kann mit meiner Lösung durchaus leben, finde es aber doch enorm heftig wie viel Zeit bei den StringStreams drauf geht.

Binaere formate sind auch in der Hinsicht besser, dass die Dateigroesser geringer ist. Die Messwerte bei von dir sind allerdings etwas gar extrem, ich glaube du machst was falsch :/. Kannst du zeigen, wie du das machst?

RazorX hat geschrieben:Bin mal wieder schockiert wie langsam die std Streams in Punkto Parsen sind. Habe für meine Projektarbeit einen .OBJ loader (nicht optimiert natürlich) geschrieben und mir das Sponza Modell ausgesucht.
[..]
Dann hab ich das ganze mal in ein binäres Zwischenformat gespeichert, sodass ich nur noch dieses Format laden muss anstelle des ganzen parsens.
[..]
Ich mein ich kann mit meiner Lösung durchaus leben, finde es aber doch enorm heftig wie viel Zeit bei den StringStreams drauf geht.

Die Standard-IO-Bibliothek ist zwar in der MSVC-Implementierung tatsächlich alles andere als optimal, aber du schließt hier doch etwas vorschnell.

Ein binäres Format wird IMMER schneller sein, selbst wenn du das gesamte IO optimal hinkriegst. Das liegt schon alleine daran, dass das ganze Parsen von Zahlen und Vergleichen von Strings grundsätzlich ein Vielfaches mehr Aufwand ist, als einfach nur Bytes einzulesen.

Obendrein redest du von stringstreams. Die Standard-Bibliothek ist immerhin so entworfen, dass man direkt aus Dateien genauso wie aus stringstreams lesen kann, das heißt du kannst dir hier schonmal einen gigantischen Batzen Kopiererei und Speicherallokationen sparen.

CodingCat hat geschrieben:Die Standard-IO-Bibliothek ist zwar in der MSVC-Implementierung tatsächlich alles andere als optimal, aber du schließt hier doch etwas vorschnell.

Ein binäres Format wird IMMER schneller sein, selbst wenn du das gesamte IO optimal hinkriegst. Das liegt schon alleine daran, dass das ganze Parsen von Zahlen und Vergleichen von Strings grundsätzlich ein Vielfaches mehr Aufwand ist, als einfach nur Bytes einzulesen.

Das ein binäres Format immer schneller ist, hab ich gar nicht angezweifelt und war gar nicht der Punkt. Ich bin letztlich ja auch nur auf binäres Zwischenformat umgestiegen, da try&error im Debug-Modus nicht mehr durchführbar war bei solchen Ladezeiten.

CodingCat hat geschrieben:Obendrein redest du von stringstreams. Die Standard-Bibliothek ist immerhin so entworfen, dass man direkt aus Dateien genauso wie aus stringstreams lesen kann, das heißt du kannst dir hier schonmal einen gigantischen Batzen Kopiererei und Speicherallokationen sparen.

Ich hatte die StringStreams vorallem der Lesbarkeit des Codes wegen genommen, da so das zeilenorientierte Parsen imho wesentlich überschaubarer wird. Hab es gerade mal auf reines fstream umgeschrieben, wahnsinnig schnell ist es zwar immer noch nicht, aber ein guter Schub von knapp ~30% im Release.

Debug: 65.7814s
Release: 11.6181s

Ja, Allokationen und Kopien wiegen auf PCs heutzutage erstaunlich wenig. Um mehr sagen zu können, bräuchte man jetzt aber einen schnelleren OBJ-Parser zum Vergleich. ;) Im Debug hast du natürlich mit der STL dummerweise massig vergleichsweise teure Debug-Zusatzfunktionalität drin.

Wie hast du eigentlich genau festgestellt, dass die Performance der Standard Streams das Problem ist und nicht z.B. eine evtl. suboptimale Verwendung dieser oder etwas ganz anderes? Ich hatte selber mal ähnliche Probleme mit riesigen (~800MB) .obj Files; per Zufall hab ich damals bemerkt, dass das Ding 10x oder sogar mehr schneller lief, wenn in der obj Datei alle v, alle vn, alle vt etc. in Blöcken zusammen standen und nicht durcheinander (oder umgekehrt, kann mich nimmer genau erinnern), vielleicht nützt dir das ja was. Ich hab dann allerdings auch auf ein Binärformat umgestellt, einfach weil auch ein paar Sekunden Wartezeit bei vielen Debug Runs zu einer Ewigkeit werden...

Warum gibt es eigentlich kein einziges vernuenftiges RPG auf Android? Nein, ich will kein Farmville spielen, sondern etwas vernuenftige Haltung unterwegs :evil:

ich will kein Farmville spielen, sondern etwas vernuenftige Haltung unterwegs

Also Max Payne macht mir auf Android sehr viel Spaß. Kann man jetzt nicht als Farmville Spiel bezeichnen ;)

Jammer Teil:
Warum setzt Google bei ihrer Dart IDE auf Eclipse. Das Ding ruckelt nur rum und bringt auch meinen Musik Player ins stocken... so lässt sich das doch nicht verwenden.

Jeason hat geschrieben:

ich will kein Farmville spielen, sondern etwas vernuenftige Haltung unterwegs

Also Max Payne macht mir auf Android sehr viel Spaß. Kann man jetzt nicht als Farmville Spiel bezeichnen ;)

Hehe, ich haette das konkretisieren sollen: Ich will keine Shooter aufm Handy spielen. Das funktioniert nicht, ich bin zu langsam fuer sowas. Und fuer die meisten Hack&Slays auf dem Handy auch :lol: Zumal die nachgemachten "Gamepads" alle irgendwie doof sind. Viel zu klein und mit dem Fingern aufm Display seh ich dann kaum noch was vom Spiel selber :lol:

Ich finde, man kann generell fast gar nichts damit vernünftig spielen. Ich hab nichtmal eine Tetrisversion gefunden, bei der die Steuerung nicht so schlecht war, dass ich nach kurzer Zeit einfach keine Lust mehr hatte. Und selbst bei so etwas wie World of Goo sehnt man sich nach der Präzisen PC Steuerung. Aber das Murmellabyrinthspiel ist ganz gut :)

Noch ein Tag bis zur Deadline der Bachelor-Arbeit und ich schreibe immer noch. Erinnert mich das nächste Mal, die Arbeit VOR der Implementierung zu schreiben.

Pffff... *wird überbewertet :)

*lieblingszitat von einem Freund von mir

Nchtrag:
Und auf dieses Dilemma mit den knappen Abgabetermin wurde ja schon hingewiesen:
siehe hier (datiert mit 08.09.2012, 17:14 )!
genauer:

eXile hat geschrieben: [...]Wenn ich von meiner BA-Erfahrung auf andere schließen darf, bedeutet das Alarmstufe Rot, lange Nächte und ganz sicherlich keinen Blur für euch in der nächsten Woche.[...]

CodingCat hat geschrieben:Noch ein Tag bis zur Deadline der Bachelor-Arbeit und ich schreibe immer noch. Erinnert mich das nächste Mal, die Arbeit VOR der Implementierung zu schreiben.

Das kommt mir bekannt vor. Ich hatte einfach drauf los implementiert, nebenbei das Konzept ausgedacht und am Ende eine Arbeit drumrum geschrieben. Und dann natürlich noch irgendwelche Pseudo-Referenzen gesucht (wie C++ Bücher) um eine Seite zu füllen. :D Am Ende wars aber nicht schlimm. Brachte ne 1.0 und ne Publikation über das Debuggen verteilter Systeme. ;)

CodingCat hat geschrieben:Noch ein Tag bis zur Deadline der Bachelor-Arbeit und ich schreibe immer noch. Erinnert mich das nächste Mal, die Arbeit VOR der Implementierung zu schreiben.

Und ich bilde mir ein das ich Zeitdruck hätte, dabei sind es noch 3 Wochen bis die Abgabe fällig wird ^^. Dir viel Glück

Danke, wird schon. Ich hab noch etwas unter 24 Stunden und nähere mich gerade stetig der inhaltlichen Vollständigkeit. ;)

CodingCat hat geschrieben:Danke, wird schon. Ich hab noch etwas unter 24 Stunden und nähere mich gerade stetig der inhaltlichen Vollständigkeit. ;)

Bist doch super im Zeitplan. Erinnere mich da noch an die zwei Pappenheimer damals in der 12.ten, die wengie Minuten NACH Abgabeschluss angefangen haben, ihre Facharbeit zu schreiben, bei 6 Wochen Zeit. Haben es dann 24 Stunden verspätet abgegeben und obwohl sie zuvor 48 Stunden lang nonstop Mario Kart 64 gezockt haben und das Ding entsprechend übermüdet geschreiben wurde, hätte es bei rechtzeitiger Abgabe 9 Punkte gegeben. So gabs 0 und das war der Ausschlag, damit einer von beiden das Jahr wiederholen musste und der andere, der auch hätte wiederholen müssen, das Abi wegen Aussichtslosigkeit abgebrochen hat. Ich habe damals aber auch erst 3 Tage vorher mir die Materie überhaupt das erste Mal angeschaut und erst am Tag er Abgabe ab 3Uhr morgens Vollgas gegeben und es hat dennoch für meine beste schriftliche Leistung in dem Fach im kompletten Abi gereicht.

CodingCat, du meintest ein paar Posts vorher, dass init()-Methoden zu vermeiden sind. Kannst du kurz beschreiben, was da grundsätzlich das Problem ist? Lieber alles im Konstruktor regeln?

ponx hat geschrieben:CodingCat, du meintest ein paar Posts vorher, dass init()-Methoden zu vermeiden sind. Kannst du kurz beschreiben, was da grundsätzlich das Problem ist? Lieber alles im Konstruktor regeln?

Genau für sowas gibts doch einen Konstruktor. Niemand zwingt einen, die init() Methode aufzurufen. Abgesehen davon, kann eine init() Methode rein prinzipiell Member oder vor allem Basisklassen nicht tatsächlich initialisieren, sondern nur deren Werte verändern.

Nach knapp zwei Wochen zurück vom Meer (ganz banal die Ostsee übrigens) und ich werd erschlagen von 30 "Goodgame sucht"-Threads. Können wir mal irgendwas gegen den Typen unternehmen?

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.)

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 (siehe auch: Compiler, die nur mit POD was taugen, 5. Auflage, DennFickDich Verlag).

Hehe, ja, darüber habe ich mich auch schon geärgert.
Meine Lösung: copy und Paste der Initialisierung in den Rumpf, also klassische C-Sytle Initialisierung. dann zeigt der Compiler den Fehler in der entsprechenden Zeile an, du kannst die Kopie wieder löschen und den Fehler in der Initialiserungsliste korrigieren,

Wie gesagt – die Warnung entsteht beim Linken, nicht beim Kompilieren.

Natürlich würde ich mich über das Fehlen dieser Flusskontrolle noch mehr aufregen, aber dass sich der Fehler nach Inlining (oder was auch immer da passiert) nur auf 100 ebenso umfangreiche K’toren zurückverfolgen lässt statt auf einen, ist scheiße.

14 movs um einen 16-Byte-Vektor zu nullen.

Yup.

Alle meine Quaternions drehen sich verkehrt rum und ich weiß nicht, ob es an den Quaternions liegt oder an der Konvertierung zu Matrizen oder an der Reihenfolge der Multiplikation


(http://www.smbc-comics.com/index.php?db=comics&id=2024)

Schrompf hat geschrieben:Nach knapp zwei Wochen zurück vom Meer (ganz banal die Ostsee übrigens) und ich werd erschlagen von 30 "Goodgame sucht"-Threads. Können wir mal irgendwas gegen den Typen unternehmen?

Ich würde vorschlagen wir führen eine neue Regel ein:

Wenn innerhalb eines Monats mehr als eine Stellenanzeige veröffentlicht werden soll, sind diese in einem Thema zusammenzufassen.

Der Vorschlag klingt gut! Und was tun wir, wenn der Typ gar nichts davon liest, weil er nur hauptberuflich hunderte Foren wie unseres zumüllt, ohne irgendwo mitzulesen?

Bis zu 4 s Ray Marching, und zwar umso langsamer, je weniger Strahlen tatsächlich teilnehmen (wenn alle teilnehmen, sind es 10 ms): Relativ konstant 10 ms Ray Marching, egal wieviele Strahlen tatsächlich teilnehmen: Das ist richtig übel, bis eben dachte ich, auf modernen GPUs wäre Flow Control nur eine Frage des Ausmaskierens einzelner Threads.