blocks|key|169491|text|不太可能。您的编译器/标准库可能会有一个非常高效且量身定制的memcpy实现。而memcpy基本上是将内存的一部分复制到另一部分的最低api。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|169492|如果你想进一步加速，找到一种不需要任何内存复制的方法。|169493|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Unlikely. Your compiler/standard library will likely have a very efficient and tailored implementation of memcpy. And memcpy is basically the lowest api there is for copying one part of memory to another.

If you want further speedups, find a way to not need any memory copying.

blocks|key|169990|text|首先，给你一句忠告。假设编写您的标准库的人并不愚蠢。如果有更快的方法来实现一个通用的memcpy，他们早就这么做了。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|169991|其次，是的，还有更好的选择。|169992|169993|在C%2B%2B中，使用std::copy函数。它做同样的事情，但它1)更安全，2)在某些情况下可能更快。它是一个模板，这意味着它可以专门针对特定的类型，这使得它可能比一般的C+memcpy.|unordered-list-item|offset|length|style|CODE|169994|更快，或者，您可以使用您对特定情况的高级知识。memcpy的实现者必须编写它，以便它在任何情况下都能很好地执行。如果您有关于需要它的情况的特定信息，您可能能够编写一个更快的版本。例如，您需要复制多少内存？它是如何对齐的？这可能会让您为这个特定的情况编写一个更有效的memcpy。但在大多数其他情况下(如果它可以工作的话)|169995|就不会那么好了|169996|entityMap^0|0|0|0|8|9|0|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|T|8|@]|9|@]|A|$]]|$1|E|3|F|5|G|7|U|8|@$H|V|I|W|J|K]]|9|@]|A|$]]|$1|L|3|M|5|G|7|X|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|Y|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|Q|$]]

First, a word of advice. Assume that the people who wrote your standard library are not stupid.
If there was a faster way to implement a general memcpy, they'd have done it.

Second, yes, there are better alternatives.

<ul>
<li>In C++, use the <code>std::copy</code> function. It does the same thing, but it is 1) safer, and 2) potentially faster in some cases. It is a template, meaning that it can be specialized for specific types, making it potentially faster than the general C memcpy.</li>
<li>Or, you can use your superior knowledge of your specific situation. The implementers of memcpy had to write it so it performed well in every case. If you have specific information about the situation where you need it, you might be able to write a faster version. For example, how much memory do you need to copy? How is it aligned? That might allow you to write a more efficient memcpy for this specific case. But it won't be as good in most other cases (if it'll work at all)</li>
</ul>

blocks|key|169595|text|优化专家Agner+Fog发布了优化内存函数：http://agner.org/optimize/#asmlib。不过，它是在GPL之下的。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|169596|前段时间，阿格纳说这些函数应该取代GCC的内置函数，因为它们的速度要快得多。我不知道从那以后是否有人这么做过。|169597|entityMap|0|LINK|mutability|MUTABLE|url|http://agner.org/optimize/#asmlib^0|N|X|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]]|C|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]]]

Optimization expert Agner Fog has published optimized memory functions: <a href="http://agner.org/optimize/#asmlib" rel="noreferrer">http://agner.org/optimize/#asmlib</a>. It's under GPL though.

Some time ago Agner said that these functions should replace GCC builtins because they're a lot faster.
I don't know if it's been done since then.

blocks|key|4430575|text|对于一个非常相似的问题(关于memset())，这个答案也适用于这里。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|4430576|4430577|clearing+a+small+integer+array:+memset+vs.+for+loop|unordered-list-item|4430578|4430579|它基本上是说，编译器为memcpy()/memset()生成一些非常优化的代码-根据对象的性质(大小、对齐方式等)而生成不同的代码。|4430580|记住，在C%2B%2B中只有memcpy()+PODs。|4430581|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/1134103/clearing-a-small-integer-array-memset-vs-for-loop/1134147#1134147^0|E|8|0|0|0|1F|0|0|0|B|8|K|8|0|A|8|0^^$0|@$1|2|3|4|5|6|7|W|8|@$9|X|A|Y|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|Z|8|@]|D|@]|E|$]]|$1|G|3|H|5|I|7|10|8|@]|D|@$9|11|A|12|1|13]]|E|$]]|$1|J|3|-4|5|6|7|14|8|@]|D|@]|E|$]]|$1|K|3|L|5|6|7|15|8|@$9|16|A|17|B|C]|$9|18|A|19|B|C]]|D|@]|E|$]]|$1|M|3|N|5|6|7|1A|8|@$9|1B|A|1C|B|C]]|D|@]|E|$]]|$1|O|3|-4|5|6|7|1D|8|@]|D|@]|E|$]]]|P|$Q|$5|R|S|T|E|$U|V]]]]

This answer for a very simiar question (about <code>memset()</code>) applies to here, too.

<ul>
<li><a href="https://stackoverflow.com/questions/1134103/clearing-a-small-integer-array-memset-vs-for-loop/1134147#1134147">clearing a small integer array: memset vs. for loop</a></li>
</ul>

