3. Ein paar Performance-Fragen

Ein paar Performance-Fragen

  • M

    Hallo!

    Hab ein paar performance fragen:

    1. Dauert es länger, mit new ein Array zu definieren als direkt mit konstantem Index, also so:
    // was dauert länger?
int* ar_new = new int[10];
int ar_def[10];

    Wenn es einen Unterschied gibt, ist der sehr groß?

    1. Was ist schneller?
    // das
int ar_1[10];
int ar_2[10];

for(int i = 0; i < 6; ++i)
  ar_1[i] = ar_2[i];

// oder das:
memcpy(&ar_1[0], &ar_2[0], 6 * sizeof(int));

    Das wärd erstrmal für den ANfang, vielleicht fällt mir ja noch mehr ein

    Gruß, Maxi

    0
  • ?

    das dauert länger: int* ar_new = new int[10];

    das ist schneller/zu bevorzugen: memcpy(&ar_1[0], &ar_2[0], 6 * sizeof(int));

    0
  • W

    Ich denke memcpy ist mindestens so schnell wie die Schleife (vielleicht sogar schneller). Bei dem ersten Fall sollte die Speichernanforderung imho ungefähr gleich schnell sein.

    0
  • C

    Bei der 1. Frage ist (bei größeren Arrays) wohl die new-Methode zu bevorzugen, da der Array dann im Heap und nicht im Stack (-> bei lokalen Variablen) angelegt wird. Somit wird die 1MB-Begrenzung (zumeist bei Windows festgelegt, kann aber beim compilieren Verändert werden) des Stack umgangen.

    0
  • M

    cool, das das new bei größeren Arrays schneller ist 🙂
    Ist das schreiben in diese beiden Arrays denn genauso schnell oder gibts da auch unterschiede?

    mit dem memcpy hab ich mir auch shcon gedacht

    0
  • C

    Maxi schrieb:

    cool, das das new bei größeren Arrays schneller ist 🙂

    Nein, schneller ist es nicht, das hast du wohl falsch verstanden. Aber man bekommt nicht so schnell einen Stack-overflow (das ist mir mal bei einem Primzahl-Programm passiert).

    0
  • M

    hm...
    aber ich werds wohl trotzdem nehemn. Ist der Unterschied groß? und wie ist das mit schreiben?

    0
  • J

    1. nur das allokieren ist verschieden schnell wenn der speicher mal da ist, ist es wurscht... beides ist einfach speicher im ram und da gibts keinen unterschied.

    2. wozu brauchst du so unheimlich viel performance, dass du das alles so genau wissen musst?

    mfg japro

    0
  • M

    hm... OK.
    Es geht und eine Renderfunktion, die eben jeden frame aufgerufen werden muss.
    Ich könnte jau auch vor der Render funktion nur einmal den Speicher allokieren(heißt das so?) und den dann immer wieder benutzen...

    Noch ne Frage:
    HAben die STL-COntainer einen großen Overhead?

    0
  • C

    Siehe meine letzte Antwort. Das gilt für alle STL-Container.

    Es gibt allerdings ein definiertes Laufzeitverhalten für STL-Funktionen. Z.B. muss der Zugriff auf ein bestimmtes Element eines std::vectors in konstanter Zeit (O(1)) stattfinden, egal wie groß der Vektor ist.
    Das Einfügen eines Elements in eine std::list ans Ende oder an den Anfang muss AFAIK auch in konstanter Zeit stattfinden.

    0
  • S

    BTW: nimm doch einen Profiler!

    Du weisst doch: Premature optimization is the root of all evil

    0
  • C

    Hi,

    nur als kleiner Tipp: Optimieren ist ja gut und schön, aber du versuchst, an der total falschen Stelle zu optimieren.

    ChrisM

    0
  • W

    ChrisM schrieb:

    Hi,

    nur als kleiner Tipp: Optimieren ist ja gut und schön, aber du versuchst, an der total falschen Stelle zu optimieren.

    Mich würde ja mal interessieren woran du erkennst, dass Maxi an der falschen Stelle optimiert.

    0
  • M

    ist deine Vermutung begründet?

    0
  • ?

    Das erkennt man daran, dass er versucht zu optimieren, bevor die Funktion überhaupt da ist und er nicht mal wissen _kann_, dass sie vielleicht der Flaschenhals ist?
    Das erkennt man daran, dass er sich in technische Details verkünstelt, die der Compiler besser beherrscht wie die meisten von uns, anstatt sich einen idealen Algorithmus zu überlegen?

    EDIT: Ach, und noch was, ich glaube schon, dass das Array im Stack schneller ist, das muss man nämlich nicht mehr löschen (Beim Stack springt nur der Stack-Pointer zurück).

    0
  • P

    Also optimieren schön und gut, man besten auch so viel wie geht aber die 2 sachen sind ja wohl nicht die krönung!

    z.B. sowas würde ich pauschal als unnütz deklarieren, obwohl es evtl. sogar etwas mehr speed geben würde: (BITTE verbessert mich falls es nicht stimmt und der speed gleich ist!)

    void AI (void) 
{ 
} 

