C28X—FPU 的CFFT RFFT FIR 速度这么快吗，比F4快了7-8倍

gongcsf

200m时钟下，CFFT 250us  RFFT 150us 512阶FIR才2.5us

是不是我算错了。

shian0551

正常，不要吃惊。不要怀疑TI,dsp的能力。很多地方无可替换。

Eric2013

没快那么多，也就2倍多点。STM32F407，这里是主频168MHz的情况下PK。
https://www.amobbs.com/thread-5612142-1-1.html

Eric2013

分享个09年，TI搞的C2000系列跟STM32F1系列的全面PK

dr2001

FFT，浮点(应该是单精度的)，ARM Cortex M4F用CMSIS DSP库，C28X DSP用TI的库，C6000用TI的库，大约周期数之比是4:2:1的样子。官方文档上可以找到。
一般这些库测试默认代码和数据访问都是0等待周期。实际运行时，ARM的一般Flash会有等待周期，性能会受影响；TI的一般在内部RAM跑，性能能保证。


DSP/通用处理器的性能看怎么比：专门优化的代码/官方库 vs 一般开发人员写的代码编译后直接跑。库对库一般DSP能占优；直接编译性能差异就可能变小，甚至ARM占优。

zxq6

dr2001 发表于 2017-5-21 19:34
FFT，浮点(应该是单精度的)，ARM Cortex M4F用CMSIS DSP库，C28X DSP用TI的库，C6000用TI的库，大约周期数 ...

是的，用库，性能能飞上天，我就测过bf531跟cortrx a9,不用库，a9比531遥遥领先，用库，531甩a9几条街。

redroof

很多dsp结构就是对编译器很不友好的。想用到它内部那些特殊的硬件操作只能调库。因为c语言没有那样的语义。其实arm自带的那些dsp指令也一样。你写c不可能编译到。比如最简单的饱合加减都是如此

redroof

想想在c或者随便什么高级语言里怎么表示饱合运算就明白了： byte c=a+b>255?255:a+b; 你这样写哪个编译器会给你生成硬件的8位饱合加法…

gongcsf

买个了个28379D. 所以查了一下执行时间。现在发现dsp很不好学，alc加速器还需要汇编。其他加速器需要用库。总之感觉很复杂也比较乱。

dr2001

gongcsf 发表于 2017-5-21 22:50
买个了个28379D. 所以查了一下执行时间。现在发现dsp很不好学，alc加速器还需要汇编。其他加速器需要用库。 ...

针对性的设计意味着通用的优化手段不好用，进而要求细致的控制，多数情况下需要汇编。

选择体系架构的时候需要考虑到开发人员的能力及可投入的开发资源。
算法稳定之后，使用别人的库或者自己优化个DSP库，显然能获得更好的性能；
如果没资源、时间、人力，那盲目的用DSP不是好主意。

redroof

gongcsf 发表于 2017-5-21 22:50
买个了个28379D. 所以查了一下执行时间。现在发现dsp很不好学，alc加速器还需要汇编。其他加速器需要用库。 ...

DSP想快，唯一的方法是用汇编。
如果写C，那么DSP明显慢于同频的ARM
因为DSP的特殊硬件指令基本上无法被正常的C代码编译得到。编译器不可能聪明到那个程度
但DSP低频高速的根源就是那些特殊硬件指令啊！
如果你没有能力优化汇编算法，就别用DSP了，这属于买椟还珠。珍珠就是那些需要写汇编才能得到的特殊指令。

redroof

zxq6 发表于 2017-5-21 21:56
是的，用库，性能能飞上天，我就测过bf531跟cortrx a9,不用库，a9比531遥遥领先，用库，531甩a9几条街。 ...

A9也有DSP库的，你得用A9的DSP库和531的DSP的库来对比才公平。估计结果应该差不了多少～
要使用531的DSP库对A9写C代码，那肯定是C代码输，就算用个I7写C也不一定能胜过专用DSP。
至少10年前3G的奔4写C代码，性能远远低于300兆的TI C6000用库，我见过实物可以证明