It basically says that compilers generate some very optimal code for <code>memcpy()</code>/<code>memset()</code> - and different code depending on the nature of the objects (size, alignment, etc).

And remember, only <code>memcpy()</code> PODs in C++.

blocks|key|4430886|text|为了找到或编写一个快速的内存复制例程，我们应该了解处理器是如何工作的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4430887|从英特尔奔腾专业版开始的处理器会“无序执行”。如果指令没有依赖关系，它们可能会并行执行许多指令。但只有当指令仅与寄存器一起操作时，才会出现这种情况。如果它们与内存一起操作，则使用额外的CPU单元，称为“加载单元”(用于从内存读取数据)和“存储单元”(用于将数据写入内存)。大多数CPU有两个加载单元和一个存储单元，也就是说，它们可以并行执行两条从内存读取的指令和一条写入内存的指令(同样，如果它们不相互影响的话)。这些单元的大小通常与最大寄存器大小相同-如果CPU具有XMM寄存器(SSE)，则为16字节；如果具有YMM寄存器(AVX)，则为32字节，依此类推。所有读取或写入存储器的指令都被转换为微操作(微操作)，这些微操作转到公共的微操作池中，并在那里等待加载和存储单元能够为它们提供服务。单个加载或存储单元一次只能服务于一个微操作，而不管它需要加载或存储的数据大小是1字节还是32字节。|4430888|因此，最快存储器拷贝将移动到具有最大大小的寄存器和从寄存器移出。对于支持AVX的处理器(但没有AVX-512)，复制内存的最快方法是重复以下顺序，循环展开：|4430889|vmovdqa+++++ymm0,ymmword+ptr+[rcx]
vmovdqa+++++ymm1,ymmword+ptr+[rcx%2B20h]
vmovdqa+++++ymmword+ptr+[rdx],ymm0
vmovdqa+++++ymmword+ptr+[rdx%2B20h],ymm1|code-block|syntax|javascript|4430890|hplbsh之前发布的Google代码不是很好，因为它们在开始写回数据之前使用了所有8个xmm寄存器来保存数据，而这并不是必需的-因为我们只有两个加载单元和一个存储单元。因此，只需两个寄存器即可提供最佳结果。使用这么多寄存器根本不能提高性能。|4430891|存储器复制例程还可以使用一些“高级”技术，如“预取”，以指示处理器提前将存储器加载到高速缓存和“非临时写入”(如果您正在复制非常大的存储器块，并且不需要立即从输出缓冲器读取数据)、对齐写入与未对齐写入等。|4430892|自2013年以来发布的现代处理器，如果它们在CPUID中具有ERMS位，则具有所谓的“增强型rep+movsb”，因此对于大内存拷贝，可以使用“rep+movsb”-拷贝将非常快，甚至比使用ymm寄存器更快，并且它将与高速缓存一起正常工作。然而，这条指令的启动成本非常高-大约35个周期，所以它只在大的内存块上支付(然而，这可能会在未来的处理器中发生变化)。有关“rep+movsb”的更多信息，请参阅https://stackoverflow.com/a/43845229/6910868上的“相对性能说明”部分以及https://stackoverflow.com/a/43837564/6910868。|offset|length|4430893|我希望您现在可以更容易地选择或编写您的情况所需的最佳内存复制例程。|4430894|您甚至可以保留标准的memcpy/memmove，但可以根据需要获得自己的特殊largememcpy()。|4430895|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/a/43845229/6910868|1|https://stackoverflow.com/a/43837564/6910868^0|0|0|0|0|0|0|5L|18|0|77|18|1|0|0|0^^$0|@$1|2|3|4|5|6|7|16|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|17|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|18|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|19|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|1A|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|1B|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|1C|8|@]|9|@$Q|1D|R|1E|1|1F]|$Q|1G|R|1H|1|1I]]|A|$]]|$1|S|3|T|5|6|7|1J|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|1K|8|@]|9|@]|A|$]]|$1|W|3|-4|5|6|7|1L|8|@]|9|@]|A|$]]]|X|$Y|$5|Z|10|11|A|$12|13]]|14|$5|Z|10|11|A|$12|15]]]]

