添加缓存行填充避免伪共享仅获1.2倍加速，是否存在实现问题

加速比低的核心原因 #

• 你当前场景下伪共享对性能的影响本来就很小：k值设为1000，每个线程的计数器块大小为4KB左右，绝大多数计数器访问不会触发跨线程的缓存行失效，哪怕完全消除所有伪共享，理论加速上限也不会超过1.5倍，你拿到1.2倍的提升属于正常结果。
• 你的缓存行填充逻辑错误，没有解决全部伪共享问题：你现在的做法是给每个线程的k个计数器末尾追加15个int填充，只能避免不同线程计数器块边缘的少量伪共享，没有覆盖所有可能的冲突场景。

填充实现的具体疏漏 #

• 内存布局不合理：你用的counters[nproc][kPadded]是行优先存储，不同线程的同一个k值计数器间隔了上千个int，根本不会发生伪共享，真正可能发生冲突的是相邻线程的计数器块边缘的少量元素，你的填充只能解决这极小一部分冲突。
• 没有做缓存行地址对齐：你假设计数器不需要分配在缓存行起始位置，这会导致就算加了填充，数组起始地址不对齐的情况下，依然会出现部分元素跨缓存行的情况，建议用alignas(cachelinesize)修饰计数器数组，或者用posix_memalign动态分配对齐内存，栈上变长数组的对齐往往不受控。
• 填充长度计算不严谨：15个int共60字节，常规x86缓存行是64字节，剩余4字节的偏移可能导致填充失效，建议直接按缓存行大小的整数倍做对齐，不要手动算int个数。
• 栈上分配风险：你用的是变长数组(VLA)存储计数器，当nproc或者k值较大时，会触发栈溢出，建议改用堆上分配的内存。

优化建议 #

• 调整计数器布局：如果要彻底消除伪共享，可以将布局改为counters[k][padded_nproc]，每个k值对应的所有线程计数器单独占用完整缓存行，避免跨线程冲突。
• 优先优化更高占比的路径：如果性能分析显示计数器累加阶段占总运行时间的比例低于30%，不用在伪共享优化上投入过多精力，可以优先优化后续的out数组写入阶段，比如给每个线程加私有输出缓冲区，减少全局内存写竞争。
• 用性能工具确认瓶颈：可以通过perf工具统计cache-misses、L1-dcache-store-misses等指标，对比填充前后的缓存命中率变化，如果缓存miss率下降幅度很小，说明伪共享本来就不是你的性能瓶颈。

内容的提问来源于stack exchange，提问作者Leon