Hi everyone,
This is something that sprung to mind when thinking about code speed and
the like, and one thing that cropped up is the initialisation of large
variables such as arrays or records. A common means of doing this is, say:
FillChar(MyVar, SizeOf(MyVar), 0);
To keep things as genera
Hi,
it could always inline it.
For small sizes do that mov and for large sizes do rep stosb on x86. It
is very fast nowadays. Faster than FillChar on my Intel laptop. (except
for mid sizes like 128 bytes)
Bye,
Benito
On 16.04.22 01:26, J. Gareth Moreton via fpc-devel wrote:
Hi everyone,
T
Benito van der Zander via fpc-devel
schrieb am Sa., 16. Apr. 2022, 15:43:
> Hi,
>
> it could always inline it.
>
> For small sizes do that mov and for large sizes do rep stosb on x86. It is
> very fast nowadays. Faster than FillChar on my Intel laptop. (except for
> mid sizes like 128 bytes)
>
F
J. Gareth Moreton via fpc-devel schrieb am
Sa., 16. Apr. 2022, 01:33:
> Actual Pascal calls to FillChar would not change in any way and so
> theoretically it won't break existing code. The only drawback is that
> the intrinsic and the internal System functions would have to be named
> the same s
On 4/16/22 16:41, Sven Barth via fpc-devel wrote:
Benito van der Zander via fpc-devel
schrieb am Sa., 16. Apr. 2022, 15:43:
Hi,
it could always inline it.
For small sizes do that mov and for large sizes do rep stosb on
x86. It is very fast nowadays. Faster than FillChar on my
Hi,
FillChar is on most platforms an assembly function and FPC *never*
inlines assembly functions.
even without inlining, rep stosb is faster than FillChar:
{$asmmode intel}
procedure repfillchar(var buffer; len: sizeuint; c: byte);
begin
asm
mov al, c
mov rdi, buffer
mov rcx,
> Am 16.04.2022 um 01:26 schrieb J. Gareth Moreton via fpc-devel
> :
>
> Hi everyone,
>
> This is something that sprung to mind when thinking about code speed and the
> like, and one thing that cropped up is the initialisation of large variables
> such as arrays or records. A common means
It's funny - for some reason I was expecting a lot of opposition!
I knew about FillChar being written in assembly langauge and know from
experience that FPC will never support the inlining of pure assembler
routines (as Florian said, it will just open a huge can of worms). My
thought was how
Florian Klämpfl via fpc-devel schrieb am
Sa., 16. Apr. 2022, 21:00:
>
>
> > Am 16.04.2022 um 01:26 schrieb J. Gareth Moreton via fpc-devel <
> fpc-devel@lists.freepascal.org>:
> >
> > Hi everyone,
> >
> > This is something that sprung to mind when thinking about code speed and
> the like, and one
On 17/04/2022 09:59, Sven Barth via fpc-devel wrote:
But we should have a general mechanism for that, not something that
just handles FillChar.
Regards,
Sven
I do agree - I don't like hard-coded literals like that for handling
special cases.
Gareth aka. Kit
--
This email has been checked
If you want to zero small records more efficiently it might be better using
Default(t) for that and looking at optimizing the code the compiler generates
for that as it seems it produces an empty temp variable which it assigns
instead of simply zeroing the record variable where default() is bein
Stefan Glienke via fpc-devel schrieb am
Di., 19. Apr. 2022, 12:38:
> If you want to zero small records more efficiently it might be better
> using Default(t) for that and looking at optimizing the code the compiler
> generates for that as it seems it produces an empty temp variable which it
> ass
You are the expert but I am not sure how that can be the case given you only
need to zero a register and blast that into the record location opposed to
twice as many mov operations being generated that I have seen with the record
that Gareth originally posted.
> On 19/04/2022 13:37 Sven Barth v
Interesting - I wasn't aware of this intrinsic! I'll make a note of
that one.
It might be useful to transform FillChar calls to the Default intrinsic
at the node level.
Gareth aka. Kit
On 19/04/2022 12:43, Stefan Glienke via fpc-devel wrote:
You are the expert but I am not sure how that ca
I would rather give a hint to change the code - because only for unmanaged
types the semantic of FillChar is equal to default().
As for performance - I just ran some benchmarks comparing the way FPC does it
and how Delphi does it. xor a register and mov that into place (Delphi way) is
faster in
At least for me, I think most programmers know not to use FillChar to
fill a managed type, but it is a good point to be careful.
Zeroing a register and moving it into a block is usually the fastest way
to go about such things, but FillChar doesn't assume the input is zero,
whereas if it were t
16 matches
Mail list logo
