DSP优化的困惑!

我必须承认，TI那些技术文档上讲得优化方法在某些时候是有用的，但是，在另外一些

地方就没用，起不到提高性能的效果，所以对方法产生困惑，根源是没有理论支撑，为什么

有效果，为什么没有效果，都不清楚原因。

no one?

你好，

  DSP的算法优化是一个积累和循序渐进的过程，特别说来，DSP在图像领域的应用是相当广泛的，特别是其独特的流水设计。拿C6000 DSP来说，其有2组功能单元，分辨的是A,B两侧，各4个单元，共8级流水。故你可以简要得知你的最高理论并行度是8，也就是当你profile得出的deocde total instructions是你的理论需要运行的指令数，那么理论的极限，不考虑CPU&DATA stall与Miss还有流水排空时间, 8的并行度就是极限。也就是约为Total/8 cycles.

   关于你说的，一开始优化就不知道那个函数有提升空间的问题，这点确实有难度，需要profile才能知道你是否有优化空间，一般来说，可以在函数设计之初就未后续的优化进行铺垫，比如，可以将计算量集中的算法放到一个函数中，可以通过破坏循环，将无因果关系的计算，放到一起，复用流水单元。另外在设计数据的结构的时候应该尽量考虑到后续能多使用优化的并行指令， 如ADD4，SUB4，MPY2等等，单指令多计算。

   总的说来，优化需要积累，需要多DSP的流水，硬件单元，cache以及算法本身都有很好的了解。

   以上的本人的一点看法，希望可以帮到你！

你好，过去的9年中，我所在团队（平均保持在10人以上）的工作重点一直聚焦于DSP（TI及其他公司的DSP平台）的优化， 说说我对DSP优化的理解吧。

对于DSP上的优化，我一直坚持两个观点：

1、DSP上的优化没有极限：你始终可以找到办法进一步提升代码执行效率，代码上的优化空间很小了，你可能在算法方面又 找到了优化空间。随着优化技能的提升，每当回头看以前的优化工作，都可以发现有很多可以提升的地方。一个例子是我们 发现即使是TI官方发布的算法库，比如imgLib，也有优化的空间，因此imgLib里面的某些函数我们使用的是自己进一步优 化后的版本。

2、DSP上优化的方法也可以不断提升：随着对DSP平台理解的加深，及优化技能的不断提升，你可以不断地改进自己的优化 方法，提高优化工作的效率。例如TI的线性汇编，也许刚开始接触优化的时候可以尝试一下，但到最后我们是彻底放弃了这 个工具。我们一直在尝试提升优化开发工作的效率，包括工作流程的改进，以及开发各种帮助开发的工具软件。举个例子， 我们的第一个优化项目是在一个DSP平台上开发一个Baseline的H.264解码器，9个人用了6个月时间；几年之后，我们在同 一个DSP平台上优化一个Mpeg2的解码器，2个人只用了2个月时间。

虽然我认为从技术上讲DSP优化没有极限，但是从一个项目的角度来说，DSP的优化是有极限的，因为你的资源（人力、时间 ）都是有限的。此时的优化极限你可以认为是以最短的时间达到优化性能指标，给测试和产品集成留下足够的时间。也不是 所有的优化都能达到预定目标，因此在开发的过程中，你需要根据自己的经验尽可能早地准确判断出优化目标是否合理，以 便尽可能早地调整项目目标。

在不考虑算法层面优化的情况下（因为这取决于你对算法的熟悉程度），就代码优化技术而言，说白了就是两个核心：
1、汇编：通过编写高效的并行汇编，让你的程序运行得尽可能快。虽然通过优化编译选项和C语言层面的优化技术能在一定程度上提升，但如果算法移植到DSP平台上和优化目标差距很大（十几倍或几十倍的优化目标），我建议尽早开始使用汇编的方式。固然TI的编译器和优化器是行业中最好的，但是通过它们得到的结果和手工汇编的差距仍然非常明显。我们过去开发的各种视频编解码算法中，手工汇编的代码量一般占整体代码量的60%-80%。当然，手工开发DSP的并行汇编对很多人来说是一项巨大的挑战，我们观察到很少有公司真正发挥出它的威力，但就我们自己而言，一般都是编写汇编的工作安排在项目后期的两三个星期，待其他方面的优化工作结束后，所有人集中精力写两周汇编，一般都可以达到我们的优化目标。
2、数据流：但光有高效的函数代码还不够，需要通过数据流的调整，在程序需要访问数据的时候及时提供相关的数据。从DDR中读取一个数据的时间可能远远超出你的想象，可能需要十几个周期，也可能需要几十个周期，具体时间和很多因素相关。通过DMA的后台数据搬移，合理利用Cache机制可以解决数据流上的大部分问题，但要在这方面做得很好是非常有难度的，必须从算法的架构设计上就加以考虑。

以上是我对DSP优化的一些基本理解，希望对你有所帮助。

