1）我可以很清楚地看到：一台计算机在一秒钟内可以进行的浮点运算的数量是量化其性能的好方法。这是正确的，对吧？
2) 我的老师一直让我计算我编写的算法的失败率。我通过计算算法做了多少次失败并计时运行需要多长时间来做到这一点。在这种情况下，翻牌率总是低于我所使用的计算机所期望的翻牌率。所以对于算法来说，失败率更像是对“其他东西”需要多长时间的评估（即开销，不涉及失败的东西）。也就是说，当触发器计数低时，大部分程序时间都花在调用函数等而不执行触发器上，对吗？
我知道这是一个非常广泛的问题，但我希望工业界或学术界的人能提供一些想法，让他们直观地感受到算法的失败率实际上是什么。
正确地说，“触发器”是衡量处理器或系统性能的指标。许多人滥用它作为实现或算法速度的衡量标准。
假设您要执行一个计算，该计算的操作次数是固定的。例如，您想将维度为 a•b 的矩阵与维度为 b•c 的矩阵相乘。如果您以通常的方式执行此乘法，则在 a 行之一和 c 列之一的每个组合中，您执行 b 乘法和 b-1 加法。所以整个矩阵乘法需要 a•c•(2b-1) 浮点运算。如果它在一秒钟内完成，有人说它提供了 a•c•(2b-1) 翻牌。
如果您有两个程序都以相同的方式进行乘法运算，则可以使用此图对它们进行比较。其中有更多“翻牌”的人更好。尽管它们使用相同的算法，但其中一个可能有更好的实现，这可能是因为它更有效地组织了内存缓存的工作。
当有人想出一种用更少操作完成相同工作的新算法时，这种情况就会中断。然后有些人使用原始方法的名义操作数来比较程序（或例程），即使程序实际上执行的操作更少。
在某种程度上，这是有道理的。如果您有两个程序执行相同的工作，并且其中一个程序以这种方式计算的“失败”数量较多，那么该程序会更快地为您提供答案。
但是，它没有任何意义，因为它引入了不准确性。我们通常对单个问题的大小不感兴趣，而是对各种大小感兴趣，并且一旦使用新算法，程序的“失败”将不会随着标称操作数线性扩展。
以此类推，假设从A镇到B镇，经过大家都用的山路80公里。如果您的汽车需要一个小时才能完成行程，那么您的汽车每小时行驶 80 公里。一天外出探索时，您会发现一条穿越山脉的通道，可将行程缩短至 70 公里。现在您可以在 52.5 分钟内完成行程。有些人用“人字拖”做同样的计算会说你的车每小时行驶 91.4 公里，因为它在 52.5 分钟内完成了 80 公里的行程。
这显然是错误的。但是，它对于决定采取哪条路线很有用。
FLOPS 是指处理器每秒执行的浮点运算量。这可以是从某些硬件/架构规范得出的纯理论数字，也可以是运行某些经过调整以提供高数字的算法的经验结果。
FLOPS 计算的主要问题来自一个系统，其中有多个并行执行块。AFAIK，仅在这种情况下，将实用算法（例如 FFT 或 RGB->YUV 转换）拆分为使用 CPU 中所有计算单元的最有用的指令集变得非常困难。（例如，在没有自动矢量化的情况下，x64 系统通常只在 Xmm0[0] 寄存器中计算浮点运算，浪费了全部潜力的 50-75%。）
这部分回答了问题 2。除了高速缓存/内存对寄存器带宽造成的明显停顿之外，实现最大 FLOPS 数字的下一个关键障碍是数据位于错误的寄存器中。这在复杂性分析中经常被完全忽略，就像 FLOPS 计算只计算基本算术运算一样。在并行编程的情况下，经常会发生这样的情况，错误的寄存器中不仅有一个，而且有 4、8 或 16 个值，而没有任何方法可以轻松地将它们一次全部置换。将其添加到算法中的开销、“热身”和“冷却”阶段，该算法试图用有意义的数据占据所有计算单元，并且您有主要原因从 1GFLOPS 系统中获得 100 MFlops。