好是一个相对术语，它取决于问题的性质、算法的性质和所涉及的硬件的属性。唯一的绝对参考点是理想的缩放比例（100% 效率）。

你可以声称你的扩展是好的，如果它比其他人在同一问题上取得的成就更好，或者如果它“接近”大量处理器的理想选择。例如，在这篇论文中（免责声明：引用我自己的工作，因为这是我最熟悉的工作）我们从 1 到 65K 进程实现了大约 95% 的效率弱扩展，并声称这很好。考虑到所涉及的算法和硬件，这并没有什么特别之处，但我们确实避免了任何会破坏效率的重大错误。

对于大多数问题领域，您给出的两个示例似乎都非常差。在第二个示例中，您实际上具有抗缩放功能——当以 20% 的效率运行 2 或 4 个进程时，挂钟时间实际上将大于串行运行。这绝对是糟糕的缩放！

如前所述，良好的缩放没有绝对的定义。您真正可以了解的只是您的代码实现的可扩展性是更好、更差还是与在类似环境中执行相同类型计算的其他代码一致。

现在，一些计算中心有时（尝试）执行一些规则以确保他们的计算资源得到有效使用（不过分）。例如，我记得其中一个，为了获得访问权限，您必须为您的代码的典型用例提出可伸缩性曲线。从那时起，您将只被允许运行代码的并行效率超过 75% 的多个进程。这个神奇的 75% 效率阈值并不意味着您的代码的可伸缩性在高于时会很好，而只是说它在低于时太糟糕了......

如果您正在寻找一般标准，那么线性缩放可能是“理想”缩放。因此，我会说你的缩放越接近直线，它就越好。

为简单起见，我们假设 A 和 B 正在解决相同的问题。alg B 在 16 个处理器内核上的加速比约为 4，而 A 为 3。

对于一般信息，弱扩展意味着每个内核的工作量保持不变，因此通常问题大小的某些方面与处理器数量成比例增加。在此示例中，随着问题大小和处理器数量的增加，A 和 B 中每个处理器完成的有用工作量都会减少。

Alg A 是“更好”的，因为从 1 到 16 的核心数量的解决方案总是比 Alg B 更好。当然，如果效率趋势继续下去，那么 Alg B 将是 18 个核心的“更好”选择，并且多于。事实上，Alg B 如果缩放真的有一个 0.2 的下限，它对于非常大的问题可能非常有吸引力。

正如其他答案所指出的那样，尽管通常认为 0.2 或 0.3 阶的效率很差。我个人的观点是，解决问题的时间才是最重要的，最好的算法是在可用计算能力的限制内最快给我答案的算法。如果 Alg A 在 16 个内核上的效率下降到 10%，那么这个问题会更有趣。有一些模拟代码具有不同的并行算法可供选择，这些算法对于不同的架构甚至不同数量的可用内核“更好”。并行性总是有通信成本，而且通常在更多数量的浮点运算中也有足够的成本。