我已经了解了不同的缓存映射技术,如直接映射,关联映射和集合关联映射技术,还学习了权衡.但我很好奇现在在intel core i7或AMD处理器中使用了什么.以及这些技术是如何演变的.还有哪些事情需要改进？
我正在尝试为英特尔的clwb指令找到不会使缓存行无效的配置或内存访问模式。我正在使用 NVDIMM 对 Intel Xeon Gold 5218 处理器进行测试。Linux 版本是 5.4.0-3-amd64。我尝试使用 Device?DAX 模式并直接将此字符设备映射到地址空间。我还尝试将此非易失性内存添加为新的 NUMA 节点，并使用numactl --membind命令将内存绑定到它。在这两种情况下，当我使用clwb缓存地址时，它都会被驱逐。我正在观察 PAPI 硬件计数器的驱逐，并禁用预取器。
这是我正在测试的一个简单循环。array 和 tmp 变量，都被声明为 volatile，所以加载是真正执行的。
for(int i=0; i < arr_size; i++){
tmp = array[i];
_mm_clwb(& array[i]);
_mm_mfence();
tmp = array[i];
}
两次读取都会导致缓存未命中。
我想知道是否还有其他人试图检测是否有某种配置或内存访问模式会在缓存中留下缓存行？
经过认真的发展，CPU 获得了许多核心，在多个小芯片、numa 系统等上获得了分布式核心块，但数据仍然不仅必须通过 L1 缓存（如果在同一核心 SMT 上），而且还必须通过一些原子/互斥同步未经硬件加速的原始过程。
我想知道为什么英特尔或 IBM 没有想出这样的东西：
movcor 1 MX 5 <---- sends 5 to Messaging register of core 1
pipe 1 1 1 <---- pushes data=1 to pipe=1 of core=1 and core1 needs to pop it
bcast 1 <--- broadcasts 1 to all cores' pipe-0
使其比其他方法快得多？GPU 支持块级快速同步点，例如barrier()或__syncthreads()。GPU 还支持本地阵列的并行原子更新加速。
当 CPU 增加 256 个核心时，此功能是否不会为在核心到核心带宽（和/或延迟）上遇到瓶颈的各种算法提供严重的扩展？
我有一个具有2个线程的应用程序，与内核1关联的线程A和与内核2关联的线程B，内核1和内核2在同一x86套接字中。
线程A忙于整数x的旋转，线程B在某些情况下会增加x，当线程B决定增加x时，它将使x所在的缓存行无效，并根据x86 MESI协议，它将新的x存储到存储缓冲区在core2收到无效ack之前，然后在core2收到无效ack之后，core2刷新存储缓冲区。
我想知道，在core2收到无效ack之后，core2刷新是否立即存储缓冲区？我是否有可能迫使cpu用C语言执行刷新存储缓冲区？因为在我的情况下，core1旋转x的线程A应该尽早获得x新值。
TL;DR：在生产者-消费者队列中，放置一个不必要的（从 C++ 内存模型的角度来看）内存栅栏或不必要的强内存顺序是否有必要以牺牲可能更差的吞吐量为代价来获得更好的延迟？
C++ 内存模型是在硬件上执行的，方法是使用某种内存栅栏来实现更强的内存顺序，而不是将它们放在较弱的内存顺序上。
特别是，如果生产者这样做store(memory_order_release)，而消费者使用 观察存储的值load(memory_order_acquire)，则加载和存储之间没有围栏。在 x86 上根本没有栅栏，在 ARM 上栅栏是在存储之前和加载之后进行放置操作。
没有围栏存储的值最终会被没有围栏的负载观察到（可能在几次不成功的尝试之后）
我想知道在队列的两侧放置围栏是否可以更快地观察到值？如果有围栏和没有围栏，延迟是多少？
我希望只有一个循环load(memory_order_acquire)和pause/yield限制为数千次迭代是最好的选择，因为它无处不在，但想了解原因。
由于这个问题是关于硬件行为的，我希望没有通用的答案。如果是这样，我主要想知道 x86（x64 风格），其次是 ARM。
例子：
T queue[MAX_SIZE]
std::atomic<std::size_t> shared_producer_index;
void producer()
{
std::size_t private_producer_index = 0;
for(;;)
{
private_producer_index++; // Handling rollover and queue full omitted
/* fill data */;
shared_producer_index.store(
private_producer_index, std::memory_order_release);
// Maybe barrier here or stronger order above?
}
}
void consumer()
{
std::size_t private_consumer_index = 0;
for(;;)
{
std::size_t observed_producer_index = shared_producer_index.load( …