Chip Smarter 说：

你好，过去的9年中，我所在团队（平均保持在10人以上）的工作重点一直聚焦于DSP（TI及其他公司的DSP平台）的优化， 说说我对DSP优化的理解吧。

对于DSP上的优化，我一直坚持两个观点：

1、DSP上的优化没有极限：你始终可以找到办法进一步提升代码执行效率，代码上的优化空间很小了，你可能在算法方面又 找到了优化空间。随着优化技能的提升，每当回头看以前的优化工作，都可以发现有很多可以提升的地方。一个例子是我们 发现即使是TI官方发布的算法库，比如imgLib，也有优化的空间，因此imgLib里面的某些函数我们使用的是自己进一步优 化后的版本。

2、DSP上优化的方法也可以不断提升：随着对DSP平台理解的加深，及优化技能的不断提升，你可以不断地改进自己的优化 方法，提高优化工作的效率。例如TI的线性汇编，也许刚开始接触优化的时候可以尝试一下，但到最后我们是彻底放弃了这 个工具。我们一直在尝试提升优化开发工作的效率，包括工作流程的改进，以及开发各种帮助开发的工具软件。举个例子， 我们的第一个优化项目是在一个DSP平台上开发一个Baseline的H.264解码器，9个人用了6个月时间；几年之后，我们在同 一个DSP平台上优化一个Mpeg2的解码器，2个人只用了2个月时间。

虽然我认为从技术上讲DSP优化没有极限，但是从一个项目的角度来说，DSP的优化是有极限的，因为你的资源（人力、时间 ）都是有限的。此时的优化极限你可以认为是以最短的时间达到优化性能指标，给测试和产品集成留下足够的时间。也不是 所有的优化都能达到预定目标，因此在开发的过程中，你需要根据自己的经验尽可能早地准确判断出优化目标是否合理，以 便尽可能早地调整项目目标。

在不考虑算法层面优化的情况下（因为这取决于你对算法的熟悉程度），就代码优化技术而言，说白了就是两个核心：
1、汇编：通过编写高效的并行汇编，让你的程序运行得尽可能快。虽然通过优化编译选项和C语言层面的优化技术能在一定程度上提升，但如果算法移植到DSP平台上和优化目标差距很大（十几倍或几十倍的优化目标），我建议尽早开始使用汇编的方式。固然TI的编译器和优化器是行业中最好的，但是通过它们得到的结果和手工汇编的差距仍然非常明显。我们过去开发的各种视频编解码算法中，手工汇编的代码量一般占整体代码量的60%-80%。当然，手工开发DSP的并行汇编对很多人来说是一项巨大的挑战，我们观察到很少有公司真正发挥出它的威力，但就我们自己而言，一般都是编写汇编的工作安排在项目后期的两三个星期，待其他方面的优化工作结束后，所有人集中精力写两周汇编，一般都可以达到我们的优化目标。
2、数据流：但光有高效的函数代码还不够，需要通过数据流的调整，在程序需要访问数据的时候及时提供相关的数据。从DDR中读取一个数据的时间可能远远超出你的想象，可能需要十几个周期，也可能需要几十个周期，具体时间和很多因素相关。通过DMA的后台数据搬移，合理利用Cache机制可以解决数据流上的大部分问题，但要在这方面做得很好是非常有难度的，必须从算法的架构设计上就加以考虑。

以上是我对DSP优化的一些基本理解，希望对你有所帮助。

Hi Chip Smarter:

    非常感谢您的回答。也非常赞同您对于优化理解和看法。我完全同意您的方法 总结

(抛开算法层面的优化考虑)。     

     但是，还是感觉没有打消我心头上的困惑，以实际例子来说明我的困惑。比方 算法A

是待优化的算法，优化之前算法A的DSP耗时是40ms，在不修改算法的情况下 进行优化。

此时，领导过来跟我说，让我在一周时间内把算法优化到10ms以内。     

      这时，我的困惑就来了，这个目标合理么？谁能证明这个目标是能够被达到的？ 我完全

不知道，我不知道在不改算法的前提下，算法A在DSP上能够被优化的极限是多少 ms，

我只知道算法A在-O3，DDR enable 这些最基本，举手之劳的优化方法下，耗时是 40ms，

我自己都不知道算法A在DSP上最快能跑多少？我怎么向领导证明这个算法A在 DSP上被

优化到10ms 是不可能的。      

        如果说我不能够证明10ms是不可能的，那么就意味着默许了10ms是可以做到的。

 那么实际我做不到，我永远都是没有完成目标。      

        所以，我最困惑的是，如何客观评估自己的优化目标，客观的知道自己的算法A 在DSP

上的优化极限是多少？客观的知道自己还有多少优化的空间。一切都是以客观分析 为依据，

不是领导说多少就是多少ms，也不是自己说多少ms，不以人的意志为转移。到底 如何评估

