Einzelnen Beitrag anzeigen

Benutzerbild von negaH
negaH

Registriert seit: 25. Jun 2003
Ort: Thüringen
2.950 Beiträge
 
#5

Re: Performance Inline Assembler vs. Objekt Pascal

  Alt 19. Nov 2003, 14:34
Also fangen wir mal an zu optimieren. Das erste was wir dabei machen ist DENKEN

Dein Code multipliziert jeweils einen 8 Bit Farbwert mit einem Double Wert. Ist das überhaupt nötig ?? Würde ein Menschliches Auge einen Unterschied bemerken wenn die Funktion nicht ganz exakt rechnet ??

Also die Floatingpoint Operationen müssen raus und durch Integer Operationen ersetzt werden.

Kritisch auf heutigen CPU's ist die Feststellung das diese CPU so clever konstruiert wurden das sie zukünftige Speicherzugriffe schon vor der Ausführung von Code erkennen kann. Zwangsläufig ergibt sich daraus das man Speicherzugriffs-Operationen als Block von Befehlen staffeln sollte und reine Registerberechnungen ebenfalls staffeln sollte. D.h. erst werden die Daten per Speicherzugriff in soviele Register wie möglich geladen, und danach mit den Registern gerechnet, und abschließend die Daten wieder gespeichert. Es ist also sinnvoller lieber in Register geladene Daten umzuordnen, als sie Byte für Byte zu laden. Der 2. Block mit den Berechnungen kann dann so gecodet werden das man voneinander unabhänige Berechnungen durchführen kann. Dies nennt man Instrctionshuffling und bewirkt das die CPU sozusagen Befehle in paralell abarbeiten kann. Alle neueren CPU's haben mehrere Pipelines, in denen sozusagen mehrere Instruktionen paralell dekodiert und ausgeführt werden können. Der Unterschied zu Multi-CPU-Rechnern ist aber das diese Piplines nur abhänig von den verwendeten Instruktionen tatsächlich parallel arbeiten können. D.h. nicht jede Reiehenfolge von Instruktionen im Code kann parallel ausgeführt werden !

Nun, wenn wir davon ausgehen das in einer Scanline einer 24Bit Bitmap jeweils RGB Bytes stehen, und wissen das jede Scanline einer Windowsbitmap immer ein Vielfaches von 4 Bytes ist, egal wieviele Pixel in der Scanline stehen, dann wissen wir auch das ein 4 Bytes Speicherzugriff auf die RGB Farbwerte absolut legal ist. Man lädt also in EAX alle 4 RGB Werte in einem Rutsch und "entschlüsselt" sie dann von Register zu Register.

Oder besser noch: wenn wir wissen das das MMX Feature der CPU's exakt dafür konstruiert wurde die RGB Werte eines Speicherbereiches in parallel zu benutzen, dann ist es besser den Source gleich in MMX zu coden.

Suche mal nach den Graphics32 Komponenten im WEB, diese enthalten schon solchen Assembleroptimierten Code.

Gruß hagen
  Mit Zitat antworten Zitat