Perfomance



  • AJ schrieb:

    @junky
    Das ist ein Zeiger. Bei ner Referenz würde es so aussehen (vom Aufruf her):

    MachWas(DeinObjekt);

    Bei der Deklaration müsstest du aber anstatt dem * ein & angeben. In der Funktion kannst du den Parameter dann übrigens auch ganz normal ansprechen, ohne *

    Call-By-Value:
    MachWas(DeinObjekt);

    Call-By-Reference:
    MachWas(&DeinObjekt);

    Mit zusätzlichem Pointer (Vom Prinzip wie Referenz)
    DeinObjekt* pObj = &DeinObjekt
    MachWas(pObj);

    😉



  • ist es eigentlich generell schlechter Stil, in C++ ein Objekt oder einen Pointer auf ein Objekt, als Rückgabewert zu haben? Oder gibt es Stellen, wo das gerechtfertigt ist?



  • Wenn du einen Rückgabewert hast, ist dieser eigentlich immer ein Objekt (oder der Inhalt, sprich "Wert") 🙂
    Manchmal ist es halt nur sinnvoller (oder sogar schneller), einen Pointer zurückzugeben.



  • Cpp_Junky schrieb:

    Wenn du einen Rückgabewert hast, ist dieser eigentlich immer ein Objekt (oder der Inhalt, sprich "Wert") 🙂
    Manchmal ist es halt nur sinnvoller (oder sogar schneller), einen Pointer zurückzugeben.

    Ein Wert (wie int, float, double, ...) unterscheidet sich grundlegend von einem Objekt.



  • int und double sind auch nur Klassen.



  • Ups stimmt ja, bei Referenzen muss man trotzdem noch die Adresse angeben.

    @Junky
    Dass int und double Klassen sind, ist mir neu 😮
    Was für Methoden haben die denn so zu bieten? Oder haben sie nur Eigenschaften? 😕



  • Ja, streng genommen ist das so. Definiert ist das ganze in den C++ Standard-Libs. Das ist nunmal das Prinzip von C++.
    Methoden ? Naja Operatoren gibts natürlich :p +,-,/,* usw.



  • Naja mir solls recht sein



  • kann mal jemand ein konkretes beispiel zeigen?



  • Thema in/dekrementieren:

    ob man jetzt ++i oder i++ schreibt ist bei einem guten Compiler egal. Der Msvc++6 zB macht anscheinend automatisch aus einem i++ ein ++i wenn er merkt dass es geht.

    Ich habe grade folgenden Test gemacht:

    int main(int argc, char* argv[])
    {
    	Sleep( 2000 );
    
    	unsigned int i;
    	char out[333];
    	DWORD zeit1, zeit2;
    
    	zeit1 = GetTickCount( );
    	for( i=0 ; i<0xffffffff ; i-- )
    	{
    		i++;
    		f( i ); // Das muss sein, sonst wird die Schleife komplett wegoptimiert
    		i++;		
    	}
    	zeit1 = GetTickCount() - zeit1;
    
    	zeit2 = GetTickCount();
    	for( i=0 ; i<0xffffffff ; --i )
    	{
    		++i;
    		f( i );
    		++i;		
    	}
    	zeit2 = GetTickCount() - zeit2;
    
    	itoa( zeit1, out, 10 );
    	printf( out );
    	printf( "\n" );
    	itoa( zeit2, out, 10 );
    	printf( out );
    	printf( "\n" );
    }
    

    Ausgabe:

    55119
    55740
    Press any key to continue
    

    Der compiler denkt also mit. Ich schreibe aber auch immer ++i, das habe ich mir wegen diesem Gerücht angewöhnt 😉



  • @0x1
    Ist bei deinem Beispiel die zweite Schleife nicht langsamer??

    @bobba
    Mir ist noch was eingefallen zum Optimieren der Performance. Du kannst beim Teilen von Zahlen noch einen kleinen Trick anwenden. Wenn du z. B. durch 2 teilst, dann kannst du auch die bits der Zahl einfach um 1 nach rechts verschieben. Das funktioniert natürlich auch beim Multiplizieren mit 2. Das kannst du natürlich auch mit anderen Zahlen machen. Alle potenzierten Zahlen mit der Basis 2. Also 2, 4, 8, 16, 32, ...
    Ist hald die Frage, ob das der Compiler nicht eh schon von selber macht, aber ein Versuch ists wert ;).


  • Mod

    wenn ihr hier alles auflisten wollt, dann werdet ihr nie fertig 🙂

    fehlt ja noch das casten von float nach int, vergleich von floats als int um das vorzeichen zu prüfen, rechnen mit reciproxen, mehrere variablem in eine stecken um SIMD zu simulieren,fixpoint artihmetik,selbst modifizierender code,die fpu in andere modie umstellen,memory pooling,allignment von klassen...

    am wichtigsten könnte sein, dass man seinen compiler in und auswendig kennt, damit man weiß was der am ende auskotzt, dazu sollte man ein wenig assembler können und sich das resultat anschauen, nicht selten dass da etwas total unperformantes rauskommt...

    http://www.flipcode.com/tutorials/tut_fastmath.shtml

    da kann man sich ein beispiel anschauen.

    rapso->greets();



  • Was haltet ihr allgemein von FPU-ASM?
    Lohnt sich der Aufwand überhaupt?



  • @raspo
    Da hast du sicher recht, dass man das ins Endlose ziehen könnte

    @kane
    FPU-ASM??



  • Mit ASM die FPU programmieren


  • Mod

    wenn du es besser machst als ein compiler, dann ja!

    rapso->greets();



  • Tja, und woher weiß ich (bevor ich meine base_math.h in asm schreibe) das
    ich das besser kann?
    Ich habe gehört, das bestimmt Operationen in C++ nicht besonders so effizient
    implementiert sind wie möglich, da sie irgendeinem Standard erfüllen müssen.



  • AJ schrieb:

    @0x1
    Ist bei deinem Beispiel die zweite Schleife nicht langsamer??

    Sind wohl Messfehler... vielleicht hab ich ja die Maus bewegt oder Outlook hat den Posteingang geprüft. Ich würde sagen beides ist gleichschnell.

    @rapso:
    Der Tipp um das Vorzeichen eines floats festzustellen ist super. Hätte man eigentlich selbst drauf kommen können. Werd ich gleich mal überall einbauen....



  • um es nochmal zu sagen, man kann nicht wirklich generele Performance Tipps geben! Das hängt konkret von deiner Anwendung ab. Wenn du siehst, dass eine Funktion eben besonders oft aufgerufen wird, kannst du sie dir angucken und dort optimieren. zB. kannst du jenachdem dort SIMD Code einfügen oder ähnliches.

    Natürlich gibt es schon einige Dinge zu beachten, dass man eben je nachdem Call-by-value vermeidet, wenn man const Referenzen übergeben/zurückgeben kann. Obwohl das in einigen Fällen die Lage sogar verschlimmern kann!

    Das mit dem Postfix/Prefix ++/-- Operator war früher bei den Compilern wichtig. Bei C++ ist das bei Klassen wichtig, wo der Operator überladen ist, weil da der Compiler nicht mehr optimieren kann, weil er ja nicht weiss, was die Funktion intern macht (bei inline kann das aber natürlich wieder anders sein!). Deswegen ist es schon keine schlechte Taktik sich die Benutzung des Prefix-Opertors anzugewöhnen, genauso wie Lieber <lvalue> <op>= <rvalue> Anstelle <lvalue> = <lvalue> <op> <rvalue>

    Aber wie gesagt, wirklich optimieren kann man nur, wenn man einen konkreten Code hat und den schön mit dem Profiler analysieren kann.


  • Mod

    kingruedi schrieb:

    Bei C++ ist das bei Klassen wichtig, wo der Operator überladen ist, weil da der Compiler nicht mehr optimieren kann, weil er ja nicht weiss, was die Funktion intern macht

    außer bei virtuellen funktionen macht der compiler genau das, das ist eine optimierung die schon seit sehr langem im intel compiler ist und im .Net compiler von m$ und die gnu leute sind da sicherlich nicht hinten dran und haben das drinne.
    (damit will ich nicht klugscheissen sondern lediglich darauf hinweisen)

    rapso->greets();


Anmelden zum Antworten