3. 性能评估环境搭建
后量子密码（PQC）算法的性能评估，与经典公钥算法（RSA、ECC）的评估有一个本质区别：PQC 算法大量依赖多项式乘法、NTT/INTT 变换、哈希与采样等操作，其性能对 CPU 指令集、缓存层次、内存带宽和编译器优化极为敏感。同一份 Kyber 或 Dilithium 参考实现，在不同机器、不同编译选项下，密钥生成、封装/解封装或签名/验签的周期数可能相差数倍。因此，环境搭建不是"装好机器跑个 benchmark"这么简单，而是要把硬件、操作系统、编译器和测量方法固定成一条可复现的实验基线，否则后续所有横向对比都失去意义。
硬件选型：先明确评估目标，再决定平台
硬件选型的第一步不是比参数，而是回答"我要评估什么"。如果目标是评估算法在服务器端的吞吐能力，应选择支持 AVX2/AVX-512 的 x86-64 平台，因为 Kyber、Dilithium 的高效实现普遍使用向量指令加速 NTT；如果目标是评估嵌入式或物联网场景，则应选择 ARM Cortex-M4/M33 等带 DSP 扩展的微控制器，关注的是代码体积、栈占用和周期数，而非吞吐。若评估目标是"算法本身的计算复杂度"，则应关闭或固定频率，避免 Turbo Boost 和动态调频干扰。
一个常见的教学示例配置如下（属于合理假设，非实测结果）：评估服务器端 PQC 性能时，选用 Intel Xeon Silver 4314（2.4 GHz 基频，支持 AVX-512），关闭超线程，固定频率为 2.4 GHz；内存配置为 8 通道 DDR4-3200，容量 64 GB；评估嵌入式场景时，选用 STM32L4R5（Cortex-M4，120 MHz，640 KB SRAM），使用板载 DWT 周期计数器测量。关键原则是：同一轮对比实验必须使用同一台机器、同一频率、同一内存配置，并在实验记录中写明 CPU 型号、微架构代号、基频/睿频状态、缓存大小和内存规格。
操作系统调优：减少测量噪声
操作系统层面的调优目标是让测量结果稳定、可重复。主要措施包括：
- CPU 频率固定：在 Linux 下将 scaling governor 设为
performance，并禁用 intel_pstate 的睿频行为，避免测量期间频率漂移。 - 进程绑定：使用
taskset或numactl将 benchmark 进程绑定到固定核心，减少调度迁移带来的缓存失效。 - 关闭干扰源：关闭不必要的后台服务、定时器和中断，必要时使用
isolcpus隔离测量核心。 - 透明大页与 NUMA：对内存敏感的算法，可评估 THP（透明大页）开关对结果的影响，并在 NUMA 机器上固定内存节点。
这些调优并非"越多越好"，而是要与评估目标匹配。例如评估嵌入式场景时，操作系统调优空间很小，重点应放在关闭调试接口、固定时钟源和确保中断可控上。
编译器选项：性能差异的主要来源之一
编译器选项对 PQC 性能的影响往往超过硬件差异。以 GCC 为例，常用的关键选项包括：
gcc -O3 -march=native -mtune=native -flto -fomit-frame-pointer \
-fno-plt -funroll-loops -o benchmark benchmark.c
其中 -O3 开启高强度优化，-march=native 允许编译器使用本机支持的 AVX2/AVX-512 指令，-flto 启用链接时优化以跨文件内联，-funroll-loops 对 NTT 等循环密集型代码有帮助。但要注意：-march=native 会降低可移植性，若实验需要跨平台对比，应显式指定目标指令集，如 -mavx2 或 -mavx512f。此外，PQC 实现常提供多个后端（ref、avx2、avx512），编译时应确认实际启用了哪个后端，否则可能"以为在测 AVX2，实际跑的是参考实现"。
gcc --version）、完整编译命令和预处理后的宏定义，确保他人能复现同一二进制。可复现实验基线：把"环境"变成"数据"
可复现实验基线的核心思想是：把环境配置、测量方法和结果判定标准全部显式化、版本化。一个最小可用的基线应包含以下要素：
| 要素 | 示例内容 | 作用 |
|---|---|---|
| 硬件指纹 | CPU 型号、频率、缓存、内存规格 | 确认平台一致性 |
| 系统配置 | 内核版本、governor、绑核策略 | 排除调度与频率噪声 |
| 编译配置 | 编译器版本、优化选项、目标后端 | 保证二进制可比 |
| 测量方法 | 计时源、迭代次数、预热策略 | 保证统计口径一致 |
| 结果判定 | 中位数、标准差、异常值剔除规则 | 避免单次结果误导 |
测量方法上，推荐使用 clock_gettime(CLOCK_MONOTONIC) 或 CPU 周期计数器（如 x86 的 rdtsc、ARM 的 DWT CYCCNT），并采用"预热 + 多次迭代 + 取中位数"的策略。例如对 Kyber768 封装操作，先预热 1000 次，再测量 10000 次，记录每次周期数，最后报告中位数和标准差。若标准差超过中位数的 5%，说明环境噪声偏大，应回到操作系统调优步骤排查。
需要强调的是，上图中的数值（1000 次预热、10000 次迭代、CV < 5%）是教学示例阈值，实际项目中应根据算法耗时和机器噪声水平调整。例如 Dilithium 签名操作耗时较长，迭代次数可适当减少；而哈希类操作极快，则需要更多迭代才能获得稳定统计量。
最后，建议把上述配置固化为一个可执行的脚本或容器镜像，例如用 Dockerfile 固定基础镜像、编译器版本和编译命令，用 shell 脚本统一设置 governor、绑核和测量参数。这样，任何人在任何时间拉取该镜像，都能得到与基线一致的测量环境。对于嵌入式平台，则可用固定的 Makefile + 板级配置文件来达到同样效果。环境搭建的终点不是"能跑"，而是"任何人按记录都能跑出同一量级的结果"——这才是后续所有 PQC 性能对比的可信前提。