我自己的很多工作都围绕着使算法更好地扩展，并且显示并行扩展和/或并行效率的首选方法之一是绘制算法/代码在内核数量上的性能，例如
其中轴表示内核数量，轴表示一些度量，例如每单位时间完成的工作。不同的曲线分别显示 64 个内核的并行效率分别为 20%、40%、60%、80% 和 100%。
不幸的是，在许多出版物中，这些结果是用对数比例绘制的，例如本文或本文中的结果。这些对数图的问题在于，评估实际的并行扩展/效率非常困难，例如
这与上面的情节相同，但具有对数缩放。请注意，现在 60%、80% 或 100% 并行效率的结果之间没有太大差异。我在这里写了更多关于这个的内容。
所以这是我的问题：在对数缩放中显示结果的理由是什么？我经常使用线性缩放来展示我自己的结果，并且经常受到裁判的抨击，说我自己的并行缩放/效率结果看起来不如其他人的（对数对数）结果，但对于我的一生，我不明白为什么我应该切换情节风格。
我们目前正在写一篇包含许多可比较图的论文，我们或多或少遇到了同样的问题。这篇论文是关于比较不同算法在内核数量上的扩展，在 BlueGene 上的内核数量范围在 1 到 100k 之间。在这种情况下使用 loglog-plots 的原因是涉及的数量级。没有办法在线性比例上绘制 6 个数量级。
事实上，当在 loglog 中绘制时间与内核数量的关系时，算法不是很容易区分，如下图所示。
因此，我们决定将并行效率绘制在内核数量上，而不是在半对数尺度上绘制时序。并行效率定义为，其中为使用单核的时间，为使用核的时间，为核数。基本上，告诉您算法在个核心上的效率。
不幸的是，这样做时，时间上的绝对差异不起作用（即，当一种算法比另一种算法慢十倍时）。为了解决这个问题，我们使用了我们所谓的“相对并行效率”，它由定义，其中是最快算法的时间。
在半对数尺度上绘制相对并行效率非常清楚地显示了算法的缩放比例，并且还显示了算法相对于彼此的执行情况。
Georg Hager 在《愚弄群众 - 特技 3：对数刻度是你的朋友》中写到了这一点。
虽然强缩放的对数图在高端上确实不是很清晰，但它们允许显示更多数量级的缩放。要了解为什么这很有用，请考虑使用常规细化的 3D 问题。在线性尺度上，您可以合理地显示大约两个数量级的性能，例如 1024 核、8192 核和 65536 核。读者不可能从情节中看出你是否跑了更小的东西，实际上，情节大多只是比较最大的两次跑。
现在假设我们可以在内存中为每个核心容纳 100 万个网格单元，这意味着经过两次 8 倍的强大缩放后，我们仍然可以在每个核心中拥有 16k 个单元。这仍然是一个相当大的子域大小，我们可以期待许多算法在那里高效运行。我们已经涵盖了图表的可视范围（1024 到 65536 个内核），但还没有进入难以扩展的状态。
假设我们从 16 个核心开始，每个核心也有 100 万个网格单元。现在，如果我们扩展到 65536 个内核，每个内核将只有 244 个单元，这将更加挑剔。对数轴是清晰表示从 16 核到 65536 核的频谱的唯一方法。当然，您仍然可以使用线性轴并有一个标题说“图中 16、128 和 1024 核心的数据点重叠”，但现在您使用的是文字而不是图本身来显示。
对数比例还允许您的缩放从机器属性中“恢复”，例如超出单个节点或机架。这是否可取取决于您。
我同意 Jed 在他的回复中所说的一切，但我想添加以下内容。我已经成为 Martin Berzins 和他的同事展示其 Uintah 框架扩展的方式的粉丝。他们在对数轴上绘制代码的弱和强缩放（使用该方法的每个步骤的运行时间）。我认为它显示了代码如何很好地扩展（尽管与完美扩展的偏差有点难以确定）。例如，参见本文* 论文的第 7 页和第 8 页图 7 和 8 。他们还给出了一个表格，其中包含与每个比例图相对应的数字。
这样做的一个好处是，一旦你提供了数字，评论者就没有多少可以说的（或者至少没有多少你无法反驳的）。
*J。Luitjens, M. Berzins。“提高 Uintah 的性能：大规模自适应网格计算框架”，第 24 届 IEEE 国际并行和分布式处理研讨会 (IPDPS10) 论文集，佐治亚州亚特兰大，第 1--10 页。2010. DOI: 10.1109/IPDPS.2010.5470437