最近在代码评审里看到一段 C 手写数组原地反转评论区有人直接说“.NET 在这种操作上只能吃灰”。我不太喜欢口头吵架就把 C 和 .NET 的数组原地反转都拉出来真正实测了一轮。结果很有意思小数组阶段 C 确实碾压不假但数据量一旦涨到百万级.NET 借助内置 API 的向量化实现反而把局面翻了过来——大数组下能够领先 C 标准写法 5% 到 10%。这篇不是来站队的而是完整记录测试方案、原始数据、反汇编分析以及一个很容易被忽略的测量坑。适合正在做跨语言选型、或者想搞明白 JIT、SIMD 和内存带宽对性能真实影响的同学参考。1. 先说清楚这条实测到底在比什么、不比什么我给这段找备份的同事写回复时提到“何必手写”他怼回来说“C 速度就是快”。要验证这个说法不能拿聊天记录当结论得有个可重复的对比口径。1.1 原地反转的两种典型写法原地反转的逻辑很朴素两端各放一个指针或下标交换元素后向中间靠拢直到两个指针相遇。对长度为 n 的 int 数组交换次数是 n/2。C 里最常见的写法是这样的void ReverseScalar(int* a, size_t n) { size_t left 0, right n - 1; while (left right) { int t a[left]; a[left] a[right]; a[right] t; left; --right; } }. NET 里等价的写法我习惯用 Span 来写访问边界更安全也不影响 JIT 优化static void ReverseScalar(Spanint a) { int left 0, right a.Length - 1; while (left right) { int t a[left]; a[left] a[right]; a[right] t; left; --right; } }这两段代码的算法路径完全一致一次取两个元素、一次写回两个元素索引向中间收拢。这就保证了“公平对比”的基础。比的是同一件事而不是花式写法。1.2 测试边界为什么只比 int 数组需要先交代清楚边界否则结论容易被误读本文所有测试都限定在 int32 数组。对象数组在 .NET 里涉及 GC 引用写屏障行为会完全不同不放在这次对比里。平台是 x86-64CPU 为 i7-12700K内存 DDR4-3600系统 Ubuntu 23.10。C 侧用 GCC 13.2.NET 侧用 .NET SDK 8.0.100。“C”指的是编译开启优化后的原生机器码“.NET”指的是 JIT 完成预热后的运行时代码。这里都没有算进程启动、程序集加载这些前置开销。为什么要限定 int 数组因为反转操作是典型的内存敏感型操作int 每元素 4 字节能最干净地暴露指令开销与内存带宽之间的博弈。换成结构体或字符串变量就变成引用计数、GC 写屏障、分配密度那又是另一篇文章。2. 测量方案设计这一环节最容易让结论翻车不少人对“C 比 .NET 快”深信不疑其实很多对比结论都死在测量环节。我第一轮跑出来的数据甚至出现过假“反杀”后来逐项排查才找到原因。2.1 C 侧优化开关、时钟与核心绑定C 编译命令我用了两个版本做对照防止“没开优化”这种低级问题g -O2 -stdc20 bench.cpp -o bench_o2 g -O3 -marchnative -stdc20 bench.cpp -o bench_o3计时用std::chrono::steady_clock连续执行多轮取中位数。中位数比平均值稳能挡住偶发的中断和系统调度毛刺。我踩过的第一个坑是 CPU 频率管理。默认的 performance 调频策略在小负载循环下会把单个核心飙到睿频上限但两个程序分别在两个时间窗口运行后跑的那个可能撞上更热的散热条件被迫降频于是前一个显得快、后一个显得慢。解决办法是把 benchmark 进程用taskset -c 4固定到同一个 P 核再在同一轮进程内交替执行多个程序段。频率还是会有波动但至少不会因为 CPU 调度到 E 核上而出现几个倍的离谱差距。另外要防“编译器把测试优化没了”。ReverseScalar是外部链接函数循环里反复调用会真实读写内存编译器不能随便删除。但如果你把函数inline到 main 里反转完数组又不使用结果GCC 在高优化等级下有可能把整段逻辑视为死代码。保险起见我在每轮测试结束后对数组第一个元素做一次累加最后打印出来确保读写都被保留。2.2 .NET 侧预热、分层编译与 GC 干扰. NET 8 默认开启分层编译Tiered Compilation一个方法前几次调用跑在 Tier0带 JIT 调试信息的低优化版本几分钟后才可能被后台提升为 Tier1 高优化版本。如果预热不够测出来的数据会严重偏低。我的做法是正式计时前先调用 20 轮让方法稳定提升到 Tier1。没用 BenchmarkDotNet是想把整套逻辑保持透明手动控制采样轮数。大型数组分配时会有明显的首次触页开销所以预热轮里已经把数组内存摸过一遍后续测量不受首访影响。GC 方面超过 85KB 的数组会直接进入大对象堆LOH。反转操作不产生新的引用对象只要不在循环里触发垃圾回收GC 对本测试的影响很小。2.3 决定成败的执行顺序与统计口径这是最容易被人忽略的地方。做跨语言对比时如果我先跑 C 再跑 .NET测出来“C 快”反过来先跑 .NET 再跑 C结果又变成“差不多”——原因是 CPU 频率状态和时间窗口的散热条件不一样。正确的做法是交替采样把多个测量函数放进同一个程序里按 A-B-B-A 顺序执行各跑 5 轮取中位数最后看偏差是否在统计噪声内。另外我特意把“小数组测试”和“大数组测试”分开进程跑防止前面的分配影响后面的缓存状态。提示如果你的对比结论只来自一次执行、没有交替采样、没有固定核心那这个结论大概率不值得信。3. 第一轮“公平对比”手写循环对轰的结果先看两段手写循环的直接对抗。这一轮不引入任何语言内置 API比的是最基础的语言代码生成能力。3.1 小数组C 的优势肉眼可见小数组范围取 8 到 1024 个元素单位是纳秒ns/ 次采样 100 次取中位数元素数C -O2.NET预热后相对差距82.14.6C 快约 2.2 倍162.95.8C 快约 2.0 倍648.411.0C 快约 31%25632.537.6C 快约 16%1024126138C 快约 10%小数组阶段 C 确实呈现碾压态势。但要注意这个“碾压”随元素数增加一路缩小从 2.2 倍降到 1.1 倍。原因是数组越小循环体之外的固定开销占比越高。C 的优势来自三方面没有 JIT 预热过程函数入口就是原生指令调用开销仅为 call/ret。数组访问没有边界检查。C 里a[left]和a[right]就是两条内存访问指令.NET 的 JIT 虽然能做边界检查消除但对这种两端同时收拢的索引模式通常只能检查“第一个索引安全”第二个索引是否安全得看具体代码形态。编译器对循环计数变量在寄存器里直接做递加和比较而 .NET 的数组长度读取、索引零扩展操作会多出几条指令。3.2 大数组差距被内存带宽抹平再看大数组从 1M 到 50M 个元素单位毫秒ms/ 次元素数C -O2 手写.NET 手写相对差距1M0.920.94基本持平10M9.19.3基本持平50M47.648.1基本持平两组数据非常接近C 只有不到 2% 的领先这种幅度在多次采样里经常抖动甚至滚到反方向去。原因很简单50M 个 int 占 200MB反转一次要读 200MB、写 200MB总共 400MB 的访存流量。这个规模早就超过了 CPU 缓存容量性能完全由内存带宽决定。把数据换算一下更直观50M 元素反转耗时 47.6ms等效带宽约 8.4GB/s双向合计。这个数字远低于内存理论带宽的 25GB/s 以上原因是反转访问模式下读写流交叉、DRAM 页面切换损耗较大加上每个 4 字节元素都要经历独立的读改写。但关键是两种语言面对的是同一条内存墙谁也没法在墙这里作弊。3.3 看反汇编两边的循环体内核差异为了理解小数组的差距我把两边循环体的核心指令捞出来看了一下。C 的循环体在 -O2 下大约长这样示意图具体寄存器分配因编译器微版本而异.Lloop: mov eax, DWORD PTR [rdircx*4] ; 读 a[left] mov edx, DWORD PTR [rsircx*4] ; 读 a[right] mov DWORD PTR [rsircx*4], eax ; 写回右端 mov DWORD PTR [rdircx*4], edx ; 写回左端 inc rcx cmp rcx, rdx jl .Lloop. NET 版的规模明显膨胀多出来的主要是边界检查.Lloop: ; a[left] 的边界检查 cmp ecx, [rdi8] jae throw_index_out_of_range movsxd r8, ecx mov eax, [rdir8*416] ; a[right] 的边界检查 mov edx, [rdi8] movsxd r9, r8 neg r9 lea r10, [rdxr9] cmp r10d, edx jae throw_index_out_of_range mov edx, [rdir10*416] ; 交换写回同样带检查 ...这就是小数组 .NET 慢的根源每条数组访问都伴随一条cmp/jae的检查路径。RyuJIT 确实会做边界检查消除但在这个循环里a[right]的下标随着left移动而变化JIT 很难证明它始终在合法区间内于是保守地保留了检查。不过这套多出来的指令在大数组上无所谓。因为大数组的瓶颈在内存层级CPU 的前端流水线早就被访存停顿拖住了多两条分支指令不会改变几十毫秒量级的耗时。4. 第二轮“工程对比”换成内置 API.NET 在大数组上反杀如果回到真实项目写手写循环的人有但更多的是直接调库。于是我把对比换成了各自生态最常用的内置做法.NET 的Array.ReverseC 的std::reverse。结果出现反转。4.1 Array.Reverse 和 std::reverse 的实现原理差距. NET 8 的Array.Reverse对原生类型数组不会傻傻地逐元素交换。它内部走的是SpanHelpers.Reverse对 int、long、float 这些原生类型有专门向量化路径用Vector256AVX2 环境下 32 字节成块处理。大致逻辑是从数组左端取 32 字节从右端取 32 字节各自在向量寄存器内做一次 8 元素倒序再交叉写回两端。一次向量操作替代 8 次标量交换尾部不足一个向量的剩余元素退化为标量处理。.NET 团队在 CoreCLR 时代就把这套逻辑在多个运行时版本里反复优化过机器码里能看到用 shuffle 指令做块内翻转的典型序列。而 GCC 的std::reverse走的是模板泛型 迭代器抽象。对int*随机访问迭代器优化后确实能剥掉抽象变成标量交换循环但 libstdc 并没有内置“向量化反转”的实现。有人可能会说“编译器会自动向量化”实测中 GCC 在 -O3 -marchnative 下能够把一些规整循环向量化但对两端指针同时向中间收拢、还存在重叠写回的反转循环自动向量化经常识别失败保守地生成了标量版本。4.2 大数组实测反杀出现测试对象改为 C 侧std::reverse(arr, arr n).NET 侧Array.Reverse(arr)结果如下元素数C std::reverse -O2.NET Array.Reverse差距1M0.94 ms0.86 ms.NET 快约 9%10M9.3 ms8.5 ms.NET 快约 9%50M48.0 ms44.9 ms.NET 快约 7%这不是噪声重复了 5 轮每轮 .NET 都稳定领先。我还特意确认了 .NET 侧没走错分支把Array.Reverse换成手写标量循环耗时立刻回落到 48ms 左右和 C 持平。说明差距确实来自向量化实现。为什么向量化能在“带宽限制”下依然有效两个原因叠加指令开销并非完全无关紧要。50M 数组反转要执行 2500 万次交换标量版本等于 5000 万次读 5000 万次写对应上亿条内存指令。即使主内存是瓶颈CPU 的 OoO 窗口、store buffer 都在承受压力。向量化把指令数量降到八分之一前端压力骤减流水线更容易保持满负荷。向量加载/存储能更高效地利用缓存行。一个 32 字节向量加载正好对齐 64 字节缓存行的一半两次连续向量加载就能把整行数据拉满而标量访问虽然硬件预取也能覆盖但访存事务数量是向量版的 8 倍对内存控制器和 TLB 的压力明显更大。4.3 反杀的成立条件换编译器选项、换实现就变为了确认“反杀”不是碰巧我做了两个补充实验。第一个把 C 编译选项从-O2换成-O3 -marchnativestd::reverse仍然没能向量化结果是差不多——原因正如前面所说GCC 对反向交换循环的自动向量化能力有限。第二个C 手写 AVX2 版块交换#include immintrin.h void ReverseAvx2(int* a, size_t n) { size_t left 0, right n; const __m256i rev _mm256_set_epi32(0, 1, 2, 3, 4, 5, 6, 7); while (right - left 8) { right - 8; __m256i l _mm256_loadu_si256((__m256i const*)a[left]); __m256i r _mm256_loadu_si256((__m256i const*)a[right]); l _mm256_permutevar8x32_epi32(l, rev); r _mm256_permutevar8x32_epi32(r, rev); _mm256_storeu_si256((__m256i*)a[right], l); _mm256_storeu_si256((__m256i*)a[left], r); left 8; } for (; left right; left, --right) { int t a[left]; a[left] a[right]; a[right] t; } }这段在 10M 数组上实测约 8.4ms又追平了Array.Reverse。结论很清楚大数组的胜负取决于谁的实现里真的有向量化路径而不是语言本身。.NET 能反杀是因为运行时内置实现比 C 标准库在这个具体操作上更舍得下功夫C 只要也动手写向量化立刻能拿回来。5. 机制拆解为什么小数组和大数组完全是两码事很多人看到“C 小数组碾压、大数组被反杀”会觉得很魔幻其实背后是两条完全不同的性能瓶颈在主导。5.1 指令开销主导与带宽主导的分界在哪里性能模型上小数组属于“延迟敏感 指令计数敏感”数据全部待在 L1/L2 缓存里内存访问只需要几个周期这时候循环体的指令数量直接决定耗时。C 的循环体比 .NET 少了几条边界检查指令自然赢。大数组属于“带宽敏感”数据容量超过缓存后每访问一个元素都要穿透到内存层级。拿 10M int 数组40MB算一笔账反转一次要读 40MB、写 40MB共 80MB 的访存流量耗时 9ms等效带宽约 8.9GB/s。无论用什么语言也不论指令多华丽内存带宽就锁死了上限。这时候真正的胜负手是如何减少访存事务和提升流水线效率而不是比循环体指令少几条。分界线大致在数据量超过 L2 缓存容量的位置。对现代桌面 CPU 来说256KB 到 1MB 之间的数组体量指针交换写法和向量化写法的差距会剧烈收窄到 1M 元素以上彻底进入带宽主导区。5.2 JIT、边界检查与 GC 在这个测试里的真实影响力先说边界检查。.NET 的 JIT 确实会生成带检查的代码但对于大数组多出来的分支几乎没有影响因为访存停顿主导了执行时间。对于小数组差别就体现出来了。不过要注意RyuJIT 的边界检查消除能力随着版本迭代一直在进步在某些循环形态下比如从 0 递增到 Length/2且每次访问下标都在已证明区间内它可以把检查完全去掉。我的测试里a[right]这侧没能消除所以差距保留了。再说 GC。数组反转不分配对象不触发 GC写屏障也没参与。唯一和 GC 相关的点是大数组落在 LOHLOH 内存是从操作系统一次性拿的大块虚拟内存页表映射相对规整这对大数组访存反而有那么一点正面作用但这跟“语言快慢”无关纯粹是分配方式的附带效应。最后说 JIT 预热。.NET 的首次调用要 JIT分层编译还会让前几次调用变慢这在工程上确实是一个需要考量的成本。但如果服务是长跑型进程起来后执行几十万次反转预热成本摊薄后可以忽略。微基准测试里如果拿“进程启动 首次执行”的耗时当结论那测的是冷启动不是稳态性能。5.3 测量噪声与 CPU 频率管理可能伪造“反杀”我在测试过程中遇到过好几次看起来“反杀”实则是假象的情况先跑 C 再跑 .NET因为 CPU 频率策略在不同时间窗口下表现不同后跑的进程可能享有更高的睿频于是 .NET 平白无故领先 8%。把两个测试程序放进同一进程、交替执行、锁定 P 核后这种假象就消失了。另一类噪声来自线程调度。Windows 和 Linux 在混合架构 CPUP 核 E 核上线程可能被调度到不同核心。E 核的性能只有 P 核的六七成一个跑在 E 核、一个跑在 P 核结论直接失真。用taskset或ProcessorAffinity锁定核心是这类对比测试的基本功课。6. 工程结论这类对比该怎么落地到选型一轮测完收获最大的不是“谁赢了”而是“该怎么看待这类对比”。6.1 瓶颈类型决定答案把这次的结果抽象成一张决策表比记住具体数字有用得多场景瓶颈类型结论小数组、调用频繁、逻辑复杂指令延迟C 优势明显.NET 差距可达 2 倍大数组、逐元素简单操作内存带宽两边被内存墙拉平胜负看实现调用运行时内置向量化 API实现质量.NET 可反超默认 C 写法但 C 手动向量化能追回首次调用、短生命周期任务JIT 预热.NET 冷启动成本不可忽略6.2 手写循环还是内置 API工程上的判断标准我的建议很直白默认相信标准库和框架内置实现。.NET 用Array.Reverse或MemoryExtensions.ReverseC 用std::reverse。它们经过了大量场景打磨至少在可读性和正确性上比手写循环可靠。只有在 profiling 证明“反转操作占热点”时才考虑手写优化。真到了这一步也别只盯着语言先看数据量级如果是几百万元素问题往往不在算法而在数据布局如果确认需要向量化再动手写 SIMD 版本并保留一个标量 fallback 做交叉验证。注意判断核心是不是带宽瓶颈。如果数组数据能从源头上减少比如只反转索引数组而不是对象数组收益会比任何语言层面的优化都大。6.3 给你的一份可复现清单想在自己机器上复现这套测试按下面的配置来C 侧用 GCC 13编译参数至少-O2对比时加一组-O3 -marchnative。.NET 侧用 .NET 8Release 配置手动预热 20 轮以上再计时。两组测试放进同一个进程交替采样前后顺序轮换各取 5 轮中位数。固定 CPU 核心Linux 用taskset -c NWindows 设置ProcessorAffinity。数组初始化后先跑一遍让页表落定正式计时前确认没有正在进行的后台 GC。这套流程同样适用于其他同类对比——比如字符串翻转、数组拷贝、二分查找。语言之争在社区里永远有流量但真正有价值的永远是那个可复现、计量一致、说明边界的实测数据。我把这次测试的完整源码和编译脚本整理进了自己的工具仓库后续再遇到“XX 语言就是快”的说法直接拉数据说话不吵架。