我目前正在 Windows 环境中使用 C++ 进行基准测试算法，并寻求有关进行准确性能评估的最佳实践的建议。
我的设置涉及使用 Windows cmd 编译和运行可执行文件以进行基准测试，其中每个可执行文件代表相同的算法但具有不同的参数。但是，我担心同时运行多个 cmd 实例以同时执行不同的基准测试可能会出现潜在的不准确性。
以下是我需要指导的具体要点：
我对一个又一个运行基准测试并等待每个基准测试完成然后启动下一个基准的顺序性质感到疲劳。考虑到每个基准测试进程占用大约 15% 的 CPU，我正在考虑跨多个 cmd 实例同时运行多个基准测试。这种方法将有助于加快基准测试过程并更有效地利用系统资源。
我非常感谢经验丰富的程序员提供的见解和建议，他们拥有 Windows 平台上 C++ 基准算法方面的专业知识。预先感谢您的帮助。
有很多方法可以使您的基准数据更加嘈杂且可重复性较差。除非您确切知道自己在做什么以及正在对哪种工作负载进行基准测试，和/或如果您想要在繁忙的系统上粗略估计每个线程的性能，否则不会推荐它。
如果您的任何代码存在严重的 L2 缓存未命中（即缓存占用空间大于约 256K 到 1 MiB 左右，具体取决于您的 CPU），它们将相互竞争 L3 缓存空间和 DRAM 带宽。 （L3 带宽可以很好地扩展多个读取器/写入器，但 DRAM 不能在典型的台式机/笔记本电脑 CPU 上实现；单个内核几乎可以使内存控制器饱和。）。
在空闲系统上进行基准测试更容易保持一致和可重复，但可能代表也可能不代表真正的多线程程序中的条件。
如果您确实想在与其他核心竞争共享资源时对代码进行基准测试，那么最好编写一个简单的负载生成器，例如以一定的速度在大型或中型阵列上循环，以生成一定量的 L3 和/或 DRAM 流量。 （或者像
_mm_stream_si128另请参阅性能评估的惯用方法？了解其他微基准测试陷阱，例如CPU频率预热，以及首先接触内存以避免定时区域中的页面错误。 （或者，如果您只想对整个可执行文件进行计时或分析，则使重复循环足够长以分摊任何启动工作，例如使用 Linux
perf stat说到 CPU 频率，当只有一两个核心处于活动状态时（与大多数核心处于活动状态时相比），大多数 CPU 都可以提高 CPU 时钟频率（涡轮）。升压时钟还取决于总体热量和功率限制，
此外，如果您的 CPU 具有 SMT（例如超线程），每个物理核心有多个逻辑核心，Windows 可能最终会在同级核心上调度多个任务，以便它们竞争 CPU 内的执行资源。 （特别是如果您运行的任务多于物理核心，但即使没有该 Window 调度程序也会多次反弹线程，我上次听说）。
根据任务的不同，共享物理核心可能会使它们的运行速度接近一半。 （希望大多数时候没有那么糟糕，如果它们的瓶颈包括指令延迟、分支错误预测以及可能的缓存未命中延迟，而不是指令吞吐量或内存带宽。根据您共享核心的工作负载，可能会出现超过一半的可用前端带宽，或者可能没有，因此这更多地取决于工作负载的性质。）如果某些运行有两个任务共享物理核心，而有些则没有，则基准测试数字将是截然不同。如果您想测试两个任务之间的 SMT 友好性，请将它们固定到同级核心，以便有意将它们一起进行基准测试。
在 Intel Alder Lake 或 Apple M1 等混合了性能和效率核心的混合 CPU 上，运行比 P 核心更多的任务将导致某些任务被调度到速度较慢的 E 核心。为了进行一致的基准测试，您可能希望将单线程任务固定到 P 核心或 E 核心，以查看它在每个核心上的单独执行情况。 （此外，Intel E 核心在 4 个 E 核心集群之间共享一个大型 L2，只有 L1 缓存是完全私有的。）