schnelstmöglich dividieren?

[Memnarch]

@AmateurProfi: Flächen ABC und Gesamt sind Integer, in diesem Beispiel waren die XYZ variablen die Farben also Bytes.

Bei den flächen kann ich schlecht auf kleinere größen ausweichen. 512*512/2 liegt soweit ich weiß über Shortint.

Whops glaube ich hab mich verschrieben Pro BildAufbau werden 786432 DIVs für die FARBEN gebraucht.
ZWert ist natürlich imo "nur" 262144 pro bildaufbau(eben pro pixel)

Obige DIV werte sind darauf ausgerechnet dass 2 Triangles so vor der Camera hocken, das jeder Pixel bedeckt ist und somit kalkuliert werden muss.

Aber vllt könnte ich pro 8*8 PixelZelle eines dreiecks die 4 ecken wie oben kalkulieren und im Quadrat anders(linear?) interpolieren.....ah mist muss eh wieder truncated werden >.<



MFG
Memnarch

[Medium]

Noch ein Stichwort frei in die Runde geschmissen: Multithreading
Bringt bei einem P4 wohl nicht die Welt, nur bei aktuellen Quadcores mit HT wär das sicherlich nett.

[Amateurprofi]

@Memnarch:

Ich hab das mal mit der FPU versucht, aber die Ergebnisse sind, gelinde gesagt, ernüchternd (etwa doppelte Rechenzeit vs. simplem Delphi-Code).
Sorry.
Ich hab auch über SSE3 nachgedacht, aber keinen vernünftigen Ansatz gefunden.

[Medium]

Irgendwann ist eben auch Schluss mit Optimierbarkeit auf unterster Ebene - irgendwo MUSS ja auch was berechnet werden . Daher eben auch unsere Vorschläge, an höhergelegenen Logiken noch was rauszuholen. Wenn es Z sein muss, und zwar per Pixel, wird man um was auch immer für eine Interpolation für jeden Pixel nicht herum kommen, und Interpolation sind Verhältnisrechnungen, und da steckt ja schon fast Sprachlich drin "duuu mussssst dividiiiieren". Oft auch Floatlastig, da gern Ranges von 0..1 genommen sind (wobei man da, wenn es nur linear bleibt, mittels Skalierung auch noch drum rum kommt meistens).
Es bleibt also nur zu gucken, wie man möglichst geschickt interpoliert, oder wie man im Vorfeld noch besser, noch mehr Notwendigkeit zur Interpolation gleich eliminiert. Oder man taucht in Parallelisierung ab (was aber so generell sicherlich sinnvoll ist, egal wie das hier ausgehen wird.)

[OldGrumpy]

@Amateurprofi: Hast Du denn auch die ganzen Constraints bzgl. Alignment usw. beachtet und die Daten optimal arrangiert? Wundert mich etwas, dass es "mit den neueren Opcodes" langsamer sein soll als mit dem "Oldschool" Delphi-Compiler

[Amateurprofi]

@OldGrumpy:

Das unten stehende war mein Versuch.

Ausschließlich mit der FPU zu arbeiten hat außer deutlicher Verschlechterung nichts gebracht.
Vielleicht bringt eine gemische Lösung etwas, z.B. alle Multiplikationen und Additionen in den
'normalen' Registern machen und nur die Divisionen mit der FPU.
Ich glaube aber nicht, daß das was bringt. Der, wie du sagst, "Oldschool" Delphi-Compiler schafft es im 31 CPU-Ticks, und das ist für mein Verständnis verdammt flink.

Kannst es ja mal versuchen, ob eine andere Anordnung der Variablen, oder ein anderer Ablauf eine bessere Zeit bringt.

Delphi-Quellcode:

var
   wert,a,b,c,x,y,z,ergebnis,x2,y2,z2,ergebnis2,x3,y3,z3,ergebnis3:integer;

FUNCTION TimeStamp:int64;
asm
   rdtsc
end;

