如何使用X86平台上使用GCC声明内存范围为无法摄取的内存范围？
虽然我已经阅读了有关此的 movntdqa 指令，但已经找到了一种干净的方法来表示不可缓存的内存范围或读取数据，以免污染缓存。 我想从海湾合作委员会做到这一点。我的主要目标是交换到大型数组中的随机位置。由于数据恢复很少，希望通过避免缓存来加速此操作。
Although I have read about movntdqa instructions regarding this but have figured out a clean way to express a memory range uncacheable or read data so as to not pollute the cache.
I want to do this from gcc. My main goal is to swap to random locations in an large array. Hoping to accelerate this operation by avoiding caching since there is very little data resue.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我认为您所描述的是内存类型范围寄存器。您可以在 Linux 下使用
/proc/mttr/ioctl(2)控制这些（如果可用并且您是用户 0），请参阅 此处 为例。由于它在物理地址范围上工作，我认为您将很难以合理的方式使用它。更好的方法是查看 GCC 提供的编译器内在函数并找到一个或更多，表达您的意图。查看 Ulrich Drepper 的系列“每个程序员都应该了解内存”，特别是第 5 部分它涉及绕过缓存。看起来
_mm_prefetch(ptr, _MM_HINT_NTA)可能适合您的需求。一如既往，当谈到绩效时——衡量、衡量、再衡量。 Drepper 的系列有精彩的部分详细介绍了如何做到这一点（第 7 部分）以及代码示例和其他内容加快代码的内存性能时可尝试的策略。
I think what you're describing is Memory Type Range Registers. You can control these under Linux (if available and you're user 0) using
/proc/mttr/ioctl(2)see here for an example. As it works on a physical address range I think you're going to have a hard time using it in a reasonable way.A better way is to look at the compiler intrinsics GCC provides and find one or more, that expresses your intent. Have a look at Ulrich Drepper's series on "What every programmer should know about memory", in particular part 5 which deals with bypassing the cache. It looks like
_mm_prefetch(ptr, _MM_HINT_NTA)might be appropriate for your needs.As always when it comes to performance - measure, measure, measure. Drepper's series has excellent parts detailing how this can be done (part 7) as well as code examples and other strategies to try when speeding up the memory performance of your code.
来自用户786653的所有好建议；尤其是 Ulrich Drepper 的文章。我要补充一点：
您对“nt”指令（例如
_mm_stream_ps内在指令）有什么看法？我不相信声明页面未缓存会比适当使用这些页面带来更好的性能，而且它们比其他替代方案更容易使用。不过，我很想看到相反的证据。All good advice from user786653; the Ulrich Drepper article especially. I'll add:
Uncached or not, the VM HW is going to have to look up page info in the TLB, which has a limited capacity. Don't underestimate the impact of TLB thrashing on random access performance. If you're not already, see the results here for why you really want to be using huge pages for your array data and not the teeny 4K default (which goes back to the days of "640K ought to be enough for anybody"). Of course if you're talking really huge arrays bigger than even a TLB full of 2MB pages can reference, even that won't help with this.
What have you got against the 'nt' instructions (e.g
_mm_stream_psintrinsic) ? I'm unconvinced declaring pages uncached will get you any better performance than appropriate use of those, and they're much easier to use than the alternatives. Would be very interested to see evidence to the contrary though.