schnelstmöglich dividieren?

[Memnarch]

ACH MIST,
ja lag daran dass ich zu kleine werte eingegeben hatte. Je größer die werte sind, umso ungenauer wird es >.<.

€dit: Zeitlich aber weiterhin dasselbe.

[gammatester]

Hier ein Beispiel (Anzeigewert ist jeweils 12345):

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var
  res,test, wert, iwert: longint;
begin
  wert := 10000;
  iwert := (int64(1) shl 32) div wert;
  test := 123456789;
  ShowMessage('Div: '+inttostr(test div wert));
  asm
    mov  eax,[test]
    mul  [iwert]
    mov  [res],edx
  end;
  ShowMessage('Mul: '+inttostr(res));
end;

[Memnarch]

WOW klasse.
Mit dieser Methode ist meine spitzen fps von 28-30 auf 52(!!) gestiegen. Ich wusste doch dass die divs und die float/int das waren. Klasse :).

MFG
Memnarch

[Amateurprofi]

@gammatester:
Funktioniert einwandfrei. Mal wieder was dazugelernt.

[bit4bit]

Sorry, da hatte ich einen Flüchtigkeitsfehler drin. :oops:

Delphi-Quellcode:

PROCEDURE Test1;
var Wert2 : Integer;
begin
   Wert2 := Integer((Int64(1) shl 32) div Wert);  { <<<------ war falsch }
   Ergebnis := Integer(((A*x + B*Y + C*Z) * Wert2) shr 32);
   Ergebnis2 := Integer(((A*x2 + B*Y2 + C*Z2) * Wert2) shr 32);
   Ergebnis3 := Integer(((A*x3 + B*Y3 + C*Z3) * Wert2) shr 32);
end;

Ich benutze einfach nur die Nachkommastellen einer Binärzahl, die 32 bit vor,
und 32 bit nach dem Komma hat. Also 2^32 entspricht der 1 ( =2^0 ).
Wenn ich 2^32 div Wert rechne, hab ich vor dem gedachten Binärkomma immer 0
stehen (Jedenfalls bei den Werten, die hier infrage kommen).
Ich benutze also zur Multiplikation immer nur die 32 bit nach dem Binärkomma
und weiß, dass mein Ergebnis um den Faktor 2^32 zu hoch ist.
Durch die Verwendung von EDX nach der Multiplikation kann ich mir ein "shr 32"
sparen.

Das Ganze würde natürlich auch mit 2^16 klappen, das Ergebnis kann ja nur 8 bit
haben! Wäre aber nur mit 16 bit Arithmetik praktisch. Das Ergebniss wär dann
eben in DX .

@gammatester

Meine Idee ist im Prinzip so, wie du sie umgesetzt hast. Wenn jetzt noch alle
Variablen als Integer definiert werden, wird’s bestimmt schneller.

@Memnarch

Wenn Du linear äquidistant interpolierst gibt’s nix schnelleres als den Bresenham-
Algorithmus. Funktioniert ja nicht nur bei x/y Koordinaten, sondern auch x/r ,
x/g und x/b . Er ist sehr genau und sehr schnell, da nur Additionen und
Subtraktionen vorkommen.
Es gibt in der Literatur eine Menge an Vorschlägen für seine Optimierung.

Tuning Tip:
Vermeide unbedingt Unterprogramme, Sprünge ( if ... then ... else ) und Schleifen
( for , while , until ) wo immer das geht. Die heutigen CPUs haben sehr lange
execution pipelines und trotz sehr aufwändiger branch prediction geht dabei immer
noch eine Menge an cycles verloren um die pipelines neu zu laden.

Wenn Du irgendwann mal ein wenig von Deinem Code zeigst, können wir Dir bestimmt
noch ein paar Tips geben, wo noch was zu holen ist!

Viel Spaß, bit4bit

[Memnarch]

@Bit4Bit: Den code kann ich leider nciht zeigen. Den habe ich während der Arbeitszeit geschrieben, und ist somit unter Verschluss. Wenn ich das ganze hier zuhause nochmal schreibe, werd ichs mal posten, aber zuhause momentan beschäftigt mit anderen programmen^^


MFG
Memnarch

[Memnarch]

Entshculdigt ich bins nochmal:

@Bit4Bit: in einem der vorherigen Posts hatte ich einen Formelbuffer erähnt. Dabei hatte ich gedacht, dass ich im Ratserizer nicht mehr direkt die Pixel(Farben) berechne, sondern lediglich in einen Buffer pro pixel abspeichere, was ich für den jeweiligen Pixel berechnen muss(also die zahlenwerte). Sobald der Rasterizer durchgelaufen ist, nudel ich dan einfach alle berechnungen des Buffers Durch. Der vorteil wäre, dass ich die Farbwerte eines Pixels 100% niemals doppelt berechne. Eine formel kann bei schlechter sortierung höchstens mehrfach überschrieben werden.

MFG
Memnarch