std::vector转置慢因内存不连续导致缓存未命中；应使用一维连续存储+行主序，非方阵转置需新缓冲区，方阵可原地循环置换但分块填充更实用。

为什么 std::vector<:vector>></:vector> 转置慢得明显？ 因为内存不连续：每行是独立分配的指针，transpose[i][j] 访问会频繁跨页、触发大量缓存未命中。哪怕逻辑上只是交换下标，实际访问模式从“按行扫描”变成“按列扫描”，在现代 CPU 上代价极高。

• 别用嵌套 vector 存矩阵，除非矩阵极小（
• 真正缓存友好的布局是单块连续内存 + 行主序（row-major），比如 std::vector<t></t> 配合 data[i * cols + j]
• 如果必须用二维接口，可用包装类隐藏索引计算，但底层仍用一维存储

用一维数组实现转置，怎么避免额外内存拷贝？ 原地转置可行，但仅限方阵（rows == cols）。非方阵必须分配新缓冲区——这不是缺陷，是内存布局的物理限制。

• 方阵原地转置用循环置换：对每个上三角位置 (i, j)（i ），轮换四个角（<code>(i,j) → (j,i) → (rows-1-i, cols-1-j) → …），但代码易错且 cache 表现未必更好
• 更实用的是申请一块新 std::vector<t></t>，大小为 rows * cols，然后用分块（tiling）填充：

  for (size_t ii = 0; ii < rows; ii += TILE) {
  for (size_t jj = 0; jj < cols; jj += TILE) {
    for (size_t i = ii; i < std::min(ii + TILE, rows); ++i) {
      for (size_t j = jj; j < std::min(jj + TILE, cols); ++j) {
        dst[j * rows + i] = src[i * cols + j];
      }
    }
  }
  }

• TILE 通常取 8–16（对应 64–256 字节），让内层循环数据尽量留在 L1 cache

用 std::valarray 或 std::span 能简化吗？std::valarray 支持 apply 和切片，但无内置转置，且实现常不优化；std::span 只是视图，不解决布局问题。

• 不要用 valarray 做高性能转置——它抽象层级高，编译器难优化访存模式
• std::span 可配合一维数据使用，例如：std::span<const t> src_span(src.data(), src.size())</const>，但它本身不改变访问顺序
• 真正省事又高效的做法：用成熟小矩阵库如 xtensor（支持 lazy transpose）或 blaze，它们默认用一维存储 + 智能迭代器

Clang/GCC 编译时要注意哪些 flag？ 没开优化，再好的算法也白搭。但盲目开 -O3 有时反而抑制向量化。

• 必开：-O2 -march=native（启用当前 CPU 的 AVX/SSE）
• 对密集数值计算，加 -ffast-math 可提升循环展开和向量化机会，但注意它放松 IEEE 浮点规则
• 避免 -fno-alias 除非你手动加 restrict，否则编译器不敢重排访存
• 用 perf stat -e cache-misses,instructions ./a.out 实测 cache miss ratio，超过 5% 就该调分块大小或检查对齐

转置快不快，核心不在“写几行代码”，而在是否让每一行 mov 指令都从 L1 cache 里拿数据——这取决于你分配内存的方式、遍历的步长、以及编译器看到的内存别名信息。漏掉其中任意一环，优化就卡在瓶颈上。

C++14

C++14 对 C++11 的修正与增强版本，适合旧系统维护和较老工具链兼容。

下载