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
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
_
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
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 Anastasopoul
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 ./t
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.
>
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 overal
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 implementa
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
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 {
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
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 () c
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
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
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 o
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::v
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.
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 t
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 vecto
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
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
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
22 matches
Mail list logo