PROCEDURE Test1;
begin
   Ergebnis := (A*x + B*Y + C*Z) div Wert;
   Ergebnis2 := (A*x2 + B*Y2 + C*Z2) div Wert;
   Ergebnis3 := (A*x3 + B*Y3 + C*Z3) div Wert;
end;

PROCEDURE Test2;
asm
   fild   wert
   fild   a
   fild   b
   fild   c
   fild   x
   fmul   st,st(3)
   fild   y
   fmul   st,st(3)
   faddp
   fild   z
   fmul   st,st(2)
   faddp
   fdiv   st,st(4)
   fistp  ergebnis
   fild   x2
   fmul   st,st(3)
   fild   y2
   fmul   st,st(3)
   faddp
   fild   z2
   fmul   st,st(2)
   faddp
   fdiv   st,st(4)
   fistp  ergebnis2
   fild   x3
   fmulp  st(3),st
   fild   y3
   fmulp  st(2),st
   fild   z3
   fmulp
   faddp
   faddp
   fdivrp
   fistp  ergebnis3
end;

PROCEDURE TestPerformance;
const count=100;
var priorityclass,priority:integer; samask,pamask,tamask:cardinal;
    t0,t1,t2,tts:Int64; i:integer;
begin
   GetProcessAffinityMask(GetCurrentProcess,pamask,samask);
   if pamask=0 then exit;
   tamask:=1;
   while tamask and pamask=0 do tamask:=tamask shl 1;
   SetThreadAffinityMask(GetCurrentThread,tamask);
   priorityclass:=GetPriorityClass(GetCurrentProcess);
   priority:=GetThreadPriority(GetCurrentThread);
   SetPriorityClass(GetCurrentProcess,REALTIME_PRIORITY_CLASS);
   SetThreadPriority(GetCurrentThread,THREAD_PRIORITY_TIME_CRITICAL);
   // Etwas einheizen
   for i:=1 to 100000000 do;
   // Feststellen wieviel Ticks TimeStamp braucht
   tts:=High(int64);
   for i:=1 to count do begin
      t0:=TimeStamp;
      t0:=TimeStamp-t0;
      if t0<tts then tts:=t0;
   end;
   // Ticks für Routine 1
   t1:=High(int64);
   for i:=1 to count do begin
      t0:=TimeStamp;
      Test1;
      t0:=TimeStamp-t0;
      if t0<t1 then t1:=t0;
   end;
   dec(t1,tts); // Zeit für TimeStamp abziehen
   // Ticks für Routine 2
   t2:=High(int64);
   for i:=1 to count do begin
      t0:=TimeStamp;
      Test2;
      t0:=TimeStamp-t0;
      if t0<t2 then t2:=t0;
   end;
   dec(t2,tts); // Zeit für TimeStamp abziehen
   SetThreadPriority(GetCurrentThread,priority);
   SetPriorityClass(GetCurrentProcess,priorityclass);
   SetThreadAffinityMask(GetCurrentThread,pamask);
   ShowMessage(IntToStr(t1)+'  '+IntToStr(t2)+'  '+IntToStr(t1-t2));
end;

PROCEDURE TMain.Test;
begin
   a:=12345;
   b:=23456;
   c:=34567;
   x:=12;
   y:=13;
   z:=14;
   x2:=123;
   y2:=123;
   z2:=125;
   x3:=234;
   y3:=235;
   z3:=236;
   wert:=37;
   testperformance;
end;

[Memnarch]

@Bjoerk: Dir ist schon klar, dass ich mein momentanes Programm auf nem P4 3GHZ im MT Modus ausführe?(Somit nur 1.5GHz wegen virtuellem kern).

@Amateurprofi:
Habe schonmal nen Mix versucht, das Resultat war auch ernüchtenrd. Da die CPU immerwieder in die FPU wechseln muss, nimtm schonalleine diese umstellung in meinder anwendung mehr weg als wenn ich einfach nur stumpf dividieren würde.