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

On Thu, 13 Mar 2025 23:27:16 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:

Michael S <already5chosen@yahoo.com> writes:

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, 

 
Most systems I work with have an 'allocate' attribute on
inbound DMA operations that will allocate in a specified
cache level (typically LLC).
 
Most DMA's are far more a hundred bytes, and the application
can be doing something else while the DMA is in process.
 
 

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. 

 
Only by incompetent programmers.

It has nothing to do with competence of programmers and everything to
do with modern computers having more cores than their users need.
This applies not only to client system but to at least 3/4th of the
servers as well.