[Delphi/ assembler] stukje code optimaliseren

[Tomatoman]

Ik heb in Delphi code geschreven die checksums uitrekent van een TrueType font file. Op zich werkt dat allemaal prima, maar de code kan vast wel wat sneller worden.

Het lullige van TrueType fonts is dat de byte-volgorde van de Mac afkomstig is en dus precies omgekeerd is aan de byte-volgorde van een pc. Om de (32-bits) checksum te berekenen, moet ik daarom een paar miljoen keer vier bytes van plaats verwisselen. Dat doet de volgende functie:

code:

  TBigLongword = packed record // 32-bit unsigned integer
    HiWordHiByte: Byte;
    HiWordLoByte: Byte;
    LoWordHiByte: Byte;
    LoWordLoByte: Byte;
  end;

function BigLongwordToLongword(const BigLongword: TBigLongword): Longword;
begin
  Result := (BigLongword.HiWordHiByte shl 24) or
    (BigLongword.HiWordLoByte shl 16) or
    (BigLongword.LoWordHiByte shl 8) or
    BigLongword.LoWordLoByte;
end;

Delphi maakt dit ervan:


Hoe kan ik deze functie een stuk sneller maken?

[Verwijderd]

Niet veel in ieder geval. De delphi compiler maakt in ieder geval redelijk geoptimaliseerde code. Je zou range-checking e.d. uit kunnen zetten bij compiler opties.

[Gerco]

-- [hier stond iets doms] --

[marcusk]

ipv 00464DB3-00464DBD:

code:

mov dh,[ebp-$03]
or edx,[ebp-$02]

lijkt mij sneller.

en 00464DCC-00464DCF lijken me een beetje nutteloos. dit dus:

code:

mov [ebp-$08],eax
mov eax,[ebp-$08]

[Verwijderd]

1) je moet die or's eruit zien te krijgen
2) geen functie gebruiken, maar inline zetten (of procedure als het niet anders kan)

[.oisyn]

bswap gebruiken, daar is die instructie voor bedoeld

code:

bswap eax

[marcusk]

hehe , das wel iets simpeler

[Verwijderd]

Op zondag 09 juni 2002 00:25 schreef .oisyn het volgende:
bswap gebruiken, daar is die instructie voor bedoeld

code:

bswap eax

ik kwam hem net tegen:

code:

function IntSwap(Source: Integer): Integer;
asm
  bswap eax
end;

[Tomatoman]

Bedankt allemaal, het gaat erop lijken . Inmiddels heb ik zelf voor het eerst van mijn leven een stukje assembler code geschreven en ben ik tot het volgende gekomen:

code:

function BigLongwordToLongword(const BigLongword: TBigLongword): Longword;
asm
  rol     ax,8      { swap LoWordHiByte and LoWordLoByte }
  shld    eax,eax,16    { swap (unaltered) HiWord and (altered) LoWord }
  rol     ax,8      { swap HiWordHiByte and HiWordLoByte }
end;

Dat scheelt al heel wat clock cycles. Ik heb het even uitgerekend.

code:

OUDE CODE:              |  NIEUWE CODE:
                      |
coderegel      clock cycles  |  coderegel      clock cycles
=========      ============  |  =========      ============
begin                11  |  asm               0
Result := [...]      50  |  [rol, shld, rol]     3+3+3=  9
end;                22  |  end;             12
                 _____  |                  _____
totaal              83  |  totaal               21

Da's bijna 75% tijdwinst . Maarreh, die bswap ken ik niet (hij zal wel bloedsnel zijn). Ik gebruik deze handleiding en daar staat 'ie niet in. Is bswap een nieuwe operator? En wat betekent dat als iemand mijn programma op een prehistorische 386 gebruikt?

[marcusk]

bswap werkt vanaf 486

[JayTaph]

Nog sneller is het natuurlijk om hiervan geen apartie functie te maken. Dat scheelt 1x een dword (of in het ergste geval 4x een byte) die gePUSHed moet worden, 1x een CALL naar de functie, 1x stack opzetten en 1x RETurn en 1x weer je stack decreasen. Waarbij vooral die PUSH, CALL en RET processortik-vreters zijn. Die kun je dus beter wegwerken dan een aantal xor'etjes meer of minder.

edit:

* JayTaph ziet nu 3 enge POP's in je debug-schermpje staan... over zonde van je tikken gesproken

[Tomatoman]

Op zondag 09 juni 2002 01:46 schreef JayTaph het volgende:
Nog sneller is het natuurlijk om hiervan geen apartie functie te maken. [...]

Helemaal mee eens, eigenlijk had ik het al zo geïmplementeerd. Maar om het topic een beetje overzichtelijk te houden, heb ik er een aparte functie van gebouwd.

BTW, via Google vond ik de volgende quote over bswap:

On the 80486, this instruction takes one clock cycle during execution.

Lijkt me moeilijk om dit nog te overtreffen.