Seite 83 von 258

Re: Jammer-Thread

Verfasst: 30.08.2012, 22:09
von dot
Schrompf hat geschrieben:Es ist nie zu spät, aber selten zu früh, die Freuden von size_t und SIZE_MAX kennen zu lernen.
Oder in dem Fall überhaupt einfach auto ;)

Re: Jammer-Thread

Verfasst: 01.09.2012, 14:46
von Krishty
Dass WinAPI-Nachrichten nicht mit einem präzisen Zeitstempel kommen, ist ein riesiger Haufen Scheiße. Ich kann garnicht in Worte fassen wie fatal das für die Komplexität von Hochleistungsanwendungen ist.

Re: Jammer-Thread

Verfasst: 01.09.2012, 17:21
von Krishty
Mein räudiges Nokia-Handy hat eine logarithmische Batteriestandsanzeige. Eine Woche zeigt es 100 % an; dann zwei Tage 75; einen Tag 50; eine halbe Stunde 25; und dann ist es leer. Wenn man bei 75 % zwei Tage wegfährt und den Stecker nicht mitnimmt, ist man gearscht.

Re: Jammer-Thread

Verfasst: 01.09.2012, 21:42
von antisteo
Ausgerechnet der Funktionsaufruf der Physik-Bibliothek, der die meiste Rechenzeit beansprucht, kann nicht parallel aufgerufen werden, weil die Funktion am Anfang viel rechnet und das Ergebnis anschließend in irgendeine verkettete Liste einsortiert. Warum?

Re: Jammer-Thread

Verfasst: 02.09.2012, 15:36
von Krishty
Die gute Nachricht: Ich habe Visual C++ gerade dazu gekriegt, unter x86 die Gleitkommaarithmetik mit SSE durchzuführen.

Die schlechte Nachricht: Ich weiß nicht, wie.

Die noch schlechtere Nachricht:

Code: Alles auswählen

 cvtsi2ss    xmm1,ebx  
 cvtss2sd    xmm0,xmm0  
 cvtps2pd    xmm1,xmm1  
 mulsd       xmm0,xmm3  
 mulsd       xmm1,xmm3  
 cvtsd2ss    xmm0,xmm0  
 cvtpd2ps    xmm1,xmm1  
 movss       dword ptr [esp+1B0h],xmm0  
 movss       dword ptr [esp+1B4h],xmm1  
 movq        xmm4,mmword ptr [esp+1B0h]  
 movq        mmword ptr [esp+23Ch],xmm4  
 movss       xmm4,dword ptr [ecx+1AD0h]  
 cvtps2pd    xmm4,xmm4  
 cvtss2sd    xmm0,xmm0  
 addsd       xmm4,xmm0  
 add         edi,eax  
 sub         edi,edx  
 cvtsi2ss    xmm2,edi  
 xorps       xmm0,xmm0  
 cvtpd2ps    xmm0,xmm4  
 movss       xmm4,dword ptr [ecx+1AD4h]  
 cvtps2pd    xmm4,xmm4  
 cvtps2pd    xmm2,xmm2  
 cvtss2sd    xmm1,xmm1  
 addsd       xmm4,xmm1  
 mulsd       xmm2,xmm3  
 cvtpd2ps    xmm2,xmm2  
 movss       dword ptr [esp+1B8h],xmm2  
 mov         edx,dword ptr [esp+1B8h]  
 xorps       xmm1,xmm1  
 cvtpd2ps    xmm1,xmm4  
 movss       xmm4,dword ptr [ecx+1AD8h]  
 cvtps2pd    xmm4,xmm4  
 cvtss2sd    xmm2,xmm2  
 addsd       xmm4,xmm2  
 cvtps2pd    xmm6,xmm0  
 mov         dword ptr [esp+244h],edx  
 cvtpd2ps    xmm2,xmm4  
 cvtps2pd    xmm4,xmm1  
 mulsd       xmm4,xmm5  
 movss       xmm5,dword ptr [esp+60h]  
 cvtps2pd    xmm5,xmm5  
 mulsd       xmm5,xmm6  
 movss       xmm6,dword ptr [esp+78h]  
 addsd       xmm4,xmm5  
 cvtps2pd    xmm6,xmm6  
 cvtps2pd    xmm5,xmm2  
 mulsd       xmm5,xmm6  
 movss       xmm6,dword ptr [esp+84h]  
 cvtps2pd    xmm6,xmm6  
 addsd       xmm5,xmm6  
 addsd       xmm4,xmm5  
 movss       xmm6,dword ptr [esp+70h]  
 cvtps2pd    xmm5,xmm1  
 cvtps2pd    xmm7,xmm0  
 cvtps2pd    xmm6,xmm6  
 mulsd       xmm5,xmm6  
 movss       xmm6,dword ptr [esp+64h]  
 cvtps2pd    xmm6,xmm6  
 mulsd       xmm6,xmm7  
 movss       xmm7,dword ptr [esp+7Ch]  
 addsd       xmm5,xmm6  
 cvtps2pd    xmm0,xmm0  
 cvtps2pd    xmm7,xmm7  
 cvtps2pd    xmm1,xmm1  
 cvtps2pd    xmm6,xmm2  
 mulsd       xmm6,xmm7  
 movss       xmm7,dword ptr [esp+88h]  
 cvtps2pd    xmm7,xmm7  
 addsd       xmm6,xmm7  
 addsd       xmm5,xmm6  
 cvtpd2ps    xmm5,xmm5  
 movss       dword ptr [esp+24Ch],xmm5  
 movss       xmm5,dword ptr [esp+74h]  
 cvtps2pd    xmm5,xmm5  
 mulsd       xmm1,xmm5  
 movss       xmm5,dword ptr [esp+68h]  
 cvtps2pd    xmm5,xmm5  
 mulsd       xmm5,xmm0  
 cvtps2pd    xmm0,xmm2  
 movss       xmm2,dword ptr [esp+80h]  
 cvtps2pd    xmm2,xmm2  
 mulsd       xmm0,xmm2  
 movss       xmm2,dword ptr [esp+8Ch]  
 cvtps2pd    xmm2,xmm2  
 addsd       xmm0,xmm2  
 addsd       xmm1,xmm5  
