Kurze frage zu einem Spielprogramier problem

[Laudian]

Oder auf die altmodische Art:

Lass das Programm in einer Schleife 1000 mal durchlaufen, am Ende "fertig" in der Konsole ausgeben und auf die Uhr gucken.

 

[Supercomputer]

Also: 304 Byte / Objekt * 500.000 Objekte = ca. 145 MB Daten

Laufzeitmessung ist leider Plattformabhängig. Unter Linux kannst du das so machen

#include <sys/time.h>

double get_time(void)
{
    struct timeval tv;
    gettimeofday(&tv, NULL);

    return (tv.tv_sec + (tv.tv_use * 1E-6));
}

void foo(void)
{
    double tstart, telapsed;

    tstart = get_time();
    /* Mach was */
    telapsed = get_time() - tstart;
    printf("Time: %f\n", telapsed);
}

Unter Windows geht das am besten mit QueryPerformaceCounter.

Ich nutze nur Linux

Bekomme beim Ausfüren die Meldung "printf was nut declared in this scope" (habe sogar die printf.h includiert, jedoch gleiches Resultat)

Wenn ich versuche im Debugg modus zu starten, um die Variablen einfach aus zu lesen, bekomme ich folgende Fehlermeldung

ptrace: Die Operation ist nicht erlaubt

Was kann ich dagegen machen?

 

[bingo88]

Für printf musst du natürlich noch die stdio.h includen. Ist das eine GUI oder Konsolenanwendung? Wenn GUI musst du das über ein Terminal starten, um die Ausgabe zu sehen.

 

[Supercomputer]

Meine Funktion ist 75.5 mal langsamer als sqrt

 

[bingo88]

Meine Funktion ist 75.5 mal langsamer als sqrt

So etwas hatte ich erwartet

Hast du das als Release Build getestet (Debug ist immer langsamer)?

 

[Supercomputer]

Nein, nur Debug

Ich habe auch damit gerechnet, dass ich langsammer bin, aber dass es so viel ist

Dafür ist meine Funkrion genauer

 

[bingo88]

In der Regel ist es auch so, dass genauere Ergebnisse länger dauern.

Du müsstest das mal als non-Debug Build testen, damit das einigermaßen vergleichbar ist.

 

[Laudian]

Und vor allem solltest du die Funktion nicht nur einmal sondern wenigstens 20-30 mal durchlaufen lassen um zufällige Schwankungen auszugleichen.

 

[Supercomputer]

Wenn ich auf Realeas stelle, bekomme ich die sqrt nicht gemessen, selbst bei 10 Milionen Durchläufen kommt 0.000000 raus.
Bei meiner Funktion bekomme ich bei 1000 Durchläufen 0.000014 raus.

Jedoch habe ich noch eine Optimierung gefunden, die eventuell nochmal die Geschwindigkeit verdoppelt, sie ist aber noch nicht implementiert.

 

[bingo88]

Dann mach das mal anders. Mess mal bitte die Gesamtlaufzeit, also außerhalb der Schleife.

 

[Supercomputer]

Ich messe ja außerhalb der Schleife.

Die Schleife (for) befindet sich bei dem geschickten Code bei "/* Mach was */"

 

[bingo88]

Upps ^^ Okay, mit Bordmitteln wird man dann nicht genauer herankommen. Eventuell ginge noch ein großes Array.

int length = 1024 * 1024 * 64;
double *a = new double[length];

tstart = ...;
for (int i = 0; i < length; ++i)
{
    a[i] = sqrt(a[i]);
}

telapsed = ...;

delete[] a;

 

[Supercomputer]

long double base::gethyp(long double lega, long double legb)
{
    long double hyp;
    long int N = 0;
    long double middle1;
    long double middle2;
    long double middle3;
    hyp = 23;//lega * lega + legb * legb;
    for (int n = 0; n * n <= hyp; n++) // Bescleunigeung der Annäherung
    {
        N++;
    }
    middle1 = hyp / N;
    middle2 = (middle1 + N) / 2;
    middle3 = hyp / middle2;
    for (int i = 0; i < 5; i++) // Bei 23 reichen auch schon 3, jedoch weiß ich nicht, wie adere Zahlen ragieren (Genaugkeit von 35 Stellen in der Variable)
    {
        middle2 = (middle2 + middle3) / 2;
        middle3 = hyp / middle2;
    }
    return (middle2);
}

