加载失败
原帖通过微基准量化“传值（pass-by-value）”的性能开销，发现在 AMD Ryzen 3900X（AMD 的 Zen 2 桌面 CPU）上某些数据大小（约 4046–4080 字节、8161–8176 字节）按值传递时出现异常高的延迟。评论主要把该现象归因于 4K aliasing 与页面/对齐相关的微架构效应，并建议检查系统页面大小、指针对齐并在不同 CPU 型号上复现实验。讨论同时涉及语言语义与底层实现的差别（传值语义 vs 编译器/ABI 的实际行为）、跨翻译单元的调用约定限制，以及微基准设计时要防止编译器优化带来的陷阱。线程还延伸到用 ChatGPT 辅助生成基准代码以及小规模容器（vector vs unordered_map）的实际性能权衡。
原帖报告在 AMD Ryzen 3900X 上将 4046–4080 字节或 8161–8176 字节的数据按值传递时出现明显性能惩罚。多位评论把根源归结为“4K aliasing”——当对某地址写入后从相差 4KB 的地址读取时，CPU 的加载/存储路径或缓存一致性机制可能触发冲突或退化。有人指出这些大小接近 0x1000 和 0x2000，暗示与页面大小（page size）和页面边界或指针对齐有关，并建议在其他 CPU 型号上复现实验来判断是否为特定微架构问题。评论中还表达了对这一看似“魔咒尺寸”现象进一步传播与复现的强烈兴趣。
有人主张“传值只是语义，不必实际复制”，并指出编译器在语义允许下可以省略真实拷贝（比如用 const reference 达到等价效果）。反对者强调现实中的编译器受限于 ABI（Application Binary Interface）和调用约定（calling conventions），尤其在没有 inlining 或 whole-program optimization 的跨翻译单元调用中，调用约定限制了编译器在参数传递方式上的自由度。评论还指出 const reference 与真正的传值在别名分析上并不等价：编译器不能总是假设引用不会与其他参数或全局变量别名，因此在某些优化上必须更保守。另有观点提醒 ABI 与链接器会“泄露”实现细节，无法在高层语义上完全屏蔽这些成本。
一位评论者表示常用 ChatGPT 快速生成微基准代码（自己设计基准，LLM 仅输出代码），但仍需手动加入防止编译器过度优化的对策以保证测量有效。该评论者回忆在小规模（约 32–64 元素）排序数组中，branchless linear scan 在实践中比二分查找或带分支的扫描更快。另有评论抱怨 ChatGPT 在容器建议上倾向于建议 unordered_map，即便元素很少时 vector 顺序遍历往往更好；也有人建议使用性能更好的 hashmap 实现（如 Abseil、Boost、Folly 的实现）替代 std::unordered_map。整体讨论反映出微基准设计、工具建议偏差与小规模数据结构选择的现实权衡。
4K aliasing: 一种与 4KB 页面偏移相关的微架构别名现象：当对某地址写入后从相差 4KB（通常为一页）的位置读取，可能引起加载/存储管线或缓存一致性路径的冲突，从而导致性能下降。
ABI (Application Binary Interface): 应用二进制接口，规定函数调用的低层约定（参数如何通过寄存器或栈传递、返回值处理、符号链接等），这些约定限制了编译器在链接或跨翻译单元时能做的拷贝消除与优化。
calling convention: 调用约定，定义函数参数放在哪些寄存器或栈位置、调用者/被调用者保存哪些寄存器等，直接影响传值的实际实现成本与跨模块兼容性。
page size / page boundary: 内存页面大小（通常为 4KB）和页面边界，数据跨越页面边界或与页面对齐方式相互作用时可能触发特定微架构行为或别名情况，导致性能突变。