Ein paar Performance-Fragen

[Maxi]

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

[japro]

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

[Maxi]

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?

[Christoph]

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.

[Shade Of Mine]

BTW: nimm doch einen Profiler!

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

[ChrisM]

Hi,

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

ChrisM

[Walli]

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.

[Maxi]

ist deine Vermutung begründet?

[Gast]

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

[Patrick]

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

[Shade Of Mine]

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.

[ChrisM]

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

[c++eus]

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.

[rüdiger]

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!

[rüdiger]

@Patrick
meinst du das ernst? ROFL

[Patrick]

kingruedi schrieb:

@Patrick
meinst du das ernst? ROFL

Du magst lachen ich hab schon viele gesehen die so coden Einer davon ist mein Nachbar, der ruft jede funktion mit Assembler auf und sagt das das schneller seine als normal. Ob das stimmt oder net ist mir relativ schnuppe War ja nurn beispiel

[rüdiger]

Denk mal drüber nach, wie der Compiler einen Funktionsaufruf tätigt. Wenn der Aufruf nicht aus nur call besteht, haben die anderen Befehle sicher einen Sinn. Ich möchte nicht der arme Trottel sein, der ein großes Programm pfelgen muss wo jemand so optimiert hat. Da kann man ja debuggen, bis man grau ist

[c++eus]

kingruedi schrieb:

Der Heap ist von der Allokierung langsamer

da stellt sich nur die Frage, ob das etwas ausmacht.

[Gast]

Nein, natürlich nicht. Solche low-level Optimierung macht fast gar nichts aus. Davon abgesehen, sollte man nicht mit sowas anfangen, bevor man andere Möglichkeiten ausgeschöpft hat.
Und man sollte schon gleich gar nicht mit sowas anfangen, bevor man nicht mal weiss, ob besagte Stelle der Flaschenhals ist.
Und man sollte schon gleich überhaupt nicht damit anfangen, bevor man besagte Funktion überhaupt erstmal implementiert hat.

[Shade Of Mine]

Optimizer schrieb:

Nein, natürlich nicht. Solche low-level Optimierung macht fast gar nichts aus.

Ich will nur mal sagen:
diese low level optimierungen können den code auch langsamer machen!!
da der compiler dann nicht versteht was gemeint war und nicht gut bzw. garnicht optimieren kann.