Tparallel und Bitmap-Bearbeitung

[himitsu]

Ja, aktiv sind gleichzeitig immer nur ein paar, aber insgesammt sind es sehr Viele.
Vermutlich also mehr Verwaltungaufwand, als Zeitersparnis.


Vorher gab es Einen Typen, der holte sich alle Infos und arbeitete das dann nacheinander ab.
Jetzt gibt es vielleicht 8 Leute, die rennen gleichzeitig zu einen Verwalter Hauptthread, holen sich durcheinanderredend irgendeine Arbeitsposition bearbeiten ein Pixel schreiben gleichzeitig in zwei Variablen rein und rennen dann wieder zum Pool-Verwalter, fragen ob noch ein Thread da ist, fragen wieder gleichzeitig den Verwalter Hauptthread und bearbeiten irgendin ein Pixel, bis alle Pixel Threads durch sind.

[Sir Rufo]

Es sind eben nicht insgesamt viele, es sind und bleiben eine Handvoll Threads, die, wenn einmal erzeugt, bis zum Ende des ThreadPools aktiv/schlafend bleiben. Diese Threads holen sich einfach die nächste Aufgabe, verarbeiten die und es geht wieder von vorne los. Da ist kaum ein Unterschied, ob ich jetzt eine Aufgabe mit 10 Einzelschritten oder 10 Aufgaben mit jeweils 1 Einzelschritt übergebe.

[himitsu]

OK, dann sind es eben massig anonyme Methoden (1), welche in einem Pool warten und von einer Hand voll Threads abgearbeitet werden.

1:
* kurzer Code von nichtmal annähern einer Millisekunde Rechenzeit
* der jeweils nur ein einziges Pixel verarbeitet

Die Verwaltung und Synchronisierung dieses Pools ist garantiert langsamer, als die eingesparte Zeit.
Über die Verarbeitung einer ganzen oder mehrere Zeilen, würde jede Methode länger rechnen und der Tool müsste gleichzeitig weniger verwalten.

[Dejan Vu]

Ich würde die Bearbeitung für jede ScanLine in einen separaten Thread verschieben, also vielleicht so:

Delphi-Quellcode:

TParallel.For(0, Bitmap.Height-1, procedure (Y: Integer) 
var
  Ziel : ^TRGBTriple;
  Quelle : ^TRGBTriple;
  OK: Boolean;

begin
  Ziel := Bitmap.Scanline[y];
  Quelle := Original.Scanline[y];
,,,

Grund:
1. Größere Abschnitte (vielleicht kann man die noch größer machen, jeder Thread X Scanlines auf einmal)
2. Keiner tritt dem anderen auf die Füße.

Die Vergleiche mit Eiern und Kuchen sind zwar boxkomisch, aber hier ist der Denkfehler ja der, das die Variablen unkontrolliert verwendet werden, und das sehe ich bei dem Eierkochenkuchenbackenvergleich nicht.

Diese TParallel-Library ist kein Hexenwerk und zaubern kann sie auch nicht. Das ist ein ziemlich banaler, aber sehr elegant zu verwendender Threadpool. Alles, was man über Threads weiß, muss man auch hier beherzigen. Wenn man die einzelnen Jobs nicht allzu granular aufteilt (1 Pixel ist SEHR granular) und den Scope/Zugriff der gemeinsam verwendeten Variablen beachtet (Füße, blaue Flecken und so), muss man sich wohl über die Anzahl der CPU-Kerne keine Gedanken mehr machen. Aber über den ganzen Rest schon.

[himitsu]

Ja, Ziel/Quelle in jeden Thread verschieben und zugleich hoffen, daß Scanline threadsafe ist.

[Dejan Vu]

Zitat von himitsu:

Ja, Ziel/Quelle in jeden Thread verschieben und zugleich hoffen, daß Scanline threadsafe ist.

=> Ansonsten vorher in ein Array packen.

[himitsu]

Man kann es auch Mathematisch erledigen ... wenn man weiß wie die Daten im Bitmap gespeichert werden.

Das Windows-Bitmap wird von unten nach oben gespeichert.
* Scanline auf die letzte Zeile
* und dann liegen die Linies hinterienander
* zwischenden Lines muß man nur noch das Align beachten, also jeweils auf 4 Byte aufrunden, aber bei 32-Bit-Bitmaps fällt das nicht auf

Delphi-Quellcode:

P: TPixelAarray;  // array[0..z] of TRGB;
P := Scanline[Bitmap.Height - 1];
Pixel := P[(Bitmap.Height - y - 1) * Image.Width + x];