目标是最想知道的，这也是为什么，我要问DSP优化的极限是多少？     

       但是，Chip Smarter 如果按照你所说的DSP优化没有极限的话，我该如何向领导 交差，

怎么证明领导提出的优化任务能否达到。这是我的困惑。     

       最后，我的邮箱是steve_feinimoshu@163.com，方便的话能否交换您的邮箱地址 ，

我也是专职做优化的，希望和您进一步交流。无论怎样，万分感谢！

      Best Regards！    

Hi Armstrong

我说的DSP优化和优化方法没有极限只是我自己的一个信念，促使我不断地去在这方面进行提升，不用在意我说的这些。

要证明你的项目设定的目标是否合理，需要一些客观数据的支持，这些数据可能包括：

1、目标硬件平台的实测性能（主要是数据访问方面的），我们在拿到一个新的硬件平台时，所做的第一件事情就是详细测试它的处理访问能力，包括单独长访问需要花多少个cycle，从DDR用DMA读数据到片内会花多少时间（换算成bytes/cycle），DMA从片内写数据到DDR，通过cache访问指定数据和代码会花多少cycle，等等，这些数据就是日后评估的基础。

2、通过测试找到算法运行真正耗时的关键模块，并对关键模块的运算处理进行分析：它进行了那些计算，这些计算的数据宽度是多少等等。不知道你是怎样测试算法执行速度的？算法执行时间的测试一定要准确，一般需要一层一层地细化下去，知道找到耗时的关键函数，甚至是代码块，你才能明确今后的优化重点在什么地方。TI的DSP从C64x+开始，DSP Core内部就提供了一个同主频的计数器，很方便，甚至一些隐含的delay都可以测出来。

3、结合一些优化开发的历史经验数据，不同类型的处理能优化的空间也是不同的。DSP的代码执行效率说到底还是靠多指令并行和单指令多数据来完成的，但是并不是所有的算法都能把这些方面利用起来。比如Haar特征检测之类的算法，由于有些计算的中间结果需要32位数据来保存，所以很难发挥出DSP的优势，可能只能优化个几倍；但是一些基于像素的图像处理算法，性能差个十几倍我们一点都不担心。

请问你要优化的是哪方面的算法呢？

Hi,Chip Smarter:

    1.

    感觉还是没有直接回答我的问题，我觉得这个问题与优化什么算法没有关系！

    hi,Chip Smarter,我可不可以这样理解你的看法。你的意思就是说: DSP优化不存在一个

极限的问题，只是一个时间的问题，只要时间充足，哪怕原来优化前的时间是100ms，

最终一定能够从100ms 被优化到1ms。可以这么理解么？

     2.

   我现在，感觉如果不考虑算法层面优化，也不考虑数据流方面EDMA和cache优化，

单单从汇编角度，流水线和指令并行角度，对于一个具体的函数，汇编asm文件中

会给出一个反馈信息，从这里的反馈信息中应该是可以看出目前的代码是否还有优化

的空间。

3.

我现在觉得，问“这个代码或者函数是不是还有优化的空间”就好象判断一个人

是不是有前途一样，很难给出明确答复，因为这个要用时间来证明，你不能说这个

代码完全没有优化空间了，就像谁也不能保证某个人以后就一定没有前途，说不定

以后事业有成一样。总之，很难明确答复。是不是可以借用鲁迅名言，时间就像海

绵里的水，只要想挤，总还是有的。那么对于优化，优化空间也像海绵垫的水，只要

想挤还是有的。

4.

但是，针对另外一种情况，上面3的情况，似乎又不正确。就想百米赛跑一样，现在

的成绩最快也要8-9s吧，无论怎样，也不可能无限制到1s吧？ 这点是不是说明，优化

还是有限制的，比如原来40ms的东西，无论你再怎么挤，总不能一下子挤到1ms去吧。

只是，我们很难知道这个极限在哪里？

5.

说点题外话，优化的确是一个小众的，冷门的专业，是一个每天都会让你有挫败感的工作。

再加上，其实现在很多算法东西，ti都在努力做成硬件，像以前的编解码算法，现在已经

有专用的芯片来完成了。

说了这么多，还是很难用肯定的回答，来说，优化到底是有止境，还是无止境。的确很

深奥，觉得更像是一个哲学问题。

Best Regards！

Hi Armstrong

单就汇编优化方面，只要一段代码的功能给定（不考虑用查表法之类的替代方式），就已经确定了该代码库的优化极限了。在选用最符合计算要求的指令，并考虑到功能单元之间的负载平衡之后，执行周期最长的那个功能单元就代表了这段代码的优化极限了。

另外，虽然专门搞优化的人比较少，但我觉得这并不是一个给人挫败感的工作，相反，它比较容易给你成就感，因为优化的效果往往比较明显。

Hi,Chip Smarter:  请问怎么可以联系上你，有问题向你请教！我邮箱bvcxzzzzz@163.com