Re: [Discuss-gnuradio] ANCI-C vs Gnuradio/C++ speeeed
On Sun, May 14, 2006 at 08:54:19AM -0700, Eric Blossom wrote:
> On Sun, May 14, 2006 at 09:40:16AM -0400, Achilleas Anastasopoulos wrote:
> >
> > I run the following simple test, compiled with
> > g++ test.cc -o test
> > and I got the following results.
> > I see a 4-fold speed reduction using STL.
> > What am I doing wrong?
>
> You're not using the "standard level of optimization" -O2
If you look at the object code it's pretty clear why the STL version
is so much slower. Given this code (which I assume is okay; I'm not
normally a C++ programmer) and g++ 3.4.2:
#include
void foo(int const n,int const m,std::vector &x)
{
for(int i = 0;i < n;i++)
for(int j = 0;j < m;j++)
x[j] = i / (j + 1);
}
void foo(int const n,int const m,int x[])
{
for(int i = 0;i < n;i++)
for(int j = 0;j < m;j++)
x[j] = i / (j + 1);
}
Without any -O option, the template version of foo() actually calls
another function. That function calls three other functions, and one
of them calls yet another function. I think this happens on every
loop iteration, presumably as part of accessing x[j]. These extra 5
functions are generated as a side effect of the templates. The plain
array version of foo(), on the other hand, doesn't need to call
anything and just accesses the memory directly.
When you add -O2, the extra functions go away and both versions of
foo() end up producing nearly identical object code.
As an extreme example of how a small amount of STL can produce lots of
little functions, try this:
#include
#include
using namespace std;
int main() { map x; x["y"] = "z"; return 0; }
With g++ 3.4.2 and no -O option, that produces 63 functions. With
-O2, it drops down to 6 functions and about 1/3 less assembly code.
When I encountered this example in a co-worker's code several years
ago the situation was much worse: their version of gcc was generating
around 100 extra functions, and some of them had names so long that
the system's assembler was actually refusing to accept gcc's output.
-Dave Dodge
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ANCI-C vs Gnuradio/C++ speeeed
On Sun, May 14, 2006 at 11:13:47AM -0400, Achilleas Anastasopoulos wrote: > > Yes, with -O the STL code is only 1.7 times > slower. > > Even better, with -O2 the two cases execute > in exactly the same time. > > So, is Gnuradio compiling with -O2 > option? Yes. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ANCI-C vs Gnuradio/C++ speeeed
On Sun, May 14, 2006 at 09:40:16AM -0400, Achilleas Anastasopoulos wrote: > > I run the following simple test, compiled with > g++ test.cc -o test > and I got the following results. > I see a 4-fold speed reduction using STL. > What am I doing wrong? > > Achilleas You're not using the "standard level of optimization" -O2 E.g., [EMAIL PROTECTED] tmp]$ g++ -O2 test.cc -o test [EMAIL PROTECTED] tmp]$ time ./test 10 1 real0m1.797s user0m1.792s sys 0m0.004s [EMAIL PROTECTED] tmp]$ time ./test 10 2 real0m1.797s user0m1.796s sys 0m0.000s ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ANCI-C vs Gnuradio/C++ speeeed
Yes, with -O the STL code is only 1.7 times
slower.
Even better, with -O2 the two cases execute
in exactly the same time.
So, is Gnuradio compiling with -O2
option?
Achilleas
Philip Balister wrote:
Try g++ -O test.cc -o test
That solved the problem for me.
Philip
Achilleas Anastasopoulos wrote:
I run the following simple test, compiled with
g++ test.cc -o test
and I got the following results.
I see a 4-fold speed reduction using STL.
What am I doing wrong?
Achilleas
---
$ time ./test 1 1
real0m0.121s
user0m0.120s
sys 0m0.001s
while
$ time ./test 1 2
real0m0.462s
user0m0.459s
sys 0m0.003s
and
$ time ./test 10 1
real0m1.185s
user0m1.184s
sys 0m0.001s
while
$ time ./test 10 2
real0m4.597s
user0m4.595s
sys 0m0.002s
--
test.cc=
#include
int main(int ac,char **av) {
const int M = 1000;
std::vector y(M);
int *x;
x=(int*)malloc(M*sizeof(int));
int N=atoi(av[1]);
if(atoi(av[2])==1) {
for (int i=0;i
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ANCI-C vs Gnuradio/C++ speeeed
I run the following simple test, compiled with
g++ test.cc -o test
and I got the following results.
I see a 4-fold speed reduction using STL.
What am I doing wrong?
Achilleas
---
$ time ./test 1 1
real0m0.121s
user0m0.120s
sys 0m0.001s
while
$ time ./test 1 2
real0m0.462s
user0m0.459s
sys 0m0.003s
and
$ time ./test 10 1
real0m1.185s
user0m1.184s
sys 0m0.001s
while
$ time ./test 10 2
real0m4.597s
user0m4.595s
sys 0m0.002s
--
test.cc=
#include
int main(int ac,char **av) {
const int M = 1000;
std::vector y(M);
int *x;
x=(int*)malloc(M*sizeof(int));
int N=atoi(av[1]);
if(atoi(av[2])==1) {
for (int i=0;ihttp://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ANCI-C vs Gnuradio/C++ speeeed
On Fri, May 12, 2006 at 07:23:10PM -0400, Achilleas Anastasopoulos wrote: > Ilia, > > I did profile two versions of the code (one with ANCI-C > and another with C++ STL ). > It seems that the bottleneck is in accessing > elements which is more expensive than accessing simple > array elements. > > As an example > vector x; > x[10]; > > is much slower than > > int *y; > y[10] > > > The reason i started with was the clean way that > these were instantiated, etc. > > Anyway, I am now reimplementing the code without using ; > will get back to you on this. Achilleas, I think you're barking up the wrong tree. There's no reason that reading or writing x[foo] should be slower than y[foo] particularly in a loop. The compiler will load the underlying pointer into a register and perform a simple indexed load or store. If you're so inclined, objdump -d example.o or objdump -d example will show you disassembled code. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ANCI-C vs Gnuradio/C++ speeeed
On Fri, May 12, 2006 at 12:45:24PM -0400, Achilleas Anastasopoulos wrote: > I have some new data on this. > > Going from ANSI-C to C++ (NO Gnuradio) using > STL vectors results in a 5-fold speed reduction! > > So Gnuradio seems to be responsible for the remaining > 4-fold reduction (for an overall 20-fold as I reported earlier). > > I am OK with Gnuradio resulting in this 4-fold speed reduction, > but I cannot swallow the fact that STL sucks that bad :-( !!! > > I believe that this is not specific to my application, but should be > true for any algorithm that uses vectors/matrices. > I wonder if anyone can corroborate this. > > Achilleas Send the code ;) What compiler command line options are you using? Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ANCI-C vs Gnuradio/C++ speeeed
On Fri, May 12, 2006 at 10:30:46AM -0400, Achilleas Anastasopoulos wrote: > > I have noticed a huge speed dissadvantage when comparing my > ANSI-C implementation of a Viterbi decoder with my Gnuradio > implementation. The core code is pretty much the same, except > that in the Gnuradio implementation I am using STL vectors. > > It seems that Gnuradio is about 20 times SLOWER than ANSI-C!!! > I was wondering if this has to do with Gnuradio itself (buffering + > python + other fat), or with the fact that I had to translate all > my ANCI-C code to C++ and use STL. > > Does anyone have similar experiences? > > Achilleas It shouldn't be any slower unless you're making life tough for the C++ compiler (that is, using constructs that it can't optimize away). If you'll send me both pieces of code (off-list) along with the benchmarking framework, I'll take a quick look at them. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ANCI-C vs Gnuradio/C++ speeeed
Al,
thanks for pointing out this mistake.
I changed this in the code.
I guess when I was using ANSI-C I was forced
to use pointer etc, but with C++ it is
easy to fall in to these traps.
Anyway, as I said to my previous post,
this does not contribute anything noticable to the
speed reduction, as most of the action is happening in
the file howto_viterbi_X.cc
and in particular in the function
void viterbi_algorithm(const int I, const int S, const int O,
const std::vector &NS,
const std::vector &OS,
const std::vector &PS,
const std::vector &PI,
const int K,
const int S0,const int SK,
const float *in, @TYPE@ *out,
std::vector &trace)
Thanks again,
Achilleas
---
On Friday 12 May 2006 18:34, al davis wrote:
>> You are returning a vector by value:
>> from fsm.h:
>> //
>> std::vector NS () const { return d_NS; }
>> std::vector OS () const { return d_OS; }
>> std::vector PS () const { return d_PS; }
>> std::vector PI () const { return d_PI; }
>> //
Returning by value means that the copy constructor is invoked to
make the copy. It is in the .cc file, forcing it to be
explicitly called, complete with stack frame overhead, but this
is not what is important. Copying a vector is done by a loop,
so it is an O(n) operation.
To return by reference, add a &
std::vector & PI () const { return d_PI; }
Now it won't make a copy, but the vector is modifyable. You
might want:
const std::vector & PI () const { return d_PI; }
to protect it.
A double nested loop takes time O(n2). By putting O(n)
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ANCI-C vs Gnuradio/C++ speeeed
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 NS () const { return d_NS; }
std::vector OS () const { return d_OS; }
std::vector PS () const { return d_PS; }
std::vector PI () const { return d_PI; }
//
inside a loop, double nested:
from: howto_trellis_encoder_si.cc
===
for (int m=0;mhttp://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ANCI-C vs Gnuradio/C++ speeeed
al davis wrote: > On Friday 12 May 2006 18:24, Ilia Mirkin wrote: >> >> vector x; >> x[0] = 5; > > Your code is wrong. The vector x is of size zero. It should > crash. > > You need: > vector x; > x.reserve(5); > x[0] = 5; You mean resize(5). After a reserve() size is unchanged. [[Though I've seen the OP's note that his example wasn't intended to be complete working code]] -- Cheers, John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ANCI-C vs Gnuradio/C++ speeeed
Responding to my own post ...
Here's why the difference is so important:
On Friday 12 May 2006 18:34, al davis wrote:
> You are returning a vector by value:
> from fsm.h:
> //
> std::vector NS () const { return d_NS; }
> std::vector OS () const { return d_OS; }
> std::vector PS () const { return d_PS; }
> std::vector PI () const { return d_PI; }
> //
Returning by value means that the copy constructor is invoked to
make the copy. It is in the .cc file, forcing it to be
explicitly called, complete with stack frame overhead, but this
is not what is important. Copying a vector is done by a loop,
so it is an O(n) operation.
To return by reference, add a &
std::vector & PI () const { return d_PI; }
Now it won't make a copy, but the vector is modifyable. You
might want:
const std::vector & PI () const { return d_PI; }
to protect it.
A double nested loop takes time O(n^2). By putting O(n) inside,
it is now O(n^3). For n large, you will certainly see a
difference.
C++ optimization has different rules than C. In some ways it is
a lower level language.
For example, take the statement:
int i;
It has different meanings
In C: There exists an object of type int called i.
In C++: Construct an object of type int called i now.
The language is full of these subtleties. They make a
difference.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ANCI-C vs Gnuradio/C++ speeeed
Quoting al davis <[EMAIL PROTECTED]>: On Friday 12 May 2006 18:24, Ilia Mirkin wrote: Also, when you do vector x; x[0] = 5; keep in mind that internally it instantiates a new int object, and then calls operator= on it. The compiler might optimize this to a certain extent, but certainly not to the level of simplicity of a single memory access/write. A good compiler will optimize it that well. Your code is wrong. The vector x is of size zero. It should crash. You need: vector x; x.reserve(5); x[0] = 5; or: vector x(5); x[0] = 5; OK, I suppose I was just giving an *idea* of what I was comparing rather than fully working compiled code. But you're right -- I just checked the generated code, and the only difference came from the array being on the stack vs somewhere on the heap, which is to be expected. I hadn't realized that compilers had come this far in terms of STL optimization. -Ilia ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ANCI-C vs Gnuradio/C++ speeeed
Ilia, I did profile two versions of the code (one with ANCI-C and another with C++ STL ). It seems that the bottleneck is in accessing elements which is more expensive than accessing simple array elements. As an example vector x; x[10]; is much slower than int *y; y[10] The reason i started with was the clean way that these were instantiated, etc. Anyway, I am now reimplementing the code without using ; will get back to you on this. Achilleas Ilia Mirkin wrote: Quoting Achilleas Anastasopoulos <[EMAIL PROTECTED]>: Ilia, you can find the relevant code here: http://www.eecs.umich.edu/~anastas/gnuradio/ looking forward to your comments. Achilleas Have you tried profiling the code? This would allow you to definitively determine what the culprits are. From a quick glance you aren't doing anything *blatantly* wrong (i.e. you're passing vectors around by cref, which is good). However, from a performance perspective, vector<> isn't really what you want to use in this case. You're just dealing with basic types, e.g. float/int/etc -- they don't have weird constructors/destructors, and thus have to do a lot more work. Also, when you do vector x; x[0] = 5; keep in mind that internally it instantiates a new int object, and then calls operator= on it. The compiler might optimize this to a certain extent, but certainly not to the level of simplicity of a single memory access/write. Note that the gnuradio interface for, e.g. (general_)work uses these primitive pointers (i.e. a vector<> of simple arrays). There doesn't really seem to be a good reason for you to be using vector<> in your code... (Do correct me if I'm wrong...) -Ilia Ilia Mirkin wrote: Would you care to share your C++ implementation (e.g. post a link) so that it might be critiqued rather than say things like "C++ is slower than C"? -Ilia Quoting Achilleas Anastasopoulos <[EMAIL PROTECTED]>: I have some new data on this. Going from ANSI-C to C++ (NO Gnuradio) using STL vectors results in a 5-fold speed reduction! So Gnuradio seems to be responsible for the remaining 4-fold reduction (for an overall 20-fold as I reported earlier). I am OK with Gnuradio resulting in this 4-fold speed reduction, but I cannot swallow the fact that STL sucks that bad :-( !!! I believe that this is not specific to my application, but should be true for any algorithm that uses vectors/matrices. I wonder if anyone can corroborate this. Achilleas Robert W McGwier wrote: Yes. I was comparing Phil Karn's native code to it and it runs at least 20 times faster. Bob Achilleas Anastasopoulos wrote: I have noticed a huge speed dissadvantage when comparing my ANSI-C implementation of a Viterbi decoder with my Gnuradio implementation. The core code is pretty much the same, except that in the Gnuradio implementation I am using STL vectors. It seems that Gnuradio is about 20 times SLOWER than ANSI-C!!! I was wondering if this has to do with Gnuradio itself (buffering + python + other fat), or with the fact that I had to translate all my ANCI-C code to C++ and use STL. Does anyone have similar experiences? Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- ___ Achilleas Anastasopoulos Associate Professor EECS Department Voice : (734)615-4024 UNIVERSITY OF MICHIGANFax : (734)763-8041 Ann Arbor, MI 48109-2122 E-mail: [EMAIL PROTECTED] URL: http://www-personal.engin.umich.edu/~anastas/ ___ -- ___ Achilleas Anastasopoulos Associate Professor EECS Department Voice : (734)615-4024 UNIVERSITY OF MICHIGANFax : (734)763-8041 Ann Arbor, MI 48109-2122 E-mail: [EMAIL PROTECTED] URL: http://www-personal.engin.umich.edu/~anastas/ ___ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ANCI-C vs Gnuradio/C++ speeeed
On Friday 12 May 2006 18:24, Ilia Mirkin wrote: > Also, when you do > > vector x; > x[0] = 5; > > keep in mind that internally it instantiates a new int > object, and then calls operator= on it. The compiler might > optimize this to a certain extent, but certainly not to the > level of simplicity of a single memory access/write. A good compiler will optimize it that well. Your code is wrong. The vector x is of size zero. It should crash. You need: vector x; x.reserve(5); x[0] = 5; or: vector x(5); x[0] = 5; ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ANCI-C vs Gnuradio/C++ speeeed
On Friday 12 May 2006 17:56, Achilleas Anastasopoulos wrote:
> you can find the relevant code here:
>
> http://www.eecs.umich.edu/~anastas/gnuradio/
>
> looking forward to your comments.
You are returning a vector by value:
from fsm.h:
//
std::vector NS () const { return d_NS; }
std::vector OS () const { return d_OS; }
std::vector PS () const { return d_PS; }
std::vector PI () const { return d_PI; }
//
inside a loop, double nested:
from: howto_trellis_encoder_si.cc
===
for (int m=0;mhttp://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ANCI-C vs Gnuradio/C++ speeeed
Quoting Achilleas Anastasopoulos <[EMAIL PROTECTED]>: Ilia, you can find the relevant code here: http://www.eecs.umich.edu/~anastas/gnuradio/ looking forward to your comments. Achilleas Have you tried profiling the code? This would allow you to definitively determine what the culprits are. From a quick glance you aren't doing anything *blatantly* wrong (i.e. you're passing vectors around by cref, which is good). However, from a performance perspective, vector<> isn't really what you want to use in this case. You're just dealing with basic types, e.g. float/int/etc -- they don't have weird constructors/destructors, and thus have to do a lot more work. Also, when you do vector x; x[0] = 5; keep in mind that internally it instantiates a new int object, and then calls operator= on it. The compiler might optimize this to a certain extent, but certainly not to the level of simplicity of a single memory access/write. Note that the gnuradio interface for, e.g. (general_)work uses these primitive pointers (i.e. a vector<> of simple arrays). There doesn't really seem to be a good reason for you to be using vector<> in your code... (Do correct me if I'm wrong...) -Ilia Ilia Mirkin wrote: Would you care to share your C++ implementation (e.g. post a link) so that it might be critiqued rather than say things like "C++ is slower than C"? -Ilia Quoting Achilleas Anastasopoulos <[EMAIL PROTECTED]>: I have some new data on this. Going from ANSI-C to C++ (NO Gnuradio) using STL vectors results in a 5-fold speed reduction! So Gnuradio seems to be responsible for the remaining 4-fold reduction (for an overall 20-fold as I reported earlier). I am OK with Gnuradio resulting in this 4-fold speed reduction, but I cannot swallow the fact that STL sucks that bad :-( !!! I believe that this is not specific to my application, but should be true for any algorithm that uses vectors/matrices. I wonder if anyone can corroborate this. Achilleas Robert W McGwier wrote: Yes. I was comparing Phil Karn's native code to it and it runs at least 20 times faster. Bob Achilleas Anastasopoulos wrote: I have noticed a huge speed dissadvantage when comparing my ANSI-C implementation of a Viterbi decoder with my Gnuradio implementation. The core code is pretty much the same, except that in the Gnuradio implementation I am using STL vectors. It seems that Gnuradio is about 20 times SLOWER than ANSI-C!!! I was wondering if this has to do with Gnuradio itself (buffering + python + other fat), or with the fact that I had to translate all my ANCI-C code to C++ and use STL. Does anyone have similar experiences? Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- ___ Achilleas Anastasopoulos Associate Professor EECS Department Voice : (734)615-4024 UNIVERSITY OF MICHIGANFax : (734)763-8041 Ann Arbor, MI 48109-2122 E-mail: [EMAIL PROTECTED] URL: http://www-personal.engin.umich.edu/~anastas/ ___ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ANCI-C vs Gnuradio/C++ speeeed
Ilia, you can find the relevant code here: http://www.eecs.umich.edu/~anastas/gnuradio/ looking forward to your comments. Achilleas Ilia Mirkin wrote: Would you care to share your C++ implementation (e.g. post a link) so that it might be critiqued rather than say things like "C++ is slower than C"? -Ilia Quoting Achilleas Anastasopoulos <[EMAIL PROTECTED]>: I have some new data on this. Going from ANSI-C to C++ (NO Gnuradio) using STL vectors results in a 5-fold speed reduction! So Gnuradio seems to be responsible for the remaining 4-fold reduction (for an overall 20-fold as I reported earlier). I am OK with Gnuradio resulting in this 4-fold speed reduction, but I cannot swallow the fact that STL sucks that bad :-( !!! I believe that this is not specific to my application, but should be true for any algorithm that uses vectors/matrices. I wonder if anyone can corroborate this. Achilleas Robert W McGwier wrote: Yes. I was comparing Phil Karn's native code to it and it runs at least 20 times faster. Bob Achilleas Anastasopoulos wrote: I have noticed a huge speed dissadvantage when comparing my ANSI-C implementation of a Viterbi decoder with my Gnuradio implementation. The core code is pretty much the same, except that in the Gnuradio implementation I am using STL vectors. It seems that Gnuradio is about 20 times SLOWER than ANSI-C!!! I was wondering if this has to do with Gnuradio itself (buffering + python + other fat), or with the fact that I had to translate all my ANCI-C code to C++ and use STL. Does anyone have similar experiences? Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- ___ Achilleas Anastasopoulos Associate Professor EECS Department Voice : (734)615-4024 UNIVERSITY OF MICHIGANFax : (734)763-8041 Ann Arbor, MI 48109-2122 E-mail: [EMAIL PROTECTED] URL: http://www-personal.engin.umich.edu/~anastas/ ___ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ANCI-C vs Gnuradio/C++ speeeed
Would you care to share your C++ implementation (e.g. post a link) so that it might be critiqued rather than say things like "C++ is slower than C"? -Ilia Quoting Achilleas Anastasopoulos <[EMAIL PROTECTED]>: I have some new data on this. Going from ANSI-C to C++ (NO Gnuradio) using STL vectors results in a 5-fold speed reduction! So Gnuradio seems to be responsible for the remaining 4-fold reduction (for an overall 20-fold as I reported earlier). I am OK with Gnuradio resulting in this 4-fold speed reduction, but I cannot swallow the fact that STL sucks that bad :-( !!! I believe that this is not specific to my application, but should be true for any algorithm that uses vectors/matrices. I wonder if anyone can corroborate this. Achilleas Robert W McGwier wrote: Yes. I was comparing Phil Karn's native code to it and it runs at least 20 times faster. Bob Achilleas Anastasopoulos wrote: I have noticed a huge speed dissadvantage when comparing my ANSI-C implementation of a Viterbi decoder with my Gnuradio implementation. The core code is pretty much the same, except that in the Gnuradio implementation I am using STL vectors. It seems that Gnuradio is about 20 times SLOWER than ANSI-C!!! I was wondering if this has to do with Gnuradio itself (buffering + python + other fat), or with the fact that I had to translate all my ANCI-C code to C++ and use STL. Does anyone have similar experiences? Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ANCI-C vs Gnuradio/C++ speeeed
I have some new data on this. Going from ANSI-C to C++ (NO Gnuradio) using STL vectors results in a 5-fold speed reduction! So Gnuradio seems to be responsible for the remaining 4-fold reduction (for an overall 20-fold as I reported earlier). I am OK with Gnuradio resulting in this 4-fold speed reduction, but I cannot swallow the fact that STL sucks that bad :-( !!! I believe that this is not specific to my application, but should be true for any algorithm that uses vectors/matrices. I wonder if anyone can corroborate this. Achilleas Robert W McGwier wrote: Yes. I was comparing Phil Karn's native code to it and it runs at least 20 times faster. Bob Achilleas Anastasopoulos wrote: I have noticed a huge speed dissadvantage when comparing my ANSI-C implementation of a Viterbi decoder with my Gnuradio implementation. The core code is pretty much the same, except that in the Gnuradio implementation I am using STL vectors. It seems that Gnuradio is about 20 times SLOWER than ANSI-C!!! I was wondering if this has to do with Gnuradio itself (buffering + python + other fat), or with the fact that I had to translate all my ANCI-C code to C++ and use STL. Does anyone have similar experiences? Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ANCI-C vs Gnuradio/C++ speeeed
Bob, let me be 100% sure of what you are saying: the comparison you are referring to was between Phil Karn's native code in ANSI-C and Phil Karn's native code ported in Gnuradio ? Thanks Achilleas Robert W McGwier wrote: Yes. I was comparing Phil Karn's native code to it and it runs at least 20 times faster. Bob Achilleas Anastasopoulos wrote: I have noticed a huge speed dissadvantage when comparing my ANSI-C implementation of a Viterbi decoder with my Gnuradio implementation. The core code is pretty much the same, except that in the Gnuradio implementation I am using STL vectors. It seems that Gnuradio is about 20 times SLOWER than ANSI-C!!! I was wondering if this has to do with Gnuradio itself (buffering + python + other fat), or with the fact that I had to translate all my ANCI-C code to C++ and use STL. Does anyone have similar experiences? Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- ___ Achilleas Anastasopoulos Associate Professor EECS Department Voice : (734)615-4024 UNIVERSITY OF MICHIGANFax : (734)763-8041 Ann Arbor, MI 48109-2122 E-mail: [EMAIL PROTECTED] URL: http://www-personal.engin.umich.edu/~anastas/ ___ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] ANCI-C vs Gnuradio/C++ speeeed
I have noticed a huge speed dissadvantage when comparing my ANSI-C implementation of a Viterbi decoder with my Gnuradio implementation. The core code is pretty much the same, except that in the Gnuradio implementation I am using STL vectors. It seems that Gnuradio is about 20 times SLOWER than ANSI-C!!! I was wondering if this has to do with Gnuradio itself (buffering + python + other fat), or with the fact that I had to translate all my ANCI-C code to C++ and use STL. Does anyone have similar experiences? Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
