Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: anton@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.arch
Subject: Re: rep movsb vs. simpler instructions for memcpy/memmove
Date: Fri, 14 Mar 2025 13:18:37 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 68
Message-ID: <2025Mar14.141837@mips.complang.tuwien.ac.at>
References: <vpufbv$4qc5$1@dont-email.me> <20250312140915.000010a8@yahoo.com> <2025Mar12.174636@mips.complang.tuwien.ac.at> <a296144c60c9774898235f505bc4c370@www.novabbs.org> <jwvy0x93vb5.fsf-monnier+comp.arch@gnu.org> <61cab9791f342672dcbd5dfd539cc5cc@www.novabbs.org> <jwv7c4s3n4d.fsf-monnier+comp.arch@gnu.org> <3104c2ab707086659d698a0377450527@www.novabbs.org> <20250313225516.00004206@yahoo.com> <5jIAP.61128$Xq5f.38323@fx38.iad> <20250314001619.000004fa@yahoo.com>
Injection-Date: Fri, 14 Mar 2025 14:39:43 +0100 (CET)
Injection-Info: dont-email.me; posting-host="71f0ca78e009fc0d53b10449285317a3";
	logging-data="1320613"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX184P3946jRzT8jlWO/TkwLg"
Cancel-Lock: sha1:Qc9LMq8+OwcjZt0XhXgCai+n8TA=
X-newsreader: xrn 10.11
Bytes: 4151

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,
>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.

The usual case where "from" is memory-mapped I/O and "to" is
cache-coherent is when loading from an NVME SSD.  AFAIK this is
usually done in larger block sizes, because of the overhead of setting
up the DMA, and is usually done in an asynchronous way.

As for the wrong level: The DMA engine transfers the data to the CPU
chip in any case: it contains all caches and the DRAM controller.  It
might put the data in, e.g., L3 cache, marked dirty, for later
writeback to DRAM, and if a CPU accesses that memory soon, it will
only see the latency and bandwidth limits of L3.

I have certainly read about a project for high-speed network routing
where the network cards deliver the packets to L3, and the routing
software has to process each packet in an average of 70ns; if the
packets were delivered to DRAM, that speed would be impossible.

As for the "transfer level speed", I would not know why delivering to
DRAM should be faster than delivering to L3, L2, or L1.  On the
contrary, it seems to me that delivering to DRAM is at least as slow
as the other variants.

In any case, that's not what most uses of memcpy() or memmove(), or
rep movsb with their synchronous interfaces are about.

>> >> 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.

It does not happen in practice, so making it fast or "optimal" by
using a prediction is not necessary.

- anton
-- 
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
  Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>