So I've been doing some playing around recently, and noticed that while FillChar has some very fast internal code for initialising a block of memory, making use of non-temporal hints and memory fences, the versions for the larger types fall back to slow Pascal code. To showcase this, I ran a test on my 6-year-old laptop that compared a small and slightly basic assembler routine against the internal functions (times are averaged over 100 iterations):

FillWord - initialise 16,777,216 words to 0

- Internal: 8177.209 µs
- Assembler: 4234.131 µs

FillWord - initialise 1,048,576 words to $AAAA

- Internal: 153.221 µs
- Assembler: 86.496 µs

FillWord - initialise 1,229 words to $5555

- Internal: 0.267 µs
- Assembler: 0.135 µs

FillDWord - initialise 16,777,216 DWords to 0

- Internal: 15552.032 µs
- Assembler: 10945.809 µs

FillDWord - initialise 1,048,576 DWords to $AAAAAAAA

- Internal: 902.060 µs
- Assembler: 470.788 µs

FillDWord - initialise 1,229 DWords to $55555555

- Internal: 0.357 µs
- Assembler: 0.275 µs

FillQWord - initialise 16,777,216 QWords to 0

- Internal: 33397.248 µs
- Assembler: 17488.901 µs

FillQWord - initialise 1,048,576 QWords to $AAAAAAAAAAAAAAAA

- Internal: 2130.116 µs
- Assembler: 1258.130 µs

FillQWord - initialise 1,229 QWords to $5555555555555555

- Internal: 0.739 µs
- Assembler: 0.402 µs

The assembler functions were as follows:
    {$ASMMODE INTEL}
    procedure SizeOptimisedFillWord(var x; count: SizeInt; Value: Word); assembler; nostackframe;
    asm
      { RCX = Pointer to x
        RDX = Count
        R8W = Value }
      PUSH RDI
      MOV  AX,  R8W
      MOV  RDI, RCX
      MOV  RCX, RDX
      REP  STOSW
      POP  RDI
    end;
    procedure SizeOptimisedFillDWord(var x; count: SizeInt; Value: DWord); assembler; nostackframe;
    asm
      { RCX = Pointer to x
        RDX = Count
        R8D = Value }
      PUSH RDI
      MOV  EAX, R8D
      MOV  RDI, RCX
      MOV  RCX, RDX
      REP  STOSD
      POP  RDI
    end;
    procedure SizeOptimisedFillQWord(var x; count: SizeInt; Value: QWord); assembler; nostackframe;
    asm
      { RCX = Pointer to x
        RDX = Count
        R8  = Value }
      PUSH RDI
      MOV  RAX, R8
      MOV  RDI, RCX
      MOV  RCX, RDX
      REP  STOSQ
      POP  RDI
    end;

I also made versions that use memory fences and other checks such as memory alignment in order to gain speed
- I've converted them to use the System V ABI of Linux as well, but are currently completely untested as I don't have the facilities to yet compile on Linux (they are also even smaller in code size because you don't need to push and pop RDI, and the destination (var x) is already stored in RDI, thereby collapsing each routine to just 3 instructions (not including the REP prefix)).

Would it be worth opening up a bug report for this, with the attached assembler routines as suggestions? I haven't worked out how to implement internal functions into the compiler yet, and I rather clear it with you guys first before I make such an addition. I had a thought that the simple routines above could be used for when compiling for small code size, while larger, more advanced ones are used for when compiling for speed.

Yours faithfully,

J. Gareth "Kit" Moreton

Am 01.11.2017 05:58 schrieb "J. Gareth Moreton" :

Would it be worth opening up a bug report for this, with the attached assembler routines as suggestions? I
haven't worked out how to implement internal functions into the compiler yet, and I rather clear it with you
guys first before I make such an addition. I had a thought that the simple routines above could be used for
when compiling for small code size, while larger, more advanced ones are used for when compiling for speed.

Improvements like these are always welcome. Two points however: The Fill* routines are not part of the compiler, but of the RTL (the Pascal routines are in rtl/inc/generic.inc, the assembly ones reside in rtl/CPU/CPU.inc) and they aren't handled differently depending on the current optimization flags, so a one-size-fits-all is needed ( i386 ones). I also think that you might need to handle memory that isn't correctly aligned for the assembler instructions (I didn't look at your routines in detail so I don't know whether they'd need to be adjusted for that). A check of the i386 routines will probably help here as well.

Regards,
Sven

Yes, for sure.

I haven't worked out how to implement internal functions into the compiler yet,

Fill* are not internal functions, so you just have to adapt the system unit.

and I rather clear it with you guys first before I make such an addition. I had a thought that the simple routines above could be used for when compiling for small code size, while larger, more advanced ones are used for when compiling for speed.

I would provide only one version, after all, Fill* is only a very small part of the rtl, so shaving off a few bytes here does not matter and we are not in a 1k contest :)

Another important thing to note is that all modifications to stack pointer and nonvolatile registers on x86_64 need SEH annotations in win64 and CFI annotations on linux/bsd. The former is available only in AT&T syntax, the latter is not supported.
This requierment, together with different parameter locations, makes writing assembler routines for x86_64 much more complicated than for i386. For this reason, existing assembler routines in RTL avoid using nonvolatile registers as much as possible. Regards,
Sergei

J. Gareth Moreton wrote

So I've been doing some playing around recently, and noticed that while FillChar has some very fast internal code for initialising a block of memory, making use of non-temporal hints and memory fences, the versions for the larger types fall back to slow Pascal code.

It might be worth it to look at the Pascal versions from generic.inc first, and see if it is possible to come up with versions that generate faster code.

I'm actually surprised "REP STOSD" should be that much faster. I remember it being slower on modern platforms than it used to be?