Geht das noch schneller? - Bitmap-Verrechnung

[Harry Stahl]

Das hatte ich gerade auch zufälligerweise im Internet gefunden.

Doch Überraschung: Ist deutlich langsamer, als meine Funktion, die ich gepostet hatte. Wahrscheinlich kostet der doppelte Zugriff auf das byte-Array mehr Zeit als die direkte Berechnung der Werte.

Edit: Halt, diese Aussage muss ich evtl. zurückziehen. Wenn ich folgende logische Abfrage wie bei mir oben einbaue, ist es zumindest ähnlich schnell:

  if RGBA^[x].rgbReserved <> 255 then begin Hängt dann eben davon ab, wieviel Pixel überhaupt Transparent sind, denn nur die müssen ja berechnet werden, die anderen können den Wert behalten.

[Dejan Vu]

Das Lookup-Array wird nur einmal berechnet, da ist es unerheblich, etwas zu optimieren. Daher würde ich diesen Vorgang nicht in die Performancebetrachtungen mit einbeziehen.
Beim Schreiben des Vorschlags ist mir aber auch aufgefallen, das es bei drei Operationen (*, /, round) nicht allzuviel zu optimieren gibt.
Aber wieso verwendest Du 'MulDiv' nicht? Das Ergebnis ist um höchstens 1 unterschiedlich (Rundungsverhalten).

[Mavarik]

Zitat von Dejan Vu:

Aber wieso verwendest Du 'MulDiv' nicht?

MulDiv ist immer ein Far-Call und Jumps und damit auf jeden Fall langsamer. (Auch wenn ich es nicht getestet habe)

Aber ein

C := A * 5 div B;

ist:

Code:

xor eax,eax
mov al,[ebp-$5]
lea eax,[eax+eax*4]
xor edx,edx
mov dl,[ebp-$06]
mov ecx,edx
xor edx,edx
div ecx
mov edx,[ebp-$04]
mov [edx+$002d4],al

ein C := MULDIV(A,5,B) ist:

Code:

xor eax,eax
mov al,[ebp-$6]       
push eax
push $05
xor eax,eax
mov al,[ebp-$5)
Push eax             // bishier schon fast so viele Ticks wie oben
CALL MulDiv
// aus MulDiv
jmp dword ptr[$00896ae8]
mov eax,[esp+$04}
or eax,eax
js $75201b80
mov edx,[esp+$80]
or edx,edx
js $75201c06
mul edx
mov ecx,[eps+$0c]
or ecx,ecx
js $75201c48
sar ecx,1
add eax,ecx
adc edx.$00
cmp edx,[esp+$0c]
jnb $75201b7a
div dword ptr [esp+$0c]
or eax,eay
js $75201b7a
ret $000c
mov edx,[ebp-$04]   // gleich mit oben
mov [edx+$02d4],al  // gleich mit oben

Ein C := A * B div 8 ist:

Code:

xor eax,eax         // gleich mit oben 
mov al,[ebp-$05]    // gleich mit oben
xor edx,edx         // gleich mit oben
mov dl,[ebp-$06],
imul edx
shr eax, $03        // div 8 erkannt
mov edx,[ebp-$04]   // gleich mit oben
mov [edx+$02d4],al  // gleich mit oben

Mavarik

[Dejan Vu]

MulDiv basiert auf In64 und ist damit überlauf-sicher, was bei A*B div C imho nicht der Fall ist. Dafür ist es langsamer als der das einfache A*B DIV C.

Bezüglich des Performancevergleiches zielte ich eher auf 'MulDiv' vs. 'Round(A*B/C)' ab, also Floating Point Arithmetik.

[Harry Stahl]

Zitat von Dejan Vu:

Aber wieso verwendest Du 'MulDiv' nicht? Das Ergebnis ist um höchstens 1 unterschiedlich (Rundungsverhalten).

Das habe ich schon in Betrag Nr. 10 gesagt, weil es dann doppelt so lange braucht.

[Harry Stahl]

Um die bisherigen Ergebnisse zusammenzufassen:

* Zugriff auf ein Lookup-Array dauert länger, als die Berechnung.
* MulDiv bringt eindeutig keine Beschleunigung
* Im vorliegenden Fall bringt auch eine Parallelisierung nichts, da der Verwaltungsaufwand
größer ist, als der Gewinn durch mehrere Prozessorkerne

Das bislang schnellste Ergebnis liefert der untenstehende Code, egal, ob per Pointer-Addition oder Array-Zugriff:

Delphi-Quellcode:

procedure Draw32BitToBitmapxxx(const BitOben: TBitmap; BitUnten: TBitmap); // Array-Zugriff
var
   h,w,i, r, g, b: Integer;
   RGBA_Unten, RGBA_Oben: pRGBALine;
begin
    for h := 0 to BitUnten.Height-1 do begin
     RGBA_Unten := BitUnten.ScanLine[h];
     RGBA_Oben := BitOben.ScanLine[h];

     For w:= 0 to BitUnten.Width-1 do begin
       if RGBA_Oben^[w].rgbReserved = 0 then begin
         // unten bleibt
       end else begin
         RGBA_Unten^[w].rgbred := (RGBA_Oben^[w].rgbReserved * (RGBA_Oben^[w].rgbred - RGBA_Unten^[w].rgbred) shr 8 + RGBA_Unten^[w].rgbred);
         RGBA_Unten^[w].rgbGreen := (RGBA_Oben^[w].rgbReserved * (RGBA_Oben^[w].rgbgreen - RGBA_Unten^[w].rgbGreen) shr 8 + RGBA_Unten^[w].rgbGreen);
         RGBA_Unten^[w].rgbBlue := (RGBA_Oben^[w].rgbReserved * (RGBA_Oben^[w].rgbBlue - RGBA_Unten^[w].rgbBlue) shr 8 + RGBA_Unten^[w].rgbBlue);

         RGBA_Unten^[w].rgbReserved := 255;
       end;
    end;
   end;