Fast die Hälfte des Texts sind Konvertierungen zwischen float und double – und das obwohl im Quelltext überhaupt keine double vorkommt. Die eigentliche Berechnung kann man überhaupt nicht mehr erkennen. Vielleicht steckt dahinter ein besonders absurder Versuch, die FPU nachzubilden. Ich weiß es nicht.

Re: Jammer-Thread

Verfasst: 02.09.2012, 19:50
von CodingCat
C++' iostream-API ist eine absolute Frechheit. Sowohl weil sie zeigt, wie man Vererbung NICHT benutzt, als auch, weil sie nur aus einem riesigen unsortierten Haufen kryptischer Abkürzungen besteht. Davon abgeshen ist sie gnadenlos over-engineered (Wie war das mit EINER Aufgabe pro Klasse?), weshalb sie obendrein auch noch gnadenlos verfettet und ineffizient ist.

Re: Jammer-Thread

Verfasst: 03.09.2012, 13:52
von Biolunar
CodingCat hat geschrieben:C++' iostream-API ist eine absolute Frechheit. Sowohl weil sie zeigt, wie man Vererbung NICHT benutzt, als auch, weil sie nur aus einem riesigen unsortierten Haufen kryptischer Abkürzungen besteht. Davon abgeshen ist sie gnadenlos over-engineered (Wie war das mit EINER Aufgabe pro Klasse?), weshalb sie obendrein auch noch gnadenlos verfettet und ineffizient ist.
Hast du konkrete Punkte, die dich stören? Bevor ich verstanden habe wie die Lib funktioniert, habe ich nämlich ähnlich gedacht ;)

Re: Jammer-Thread

Verfasst: 04.09.2012, 15:16
von Artificial Mind
http://io9.com/5940036/how-copyright-en ... ugo-awards
Willkommen in einer dystopischen Realität ...

Re: Jammer-Thread

Verfasst: 04.09.2012, 19:49
von MoritzPGKatz
Artificial Mind hat geschrieben:http://io9.com/5940036/how-copyright-en ... ugo-awards
Willkommen in einer dystopischen Realität ...
Oha...

Zum Thema passend:
Ich war am Sonntag auf dem Barcamp der C3S - wen das Thema Urheberrecht/Lizensierung interessiert und nicht nur über GEMA & Co. meckern, sondern auch eine Alternative supporten möchte, sollte sich das unbedingt mal reinziehen.

Re: Jammer-Thread

Verfasst: 05.09.2012, 23:10
von antisteo
gwX muss die Voxel in Newton-Objekte umrechnen. Bis jetzt habe ich die Voxel als konvexe Hüllen erzeugt und als Objekte gespawnt. Das war zwar zur Laufzeit schnell, dafür aber für Änderungen der Landschaft irre langsam.
Die schnellere Variante ist, die Dreiecke des Marching Cube als TreeCollision zu erstellen. Allerdings hat Newton einen Bug, wodurch bei gewissen Eingabedaten Newton abschmiert.
Dass Newton bei falschen Eingabedaten abschmiert, ist nichts neues. Allerdings lasse ich mir die Dreiecke loggen und es sind valide Dreiecke. Kein NaN, kein Infinity, keine Dreiecke, bei denen die Eckpunkte aufeinanderliegen...
es ist zum heulen.

Re: Jammer-Thread

Verfasst: 06.09.2012, 21:47
von glassbear
Erfahrene Elektrotechniker schreiben Code wie ich vor vielleicht 6-7 Jahren. AAAAAAAAAAAAAAAAAAAAAAAH. Und ich soll das "mal eben" umarbeiten und auf Threading umstellen. AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAH. :twisted:

Re: Jammer-Thread

Verfasst: 06.09.2012, 22:01
von Jörg
Kannst denen ja mal zum Dank eine Schaltung entwerfen ;)

Re: Jammer-Thread

