TI中文支持网
hi,My dear TI supports:
对于DSP算法的性能优化，遇到困惑了，想和大家沟通下！欢迎批评指正!
1.不知道DSP优化的极限在哪里?
算法性能优化，感觉是看不见摸不着的东西，比如一个算法函数，如果从 效果角度，
就很容易有对比性，比方说，你去实现一个图像去噪函数，那么 最终这个函数是否达到了
去噪效果，你是知道的。因为你其实在动手编程 之前，已经知道去噪的目标是为了让图像
从模糊变成清晰的，前后有对比性。
但是，性能优化就不同，你没有对比的目标，因为你没法知道代码在DSP上面 到底最好的
性能是多少？你只知道，刚开始未优化之前，去噪函数耗时值是 多少，但是，终点在哪里？
你不知道？所以，我感觉优化是一个只有起点， 没有终点的探索。感觉到现在为止，我才
真正看清楚了这一点！这也是我觉得 DSP优化难做的地方.
总之，一开始优化，我就不知道，函数中具体什么地方还可以再有提升的空间， 也不
知道优化到什么程度已经达到极限了？一切都是在摸索。
我当然知道有些人会说，TI会有很多技术文档里面会告诉你怎样优化，包括得 意技术
论坛里面好像也有不少各式各样的方法。但这又怎样呢？目标在哪里呢？ 在某种程度上来讲，
目标和终点远比方法重要！没有那个终点和目标，一切都很迷茫。 我做个比喻，这就好像，
一个人让你去装修，但是他不告诉最后究竟装修成什么样？ 达到什么标准？然后你就开始装修，
你当然知道好多装修的方法，怎么装比较好，但是 装修的标准是什么呢？目标是什么呢？为什
么你觉得这个目标已经是最好的了，没有 比你的装修更好的了？
再回到优化的话题，一个只有起点，没有终点，不知道终点在哪里的任务，想说爱你不容
易啊！ 没有对比性，没有好的，就没有坏的，一切因为没有对比，不知道好的性能是怎样，
就自然 不知道差的性能是怎样，还有哪些优化的空间！这个最致命啊！
Best Regards!
Armstrong：
我必须承认，TI那些技术文档上讲得优化方法在某些时候是有用的，但是，在另外一些
地方就没用，起不到提高性能的效果，所以对方法产生困惑，根源是没有理论支撑，为什么
有效果，为什么没有效果，都不清楚原因。
Armstrong：
no one?
Louis：
回复 Armstrong:
你好，
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以及算法本身都有很好的了解。
以上的本人的一点看法，希望可以帮到你！
CVD：
你好，过去的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优化的一些基本理解，希望对你有所帮助。
Armstrong：
回复 CVD:
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优化的一些基本理解，希望对你有所帮助。
CVD：
回复 Armstrong:
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的优势，可能只能优化个几倍；但是一些基于像素的图像处理算法，性能差个十几倍我们一点都不担心。
请问你要优化的是哪方面的算法呢？
Armstrong：
回复 CVD:
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！
CVD：
回复 Armstrong:
Hi Armstrong
单就汇编优化方面，只要一段代码的功能给定（不考虑用查表法之类的替代方式），就已经确定了该代码库的优化极限了。在选用最符合计算要求的指令，并考虑到功能单元之间的负载平衡之后，执行周期最长的那个功能单元就代表了这段代码的优化极限了。
另外，虽然专门搞优化的人比较少，但我觉得这并不是一个给人挫败感的工作，相反，它比较容易给你成就感，因为优化的效果往往比较明显。
yali xiao：
回复 CVD:
Hi,Chip Smarter: 请问怎么可以联系上你，有问题向你请教！我邮箱bvcxzzzzz@163.com
