schnelle getPixel Funktion

[ChrisE]

Hmm,

also ich versteh es zwar nicht, aber die Lookup-Upversion ist langsamer als die Berechnungsvariante :gruebel:

Gruß, Chris

[Medium]

Griffe in den Heap kosten nun mal auch, und bei einem 2D-Array muss intern ebenso wie bei einem Bitmap der 2D-Index zu einer "1D"-Adresse umgerechnet werden. Man hat quasi das selbe Problem damit nur verdoppelt - fiel mir aber auch erst nicht auf, da LUTs an sich oft ja schon helfen. Aber wohl dann doch eher nicht, wenn man eine Multiplikation und eine Addition gegen das selbe plus etwas mehr Traffic aufm Bus eintauscht :)

[jaenicke]

Zitat:

Zitat von schwarzerlotus (Beitrag 1117208)

Ich hab noch nicht so viel mit Delphi gemacht - von daher kann an sich die Assembler Übersetzung in der IDE anzeigen lassen oder hast du dafür ein externes Tool benutzt?

Wenn du an der Stelle einen Haltepunkt gesetzt hast, drückst du Strg + Alt + C. Dann kannst du auch assemblerbefehlsweise durch den Code laufen, falls gewünscht.

[FredlFesl]

Ist TGraphic32 nicht eine Option?

[freeway]

die kochen doch alle nur mit Wasser ;)
Bisher hab ich noch keine Alternative gesehen die einen signifikanten Vorteil bietet.
Selbst die Berechnung der Adressen zum direkten Zugriff ist nur marginal schneller.
Sourcecode zum damaligen Test

Delphi-Quellcode:

Var pic_Line : integer;
    row  : PRGB32Array;
    pic_offset, pic_data : integer;
    red_count : integer;

type
  TRGB32 = packed record
    B, G, R, A: Byte;
  end;

  TRGB32Array = packed array[0..MaxInt div SizeOf(TRGB32)-1] of TRGB32;
  PRGB32Array = ^TRGB32Array;

implementation

{$R *.DFM}

procedure TForm1.Start(Sender: TObject);
var  x, y, i: Integer;
begin
  setlength(steps_adr,10);
  if not openDialog1.Execute then exit;
  image1.Picture.Bitmap.LoadFromFile(OpenDialog1.Filename);

  with Image1.Picture.Bitmap do
  begin
    PixelFormat := pf32bit;
    row := Scanline[0];                                                            //start position
    pic_Line := (Longint(Scanline[1]) - Longint(row)) div SizeOf(TRGB32);          //direction
  end;
  count_red(Sender);
end;

procedure TForm1.count_red(Sender: TObject);
begin
      pic_offset := Y * pic_Line;                                  //offset
      pic_data := Image1.Picture.Bitmap.Width - 1 + pic_offset;    //data

      for x := pic_offset to pic_data do
        with row[x] do
          begin
//            B := 0;
//            G := 0;
            red_count  := red_count + R;
//          A := 0;
          end;
  Image1.Invalidate;
end;

end.

[Medium]

Die (derzeit, auf Consumer-Hardware) höchste Instanz der Optimierung von paralleler Massendatenverarbeitung wäre natürlich die Nutzung der GPU. Entweder mittels Shadern (DirectX/OpenGL), oder etwas mehr auf allgemeine Zwecke ausgelegt CUDA/OpenCL. Leider hat man bei allen vieren für Delphi nicht die ausgewachsensten Frameworks (bei letzteren eigentlich nirgends...), und es ist eine völlig andere Art der Programmierung, die wenn frisch angegangen sicherlich einiges an Lernzeit braucht bis es mal produktiv eingesetzt werden kann. Meiner eigenen Erfahrung nach sind dort allerdings durchaus Performancezuwächse von Faktoren um 50-100 zu bereits gut optimiertem CPU Code locker drin, dafür stellt man aber dann auch wieder etwas speziellere Hardwareanforderungen an den Kunden.
Wenn Zeit aber so entscheidend ist, könnte sich so ein Exkurs ggf. auch lohnen. Allerdings ist das Lernen der APIs und Sprachen nicht alles: Man müsste zudem etwas tiefer in die Theorie zur Parallelisierung von Algorithmen (und das Thema "Was mag meine Hardware gern?") einsteigen um eine bestehende Aufgabe günstig zu zerlegen zu wissen. Vorteil des ganzen: Es ist ein verflucht spannendes und zukunftsträchtiges Thema! Mir z.B. hat es sogar die Idee (und überhaupt praktische Anwendbarkeit dieser) zu meiner Abschlussarbeit geliefert - welche als Spaß-Projekt um genau o.g. (und C#) mal genauer anzuschauen begann.
Ist, als Neuling in diesem Gebiet, sicherlich nichts für nächste Woche rund und fertig, aber wenn du die Zeit und Muße hast, auch für später nicht die schlechteste Übung. So frei nach dem Motto "Horizont, ick hör dir Trappsen" :) Und gerade Bitmapverarbeitung böte sich da als quasi Hybrid zwischen Bilddaten und allgemeinen Berechnungen geradezu an - nahezu alle Bitmap-Operationen lassen sich hervorragend parallelisieren *mundwässrigmach* ;)

[schwarzerlotus]

Moin zusammen

Zitat:

Zitat von jaenicke (Beitrag 1117318)

Wenn du an der Stelle einen Haltepunkt gesetzt hast, drückst du Strg + Alt + C. Dann kannst du auch assemblerbefehlsweise durch den Code laufen, falls gewünscht.

thx gut zu wissen

Zitat:

Zitat von FredlFesl (Beitrag 1117347)

Ist TGraphic32 nicht eine Option?

du meinst http://www.graphics32.org/wiki/ richtig? Hatte ich auch ausprobiert ist aber leider bei den Pixelzugriffen um den Faktor drei langsamer im Vergleich mit der Scanline Variante.

@Medium

CUDA steht auf jeden Fall auf dem Plan für die nächste Zeit und da wir den Vorteil haben unsere Hardware mit auszuliefern ... ;)

Danke an alle für die vielen Ideen und Anregungen

[jaenicke]

Zitat:

Zitat von schwarzerlotus (Beitrag 1117416)

CUDA steht auf jeden Fall auf dem Plan für die nächste Zeit und da wir den Vorteil haben unsere Hardware mit auszuliefern ... ;)

CUDA ginge dann ja nur mit NVidia, OpenCL (oder auch Direct Compute Shader) gehen unabhängig davon:
https://code.google.com/p/delphi-opencl/