Ein paar Performance-Fragen

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?

...

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

Stimmt nicht. Es gibt nur "eine" Möglichkeit eine Funktion aufzurufen und somit kann zwischen dem was der Kompiler hinsetzt und ASM kein Unterschied sein!

Dauert es länger, mit new ein Array zu definieren als direkt mit konstantem Index

Nur beim allokiren und freigeben gibt es einen Unterschied. Bei new muss erst eine Stelle im Heap gefunden werden die gross genug ist. Allerdings kann es sein, dass new char[16] schneller ist als char[64]! Und da man bei Stack allocation oftmals Puffer braucht den man bei new nicht braucht...

Was ist schneller?

memcpy da du deine Schleife nicht optimirt hast!

int*i1 = ar_1;
int*i2 = ar_2;
for(int i = 0; i < 6; i++) 
     *(i1++)=*(i2++);

Die Schleife oben ist schneller als memcpy da der Funktionsaufruf weg fällt. Allerdings haben manche Kompiler auch einen Schalter Funktionen wie memcpy zu inlinen womit es gleichstand wäre.

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

statische Variablen sind globale Variablen die nur in einem scope sichtbar sind (wie schon von Optimizer erklärt).

Shade Of Mine

hallo schrieb:

Die Schleife oben ist schneller als memcpy da der Funktionsaufruf weg fällt. Allerdings haben manche Kompiler auch einen Schalter Funktionen wie memcpy zu inlinen womit es gleichstand wäre.

Nein.
ich glaube kaum ein compiler setzt für memcpy einen funktionsaufruf.

aber er kann, falls es besser ins alignment des codes passt...

ChrisM

Hi,

@Maxi: Warum fragst du eigentlich diese ganzen (trivialen) Sachen hier?

Erstens känntest du das alles selbst mit einem Profiler (oder meinetwegen auch ohne: Jede Variante 100000 laufen lassen und Zeit mit time() merken) oder zweitens einfach mal überlegen: Wäre eine globale Variable schneller als eine statische, warum sollte der Compiler dann nicht einfach jede statische Variable intern als globale verwenden?

ChrisM

Maxi

Jetzt bringst du mcih in Verlegenheit...
Ich war vorhin dabei mir zu überlegen, wo ich meine Engine denn schneller machen könnte und da kamen mir eben diese Ideen/Fragen. Und ich bin eher so einer, der die frage dann im Forum stellt und die nciht erst versucht sie selbst zu beantworten :). Áber jetzt weiß ich wenigstens, dass ich nith an den kleinen Stellen optimieren sollte, sondern noch mal direkt in die algorithmen schauen und gucken was da zu machen wäre

rüdiger

@c++eus

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

das habe ich auch nicht behauptet. Nur kann man allgemein sagen, dass Heap-Allokierung langsammer oder genauso schnell wie Stack-Allokierung ist, fertig aus.

@Maxi

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?

lol, entweder hast du den Thread nicht gelesen oder wolltest einfach die ständigen Warnungen vor Premature-Optimisation ignorieren