C语言中实现数组求和看似基础，但背后涉及内存访问、编译器优化与指令并行等多个层面。不同写法在小数组上差异不明显，一旦数据量上升到百万级，性能差距就会拉开。本文从最直观的循环累加讲起，逐步介绍指针遍历、编译器向量化以及分块求和等几种常见且高效的做法。
一、最基础的下标循环求和
初学者最熟悉的写法是利用数组下标，从0遍历到n-1，把每个元素加到一个累加变量里。这种方式语义清晰，任何C教材都会首先展示。只要数组已正确初始化，结果就稳定可靠。
需要注意累加变量的类型应与数组元素匹配，否则可能发生隐式转换导致精度丢失。若元素是float而用int累加，小数部分会被截断。下面给出标准的int数组求和示例：
#include <stdio.h>
int sum_array(const int *arr, int n) {
int total = 0;
for (int i = 0; i < n; i++) {
total += arr[i]; // 通过下标访问元素
}
return total;
}
int main(void) {
int data[] = {1, 2, 3, 4, 5};
int result = sum_array(data, 5);
printf("sum=%dn", result);
return 0;
}
这种写法的优点是可读性高，编译器通常能将其优化为指针形式。缺点是当数组极大且未开启优化时，每次计算arr[i]都要做偏移量乘法，理论上不如直接移动指针高效。不过现代编译器在O2级别基本会消除这一差异。
二、使用指针算术提升访存效率
指针遍历的思路是让一个指针从数组首地址走向尾地址，每步前进sizeof(元素)字节。这样省去了下标乘步长的运算，在老旧编译器或裸机环境中更友好。代码看起来更贴近硬件，也方便理解连续内存的布局。
在函数中我们用const int *end标记结束位置，循环条件变为指针比较。这种方式在嵌入式开发中很常见，因为部分微控制器工具链优化能力弱，手写指针能减少指令数。示例如下：
#include <stdio.h>
int sum_by_pointer(const int *arr, int n) {
int total = 0;
const int *end = arr + n;
for (const int *p = arr; p < end; p++) {
total += *p; // 解引用指针取值
}
return total;
}
int main(void) {
int data[] = {10, 20, 30};
printf("sum=%dn", sum_by_pointer(data, 3));
return 0;
}
指针写法的潜在问题是边界容易写错，比如把p <= end写成越界访问。另外对数组做指针运算时要保证原数组未释放，否则出现悬空指针。在大部分桌面平台，它与下标法经编译后生成的汇编基本一致。
三、借助restrict与向量化加速
当数组很大且追求极致性能时，可以告诉编译器数组之间没有内存重叠，这通过restrict关键字实现。它让编译器放心地做自动向量化，把多次加法合并成一条SIMD指令，一次处理四个或八个整数。
开启编译选项如-O3 -ftree-vectorize后，求和循环会被展开。下面代码演示了restrict的使用，适合在信号处理或数值计算库中采用。注意restrict仅在C99及以上有效，且调用方必须保证不传重叠内存。
#include <stdio.h>
// 使用restrict承诺arr不与其他指针重叠
int sum_restrict(const int *restrict arr, int n) {
int total = 0;
for (int i = 0; i < n; i++) {
total += arr[i];
}
return total;
}
int main(void) {
int data[1000];
for (int i = 0; i < 1000; i++) data[i] = i;
printf("sum=%dn", sum_restrict(data, 1000));
return 0;
}
这种方法的优势是充分利用CPU并行单元，在大数据上提速明显。缺点是可移植性稍差，且若违反restrict约定会导致未定义行为。普通业务程序不必强求，但在性能热点函数中值得尝试。
四、分块求和降低缓存缺失
如果数组大到无法放入CPU缓存，线性遍历会造成大量缓存缺失。分块思想是把数组切成若干适合缓存的小段，每段内求和后再合并。这样提升局部性，减少内存延迟影响。
下面示例将数组按每256个元素分块，适合在64字节缓存行、多KB一级缓存的机器上运行。分块大小需根据实际缓存调优，并非越小越好。代码展示基础分块逻辑：
#include <stdio.h>
#define BLOCK 256
int sum_blocked(const int *arr, int n) {
int total = 0;
for (int i = 0; i < n; i += BLOCK) {
int partial = 0;
int end = (i + BLOCK < n) ? i + BLOCK : n;
for (int j = i; j < end; j++) {
partial += arr[j];
}
total += partial;
}
return total;
}
int main(void) {
int data[500];
for (int i = 0; i < 500; i++) data[i] = 1;
printf("sum=%dn", sum_blocked(data, 500));
return 0;
}
分块求和的代价是代码稍复杂，且小块之间仍存在跨块访问。但在数组远超过缓存容量时，它比单纯线性累加更稳定。结合多线程还可把每个块交给不同核心，进一步扩大吞吐。
五、方法对比与选用建议
为方便理解，我们把四种方式在易用性、性能和适用场景上做个简单比较：
| 方法 | 易用性 | 性能特点 | 适用场景 |
|---|---|---|---|
| 下标循环 | 高 | 通用，编译后较优 | 一般业务、教学 |
| 指针遍历 | 中 | 老编译器更友好 | 嵌入式裸机 |
| restrict向量化 | 中 | 大数据明显加速 | 数值计算库 |
| 分块求和 | 低 | 降低缓存缺失 | 超大数组 |
实际工程中，建议先写下标版本保证正确，再用性能剖析工具定位热点。若确实慢，再按场景换用指针或向量化。不要过早优化，但也不能忽视数组规模增长带来的隐性开销。
综上，C语言数组求和从表面看是一行累加，深入后却串联起语言特性、硬件结构与编译原理。掌握这些写法，你在面对不同平台时就能从容选出合适的那一种。