[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] ANCI-C vs Gnuradio/C++ speeeed

From: Achilleas Anastasopoulos
Subject: Re: [Discuss-gnuradio] ANCI-C vs Gnuradio/C++ speeeed
Date: Sat, 13 May 2006 10:19:36 -0400
User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)


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:
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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]