TDA4VM: 关于TDA4.R5F的计算性能

我们在TDA4中开展业务，需要将某些控制算法放在R5F上运行，因此对R5F上的计算性能做了一些测试，其结果让我感到吃惊。

具体这么测试的，我们的测试中仅针对基本的运算进行了benchmark，比如加、乘、除、乘加以及开根号的运算，

同样的运算我们对比了tda4的arm72和r5f

测试分为2组，都是循环1000，不同的是第一组运算的数据长度为1024，第二组的运算长度是2048，

具体benchmark的结果如下，具体数值以微妙为单位,

第一组，数据长度1024：

第二组，数据长度2048：

第一组测试，可以看出A72的运算性能几乎是R5F的20-30倍，

第二组测试，可以看出A72的运算性能几乎是R5F的100倍，

这个有点意外，通过手册得知，A72的主频2.3G，R5F的主频1G，主频没差到1个量级，运算性能却差了2个量级。

从表2可知，R5F的sqrt的性能比其他的运算性能都强，

我是这么想的，sqrt以外的运算都是双目运算符，基本这样：z = op(x, y)

而sqrt是单目运算，这样：y = op(x)

这样看，sqrt和其它运算的差异就在访存上了，从此也可以看出R5F运算性能出奇低的原因在于访存。

因此，我想请教的是：

1）A72和R5F的性能差异为什么会差20倍到100倍？有什么具体的原因吗？

2）从表1和表2的对比，似乎可以看出R5F的cache很小，至少可以看出，表1的测试，其cache命中率远高于表二，R5F的cache大小可以设定吗？如何设定？

3）是因为访存的问题吗？我现在没有搞清楚如何直接申请R5F的片上内存，我测试了2种内存申请的接口，原生的malloc，以及TI提供的tivxMemAlloc(work_buf_size,TIVX_MEM_EXTERNAL)。测试出来的性能几乎没有区别，因此我猜原生的malloc也是在DDR上申请的。该如何申请片上内存？即便全部在DDR上操作，我猜这段DDR也是non-cache的，该如何设定DDR的cache呢？

Katherine Wang：

已为您咨询TI工程师，稍后给您回复

,

Katherine Wang：

A72 内核比 R5 快得多。内核设置方式（MHz、缓存设置）、使用的内存（缓存、TCM、SRAM、DDR）、编译器设置（优化级别、SIMD 的使用“““）和框架开销（裸机、Linux、RTOS）的不同可能会导致数量级的差异。需要您描述以上所有参数才能解开最终性能，需要以上每个领域的更多信息才能充分理解您的运算结果。通常使用诸如硬件 ETM 跟踪之类的方案可以提供一种方法来足够详细地在数量上查明时间的去向。

对于可能测量的小型通用代码序列（如 dhrystone），您应该会看到约 10 倍的差异与合理的代码生成。一旦代码变得更大和更多样化，差距就会变得更大，因为 A72 具有更强大的原语和相对巨大的 L1/L2/L3 缓存以及发布和跟踪很长的事务流的能力。 R5 有一个相对较小的 L1 和一个速度很快的 TCM，但是由于其有限的发布能力，超出这些序列化的访问可能会发生。一个核心属于赛车级别，另一个更像是一辆非常可靠的踏板车。对于某些 R5 类型的任务，可能需要使用 DMA 预取和覆盖来维持更高的速率。

对于您的 100 倍案例，由于缓存、内存设置、编译选项和框架开销的敏感性得我们很难下结论。然而，即使在控制良好的设置中，也预计会有一个合适的间隙。

,

霄 吴：

谢谢TI专家们的详细的回复。

有几点想深入沟通一下：

1）如您所说，我们做过dhrystone的benchmark，如果把优化等级都配置在O2，那么A72的DMIPS是R5F的8倍以上。能不能帮忙解释一下，这种情况下，为什么主频没差一个量级，DMIPS却接近了一个量级？有哪些具体的原因会导致这样的问题？

2）我们自己的基本乘加运算的测试中，A72和R5F的优化等级都是O3，并且A72的编译选项额外加了这些：”

