3. for Schleife ?

for Schleife ?

  • I

    Funzen tun alle Varianten, aber Var. 2 ist die schnellste.

    0
  • S

    wie kommst du auf die Idee zweite Variante sei die schnellste? Hier ein Auszug aus dem was VC7.1 produziert:

    int a = 0, b = 0;
a++, ++b;

__asm inc a;

    ;Initialisierung
mov         dword ptr [a],0		
mov         dword ptr [b],0 

;erste Variante
mov         eax,dword ptr [a] 	
add         eax,1 
mov         dword ptr [a],eax

;zweite Variante
mov         ecx,dword ptr [b]	
add         ecx,1 
mov         dword ptr [b],ecx 

;Inline Assembler
inc         dword ptr [a]

    es könnte auch an VC7.1 liegen 🙄 :p

    0
  • J

    na endlich mal einer, der begriffen hat, dass Compiler heutzutage etwas intelligenter sind als anno 1970. In der Tat optimiert ein Compiler (bzw. die Optimierstufe des Compilers) den Code heute so hoch, dass man nicht annähernd sein listing in einer Hochsprache wiedererkennt...

    -junix

    0
  • J

    btw: Auch MSVC 6sp5 generiert schon folgenden code:

    ; Als Kommentare jeweils die C-Codes dazu

; int a = 0;
mov dword ptr [ebp-8], 0
; int b = 0;
mov dword ptr [ebp-0Ch], 0

; a++;
mov eax, dword ptr [ebp-8]
add eax, 1
mov dword ptr [ebp-8], eax

; b++;
mov ecx, dword ptr [ebp-0Ch]
add ecx, 1
mov dword ptr [ebp-0Ch], ecx

    Ist zwar grundsätzlich compilerabhängig, was daraus jeweils gemacht wird, aber alle aktuellen Compiler sind schon hochoptimierend... *hrm* (o: (nur so als Ergänzung *g*)

    -junix

    [edit]was mich allerdings wundert, ist, dass er nicht direkt inkrementiert.. hmm wär jetzt spanned was der intel-compiler daraus wurschtelt.[/edit]

    0
  • B

    gcc 3.2.2 erzeugt schon ohne Optimierung bei ++i, i++, i+=1 und i=1+i denselben code:

    leal    -4(%ebp), %eax
incl    (%eax)

    (edit: [ code ] rückt irgendwie falsch ein 😕 )

    0
  • W

    Naja, solche simplen Optimierungen kann selbst ein vorsintflutlicher Compiler bei Builtins vornehmen. Aber nichts desto trotz sollte man sich ++i angewöhnen um bei Objekten bei denen der Compiler nicht optimiert nicht einfach aus Gewohnheit postincrement zu verwenden.

    0
  • P

    Was spricht gegen das Post increment?

    0
  • T

    Beim Postinkrement muss erst eine temporäre Variale angelegt werden, die den alten wert speichert und zurück gibt.

    0
  • C

    OT:
    Wenn das Post-Increment über das Pre-Increment implementiert ist, und zwar so:

    inline const A A::operator++(int)
{
  A old = *this;
  ++(*this);
  return old;
}

    Darf der Compiler die Erstellung und Kopie der Variablen old komplett entfernen, wenn er feststellt, dass der Rückgabewert von operator++ nicht verwendet wird?

    0
  • J

    nur bedingt!
    Der Copy-Konstruktor könnte seiteneffekte haben.

    0
  • C

    Return value optimization entfernt z.B. auch Copy-Konstruktor Aufrufe. Aufrufe des Copy-C'tor werden also nicht garantiert.
    Allerdings funktioniert return value optimization nur bei temporären Objekten, was hier nicht zutrifft.

    Wie ist das in diesem Fall?

    0
  • B

    Er darf die Kopie beim zurückgeben von old wegoptimieren (NRVO), aber nicht die Erzeugung von old.

    0
  • H

    (edit: [ code ] rückt irgendwie falsch ein 😕 )

    du meinst die erste Zeile? mach einfach einenPunkt in die Erste Zeile und fang erst ab der zweitzen an zu schreiben.

    0
Anmelden zum Antworten