3. 性能评测环境搭建

后量子签名（如 ML-DSA/Dilithium、SLH-DSA/SPHINCS+、Falcon）的性能评测，与经典 ECDSA/Ed25519 评测有一个显著差异：密钥生成、签名、验签三阶段的耗时分布极不均衡，且对内存带宽、缓存层次、随机数质量、编译器优化选项高度敏感。因此，评测环境不是"随便找台机器装上库跑一下"，而是要先明确"测什么、在哪测、用什么测"，再让硬件、软件、工具三者形成可复现的闭环。本节围绕这三层展开，并给出可直接落地的配置样例。

一、硬件选型：先定评测目标，再定配置

硬件选型的第一原则是与评测结论的用途匹配。如果目标是"横向比较算法在服务器侧的开销"，应选择主流服务器 CPU（如 x86-64 的 Xeon/EPYC 或 ARM64 的 Graviton/鲲鹏），并固定主频策略；如果目标是"评估嵌入式/物联网侧可行性"，则应选低功耗 ARM Cortex-A/M 系列或 RISC-V 平台。两类平台的结论不可互相替代。

CPU 方面，需要重点关注三点：一是是否支持 AVX2/AVX-512 或 ARM NEON，因为 liboqs 中 Dilithium、Kyber 等实现带有向量化优化路径，开启与否可能带来数倍差异；二是是否关闭频率调节与超线程干扰，评测时应将 CPU governor 设为 performance，并尽量绑定核心；三是缓存容量，SPHINCS+ 的哈希树遍历对 L2/L3 命中率敏感，缓存小的平台会放大其劣势。

内存方面，签名算法本身内存占用不大，但评测框架、批量测试数据、密钥池会占用可观空间。建议至少 16 GB，服务器侧 32 GB 以上；更重要的是保证内存通道数与频率一致，避免不同机器间带宽差异污染结果。存储方面，评测过程本身是计算密集而非 IO 密集，但需要保证测试数据与日志写入不成为瓶颈，建议使用 SSD，并将测试目录放在本地盘而非网络挂载盘，防止 IO 抖动影响计时。

二、软件环境：操作系统、编译器与依赖库

操作系统建议使用长期支持的 Linux 发行版（如 Ubuntu 22.04/24.04 LTS、Debian 12、Rocky Linux 9），原因是计时接口稳定、CPU 调频可控、编译工具链成熟。评测前应关闭不必要的后台服务，禁用自动更新，并将 cpufreq 设为 performance：

# 固定 CPU 频率策略，减少计时抖动
sudo cpupower frequency-set -g performance
# 查看当前策略与频率
cpupower frequency-info | grep -E "governor|current CPU frequency"

编译器方面，GCC 与 Clang 均可，但必须在报告中写明版本与优化选项。liboqs 默认使用 CMake 构建，优化级别通常为 -O3；若开启 -march=native，会启用本机全部指令集，性能更好但可移植性差，跨机器对比时应统一为明确的指令集基线（如 -mavx2）。此外，-flto（链接时优化）对签名这类小函数密集的代码有明显影响，建议在对比实验中固定开关状态。

依赖库主要包括：CMake（≥3.15）、Ninja 或 Make、OpenSSL 开发包（用于对照经典算法与部分哈希原语）、Python3（用于结果汇总脚本）、以及可选的 libssl-dev、zlib1g-dev。安装示例如下：

sudo apt update
sudo apt install -y build-essential cmake ninja-build git \
    libssl-dev python3 python3-pip cpufrequtils

三、基准测试工具：OpenSSL 与 liboqs 的安装与配置

OpenSSL 主要用于两类用途：一是作为经典算法（ECDSA、Ed25519、RSA）的对照基线，二是提供 SHA-2/SHA-3 等哈希原语的参考实现。系统自带的 OpenSSL 版本可能较旧，若需测试较新的算法支持，可从源码编译：

git clone https://github.com/openssl/openssl.git
cd openssl
./Configure --prefix=/opt/openssl --openssldir=/opt/openssl/ssl
make -j$(nproc) && sudo make install_sw
# 验证
/opt/openssl/bin/openssl version

liboqs 是 Open Quantum Safe 项目提供的后量子算法集合，包含 ML-KEM、ML-DSA、SLH-DSA、Falcon 等参考实现与优化实现，并自带 speed 与 test_kem/test_sig 等基准程序。推荐从源码构建，以便控制编译选项：

git clone --depth 1 https://github.com/open-quantum-safe/liboqs.git
cd liboqs
cmake -GNinja -B build \
    -DCMAKE_BUILD_TYPE=Release \
    -DOQS_USE_OPENSSL=ON \
    -DCMAKE_C_FLAGS="-O3 -mavx2"
cmake --build build -j$(nproc)
sudo cmake --install build --prefix /opt/liboqs

构建完成后，可用自带的 speed 工具快速获得各算法的密钥生成、签名、验签耗时：

/opt/liboqs/bin/speed_sig --help
# 示例：测试 ML-DSA-65 与 SLH-DSA-SHA2-128s
/opt/liboqs/bin/speed_sig -a ML-DSA-65 -i 1000
/opt/liboqs/bin/speed_sig -a SLH-DSA-SHA2-128s -i 100

需要注意，speed_sig 默认输出的是单次操作的平均耗时，迭代次数 -i 过小会导致结果波动大，建议签名类算法至少 1000 次、SPHINCS+ 类较慢算法至少 100 次，并重复 3～5 轮取中位数。若需更细粒度的分阶段数据（如密钥生成、签名、验签分别统计），可基于 liboqs 的 C API 自行编写测试程序，用 clock_gettime(CLOCK_MONOTONIC) 计时，并在每轮之间插入固定间隔以降低热效应影响。

四、配置样例与结果判读

下面给出一份可直接参考的评测配置记录表，用于在报告中固定环境变量。表中数值为示例配置，实际应按所用机器填写：

结果判读时，建议同时关注均值与离散程度：若同一算法多轮结果的标准差超过均值的 5%，说明存在频率抖动、后台干扰或缓存效应，应先排查环境再下结论。对于 SLH-DSA 这类耗时较长的算法，单轮测试时间可能达到数十秒，应避免在测试期间运行其他进程。最后，所有结论都应附带"环境指纹"——即上表中的关键字段，否则跨团队、跨机器的性能数字无法比较，评测本身也就失去了意义。