void RENDER (void) 
{ 
} 

int main (void) 
{ 
    asm volatile ("hauptschleife:");
    {
        asm volatile("call AI"); 
        asm volatile("call RENDER"); 
    }
    asm volatile ("jmp hauptschleife");    

    return 0;
}

    man besten lässt sich immer bei dingen wie KI, Kollisionsabfrage und LOD optimieren. aber allein der Renderer bringts nicht (außer du machst es Hardcore low level da sollte sich einiges Optimieren lassen).

    0
  • S

    und das soll schneller sein?

    wohl eher langsamer, da es hier kein inline geben kann 😉

    Ne, optimieren überlässt man den Compiler. Dann schaut man mit dem Profiler nach, wo es sinnvoll ist, etwas zu verbessern.

    0
  • C

    Hi,

    MaSTaH schrieb:

    ChrisM schrieb:

    Hi,

    nur als kleiner Tipp: Optimieren ist ja gut und schön, aber du versuchst, an der total falschen Stelle zu optimieren.

    Mich würde ja mal interessieren woran du erkennst, dass Maxi an der falschen Stelle optimiert.

    das erkenne ich daran, dass er fragt, wie es schneller geht, einige wenige Bytes zu kopieren. Mal ganz davon abgesehen, dass die Frage unnötig ist (wäre memcpy() nicht mindestens gleich schnell, würde man es ja nicht brauchen, sondern einfach immer eine eigene Schleife schreiben, lohnt es sich bei einigen wenigen Bytes nicht, an solch einer Stelle zu optimieren.

    Oder wie TGGC sagen würde: It's easier to optimize correct code than to correct optimized code!

    ChrisM

    0
  • C

    das muss man nämlich nicht mehr löschen

    was hat das denn mit der Geschwindigkeit zu tun? Das auf dem Stack muss zwar nicht gelöscht werden, aber dennoch hat das Löschen nichts mit der Geschw. zu tun. Außerdem hat keiner behauptet, das Array auf dem Heap wäre schneller.

    0
  • R

    Der Heap ist von der Allokierung langsammer und Deallokierung verbraucht auch eine gewisse Zeit, da beim Heap die Blöcke nicht so ideal verteilt sind und man nicht einfach die nächsten x byte nehmen kann wie beim Stack.

    Aber trotzdem halte ich nicht viel davon, den Stack zu nehmen, wenn man den Heap nehmen müsste. Die Tricks, die man dann benutzen muss, sind wahrscheinlich teurer (wenn man keine Tricks brauch, dann reicht ja auch Stack-Allokierung :)).

    Wie gesagt, intensive Optimierung nur mit Profiler Hilfe!

    0
Anmelden zum Antworten