在阅读许多比较不同机器/架构上算法的并行实现的研究论文时,我注意到性能比较总是以GFlop/s的形式列出,而不是以秒为单位的实际挂钟时间。我很好奇为什么要使用这个约定。
我唯一的猜测是,由于每家公司都 将其设备宣传为具有特定的峰值翻转计数/秒,因此此类研究论文通过将特定应用程序的性能列为“GFlop/s”来调查其“潜力”已实现多少手。
这个对吗?
另外,说说a的表现X矩阵 - X矢量乘法已被表示为 4 GFlop/s。通过以下公式获得挂钟时间(秒)是否合理?
在阅读许多比较不同机器/架构上算法的并行实现的研究论文时,我注意到性能比较总是以GFlop/s的形式列出,而不是以秒为单位的实际挂钟时间。我很好奇为什么要使用这个约定。
我唯一的猜测是,由于每家公司都 将其设备宣传为具有特定的峰值翻转计数/秒,因此此类研究论文通过将特定应用程序的性能列为“GFlop/s”来调查其“潜力”已实现多少手。
这个对吗?
另外,说说a的表现X矩阵 - X矢量乘法已被表示为 4 GFlop/s。通过以下公式获得挂钟时间(秒)是否合理?
传统上,我会说人们或多或少地了解解决问题所需的浮点运算的数量(等等),因此将绩效报告为比率是有意义的。然后读者可以通过您描述的方法获得运行时间,但他们也可以将其与用于查找该方法效率的硬件的理论峰值性能进行比较。
就个人而言,我喜欢看到报告的运行时间和性能率。
确定运行时间的方法唯一可能不合理的是,您必须确保您拥有正确的操作复杂度公式。如果作者使用具有不同操作计数的方案,那么您可能会得到非常错误的计算。例如,对于密集矩阵向量乘法,您给出的可能是可以的,但如果这是一个稀疏示例,则可能使用了某种不相乘零的方法。如果您使用您的方法来计算运行时间而不考虑稀疏性,那么您将遇到麻烦。
使用 Linpack 基准测试对超级计算机进行排名(以及在人们对高性能计算系统进行基准测试的许多其他情况下),通常会缩放问题的大小并以 Gflop/s 报告问题大小的特定值的性能机器达到最佳性能的位置。在 Linpack 基准测试的情况下,操作计数是众所周知且标准化的,因此在解决该大小的基准问题时实际执行了多少浮点操作是毫无疑问的。
如果两台不同的机器在非常不同的问题大小下具有峰值性能,那么比较这些大小(甚至是一个常见问题大小)的运行时间不会给出合理的比较。
另一方面,如果你只想求解一个 100x100 的线性方程组,不要指望一台在 PetaFlop/s 范围内具有峰值性能的机器在求解你的微小方程组时会比一台好的机器快得多。台式机!