memcpy



  • Hallo,

    ich mache recht viel mit Assembler, und hole zumeist 10-30%
    mehr aus Pixeloperationen herraus, bei einer Messung die das
    Verschieben eines Speichers im 4Byte Modus durchführt, bin
    ich dem memcpy bei 1000 Durchgängen ca 15[ms] unterlegen
    wie ist das möglich ?

    void CDraw::MovMem(DWORD scr,DWORD anz)
    {
      __asm
      {
         mov ebx, this
         mov edi, [ebx]CDraw.m_pTmp;
         mov esi,scr 
         mov ecx,anz 
         rep  movsd 
       }
    }
    

    Aufrufer :

    DWORD ti=GetTickCount();
    
      for(int n=0;n<1000;n++)
        m_drw.MovMem((DWORD)pMap,(m_Width*m_Height)>>2);
        //memcpy(pOut,pMap,m_Width*m_Height);
    
      CVersions::DbgMsg(0,"Time=%d\r\n",GetTickCount()-ti);
    

    Obschon memcpy(rep movsb) BYTE weise arbeiten müsste,
    erleidet der Vorgang in diesem Beispiel
    ~15[ms] Verlust im Vergleich zu memcpy, liegt das am inline asm ?

    Regel: desto größer der asm code desto effektiver wirkt dieser gegen
    den hochoptimierten c++ code

    Gruß K.


  • Mod

    Das ist kein Wunder. Du machst es auch schlechter als memcpy.
    Glaubst Du ehrlich mit etwas Asssembler schlägst Du die Leute die Libraries bauen.

    memcpy benutzt DWORD moves für den durch 4 Teilbaren Teil. Dann einen WORD move und einen BYTE move je nachdem was noch nötig ist die Anzahl der Bytes aufzufüllen. Dabei achtet es aus die DWORDF boundaries. Entsprechend werden BYTE/WORD moves auch zuerst durchgeführt...

    Du hast den Sourcecode schau rein.



  • ebend desshalb müsste das "sture" movsd (4byte), schneller sein als
    das memcpy <-das ebend auch fragmentiert arbeiten muss.

    Da ich bei Kamerabildern 4byte align Daten verschiebe, könnte es
    am inline __asm liegen, das warscheinlich den Datenfluss mehr stört
    und tatsächlich "inline" eingefügt wird, incl. diversen puscha's & popa's.

    Ich denke das ich einiges mit mit Assembler mache. (seit Jahrzehnten)
    Und das garnicht die Frage war ob ich besser bin als andere alte .



  • dabei bist du aber noch immer nicht auf Byte grenzen, zumindest nicht in dem Codeausschnitt den du in deinem ersten Thread gepostet hast. Wenn dann solltest du schon gewisse sachen beachten und wenn du schneller sein willst und wirklich große mengen Kopieren willst warum benutzt du dann nicht MMX-Register dann wirst du sicher schneller sein



  • In der Tat: MMX und heutzutage vor allem SSE und AVX sind der Schlüssel...



  • kann doch wohl nicht wahr sein , schreibt ihr nur etwas um euch wichtig zu machen ? Hier war eine Anfrage mit der Deutung das inline ASM scheinbar
    nichts bringt da es den Datenstrom des Codegenerators stört.

    Man sollte asm also besser in größeren happen mit dem masm übersetzen um
    in den Genuss der Vorteile zu kommen!

    Und was ist das für ein Bytegrenzen gerede, es geht um die DATEN -masse
    die im 4BYTE schritt über den Bus geht.. und damit garkeine Bytes
    einzeln anfassen soll, und warum der Code langsamer ist als memcpy der genau das handeln muss, und das es daran liegt das inline asm den codegenerator stört. Kann doch wohl nicht wahr sein hier..

    Seit ihr schwul miteinand oder was ?



  • kahn schrieb:

    Man sollte asm also besser in größeren happen mit dem masm übersetzen um
    in den Genuss der Vorteile zu kommen!

    Am besten alles in asm. löl.

    kahn schrieb:

    Seit ihr schwul miteinand oder was ?

    Klar.
    http://www.youtube.com/watch?v=gY4PI5MIALY


  • Mod

    @kahn: Mäßige Deinen Ton!

    Du hast Recht. Du hast movsd in Deinem Code, also einen eine DWORD move.

    Aber scheinbar hast Du Dir den Sourcecode von memcpy doch nicht angesehen.
    Dann wäre Dir aufgefallen, dass mempcy intern Code nutzt für SSE (SSE2).

    Auf SSE wurdest Du bereits von den Herren hingewiesen, die Du hier beschimpfst.



  • kahn schrieb:

    kann doch wohl nicht wahr sein , schreibt ihr nur etwas um euch wichtig zu machen ? Hier war eine Anfrage mit der Deutung das inline ASM scheinbar
    nichts bringt da es den Datenstrom des Codegenerators stört.

    Was in dem Fall aber nicht das Problem ist.

    Man sollte asm also besser in größeren happen mit dem masm übersetzen um
    in den Genuss der Vorteile zu kommen!

    Was grundsätzlich stimmen mag, aber in dem Fall nicht viel bringen wird.

    Und was ist das für ein Bytegrenzen gerede, es geht um die DATEN -masse
    die im 4BYTE schritt über den Bus geht.. und damit garkeine Bytes
    einzeln anfassen soll, und warum der Code langsamer ist als memcpy der genau das handeln muss, und das es daran liegt das inline asm den codegenerator stört. Kann doch wohl nicht wahr sein hier..

    Und es ist immer noch nicht das Problem.

    Seit ihr schwul miteinand oder was ?

    Bist du auf den Kopf gefallen oder was?



  • @kahn

    Wenn du dich nicht Prozessoren, Datenübertragung und Busbreiten und Bytegrenzen beschäftigst, wirst du außer deinen in meinen Augen doch recht Sinnfreien ASM-Code und deinen doch eher unter die Gürtellinie gehenden beleidigungen hir nicht weiter kommen.

    Mit paar Registern kannst du heute nicht mehr wirklich an großen Datenmengen was machen, weil das kann der Compiler sicher gleich gut oder sogar besser wie diu gesehen hast. Also wenn Beschäftige dich mit den Prozessorerweiterungen schon alleine MMX kann 64 bit breit Register nutzen, welche du zum kopieren benutzen kannst (SSE dann mit 128). nur so was bringt dann bei großen Datenmengen noch mehr Geschwindigkeit, aber auch nur wenn du wieder auf bestimmte Grenzen achtest.

    Und warum die Grenzen sop wichtig sind ist ganz einfach weil die CPU nicht ne x-Beliebige Adresse laden kann, also muss die nächst beste genommen werden und das ganze dann "zurechtgerückt" werden. Was dann wieder zeit kastzet, deswegen wird das mit deinem Code auch nix.



  • (seit Jahrzehnten)

    Ja, es gibt welche, die lernen seit Jahrzehnten nichts mehr.

    10-30% mehr aus Pixeloperationen herraus

    Mehr als was, deine unoptimaler C-Code? Oder mehr als die Funktionen der IPP-Bibliothek. Schon mal was von Halide gehoert?

    daran liegt das inline asm den codegenerator stört

    Nein.


Log in to reply