Forum: GNU Radio Re: ANCI-C vs Gnuradio/C++ speeeed

Announcement (2017-05-07): is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see and for other Rails- und Ruby-related community platforms.
C369ebbe1655201988e376af57460f23?d=identicon&s=25 Achilleas Anastasopoulos (Guest)
on 2006-05-13 16:22
(Received via mailing list)

the encoder IS NOT the bottleneck in this communication system.
It is the Viterbi Algorithm that is responsible for 80%-90%
of the overall time.



You are returning a vector by value:
from fsm.h:
   std::vector<int> NS () const { return d_NS; }
   std::vector<int> OS () const { return d_OS; }
   std::vector<int> PS () const { return d_PS; }
   std::vector<int> PI () const { return d_PI; }

inside a loop, double nested:
for (int m=0;m<nstreams;m++) {
   // stuff deleted
   for (int i = 0; i < noutput_items; i++){
     out[i] = (int) d_FSM.OS()[d_ST_tmp*d_FSM.I()+in[i]];
     d_ST_tmp = (int) d_FSM.NS()[d_ST_tmp*d_FSM.I()+in[i]];

I am amazed that you are only getting a 5-fold reduction!

A few years ago, I made some tests, in gnucap.  I found that in
all tests there was no run time speed penalty for using STL,
even in speed critical tight loops.  By using it, I was able to
do things that would have been impractical without it,
resulting in a net speed improvement.  Compiling is slower, but
I can live with that.
This topic is locked and can not be replied to.