-
Forum: Algorithmen, Datenstrukturen und Klassendesign
by Harry Stahl,
30. Nov 2014
Nun ja, TParallel hatten wir hier ja auch schon. Der Link zeigt zwar die Parallel-For-Verwendung aber mit canvas.pixel, das ist ja so ziemlich das Langsamste, was man machen kann.
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
by Harry Stahl,
30. Nov 2014
Um das jetzt noch zu vervollständigen: Jetzt funktioniert auch Deine Lösung mit ca. 32 MS recht schnell und richtig.:thumb:
Wenn man die Graphics32 also nicht verwenden möchte, wäre Deine Lösung auch noch eine Variante.
OK, mit XE2 kannst Du das Demo nicht kompilieren, da ja dort noch nicht die TParallel-Library zur Verfügung stand.
Wenn Du aber die "System.Threading" Unit rausnimmst und...
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
by Harry Stahl,
29. Nov 2014
Ich habe nun den Rat gefolgt und habe mir die Graphics32-Unit mal angehen.
Der Grafk-Typ TBitmap32 ist zwar ein eigener Klassen-Typ, aber die Lowlowel-Routinen, die dahinter liegen, kann man auch auf TBitmap anwenden.
Die Lösung besteht also nun darin, GR32 und GR32_Blend aus der Graphics32 einzubinden und dann kann man die Funktion mit einer Zeile (1) benutzen, die dann auch nur noch 31 MS...
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
by Harry Stahl,
29. Nov 2014
@Amateurprofi:
Danke, dass Du Dich der Sache noch mal angenommen hast. Allerdings stimmt das Ergebnis immer noch nicht.
Falls Du die Sache noch weiter verfolgen willst, kannst Du hier im Thread-Beitrag Nr. 26 das Demoprojekt laden, das ich gepostet habe.
Da brauchst Du nur im Button-Click Event folgendes zu machen, um Deine Procedure einzubinden:
for L := 1 to count do begin
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
by Harry Stahl,
29. Nov 2014
Danke für den Tipp. Allerdings möchte ich erst mal nur 2-3 bestehende Grafik-Funktionen unter Weiterverwendung von TBitmap und meines bisherigen Source-Codes beschleunigen.
Die Konsequenz, das ganze Programm umzuschreiben, möchte ich derzeit noch ganz gerne vermeiden...
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
by Harry Stahl,
29. Nov 2014
Ja, das gute alte Assembler...
Wäre noch etwas schneller als meine letzte Variante (hier zuletzt ca. 62 MS, die ASM ca. 47 MS), allerdings ist das Ergebnis erkennbar falsch, siehe Screenshot).
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
by Harry Stahl,
27. Nov 2014
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.
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
by Harry Stahl,
27. Nov 2014
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.
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
by Harry Stahl,
26. Nov 2014
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...
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
by Harry Stahl,
26. Nov 2014
Das habe ich schon in Betrag Nr. 10 gesagt, weil es dann doppelt so lange braucht.
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
by Harry Stahl,
25. Nov 2014
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...
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
by Harry Stahl,
25. Nov 2014
Danke, das war ein wichtiger Hinweis, den ich übersehen hatte: Wenn die Bitmap Premultiplied ist, funktioniert die Alphablend-Funktion auch wie bei allen Bitmaps wie gewünscht!!:oops:
Insgesamt ist dann die Kombination temporäres Premultiplied-Bitmap erzeugen und mit Alphablend benutzen schon schneller als die hier bislang gefundene Lösung.
Das hier ist meine aktuelle PreMultiply-Funktion:...
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
by Harry Stahl,
24. Nov 2014
Nein, muss gestehen, kannte ich bislang nicht (habe mit GraphicEX, ansonsten teilweise mit ImageEn, aber meistens mit eigenen Lösungen gearbeitet).
Werde ich mir mal ansehen. Gibt es dort so eine spezielle Verrechnungsfunktion wie hier benötigt?
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
by Harry Stahl,
24. Nov 2014
Ja, sagt mir was. Wäre durchaus eine Überlegung (gewesen), aber dafür hätte man das dann von Anfang an im Programm (es dreht sich hier um ein Bildbearbeitungsprogramm) berücksichtigen müssen.
Die einzige Verwendung der hier diskutierten Funktion im Programm ist die Anzeige des fertig verrechneten Bitmap-Ebenen-Stapels auf einen Karo-Hintergrund (siehe anliegenden Screenshot).
Ich verwende...
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
by Harry Stahl,
24. Nov 2014
@manfred42:
Habe mal das Zip-Paket (mit einem anderen ZIP-Programm gepackt) an Deine private Mailadresse geschickt, wie gewünscht.
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
by Harry Stahl,
23. Nov 2014
Erst mal vielen Dank an Euch fürs mit überlegen, ich finde es echt spannend, hier die anderen Ansätze mal zu sehen. Jede der zuletzt genannten Varianten war immer ein weniger schneller als die Ausgangsfunktion.
Ich habe jetzt einfach mal bei ImageEn nachgesehen, die ich hier lizenziert habe, wie die das machen. Da ist das Bild zwar auch geringfügig unterschiedlich als meine Ausgangsfunktion,...
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
by Harry Stahl,
22. Nov 2014
Ich habe mal die Bilder was kleiner gemacht, damit ich sie noch in die Form integrieren kann (im Original sind sie ca. jeweils 30 MB groß, da weigert sich Delphi) und das Testprojekt mal hier hochgeladen.
Auf dem Screenshot kann man sehen: Alt gibt die Zeit für die Ursprungs-Procedure vor. Optimiert ist das, wo wir uns gerade bemühen (im Source jetzt gleich mit "Alt") und Par ist die...
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
by Harry Stahl,
22. Nov 2014
Und die erste Variante ist nach wie vor nicht kompilierbar. Zwar akzeptiert der Compiler die erste Zeile, bei der zweiten sagt er aber "E2014: Anweisung erforderlich aber Ausdruck vom Typ Integer gefunden"
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
by Harry Stahl,
22. Nov 2014
Die Variante mit SHR ist compilierbar, ist auch schneller, aber das Ergebnis ist falsch, siehe anliegende Screenshots.
Das habe ich von Dir da verwendet:
procedure Draw32BitToBitmapNew(const BitOben: TBitmap; BitUnten: TBitmap);
var
h,w,i: Integer;
RGBA_Unten, RGBA_Oben: pRGBALine;
begin
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
by Harry Stahl,
22. Nov 2014
Mache ich doch gerne. Rückmeldung zu Variante 1+2:
E2015: Operator ist auf diesen Operandentyp nicht anwendbar.
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
by Harry Stahl,
22. Nov 2014
Jetzt noch mal Ergebnisse bei Parallelisierung des ganzen mit TParallel:
Auf 2-Kern-Rechner von ca. 300 MS auf 150
Auf 4-Kern-Rechner von ca. 300 MS auf 100
Auf 6-Kern-Rechner von ca. 300 MS auf 56
Also fast 6 mal so schnell!!
Jetzt lohnt sich das mit den Kernen so richtig, insbesondere bei den rechenintensiven Grafikbearbeitungsaufgaben eine echt hilfreiche Sache.
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
by Harry Stahl,
22. Nov 2014
Ich glaube, Du könntest Recht haben, mit der Vermutung, dass es eigentlich nie größer als 255 werden kann, da ja von einem Ausgangswert, der nie größer als 255 sein kann, immer etwas abgezogen wird. Also muss man in der Tat nur den <0 Fall berücksichtigen.
Auch /256 statt /255 müsste richtig sein, da es ja um die Anzahl der möglichen Farbabstufungen geht.
Super!!
Das umgesetzt werden...
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
by Harry Stahl,
22. Nov 2014
wenn ich Round durch Floor ersetze, dauert es 3 mal so lang...
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
by Harry Stahl,
22. Nov 2014
Was meinst Du hiermit genau?
Ich vermute mal, eine x in 0..255 Prüfung braucht mehr Zeit und ich weiß dann immer noch nicht, ob x evtl. kleiner als 0 (dann schwarz) oder größer 255 ist (dann weiß).
-
Forum: Algorithmen, Datenstrukturen und Klassendesign
by Harry Stahl,
22. Nov 2014
Selbst dieser Versuch, einen lokalen TRGBQuad zu verwenden (cu- und co-Variablen), führt bei 5 Durchläufen, bei einem Bitmap von ca. 3500x2500 Pixel zu 300 MS mehr Zeit:
procedure Draw32BitToBitmapNew(const BitOben: TBitmap; BitUnten: TBitmap);
var
h,w,i: Integer;
RGBA_Unten, RGBA_Oben: pRGBALine;
cu, co : TRGBQuad;
begin
For h := 0 to BitUnten.Height-1 do begin