Closed mpbraendli closed 6 years ago
One thing I notice is that dab2eti
now takes three times the CPU load as before...
This is a No-Go for me. Thanks for finding that out.
I haven't yet checked where this comes from, but this could possibly be fixed so that we can benefit from the other improvements.
I'm glad I asked first :-) I wonder if this comes from the viterbi decoder (spiral viterbi versus ka9q), or from other parts. If I find the time, I will compare the performance using gprof or valgrind's callgrind.
I do see an increase in CPU usage of around 2x. I wanted to compare with and without spiral viterbi enabled, but I'm not able to compile it on "master", whereas on elgroj_tuningstability it works.
cmake . -DCMAKE_BUILD_TYPE=Debug -DENABLE_SPIRAL_VITERBI=On
make
[...]
CMakeFiles/dab2eti.dir/viterbi_spiral.c.o: In function `update_viterbi_blk_GENERIC':
/[...]/dabtools/src/viterbi_spiral.c:312: undefined reference to `renormalize'
Are you able to compile master with spiral viterbi?
@mpbraendli Apologies for not responding to this for so long. I'll check things out and report back.
The issue is -DCMAKE_BUILD_TYPE=Debug master builds fine in release mode.
I am guessing that renormalize is marked as inline without being static is the problem?
Yes it is, I will send in a pull request against master.
Pull request #15 should deal with this.
I've merged elgroj/tuningStability into our master branch, and created the branch elgroj_tuningstability. I observe faster locking with my receiver using that branch. Are you ok if I push those changes into "master"? Cheers mpb