In order to find or write a fast memory copy routine, we should understand how processors work.
Processors since Intel Pentium Pro do “Out-of-order execution”. They may execute many instructions in parallel if the instructions don’t have dependencies. But this is only the case when the instructions operate with registers only. If they operate with memory, additional CPU units are used, called “load units” (to read data from memory) and “store units” (to write data to memory). Most CPUs have two load units and one store unit, i.e. they can execute in parallel two instructions that reads from memory and one instruction that writes into memory (again, if they don’t affect each other). The size of these units is usually the same as the maximum register size – if the CPU has XMM registers (SSE) – it’s 16 bytes, if it has YMM registers (AVX) – it is 32 bytes, and so on. All instructions that read or write memory are translated to micro-operations (micro-ops) that go to the common pool of micro-ops and wait there for the load and store units to be able to serve them. A single load or store unit can only serve one micro-op at a time, regardless of the data size it needs to load or store, be it 1 byte or 32 bytes.
So, fastest memory copy would be move to and from registers with maximum size. For AVX-enabled processors (but without AVX-512), fastest way to copy memory would be to repeat the following sequence, loop-unrolled:
<pre><code>vmovdqa ymm0,ymmword ptr [rcx]
vmovdqa ymm1,ymmword ptr [rcx+20h]
vmovdqa ymmword ptr [rdx],ymm0
vmovdqa ymmword ptr [rdx+20h],ymm1
</code></pre>
The Google code posted earlier by hplbsh is not very good, because they use all 8 xmm registers to hold the data before they begin to write it back, while it is not needed – since we only have two load units and one store unit. So just two registers give best results. Using that many registers in no way improves performance.
A memory copy routine may also use some “advanced” techniques like “prefetch” to instruct the processor to load memory into cache in advance and “non-temporal writes” (if you are copying very large memory chunks and don’t need the data from the output buffer to be immediately read), aligned vs unaligned writes, etc.
Modern processors, released since 2013, if they have the ERMS bit in the CPUID, have so-called “enhanced rep movsb”, so for large memory copy, the “rep movsb” may be used – the copy will be very fast, even faster than with the ymm registers, and it will work with cache properly. However, startup costs of this instruction are very high – about 35 cycles, so it pays up only on large memory blocks (however, this may change in future processors). See “The explanation on relative performance” section on <a href="https://stackoverflow.com/a/43845229/6910868">https://stackoverflow.com/a/43845229/6910868</a> and also see <a href="https://stackoverflow.com/a/43837564/6910868">https://stackoverflow.com/a/43837564/6910868</a> for more information on “rep movsb”.
I hope it should now be easier for you to choose or write the best memory copy routine needed for your case.
You can even keep the standard memcpy/memmove, but get your own special largememcpy() for your needs.

blocks|key|1213503|text|我不确定使用默认的memcpy总是最好的选择。我研究过的大多数memcpy实现都倾向于在开始时尝试对齐数据，然后进行对齐的副本。如果数据已经对齐，或者非常小，那么这是在浪费时间。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1213504|有时候，有专门的字拷贝，半字拷贝，字节拷贝memcpy是有益的，只要它不会对缓存产生太大的负面影响。|1213505|此外，您可能需要对实际分配算法进行更精细的控制。在游戏行业中，人们编写自己的内存分配例程是非常普遍的，无论工具链开发人员首先花费了多少精力来开发它。我见过的游戏几乎都倾向于使用Doug+Lea's+Malloc。|offset|length|1213506|一般来说，你会浪费时间去优化memcpy，因为毫无疑问，在你的应用程序中会有很多更容易的代码来加速。|1213507|entityMap|0|LINK|mutability|MUTABLE|url|http://g.oswego.edu/dl/html/malloc.html^0|0|0|2G|H|0|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@$F|U|G|V|1|W]]|A|$]]|$1|H|3|I|5|6|7|X|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|Q]]]]

I'm not sure that using the default memcpy is always the best option. Most memcpy implementations I've looked at tend to try and align the data at the start, and then do aligned copies. If the data is already aligned, or is quite small, then this is wasting time.

Sometimes it's beneficial to have specialized word copy, half word copy, byte copy memcpy's, as long as it doesn't have too negative an effect on the caches.

Also, you may want finer control over the actual allocation algorithm. In the games industry it's exceptionally common for people to write their own memory allocation routines, irrespective of how much effort was spent by the toolchain developers in the first place developing it. The games I've seen almost always tend to use <a href="http://g.oswego.edu/dl/html/malloc.html" rel="nofollow noreferrer">Doug Lea's Malloc</a>.

Generally speaking though, you'd be wasting time trying to optimize memcpy as there'll no doubt be lots of easier bits of code in your application to speed up.

blocks|key|1471374|text|这取决于你想做什么.如果这是一个足够大的memcpy，并且您只是在稀疏地写入副本，那么使用MMAP_PRIVATE创建写时复制映射的mmap可能会更快。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1471375|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Depending on what you're trying to do... if it's a big enough memcpy, and you are only be writing to the copy sparsely, a mmap with MMAP_PRIVATE to create a copy-on-write mapping could conceivably be faster.

blocks|key|4430682|text|根据您的平台，可能存在特定的用例，例如，如果您知道源和目标与缓存线对齐，并且大小是缓存线大小的整数倍。一般来说，大多数编译器都会为memcpy生成相当优化的代码。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4430683|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Depending on your platform there may be for specific use cases, like if you know the source and destination are aligned to a cache line and the size is an integer multiple of the cache line size. In general most compilers will produce fairly optimal code for memcpy though.

Are there faster alternatives to memcpy() in C++?

optimized memcpy

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

在C++中有没有比memcpy()更快的替代品？

问优化的memcpy
EN

回答 8

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问优化的memcpyEN

回答 8

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问优化的memcpy
EN