OMAP3530：循环在 DSP 上的运行速度比在 ARM 上慢答案

【问题标题】：OMAP3530: Loop runs slower on DSP than on ARMOMAP3530：循环在 DSP 上的运行速度比在 ARM 上慢
【发布时间】：2015-11-15 19:34:58
【问题描述】：

OMAP3530 实现了一个 ARM 处理器和一个 C64x+ DSP。我有一个测试循环，我希望在 DSP 上比在 ARM 上运行得更快，但事实并非如此。

循环：

#define DIM 4
#define LIM 1000
#define MASK 3

int i, j;
uint32 arr[DIM][DIM] = {0};
uint32 rand[DIM][DIM] = {1, 5, 2, 7,
                         5, 4, 3, 8,
                         1, 2, 9, 3,
                         6, 6, 8, 4};

for (i = 0; i < LIM; i++)
    for (j = 0; j < LIM; j++)
        arr[i & MASK][j & MASK] += rand[i & MASK][j & MASK];

基准测试：

ARM：5 毫秒
DSP：25 毫秒

DSP 的重点是处理像这样的简单算术运算，所以我预计它会更快。我没有对 DSP 做太多配置，因为我对它非常缺乏经验。我相信缓存没有配置，所以正在调查，但欢迎任何其他建议。

有人可以就可能的解决方案提出建议吗？

编辑 - 将 LIM 值更改为 5000 以增加迭代次数。新基准：

ARM：120 毫秒
DSP：530 毫秒

【问题讨论】：

您的基准测试如何？您是在 ARM 端测量 DSP 时间，还是使用 DSP 上的处理器周期寄存器？从 ARM 到 DSP 以及返回的转换需要很多时间，而且你的函数并没有那么大，我希望代码花费任何时间。 _itoll(TSCH, TSCL) 将为您提供 DSP 上过期的周期数作为 64 位结果。
是的，您肯定希望启用缓存，除非您仅依赖紧密耦合的内存并使用 DMA 执行其他所有操作。一次高速缓存未命中很容易花费超过 400 个周期。你也可以在这段时间内执行 3200 条指令（每个时钟 8 条指令）。
@NilsPipenbrinck 在 ARM 端使用 GP 计时器模块进行基准测试。从 ARM 到 DSP 并返回大约需要 3.5 毫秒（这是在 DSP 上没有进行循环的时间，只是使用 IPC 发送“开始”消息和“完成”消息）。我更新了问题以使循环更长（将 LIM 更改为 5000）。我认为我们可以忽略 IPC 时间
@NilsPipenbrinck 关于 TCM：这个测试用例是一个更大的循环的一部分，该循环从数组 A（在 ARM 上定义）中的行中进行 EDMA，与它们一起修改数组 B 和 C（定义DSP），然后将 memcpys B 和 C 返回到 ARM。我是新手，但我认为我们没有明确使用 TCM，它可能会显示一些基准改进。您对如何合并它有任何参考吗？

标签： signal-processing benchmarking omap

【解决方案1】：

我以前见过这种情况。仅在非常特定的场景中使用 DSP 才能获得回报。一百万个添加肯定不是用例——它并不是说 ARM A8 在添加数字方面非常糟糕，所以你运行的代码在 ARM 上会在较慢的协处理器上高效。这根本不会加快速度。

您正在查看的特定 OMAP 具有带 NEON 的 ARM Cortex A8 内核，这意味着它具有单指令多数据 Multiply/Accumulate 指令。根据我的经验，这些甚至应该比让编译器尽可能高效地实现你的循环更快。不过，假设您也在某处进行乘法运算，里程可能会有所不同。

如果您想释放手动优化的、富含内在函数的特定于平台的代码的强大功能，请查看VOLK，它是GNU Radio 项目的衍生产品，提供了一个Vector O优化的LKernels库，涵盖通用实现，x86/MMX/大多数内核的 SSE2/AVX，以及其中一些内核的 NEON 实现。您的问题特别感兴趣的可能是16i_x5_add_quad_16i_x4 kernel。

总结：除非您确定 C64x 比功能强大的 OMAP 有很多优势，否则我不会使用它。您提到这是 DSP 上更大循环的一部分，但您还没有办法计算您的算法在 DSP 上花费的周期——我建议您将开发设置置于易于决定的状态你的实施有多好。 ARM 上的通用计时器肯定不是一个好的基准。

【讨论】：