Allgemeine Optimierung



  • Hallo!

    Es gibt sicher sehr viele Tricks (z.B. mit xor ein Register auf 0 setzen) und Kniffe, mit denen man den Asm-Code schneller machen kann!

    Danke.



  • Original erstellt von <Alex>:
    Hallo!
    Es gibt sicher sehr viele Tricks (z.B. mit xor ein Register auf 0 setzen) und Kniffe, mit denen man den Asm-Code schneller machen kann!
    Danke.

    ja, das nehme ich auch an.
    welchen suchste?

    edit:
    nein, stimmt gar nicht. von den einbefehligen sie XOR ax,ax; statt MOV ax,0; oder AND ax,ax; statt CMP ax,0; gibts gar nicht viele.
    und die größeren sind dann ganz schnell ganz speziell.

    [ Dieser Beitrag wurde am 18.05.2003 um 14:05 Uhr von volkard editiert. ]



  • wir könnten doch ne liste mit x86asm optimierungsmöglichkeiten machen



  • Das wäre echt toll!!!



  • dann fang ich mal an und mach auch gleich das thema kaputt:

    für
    x=abs(x);
    kann man schreiben
    (x in ax)
    cdw
    xor ax,dx
    sub ax,dx



  • a=a/2;

    asm:

    shr eax,1

    emm... und "fast float to int" nachzusehen bei http://www.stereopsis.com/FPU.html

    rapso->greets();



  • wenn das der compiler nicht selbst macht, sollte man sich nen neuen holen...



  • mit dem xor ax,ax muss man aber aufpassen... weil wenn ich z.b.

    mov ax, 0
    mov bx, 0
    

    habe wird das auf neuen prozis schneller sein als:

    xor ax, ax
    xor bx, bx
    

    die meisten von diesen optimiert tricks sind antiquiert und spielen eigentlich nur eine rolle wenn man nen 486 oder so programmiert.

    so ist z.b. auch das shiften anstatt multiplizieren/dividieren nicht mehr unbdingt schneller da die cpu das multiplizieren mit zweierpotenzen selbst optimiert und nicht länger als der shift braucht....

    [ Dieser Beitrag wurde am 19.05.2003 um 16:25 Uhr von japro editiert. ]



  • Original erstellt von japro:
    [QB]so ist z.b. auch das shiften anstatt multiplizieren/dividieren nicht mehr unbdingt schneller da die cpu das multiplizieren mit zweierpotenzen selbst optimiert und nicht länger als der shift braucht..../QB]

    schwachsinn. das macht der compiler, wenn überhaupt.



  • Am wichtigsten ist immer noch der Algorithmus. Das wird auch so bleiben.

    Wenn du die Primzahlen von 2-10000000 mit der "Durch-Alles-Dividieren-Methode" finden willst, kannst du diesen Algorithmus gerne in Assembler hoch optimieren, sodass er auf einem 2GHz-Rechner in 5 Minuten abläuft.

    Trotzdem ist sogar eine Java-Implementation vom Sieb des Erathostenes zig-mal schneller.

    Optimier also nicht an den falschen Stellen. 🙂


Anmelden zum Antworten