end;

procedure Draw32BitToBitmapnew(const BitOben: TBitmap; BitUnten: TBitmap); // Pointer-Addition
var
  h,w: Integer;
  RGBA_Unten, RGBA_Oben: ^TRGBQuad; // pRGBALine;
begin
  For h := 0 to BitUnten.Height-1 do begin
    RGBA_Unten := BitUnten.ScanLine[h];
    RGBA_Oben := BitOben.ScanLine[h];

    For w:= 0 to BitUnten.Width-1 do begin
      if RGBA_Oben^.rgbReserved = 0 then begin
        // unten bleibt
      end else begin
        RGBA_Unten^.rgbBlue  := ((RGBA_Oben^.rgbReserved * (RGBA_Oben^.rgbBlue -  RGBA_Unten^.rgbBlue))  shr 8 + RGBA_Unten^.rgbBlue);
        RGBA_Unten^.rgbGreen := ((RGBA_Oben^.rgbReserved * (RGBA_Oben^.rgbgreen - RGBA_Unten^.rgbGreen)) shr 8 + RGBA_Unten^.rgbGreen);
        RGBA_Unten^.rgbred   := ((RGBA_Oben^.rgbReserved * (RGBA_Oben^.rgbred -   RGBA_Unten^.rgbred))   shr 8 + RGBA_Unten^.rgbred);

        RGBA_Unten^.rgbReserved := 255;
      end;
      inc (RGBA_Unten);
      inc (RGBA_oben);
   end;
  end;
end;

[Mavarik]

Zitat von Harry Stahl:

* Im vorliegenden Fall bringt auch eine Parallelisierung nichts, da der Verwaltungsaufwand
größer ist, als der Gewinn durch mehrere Prozessorkerne

Das kann ich eigentlich kaum glauben.

Vielleicht über die Parallel FOR ok, kann ich nicht nachvollziehen. Aber einen optimierten thread mit entsprechendem vorbereiteten Prozessen müsste schneller sein.

Können wir am Sa. ja mit unserem Thread König, emm Kaiser, ich meine Kaisler diskutieren.

Mavarik

[manfred42]

Hallo, ich bin hier neu hinzugestoßen und versuche mich am Beschleunigen.
Zuförderst ein paar Fragen zu den Details:
● Ist der Nenner in der Formel 255 oder 256? Bei 255 sind einige Klimmzüge nötig
● Ist Round vonnöten, oder dient es nur zur Float-Integer-Konvertierung?
● Von welcher WEB-Site kann ich 2 repräsentative 32-bittige Bitmaps absaugen?

Da ich schon einmal mit MMX-Befehlen Antialiasing veranstaltet habe,
würde ich mich gern an der Bitmap-Verrechnung versuchen.

MfG Manfred(19)42

[Harry Stahl]

Zitat von manfred42:

Hallo, ich bin hier neu hinzugestoßen und versuche mich am Beschleunigen.
Zuförderst ein paar Fragen zu den Details:
● Ist der Nenner in der Formel 255 oder 256? Bei 255 sind einige Klimmzüge nötig
● Ist Round vonnöten, oder dient es nur zur Float-Integer-Konvertierung?
● Von welcher WEB-Site kann ich 2 repräsentative 32-bittige Bitmaps absaugen?

Da ich schon einmal mit MMX-Befehlen Antialiasing veranstaltet habe,
würde ich mich gern an der Bitmap-Verrechnung versuchen.

MfG Manfred(19)42

256 wäre wohl richtig.
Round wäre gut, zur Not aber auch ohne.
Erstelle Dir doch einfach selber 2 passende Bitmaps, hier die Größe und Bedingungen, mit denen ich hier teste:

- 3548x2558 Pixel, 32 Bit-Format.
- Das untere Bitmap hat einen Verlaufsuntergrund, das obere Bitmap hat zwei rechteckige Bereiche (jeweils 340 x 2300), die zu 100% transparent sind.

[Harry Stahl]

Zitat von Mavarik:

Zitat von Harry Stahl:

* Im vorliegenden Fall bringt auch eine Parallelisierung nichts, da der Verwaltungsaufwand
größer ist, als der Gewinn durch mehrere Prozessorkerne

Das kann ich eigentlich kaum glauben.

Vielleicht über die Parallel FOR ok, kann ich nicht nachvollziehen. Aber einen optimierten thread mit entsprechendem vorbereiteten Prozessen müsste schneller sein.

Können wir am Sa. ja mit unserem Thread König, emm Kaiser, ich meine Kaisler diskutieren.

Mavarik

Hängt eben davon ab, was die Funktion macht. Wenn die nur wenige Befehle ausführen muss, sind die Aktionen, welche für die Threadverwaltung benötigt werden, zeitintensiver, als die Abarbeitung der wenigen Befehle. Das gilt sowohl für Parallel FOR und für Parallel Task.

Muss man quasi im Einzelfall testen, wo was schneller ist.