Re: memcpy and friend (was: 80286 protected mode)

On 15/10/2024 13:55, Michael S wrote:

On Tue, 15 Oct 2024 13:20:31 +0200
David Brown <david.brown@hesbynett.no> wrote:
 

>
It means "scalable".  The idea is that the same binary code will use
different stride sizes on different hardware - a bigger
implementation of the core might have vector units handling wider
strides than a smaller one.  Am I missing something?
>

 In practice, it means that at any given implementation you have fixed
width.

Yes.  Or, more accurately, you have fixed maximum width.  If the final step doesn't use the full width, that's okay.

The spec does not say that width is equal to width of FP execution
engine, but it appears to be a case in all implementations so far (1
512-bit implementation from Fujitsu, 1 256-bit implementation from Arm
Inc, quickly de-emphasized and many 128-bit implementations from several
vendors).

In general I'd expect the maximum width per step to match that of the appropriate execution engines, yes.

'S' means that width-agnostic implementation of common algorithms, esp.
of Linear Algebra, is possible. Nobody promised that width-agnostic
would be as efficient as width-aware. Especially so in algorithms
that do little or no math. By chance, in case of memmove() we do want
to be very efficient.
 

Perhaps.  That is an issue of the quality of the SVE, rather than the principle of it.  I don't know about the details of real-world SVE implementations, but I see no reason why the maximum stride size should be the same for all SVE instructions.  An implementation that has a small cost-optimised floating point unit may have wider integer SVE strides or wider memory set/copy strides.

Also, you don't seem to understand an issue at hand, which is
exposing a hardware that aligns *stream* of N+1 aligned loads
turning it into N unaligned loads.
In absence of 'load multiple' instruction 128-bit SVE would help you
here no more than 128-bit NEON. More so, 512-bit SVE wouldn't help
enough, even ignoring absence of prospect of 512-bit SVE in
mainstream ARM64 cores.
May be, at ISA level, SME is a better base to what is wanted.
But
   - SME would be quite bad for copy of small segments.

>
I would expect a certain amount of overhead, which will be a cost for
small copies.
>

   - SME does not appear to get much love by Arm vendors others than
Apple

>
If you say so.  My main interest is in microcontrollers, and I don't
track all the details of larger devices.
>

   - SME blocks are expected to be implemented not in close
proximity to the rest of the CPU core, which would make them
problematic not just for copying small segment, but for
medium-length segments (few KB) as well.
  

>
That sounds like a poor design choice to me, but again I don't know
the details.
>

 That (i.e. implementation of SME as very powerful accelerator shared
by several cores) is an excellent design choice for what SME is invented
for - matrix multiplications and kernels that are similar to matrix
multiplication.
For that purpose it works very well on Apple chips, delivering lots of
FLOPs to single thread/core. Programmers like it, both because
single-threaded programming is easier than multi-threaded and because
when fewer cores are tied driving FPUs more cores left available for
something else.
To me it also sounds as very suitable choice for long memcpy/memmove,
i.e. for segments bigger than size of L1D$. But I am sure that it was
not a major consideration for Apple designers.