从何种大小开始按const引用传递比拷贝更快？及相关技术疑问

1. 跨编译单元时，const T&和T传递是否还有区别？ #

当函数声明与实现不在同一编译单元时，编译器无法进行跨单元的等价优化。调用方只能依据头文件里的声明生成代码——比如声明是void func(const T&)，就必须传递指针（引用本质是指针的语法糖）；而函数实现即便能内部优化成按值处理，也无法改变调用方已经生成的传指针逻辑，这时候指针解引用的开销是无法避免的。

举个实际例子：头文件声明void foo(const char&)，调用方会传递char的地址；实现里哪怕把参数当值用，也得先解引用指针拿到数据，这一步的开销在跨单元场景下没法被消除。但如果是同一编译单元，编译器会直接把调用改成传值，跳过指针解引用的步骤。

2. 处理器能否通过指针解引用加载多个字？ #

这得结合处理器架构和具体机制来看：

• 单个普通指针解引用指令，通常只能加载对应类型大小的数据（比如x86的mov rax, [rdi]加载8字节，mov eax, [rdi]加载4字节）。
• 但处理器的内存预取机制会自动提前加载指针指向地址附近的缓存行（通常是64字节），如果后续的解引用操作访问的是同一缓存行内的连续数据，就能直接从缓存读取，不需要再发起内存请求。
• 另外，你可以主动使用SIMD指令（比如x86的AVX、ARM的NEON），一次性从指针指向的地址加载多个字（比如AVX2能一次加载32字节），但这属于特殊指令的主动使用，不是普通指针解引用的默认行为。

3. 拷贝比指针解引用更快的阈值，以及测试方法 #

阈值的大致范围 #

这个阈值完全依赖CPU架构、缓存状态、指令集：

• 对于小类型（char、short、int，甚至16字节以内的结构体）：拷贝到寄存器的开销几乎可以忽略，远低于指针解引用（哪怕缓存命中，解引用也要几纳秒，而拷贝直接在寄存器间操作）。
• 当类型大小超过寄存器容纳上限（比如x86-64通用寄存器单份存8字节，多寄存器拼接最多16-32字节），或者需要拷贝到栈上时，拷贝开销会逐渐上升。当类型大小超过64字节（一个缓存行），拷贝需要跨缓存行操作，这时候指针解引用（只需加载一次缓存行）的开销可能反超；但如果数据不在缓存里，两者都会触发缓存miss，开销差距会大幅缩小。

测试方法 #

要得到准确结果，得做可控的基准测试：

• 用专业基准测试库：比如Google Benchmark，它能自动控制测试环境、统计误差，还能避免编译器优化掉无用代码。你可以写传值、传const引用两个版本的函数，循环调用相同次数，对比执行时间。
• 控制缓存状态：分两种场景测试：
  1. 缓存命中：把测试数据放在小数组里，确保全部能装进L1缓存。
  2. 缓存miss：用远大于L3缓存的数组，强制每次访问都从内存加载。
• 避免优化干扰：函数内部要做实际计算（比如把参数累加进全局变量，或者返回参数的计算结果），不能让编译器把函数调用优化成空操作。
• 多次测试取平均：CPU频率波动、系统负载都会影响结果，要跑足够多的测试次数，取中位数或平均值来减少误差。

内容的提问来源于stack exchange，提问作者Caio Vinícius