Frage zu Effektivität



  • Hi, ich bräuchte mal die Info, was Rechentechnisch die optimalere Lösung ist.

    int a,b,j;
    ...
    for(j=0;j<a+b;j++)
    {
      ..
    }
    

    oder

    int a,b,j;
    ...
    int hlp=a+b;
    for(j=0;j<hlp;j++)
    {
      ..
    }
    

    Im ersten Fall wird ja temporär eine Variable erzeugt, mir ist jetzt nicht klar, ob a+b bei jedem Schleifendurchlauf wieder berechnet wird, oder nur einmal. Wenn dies der Fall wäre, gäbe es ja vom Aufwand her keine Unterschied.



  • a+b wird jedesmal neu berechnet. Zumindest von der Definition her.
    Ob ein guter Compiler das erkennt, dass der Wert konstant ist und ihn nur einmal berechnen lässt, weiß ich nicht. Bestenfalls kommt aber dann auch nur die untere Lösung raus.
    Auf jeden Fall würd ich die zweite Lösung vorziehen, und außerdem das hlp const machen - das ist immer gut 🙂



  • Btw ist das eine Frage der Effizienz, denn effektiv sind beide Varianten.



  • @Bashar
    Was ist "Btw"?

    Mir geht es darum, die Anzahl der Rechenoperationen in einem Programm zu minimieren, damit es schneller wird. Ich greife hierbei nach jedem Strohhalm.



  • IMHO heist btw = by the way.



  • Und was heißt "imho" *zank* 😃
    Zum Thema: Ich denke, dass jeder halbwegs moderne Compiler das optimieren kann. Wie sähe es denn eigenlich aus wenn man die Variablen a und b volatile machen würde, oder hat das nix damit zu tun?



  • Bei volatile könnte er nicht optimieren. IMHO ist nur ne höfliche Form von IMO 😉



  • Kenn dein Problem 😃

    Guckst Du hier!

    www.acronymfinder.com

    Jeden falls ist das, so das Beste was ich finden konnte



  • Helium schrieb:

    Bei volatile könnte er nicht optimieren. IMHO ist nur ne höfliche Form von IMO 😉

    Bezweifle, das IMHO eine als eine höflicher Form von IMO genmeint ist



  • Mir war klar was IMHO bedeutet. Benutze es selbst 1000 Mal am Tag übertreib. Wollte nur ärgern.
    @Helium: Glaubst du nicht der Compiler könnte ein schwachsinniges volatile wegoptimieren? Naja, im Zweifelsfall müsste man es einfach mal testen.



  • Es kann doch nicht schaden, dass gleich vernünftig vorher auszurechnen. Dann kann man sich erstens sicher sein, und der Compiler wird wohl auch nichts besseres machen.
    Ich finde die Einstellung falsch, etwas absichtlich 50 Milliarden mal neu zu berechnen und zu sagen "ach der Compiler wird das schon machen...", man sollte auch mal wissen, was in einer for-Schleife passiert.



  • @Ziemlich arroganter Vorposter: Danke, ich weiß was in einer for-Schleife passiert. Habe ich gesagt, dass ich es so machen würde? Ich habe lediglich angemerkt, dass Compiler intelligente Werkzeuge sind und (bei builtins) dieses Problem beheben können. Es bringt nur nichts sich ewig und drei Tage über so etwas den Kopf zu zerbrechen. Ein Flaschenhals ist das i.d.R. nicht.



  • In der for-Schleife werden Punkte aus einer CAD-Datei in ein Feld geschrieben.
    Die Größe des Feldes kenne ich aber erst, wenn ich die Datei geöffnet habe.

    Da ich bisher den ersten Weg im Programm verwendet habe und nun auf der Suche nach Möglichkeiten bin, den Programmablauf zu beschleunigen, wollte ich nur wissen, was schneller ist.

    Ich habe mir die for-Schleife mit dem Debugger mal angesehen und festgestellt, daß die Berechnung immerwieder neu gemacht wird, wenn ich in der Schleife auf die Variablen zugreife. Mache ich nichts mit den Variablen, interpretiert der Compiler sie als const und berechnet den Ausdruck nur einmal.



  • Nun sollte man noch anmerken, dass im Debug-Modus i.d.R. nicht höchste Optimierungsstufe herrscht. Wenn du den Wert dieser Variablen nicht veränderst, dann darf der Compiler sowas theoretisch optimieren. Man sollte immer den besten Weg wählen und nicht den bequemsten. Deshalb würde ich vorschlagen das a+b konstant vorneweg zu berechnen. Kostet dich im Zweifelsfall (also bei einem Durchlauf) praktisch garnichts.



  • MaSTaH schrieb:

    @Ziemlich arroganter Vorposter: Danke, ich weiß was in einer for-Schleife passiert. Habe ich gesagt, dass ich es so machen würde? Ich habe lediglich angemerkt, dass Compiler intelligente Werkzeuge sind und (bei builtins) dieses Problem beheben können. Es bringt nur nichts sich ewig und drei Tage über so etwas den Kopf zu zerbrechen. Ein Flaschenhals ist das i.d.R. nicht.

    lol, was geht denn jetzt?!? Ich wollte eigentlich nur das ausdrücken, was du inzwischen selber gesagt hast, nämlich dass man nicht einfach den bequemsten Weg wählen soll.
    Ich habe auch nicht gesagt, dass du nicht weisst, was eine for-Schleife ist, sondern wollte nur zum Ausdruck bringen, dass man sich generell über sowas Gedanken machen sollte, bevor man sich auf den Compiler verlässt.
    Das war keineswegs auf dich bezogen.

    MfG



  • @Mastah:

    Glaubst du nicht der Compiler könnte ein schwachsinniges volatile wegoptimieren?

    Macht VC6 tatsächlich bei lokalen variablen.

    Originale Frage:

    Wenn der optimizer ein Register für die Summe frei hat, wird er diese auf alle Fälle dort halten. Wenn nicht, tendiert zumindest VC6 eher dazu, die Summe jedesmal neu zu berechnen - was auch nicht schlimm ist, da der Schleifenkörper dann meist das overhead von 1 Takt (oder wenn du Glück hast 0 Takten) nicht bemerkt.

    In den meisten Fällen ist's egal, also eher eine Stilfrage. Ich tendiere zur Hilfsvariablen, einfach damit man nicht schlampig wird, wenn's wirklich mal kritisch ist.



  • Optimizer schrieb:

    Das war keineswegs auf dich bezogen.

    Ist ja schon gut. Bin eben mit dem falschen Fuß aufgestanden 😉 .


Anmelden zum Antworten