Verfasst: 06.09.2012, 22:57
von glassbear
Jörg hat geschrieben:Kannst denen ja mal zum Dank eine Schaltung entwerfen ;)
Machen die ja nicht mal. Die schreiben nur Code. Uebel :twisted:

Re: Jammer-Thread

Verfasst: 06.09.2012, 23:35
von kaiserludi
eXile hat geschrieben:
Krishty hat geschrieben:Eben angepackt (allerdings mit unsigned (normalized) int). Wie gut sich das anfühlt … den Quadranten eines Winkels für die eigenen trigonometrischen Funktionen bestimmen? Bloß die oberen Bits abfragen!
Das ist schön zu hören. :) Hast du dir neue Minimax-Polynome gebastelt, um die höhere Genauigkeit (in Vergleich zu float) zu nutzen?
Krishty hat geschrieben:Wo genau, außer bei Quaternion-Interpolation, ist das von Nutzen?
Naja, genau da. Und zwar sowohl beim SLERP mit Quaternionen wie auch der Konvexkombination von Quaternionen. Ich wollte eher davor warnen, im Bereich der Quaternionen auch nur in irgendeiner Weise mit Winkeln zu rechnen, genauso wenig wie man im Bereich der Rotationsmatrizen niemals plötzlich anfangen sollte, mit Winkeln zu rechnen.
glassbear hat geschrieben:AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAH. :twisted:
Du hast noch nie Code von Mathematikern gesehen. Ich sage nur: Jeder Variablenname ist maximal zwei Buchstaben lang. AAAAAAAAA!
Das geile ist: Die allersete Programmierpsrache, in der ich entwickelt habe, war damals TI-Basic, ein von der Syntax Basic recht nahe Interpretersprache für grafische Taschenrechner. Der Speicherplatz auf den Geräten war knapp und alle Programme wurden bei jedem Run komplett aus dem Source interpretiert, jeder Kommentar hat also den Bedarf an äußerst knappem Endbenutzer"-festplattenplatz" (ok, eigentlich ein Flashspeichership, aber eben als Dauerspeicher genutzt) erhöht. Um möglichst viele möglichst umfangreiche Games dort unterzubringen habe ich aberweitzige Codesizeoptimierungen betrieben und Spiele von 20k Sourcecode auf 5k optimiert. Das beliebteste nake auf dem System hatte, bevor ich mich daran gemacht habe, ca. 2k Code, nach meinen Optimierungen unter 200Bytes ohne Funktionseinbußen und lief dann auch doppelt so schnell. Null Kommentare und alle Variablennamen auf einzelne Buchstaben umbennen waren da noch die harmloseren Geschichten.

Re: Jammer-Thread

Verfasst: 07.09.2012, 17:49
von spobat
Schau an, was Visual Studio 11 mit meinem aus Visual Studio 10 headern macht:

Code: Alles auswählen

virtual virtual static static static void init();
Ich frage mich ja, was hier ein static *ueberhaupt* zu suchen hat. Ist wohl mehr als nur eine "wortverfielfachung".
Zum glueck laesst sich das aber mit einem "find-replace" durchgang beheben :)

Ist es eine gute Idee, die gleichen Funktionen in verschiedenen Menues zu haben?
"Run Code Analysis" findet sich beispielsweise sowohl unter "BUILD" als auch unter "ANALYZE".
Ich find es ne schlechte Sache, das muellt nur die Menues zu und sorgt fuer uneinheitliche Bedienung zwischen Entwicklern.

Re: Jammer-Thread

Verfasst: 07.09.2012, 18:22
von CodingCat
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.)

Re: Jammer-Thread

Verfasst: 08.09.2012, 15:12
von CodingCat
Diskussion zu Winkelgenauigkeit und schneller Trigonometrie ausgelagert in [C++] Schnellers sin/cos/tan.

Re: Jammer-Thread

Verfasst: 08.09.2012, 20:03
von spobat
@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.

Re: Jammer-Thread

Verfasst: 11.09.2012, 16:07
von RazorX
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.

Re: Jammer-Thread

Verfasst: 11.09.2012, 18:04
von spobat
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?

Re: Jammer-Thread

Verfasst: 11.09.2012, 18:15
von CodingCat
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.

Re: Jammer-Thread

Verfasst: 11.09.2012, 19:29
von RazorX
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

Re: Jammer-Thread

Verfasst: 11.09.2012, 19:51
von CodingCat
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.

Re: Jammer-Thread

Verfasst: 11.09.2012, 20:01
von dot
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...

Re: Jammer-Thread

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

Re: Jammer-Thread

Verfasst: 12.09.2012, 09:12
von Jeason
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.

Re: Jammer-Thread

Verfasst: 12.09.2012, 17:55
von glassbear
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:

Re: Jammer-Thread

Verfasst: 13.09.2012, 00:11
von Jonathan
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 :)

Re: Jammer-Thread

Verfasst: 13.09.2012, 00:23
von CodingCat
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.

Re: Jammer-Thread

Verfasst: 13.09.2012, 00:34
von joggel
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.[...]