Das ist mein aktuelle Funktion, wißt ihr vllt, noch eine optimierungsmöglichkeit?
Die funktioniert so nur für Zahlen >= 1.

Habe es jetzt hin bekommen, lasse die Schleife jetztz 1000000.0 mal durchlaufen und bekomme heraus, dass meine Funktion genau 38.725490196 mal langesammer als sqrt ist.

Gerade nochmal durchlaufen lassen ohne etwas zu ändern, jetzt ist meine Funktion auf einmal nur noch 3.430225673 mal langsammer O.o

 

[XPrototypeX]

for(int n = n*n; n >= hyp; n--)

rechnet nicht in jedem schleifen durchgang n*n.

Ansonsten kann ich auf den ersten blick nichts finden.

Aber es ist schwachsin jetzt zu optimieren. Schreib bzw nehm die Funktionen die du brauchst und mach dein Ding (so Sachen werden dein Programm garantiert nicht merklich verlangsamen). Wenn die performance nicht stimmt kannst du immer noch optimieren aber dann richtige bottlenecks und nicht so etwas. So geht dir einfach nur Zeit verloren ohne das du etwas sichtbares auf die Beine stellst.

Wieso verwendest du C und nicht C++? Du könntest dir eine utility Klasse schreiben mit solch Berechnungen. Sollten halt static und ggf. inline sein.

So Micro Benchmarks sind schwer zu machen. Die CPU ist mal mehr mal weniger Ausgelastet. Manche instructionen stehen vielleicht nach in irgendeinen Cache. Das kann dir alles dazwischen Funken.

 

[Supercomputer]

for(int n = n*n; n >= hyp; n--)

rechnet nicht in jedem schleifen durchgang n*n.

Wieso verwendest du C und nicht C++? Du könntest dir eine utility Klasse schreiben mit solch Berechnungen. Sollten halt static und ggf. inline sein.
.

Damit wird "n" doch auf irgedneinen zufälligen Wert gesetzt, oder?

Ich nutze C++, nicht C.

Diese Funktion gehört zur Klasse "base".

 

[XPrototypeX]

Ah, ja vergess das bin leicht übermüdet.... Hab den code nicht nachvollzogen.

Da es jedoch utility methoden sind sollten sie besser static sein.

 

[Supercomputer]

Ah, ja vergess das bin leicht übermüdet.... Hab den code nicht nachvollzogen.

Da es jedoch utility methoden sind sollten sie besser static sein.

Ist doch nichts passiert, alles in Ordnung

Danke für den Tipp, es static zu setzen.

 

[XPrototypeX]

Joa aber so micro Optimierungen sind echt nicht nötig. Wenn es wirklich zu Problemen mit der Performance kommen sollte, hilft dir ein Profiler. Der deckt dann auf and welchen Stellen das Program am meisten Zeit benötigt. Ich an deiner Stelle würde weiter machen und ggf. Optimierungen ganz am Ende machen.

 

[Supercomputer]

Das denke ich mir mittlerweile auch.

 

[Bunny_Joe]

Hi


Ich zitiere mich mal kurz ausm anderen Thread:

Hey ich hätte da noch ein Buch für dich: Game Engine Architecture

Das Buch "Game Engine Architecture" wurde vom Naughty Dog Lead Programmierer Jason Gregory geschrieben und erscheint am 5. August in einer zweiten Ausgabe.
In der überarbeiteten Ausgabe wurde viel hinzugefügt und überarbeitet.....unter anderem: extended/updated sections on multicore programming, pipelined CPU architecture and optimization, localization, C++11, pseudovectors and Grassman algebra, dual quaternions, SIMD vector math, memory alignment and anti-aliasing

Es ist zwar eher an Spieleengine Programmierung ausgerichtet, aber dürfte auch für dein Projekt ziemlich aufschlussreich sein.

Der einzige "Nachteil": es ist halt auf englisch^^





Edit:

Dieses Kapitel im Buch wäre wohl das Interessanteste für dich^^

12. Collision and Rigid Body Dynamics

12.1 Do You Want Physics in Your Game?

12.2 Collision/Physics Middleware

12.3 The Collision Detection System

12.4 Rigid Body Dynamics

12.5 Integrating a Physics Engine into Your Game

12.6 Advanced Physics Features