Re: [PATCH 3/6] newlib: mem[p]cpy/memmove improve performance for optimized versions

On Jan 28 16:33, Richard Earnshaw (lists) wrote:
> On 28/01/2025 16:11, Corinna Vinschen wrote:
> > On Jan 27 10:45, Alexey Lapshin wrote:
> >> This change improves performance on memory blocks with sizes in range
> >> [4..15]. Performance measurements made for RISCV machine (memset):
> >>
> >> size  4, CPU cycles change: 50 -> 37
> >> size  5, CPU cycles change: 57 -> 40
> >> size  6, CPU cycles change: 64 -> 47
> >> size  7, CPU cycles change: 71 -> 54
> >> size  8, CPU cycles change: 78 -> 44
> >> size  9, CPU cycles change: 85 -> 47
> >> size 10, CPU cycles change: 92 -> 54
> >> size 11, CPU cycles change: 99 -> 61
> >> size 12, CPU cycles change: 106 -> 51
> >> size 13, CPU cycles change: 113 -> 54
> >> size 14, CPU cycles change: 120 -> 61
> >> size 15, CPU cycles change: 127 -> 68
> > 
> > But is that generally true for other architectures as well?
> > 
> 
> No, it can be very dependent on the microarchitecture.  I know of Arm
> implementations where it would be better and implementations where it
> would be (much) worse.

Ok, we're talking about the case that memcpy runs the optimization based
on the fact that the size of the block to copy is at least sizeof(long)
vs. at least sizeof(long)*4, while the check for being aligned is based
on sizeof(long) alone.  So assuming sizeof(long) is 4, the optimization
doesn't kick in for blocks < 32 bytes right now, while Alexey's change
allows to run the optimization even for 4 byte blocks.

As I understand it, the additional length checks in the optimizing code
*may* have a bigger performance hit than the time saved by copying 4
bytes at once rather than bytewise.

Alexey's test above show that even for a 4 byte copy, optimizing still
has a performance boost compared to a bytewise copy on RISCV.

This part is interesting.  Do we really have a supported architecture,
where one additional `while (len0 >= BIGBLOCKSIZE)' check has such an
impact, that running the optimizing code is worse than a byte copy for
small, but aligned blocks?

> The other variable is that for misaligned
> copies there's a choice of bringing the source data to alignment or
> the target data (you really don't want to do a large copy with both
> misaligned).  That can also vary by micro-architecture.

Yeah, but our simple fallback memcpy doesn't try to align, it just
runs the optimizing copde block if both blocks are already aligned
on input.  Alexey's patch doesn't change this.

> But we have custom assembler versions for Arm, so it probably doesn't
> matter for us, except at -Os

-Os isn't affected because it runs the PREFER_SIZE_OVER_SPEED code
which only does byte copy anyway.


Corinna