c – 确定我们的ASM程序的FLOPS

前端之家收集整理的这篇文章主要介绍了c – 确定我们的ASM程序的FLOPS前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我们必须实施一个ASM程序,用于以坐标方案格式(COOS)以及压缩行格式(CSR)乘以稀疏矩阵.现在我们已经实现了所有这些算法,我们想知道它们与通常的矩阵乘法相反的性能是多少.我们已经实现了代码来测量所有这些算法的运行时间,但是现在我们决定还要知道我们可以执行多少个浮点运算(FLOPS).
任何建议如何衡量/计数这个?

这里有一些使用系统的背景信息:

processor   : 0
model name  : ARMv7 Processor rev 2 (v7l)
Features    : swp half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpd32 
cpu implementer : 0x41
cpu architecture: 7
cpu variant : 0x3
cpu part    : 0xc08
cpu revision    : 2

我们的第一个想法是实现一种在每个浮点运算(算术运算以及比较和移动运算)之后递增的FPO计数器,但这意味着我们必须在代码中插入增量运算,这些代码也会减慢下来的应用程序…
有没有人知道是否有某种硬件计数器来计算浮点运算的数量,或者是否存在可用于监视我们的程序和测量FPO数量的某种性能工具.
任何建议或指针都不胜感激.

这是使用计数方法对矩阵乘法的FLO​​P进行评估.我们首先测量了我们感兴趣的每个指令的运行时间,而不是插入计数器,之后我们计算了每秒的浮点运算次数.

解决方法

它看起来像最接近你可以得到与 the performance events supported by Cortex-A8是执行总指令的计数,这是不是非常有用的,因为“一个指令”执行任何从0到(我认为)8 FP操作.退后一步,显而易见的是,尝试在硬件中测量算法的FLO​​PS不会真的奏效 – 例如您可以使用向量操作编写一个实现,但并不总是将实际数据放在每个向量的所有通道中,那么cpu需要使用精神来知道它执行的FP操作的实际数量是多少.

幸运的是,给定一个算法的正式定义,计算涉及的操作数应该是相当简单的(尽管不一定容易,这取决于复杂性).例如,在我的头脑中穿过,m×n矩阵与n×m矩阵的标准初始乘法出现到每个输出元素的m * m *(n n-1)个运算(n次乘法和(n-1)个加法).一旦纸上分析得出了适当的参数化运算计数公式,您可以将其放入基准测试工具中,以计算测试数据的数字.

一旦你完成了所有这些,你可能会开始后悔花费所有的时间来做,因为你会有(任意数字)/(执行时间),这比单独执行时间更有意义大多数情况下,(任意数字)不同的情况之间的比较复杂化. NEON性能特别是由流水线延迟和内存带宽支配,因此低级实现细节可以轻松超过算法可能存在的固有差异.

以这种方式思考:在某些给定的100MHz cpu上,a b b总共需要5个周期,而(a b)* 2总共需要4个周期* – 前者的分数为60 MFLOPS,后者仅为50 MFLOPS.你会说更多的FLOPS意味着更好的表现,在这种情况下,需要25%更长时间才能得到相同结果的例程是“更好”吗?你会说更少的FLOPS意味着更好的表现,这对于任何合理的解释显然是不真实的?或者你会得出结论,除了综合基准测试之外,FLOPS对于一个cpu的理论最大带宽与另一个cpu的理论最大带宽是非常无意义的?

为了争论,数字从稀薄的空气中抽出来;然而,它们实际上并不遥远,像Cortex-M4F – 单精度FPU,其中加法和乘法都是单循环,加上一个或两个用于寄存器危险.

猜你在找的C&C++相关文章