Optimization 每秒触发器是处理器速度的量度，还是算法速度的量度？

1） 我可以非常清楚地看到：一台计算机在一秒钟内能够完成的浮点运算的数量是一种很好的量化其性能的方法。没错，对吧

2） 我的老师一直让我计算我编程的算法的失败率。我通过计算算法的失败次数和运行时间来实现这一点。在这种情况下，触发器的速率总是远远低于我所使用的计算机期望的触发器速率。因此，对于算法来说，失败率更像是对“其他东西”需要多长时间的评估（即开销，不涉及失败的东西）。也就是说，当触发器计数较低时，大多数程序的时间都花在调用函数等而不是执行触发器上，对吗

---

我知道这是一个非常广泛的问题，但我希望工业界或学术界人士能提供一些想法，让他们直观地感觉到算法的失败率实际上是什么。

正确地说，“失败”是处理器或系统性能的衡量标准。许多人滥用它来衡量实现或算法速度

假设您要执行的计算的操作数是固定的。例如，您希望将一个维度为a•b的矩阵与一个维度为b•c的矩阵相乘。如果您以通常的方式执行此乘法，那么在a行和c列的每一个组合中，您将执行b乘法和b-1加法。所以整个矩阵乘法需要a•c•（2b-1）浮点运算。如果它在一秒钟内完成，一些人说它提供了一个•c•（2b-1）翻牌

如果你有两个程序都以相同的方式进行乘法运算，你可以用这个数字来比较它们。其中一个“失败”次数越多越好。即使它们使用相同的算法，其中一个可能有更好的实现，可能是因为它可以更有效地组织内存缓存的工作

当有人想出一种新的算法，用更少的操作完成同样的工作时，这种情况就发生了。然后，有些人使用原始方法的标称操作数比较程序（或例程），即使程序实际上执行的操作更少

在某种程度上，这是有道理的。如果你有两个程序做同样的工作，其中一个程序有更高的“失败”次数，那么这个程序会更快地给你答案

然而，它没有意义，因为它引入了不精确性。我们通常对单个问题的大小不感兴趣，而是对各种大小的问题感兴趣，一旦使用了新算法，程序的“失败”将不会与标称操作数成线性比例

打个比方，假设从A镇到B镇的距离是80公里，在每个人都使用的山路上。如果你的车花了一个小时，那么你的车就是以每小时80公里的速度行驶。有一天，当你外出探险时，你发现了一条穿越群山的通道，这条通道将行程缩短到70公里。现在您可以在52.5分钟内完成行程。有些人用“翻牌”做的同样计算会说你的车每小时行驶91.4公里，因为它在52.5分钟内完成了80公里的行程

---

这显然是错误的。但是，它对于决定采取哪种路由很有用。

触发器表示处理器每秒执行的浮点运算量。这可能是从某些硬件/体系结构规范中得出的纯理论数据，也可能是运行某些优化为给出高数值的算法得到的经验结果

FLOPS计算中的主要问题来自一个系统，其中存在多个并行执行块。好吧，只有在这种情况下，将一个实用算法（例如FFT，或RGB->YUV转换）拆分为使用CPU中所有计算单元的最有用的指令集才会变得非常困难。（例如，如果没有自动矢量化，x64系统通常只在Xmm0[0]寄存器中计算浮点运算，浪费了50-75%的全电势。）

---

这部分回答了问题2。除了cache/memory在注册带宽时引入的明显停顿之外，在实现最大触发器数的过程中，下一个关键障碍是数据位于错误的寄存器中。这是在复杂度分析中经常被完全忽略的东西，就像触发器计算一样，它只计算基本的算术运算。在并行编程的情况下，经常会发生这样的情况：在错误的寄存器中不仅有一个值，还有4、8或16个值，而没有任何方法可以轻松地一次将它们全部置换。加上开销，“预热”和“冷却”阶段，该算法试图用有意义的数据占用所有计算单元，因此1GFLOPS系统中获得100 MFlops的主要原因。

对标题问题的最佳答案可能是“是”