Ein paar Performance-Fragen

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?

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.

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.

@kingruedi
das ist mir schon klar das call benutzt wird ich benutze ja oft für Algos Assembler aber mein Nachbar lässt sich davon nicht beirren.

Nebenbei ist er nicht der einzigste den ich kenne der sowas macht

Walli

Optimizer schrieb:

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?

Also aus seinen Postings zu diesem Zeitpunkt konnte ich _nicht_ 100%ig erkennen, dass die Funktion noch in Planung ist. Meine Kristallkugel ist wohl wieder kaputt.

Walli

Patrick@Friends schrieb:

Nebenbei ist er nicht der einzigste den ich kenne der sowas macht

LOL, was für Leute kennst du?

Maxi

Hm... hat sich ja ne richtige Diskussion aus meine topic entwickelt

ALso, die Funktion ist halb implementiert gewesen, jetzt ist sie es ganz und funktioniert einwandfrei. So, um noch etwas Stoff einzubringen noch ne Frage:

Bigt es einen Zeitunterschied beim zugreifen auf globale oder lokale oder static-Variablen?

Maxi schrieb:

Bigt es einen Zeitunterschied beim zugreifen auf globale oder lokale oder static-Variablen?

Ich schätze mal nicht. IMO gibt es nur einen zeitlichen Unterschied beim Anlegen und Zerstören der Variablen zwischen global und lokal. Statische Variablen sind glaub ich auch global, nur dass der Gültigkeitsbereich eingeschränkt ist. Korrigiert mich...

@Mastah: Für mich hat sich das Ganze schon ein bisschen so angehört, wir haben dann auch ewig über premature Optimization gesprochen, usw., obwohl ich mir jetzt auch nicht 100%ig sicher war.
Ich nutze übrigens keine Kristallkugel, sondern einen der sehenden Steine aus Herr der Ringe.

Christoph

Maxi schrieb:

Bigt es einen Zeitunterschied beim zugreifen auf globale oder lokale oder static-Variablen?

...