Re: rep movsb vs. simpler instructions for memcpy/memmove

On Thu, 13 Mar 2025 22:16:19 +0000, Michael S wrote:

On Thu, 13 Mar 2025 21:42:25 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
>

Michael S <already5chosen@yahoo.com> writes:

On Thu, 13 Mar 2025 19:35:33 +0000
mitchalsup@aol.com (MitchAlsup1) wrote:
>

>
And they have "So Many" extra burdens, such as when from is MMI/O
space access and to is cache coherent, and all sorts of other self
imposed problems.

>
This case is pretty useful in practice.

>
Although mostly done with DMA controllers in these modern times
to offload from the CPU.
>

>
For up to few hundreds bytes it would be slower. For few thousands byte
it could be faster at transfer level, but data ends up in the wrong
place in the memory hierarchy, too far away from the ultimate consumer,
so still slower from the "full job done" perspective.
And CPU time that you "saved" by offload is almost always just uselessly
wasted in idle loop.
>

>

Using MTRRs one can switch the kind of memory
to and from point in the middle of a REP MOVs.

>
How exactly?

>
The REP MOV straddles the boundary between two MTRRs.
>

>
Crossing boundary that way can typically be predicted far in advance,
so not really big problem.
I think, Mitch had something less mundane in mind.

I was just trying to illustrate why optimal REP-MOVS is more difficult
than a SW person might initially guestimate.
One side might be a byte array down PCIe tree in config space,
while the destination is a line access only. Yeah, just try to
do this optimally.
Since MM is available in the interconnect protocol, one could
imagine one PCIe device transferring a page to another PCIe
device without the data stream ever touching DRAM (or L3).
Yeah, just try doing that with MTRRs and system MMUs in the
way. ...