差点就悲剧了。。。。
算法原来是C的，同事给改成LV的，刚改出来的算法全局变量满天飞，写的时候是方便了，可是跑起来就悲剧了，一秒的数据需要两秒多来处理。我是强忍着头晕目眩给改成了用移位寄存器的。测试之下，效果不错，一秒的数据50个毫秒就处理完了。
本以为万事OK了，让同事照着写第二种算法就好了。同事照着写了，然后放RT底下跑，一秒的数据需要一秒半来处理。我们基本上把能做的优化措施都给做了，可是还跑成这样。还有一个多星期就要出去做实验了，程序跑成这样，到时我可就悲剧了。。。。
没办法，现在硬件就算想买好点的周期也来不及，只能回到最开始的C代码了。用C写的一个dll来实现第二种算法，在PC上效率足足提高了能有至少5倍。接下来折腾怎么编译成RT（VxWorks）下的out文件，单位的破网，上NI的网站比老牛拉破车还慢，可把我给急坏了。回到家终于在NI网站上找到了编译的方法，还不错，文档还例子都很详细，照葫芦画瓢就搞定。今天一测，同样的算法处理一秒数据只需要90个毫秒不到的时间，热泪啊~~~~~~
总结一下，这个故事告诉我们，只会LabVIEW还是不够滴~~
你这种温拿应该单独配一个3g上网卡~~
这个故事高速我们，不该用lv的时候不应该用lv
这个故事还告诉我们，熊猫不只是lv大牛~~
必要的时候，还会有人建议汇编提高效率~~
能解释一下吗?
LV的小波和相关算法有问题？
这效率也太低了吧
如果真的是这样只可能是LV里面的小波和相关算法和你用C写的不一样
或者NI写这部分算法的人脑子进水
拜见大牛
这个re
自己照着原始C代码用lv实现的FIR、小波和相关算法，算法并不复杂，本来想着还是用同一个工具来实现是最好的，结果就遇上了这样的效率问题。。。。
也许lv自带的那些算法效率都很好，毕竟还是用C或者汇编这类的来实现的，效率还是很好的，但是用lv来自己实现对效率要求高点的算法就得多测试一下和考虑一下了。
那天改完都差点晕菜了。。。。
线太多了。。。。
就算lv实现的效率还不错，可是这么来实现，不出错可能都不太容易。。。。
LV不也是C的引擎么，效率差这么多我觉得有点说不过去。
这你就搞错一个概念了，C引擎没错，但是它有自己的编译运行方式，这个是关键
我觉得如果是这样的话他给做成基于C的应该也没什么难度吧
做成一个dll之类
这个我不太懂，但是觉得应该有办法解决的吧
不是说了是RT底下么，要是windows我还弄不出来那才是真正的悲剧。。。。
没用过Eclipse，没用过GCC，让你去干这个你也会没底的
OTZ
恭喜啊, 碰到问题和挑战, 人才能进步
呵呵 果然还在这里啊~
其实看看能否考虑直接在FPGA中实现信号处理， 现在已经有很多现成IP了。
FPGA上的FIR只到8阶，我这可是到1000阶的。。。。
ms在网上看到过对FPGA和DSP的评价，FPGA强项还是在控制方面，DSP信号处理比较强大。虽然在NI网站上看到有第三方的cRIO DSP模块，但是对我们来说购买什么的好像还不是很方便，倒是希望能够看到NI出的cRIO上用的DSP模块。
是的， 如果是1000阶的就算了……
你这样的高手，应该多去 gsdzone 那边回答回答问题， 这边好像问题越来越少了 。
当年熊猫为啥没去贵公司呢
因为有更好的坑 恩