这个Demo本来是用Java写的,出于后续开发的需要,又用VC6重写了一下。网络编码需要密集的矩阵运算,CPU开销很大,对代码执行效率要求很高,所以是断然不能用Java继续做下去的。
移植完了,开始测试性能时犯了个傻,VC6工程的默认配置是Debug模式,一上来直接就跑程序,结果发现代码效率反倒大大不如Java,惊呼原来C++在速度上也有不如Java的时候,然后还很认真地用两种语言分别跑几千万次乘法确认了一下这种速度差距。后来经同学提醒,换成Release模式再试,编码速度大概是Java的三倍左右,终于可以安心了。
然后测试解码,居然耗时是编码的10倍,原来又是个低级错误,从别处抄来的高斯消元函数,运算所用的矩阵还放在原封不动的double型里,大部分时间都耗在int和double的转换上了,有限域GF(2^8)上一共就256个元素还用double,这不有病么?
磨了半天,正式开始测试性能,测试在我的本子上进行(Intel Core Duo T2050 1.6GHz,DDR2 512M*2),Demo使用VC6编译,编码对象为一首mp3,分组大小固定为512K,每组测试用例运行100次后取平均值,结果如下表,可以看出Demo的性能还是能达到P2P流媒体系统实际要求的。
分块数 | 1 | 2 | 4 | 8 | 16 | 32 | 64 | 128 |
分块大小(KB) | 512 | 256 | 128 | 64 | 32 | 16 | 8 | 4 |
编码密度* | 1 | 1 | 1 | 1 | 0.798 | 0.421 | 0.221 | 0.116 |
编码时间(ms) | 7 | 14 | 27 | 56 | 122 | 244 | 404 | 640 |
解码时间(ms) | 7 | 17 | 33 | 65 | 129 | 252 | 494 | 981 |
* 编码密度p反映的是系数矩阵的稀疏度,两者成反比,编码密度越小则编解码速度越快,相应地矩阵线性相关概率越大,这里使用公式p=(logn+10)/n计算,其中n为分块数,可以在速度和线性相关概率间获得一个比较理想的平衡点。