为什么把博客重开了
之前的 WordPress 博客数据库没保住，文章全丢了。这次干脆换了一套 Next.js + Markdown 文件驱动 的新系统（就是你现在看到的这个），文章以 .md 存在仓库里，再也不会因为数据库丢失而消失。
新博客的第一篇，写写我在 ASC 超算竞赛里最核心的一段经历：HPL 性能调优。
ASC 竞赛里我们做了什么
ASC（ASC Student Supercomputer Challenge）是全球三大超算竞赛之一，赛题要求在限定功耗内自建集群并冲击 LINPACK 峰值。我们队伍两次拿下国际二等奖。
单机 HPL 调优的关键指标是效率 = 实测 TFLOPS / 理论峰值。我们最终做到了：
| 指标 | 数值 |
|---|---|
| HPL 实测 | 20.36 TFLOPS |
| Rpeak 效率 | 95.6% |
| 强扩展效率（多机） | 101.1%（超线性） |
| HPCG 相对提升 | 3.52× |
调优 HPL 的几条实战经验
1. 先算 Roofline，再动手
机器能跑多快不由你决定，由内存带宽和计算密度决定。先用 stream 测实际带宽，用 linpack_analyze 之类的工具估算理论可达到效率，再决定调参方向。
2. 问题规模 N 是最大的杠杆
HPL 效率强烈依赖 N（矩阵规模）与 NB（分块大小）的组合。N 太小，通信占比高；N 太大，超过内存容量导致换页崩溃。用可用的 90% 内存去推最大 N，是第一步。
3. 进程网格 P×Q 影响全局 P×Q 网格形状决定通信模式。对双路机器，通常让 P ≤ Q 且尽量匹配 NUMA 拓扑，减少跨片通信。
4. 编译器 flag 和数学库
-O3 -march=native 是底线，更重要的是换用高性能 BLAS（如 OpenBLAS / MKL / 自编译 ACML），峰值效率差距可达 10~20 个百分点。
5. 用 CPU 亲和性锁核
把 OpenMP 线程 pthread 绑定到物理核，避免线程在核间漂移导致的 cache miss。一个 GOMP_CPU_AFFINITY 可能值 3~5% 效率。
这件事对我的意义
超算调优的本质是在预算内榨干硬件——这和我后来做 AI Agent 推理缓存优化、OCR 管线加速、甚至 2C2G 云服务器上把博客跑流畅，是同一件事：资源约束下的效率工程。
这套博客本身也是——一台 2G 内存的海外小 VPS，跑着 Next.js、反代着 HTTPS，文章用 Git 管理。后续我会把 ASC 那两年更完整的方案（HPCG Roofline、GPU 容器化基准、4000 核集群调度）逐步整理成文，欢迎关注。