能，结构体成员按大小降序排列可减少 padding、压缩体积并提升缓存利用率；如 Bad 占 12 字节，Good 仅 8 字节，配合 alignof/offsetof 验证布局。
结构体成员按大小降序排列能减少 padding 吗？
能，而且这是最易见效的缓存友好优化之一。CPU 读取内存时以 cache line（通常 64 字节）为单位加载，如果结构体内部存在大量 padding，会导致单个 cache line 能容纳的有效数据变少，等效降低带宽利用率。
编译器按声明顺序填充结构体，若小字段（如 bool、char）穿插在大字段（如 double、void*）之间，会强制插入 padding 对齐。把 int、long long、指针等大成员放前面，char、bool 放后面，可显著压缩体积。
struct Bad { char a; int b; char c; }; // sizeof == 12（a+3pad+b+c+3pad）struct Good { int b; char a; char c; }; // sizeof == 8（b+a+c+2pad，或更优：a+c+b，但需对齐到 4）
用 alignof 和 offsetof 验证布局，或直接 static_assert(sizeof(S) 约束大小。
遍历数组时该用 row-major 还是 column-major？
C++ 原生数组和 std::vector 是 row-major 存储，所以嵌套循环必须外层遍历行、内层遍历列，否则每次访问都跨 cache line，性能暴跌。
立即学习“C++免费学习笔记（深入）”；
比如二维矩阵 std::vector<:vector>> 是反模式：每行堆分配、地址不连续；改用一维向量 + 手动索引（data[i * cols + j]）才能保证空间局部性。
- ✅ 缓存友好：
for (int i = 0; i < rows; ++i) { for (int j = 0; j < cols; ++j) { sum += data[i * cols + j]; } } - ❌ 缓存不友好：
for (int j = 0; j < cols; ++j) { for (int i = 0; i < rows; ++i) { sum += data[i * cols + j]; // 每次 i 变化都跳 cols*sizeof(double)，极易 miss } }
std::vector 真的节省空间但破坏缓存友好性吗？
是的。std::vector 是特化实现，按位存储，虽然空间压缩了 8 倍，但每次 operator[] 需要位运算 + 掩码 + 分支，无法被 CPU 预取器识别，且不能取地址、不满足 ContiguousContainer，导致 vectorized 指令（如 AVX）完全失效。
除非内存极端受限且访问极少，否则应避免。替代方案包括：
- 用
std::vector（每个布尔值占 1 字节，但支持随机访问、可向量化、预取有效） - 用
std::deque（若需频繁首尾插入，但随机访问稍慢） - 手动打包成
uint64_t数组 + bit-ops（仅当热点路径且 profile 确认收益时）
循环展开和 prefetching 在什么场景下值得手动做？
编译器（如 GCC -O3、Clang -O2）已默认做基础循环展开和软件预取，手动干预只在以下情况必要：
- 处理超长固定长度数组（如 4096 元素），且 profiler 显示 L1D miss 率 >15%
- 访问模式非规则（如 stride 不是常量，或依赖前次计算结果）
- 目标平台预取指令可用（x86:
_mm_prefetch；ARM:__builtin_prefetch），且你控制内存分配对齐（aligned_alloc）
示例（安全预取）：
for (int i = 0; i < n; ++i) {
if (i + 64 < n) __builtin_prefetch(&arr[i + 64], 0, 3); // 提前读入下 64 个元素
sum += arr[i] * weight[i];
}
注意：prefetch 地址必须有效，否则触发 page fault；参数 3 表示“高局部性、写倾向”，需按实际访存意图调整。
真正影响缓存友好的，从来不是某一行 magic 指令，而是数据布局是否连续、访问步长是否恒定、结构体是否紧凑——这些决定了硬件预取器能否跟上你的节奏。其他都是边际优化。