-march=armv8-a“，R5F的编译选项都加入了这些：“

-mfloat-abi=hard -mfpu=vfpv3-d16 -mcpu=cortex-r5 -march=armv7-r”，这样保证编译器能够获取足够多的信息，比如，对于R5F而言，能编译出更加符合R5F需要的程序。这样的话，即便考虑了A72有SIMD和cache的加持，也很难想象A72会比R5F高出100倍的效率。因此，我想，一个很重要的因素，是不是A72和R5F内部的流水线结构造成的？就好比您说的”跟踪很长的事务流的能力“。其实，我对A72和R5F的内部流水线结构不是很清楚，能不能请您简单说一下？或者推荐什么资料，我自己阅读一下？

,

Katherine Wang：

我相当确定您看到从 R5 到 MSMC SRAM 或 DDR RAM 的内存访问性能很差，我们做了很多测试（测试了R5 所有可能的 MPU 配置，然后记录了 TDA4 + 外部 DDR RAM 的每个片上存储器的访问时间）。

举个例子：根据您配置 MPU 的方式，从 DDR RAM 读取 4 字节需要 R5 289 个周期。在 DDR RAM 上写入 4 个字节需要 226 个周期。 （出于1GHz 时钟的原因，您可以将其转换为 289/226 ns）。

使用相同的设置，访问 MSMC SRAM 大约需要 186（读取）和 198（写入）周期。

其次，我记得当 TI 为 R5 内核从 ti-armcl 切换到 ti-armclang 工具链时，thumb 选项对 ti-armclang 不可用。这增加了代码大小并降低了大约 10-20% 的性能。在代码中使用 memcpy 时也要多加注意，您需要告诉链接器您想要快速的 memcpy 实现，而不是小的。

,

霄 吴：

谢谢

,

Katherine Wang：

不客气，感谢您的提问

,

Katherine Wang：

关于 1) ，O2 的代码生成将因工具链供应商和工具链版本而异。与编译标志一起，用于字符串操作的库可以产生很大的不同。我看过各种实验的运行日志，其中在 R5 上获得了 0.35 到 2.11 之间的值。应该运行过去的 dhrystone 以禁止内联，如果有人这样做，他们将看到 ARM 发布的 1.6 范围内的更多值。 Dhrystone 的占用空间很小，可以存放在 L1I/D 缓存或 TCM 中。 A72 将看到类似但更大范围的 dhrystone 值。在不控制我引用的变量的情况下，可以看到非常广泛的范围。

关于 2) ，正在使用哪些工具和环以及其版本是什么？您甚至可以在其他常用芯片上制作原型，以帮助理清您的环境与原始 CPU 功能的对比。

如果您查看 ARM LTD 的 ARM R5F 和 A72MPCORE TRM，您将看到一张表，用于它们的 L1 和 L2 内存子系统。它将详细说明可以在系统中跟踪的未完成交易的数量。此问题功能与硬件流式微优化一起可以生成访问流。如果您知道您的应用程序访问配置文件、接触的内存级别、硬件跟踪限制和延迟级别，您就可以了解可实现的性能。由于 Dhrystone 绑定在 L1 内存中，任何性能差距往往更多是由于环境配置错误或编译器设置所致。您可能需要修复 dhrystone 设置才能信任其他结果。

如果您知道您的通用代码的 xMIPS 大致需要什么，您可以为您的用例足够好的预算。如果代码是典型的，缓存可以使您的代码平均运行良好。根据选择的目标内存，缓存局部性较差的代码可能会变慢。在真正的截止日期很重要的情况下，可能有必要将代码放在 TCM、本地 OCM 中，而不是像 DDR 这样的更远和共享的回忆录中。在某些情况下，需要 DMA 在处理之前将数据拉近。当然，A72 内存层次结构中和沿线的硬件性能将远远高于 R5 提供的性能。 dhrystone 的 100 倍表示您的设置中有问题。也许您的 MPU 设置不正确并且未使用缓存。