我有一个随机程序，有顺序和并行变体。该程序的本质是它的运行时间根据其"运气"而有很大差异。它通常以看似地理分布的模式取值在 1 秒到 2 分钟之间。平行变体在数字不同时表现出相似的行为。
在这种情况下，衡量并行加速比的"好"方法是什么？ 我可以只使用测量值的平均值/中位数作为"运行时"的代表
我将如何解释这种方法，是否有(统计/数学上)更好的方法来计算加速比？
编辑：感谢user3666197，它注意到一些非常重要的技术细节，这是获得良好数据所必需的。 我已经做了功课，想澄清我的问题。
我使我的基准测试过程尽可能可靠：
- 基准测试使用种子运行，结果可重复。
- 每个配置在脚本中使用不同的种子重复多次(~400 次)
我的问题仍然是：如何计算该程序的加速比。
我做了什么：
平均顺序运行时间约为 8.38，中位数为 4.8，这是一个很大的差异。对于 2 个线程，平均运行时间为 4.36，而中位数运行时间为 2.42。 如果我将顺序除以并行，我会得到 1.92(平均值)和 1.992(中位数)的加速。 对于 4 个线程相似：均值：2.25 运行时和 3.72 加速，中位数：1.12 中位数和 4.3 加速比(超线性)。 8 个线程存在类似的数字。
我尝试以不同的方式可视化数据。情节
直方图显示了使用各种线程的运行时分布，右侧的箱线图也是如此。可见，可以看到一些加速。
如果我根据种子配对测量值，我会得到成对的时间：顺序和并行时间。 我的第一个想法是通过计算回归线的斜率来计算加速比，但是，回归线似乎没有正确"汇总"数据并且价值有限。在右下图中，仅显示 4 个线程的点。
我建议您根据足够大的一组测量值的运行时的算术平均值来计算加速比。确保正确传达数字代表的内容。可能很难确保您具有足够大的设置测量值以具有一定的置信度来计算适当的均值，尤其是在样本未呈正态分布的情况下。包括您关于分布和发现的发现。确保在计算加速比之前先汇总运行时。
Torsten Hoefler和Roberto Belli有一篇出色的论文，详细介绍了您的问题。特别是第 2.1.1 节和第 3 节。
如何衡量并行加速与纯[SERIAL]代码？
始终既要定量又要系统。
这意味着至少：
1) 使用所有系统步骤来控制测试可重复性 2) 比较苹果和
苹果，包括随机发生器的受控种子设置
3) 最好，将所有测试电池生成为脚本化、可自动重复的实验
4) 在测试的 UUID# 可区分日志中记录性能(总体和局部部分计时) 5)收集相当1E+3~1E+4大小的试运行群体，而不仅仅是几个单位的单个试验
鉴于您的解决方案已经以纯 [SERIAL] 代码执行方式和其他一些[CONCURRENT]甚至[PARALLEL]方式实现，最确切的步骤是比较端到端测试持续时间。
使用单调时钟是很常见的，在[TIME]域中具有优于~ [us]分辨率。
有关内部性的更多详细信息，最好查看重新制定的阿姆达尔定律以及对并行加速初始、不受约束的资源使用公式的批评。