如何解决了解延迟有界 memcpy/memset x86_64
我一直在查看一些 stackoverflow 帖子（Why is std::fill(0) slower than std::fill(1)? 和 Enhanced REP MOVSB for memcpy），决定最佳 memcpy/memset 策略的一个因素似乎是操作是否会受到延迟或 DRAM 带宽限制。要点之一是 rep movsb 的切换延迟比我不理解的正常写入更长。
为什么 ERMSB rep movsb 比 memcpy/memset 的 movaps（或任何其他正常写入）循环具有更长的切换延迟 em>
上面描述的 rep movsb 与单个内核上不同缓冲区大小的显式 movap 循环的行为与我们之前在服务器内核上看到的非常一致。正如您所指出的，竞争是非 RFO 协议 [Read For Ownership] 和 RFO 协议之间的竞争。前者在所有缓存级别之间使用较少的带宽，但特别是在服务器芯片上，一直到内存的切换延迟很长。由于单核通常并发受限，延迟很重要，非 RFO 协议获胜，这就是您在 30 MB L3 以外的区域看到的
然而，在 Enhanced REP MOVSB for memcpy 中，BeeOnRope 说
但是，如果您的并发受限，情况就会平衡，但有时会逆转。您有 DRAM 带宽可供备用，因此 NT 存储无济于事，它们甚至会受到伤害，因为它们可能会增加延迟，因为线路缓冲区的切换时间可能比预取将 RFO 线路带入 LLC（甚至L2)，然后存储在 LLC 中完成以有效降低延迟。最后，服务器 uncore 的 NT 存储往往比客户端慢得多（和高带宽），这加剧了这种影响。
我无法理解非 RFO 方法 (rep movsb) 如何具有更长的延迟切换，并解释了延迟切换来自何处是 LFB（行填充缓冲区）是否必须切换到缓存在 L2/LLC 或 DRAM 中。
Enhanced REP MOVSB for memcpy 帖子讨论了 rep movsb 的优点，其中：
立即准确地发出预取请求。硬件预取在检测类似 memcpy 的模式方面做得很好，但它仍然需要几次读取才能启动，并且会“过度预取”超出复制区域末尾的许多缓存行。 rep movsb 确切知道区域大小并且可以准确预取。
鉴于 rep movsb 正在预取（比 movaps 循环更有效），您是否期望 LFB 至少在L2/LLC 与 movaps 循环相比。如果是这种情况，我不明白：
前者在所有缓存级别之间使用的带宽较少，但特别是在服务器芯片上，一直到内存的切换延迟很长
特别是长延迟切换是否来自。
所以我的问题是
rep movsb中 LFB 的额外切换延迟来自哪里？- 更一般地说，是什么导致了
rep movsb和 memcpy/memset 中的延迟界限？
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
