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

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Achilleas A. (Guest)
on 2006-05-13 18:22
(Received via mailing list)
Al,

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.

Achilleas

=============================================



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:
from: howto_trellis_encoder_si.cc
===============
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.