Hi,
I want to use the C++ classes for FFTW that are present in gnuradio for
a
non-gnuradio application. How do I link the gnuradio library to such an
application?
Thanks
On 08/16/2011 11:00 PM, Marcus M wrote:
If you just want the FFTW library, it’s already available from C++
directly–you don’t have to go
through the Gnu Radio library to get it.
Actually I wanted to profile some classes that I wrote for my gnuradio
application. In these classes I use gr_complex and the gri_fftw class.
As I
do not know how to use gprof in a gnuradio application I thought I will
use
the classes outside of gnuradio to run the profile tests. So that’s why
I
want to link the gr_complex and gri_fftw in the test application.
On Wed, Aug 17, 2011 at 5:08 AM, Marcus M [email protected] wrote:
Actually I wanted to profile some classes that I wrote for my gnuradio
application. In these classes I use gr_complex and the gri_fftw class. As I
do not know how to use gprof in a gnuradio application I thought I will use
the classes outside of gnuradio to run the profile tests. So that’s why I
want to link the gr_complex and gri_fftw in the test application.
Hi Marcus,
Both are in the gnuradio-core package and you can use pkg-config to
get the appropriate flags:
pkg-config --libs gnuradio-core
You can use the above directly in the linker command by surrounding it
with back-quotes(?)
pkg-config --libs gnuradio-core
Alex
@Alexander, thanks for your reply, it worked like a charm.
On Wed, Aug 17, 2011 at 8:48 AM, Marcus M. [email protected]
wrote:
Hi Marcus M (cool name, actually),
By the way: You’ll be benchmarking FFTW (float implementation) complex2real
fft, why would you want
to use it wrapped in gri_fft? Using FFTW is -after all- three lines of
code, using the benchmarking
functions one line more.
I actually wanted to test my gnuradio block that performs acquisition of
DSSS signals. As I am not sure how gprof works in gnuradio I thought i
will
use the same classes that I used for my block and test the block using a
test code outside of gnuradio while retaining everything ‘gnuradio’ in
it. I
didn’t want to change the code as I suspect that may result in
performance
difference.
I use gri_fft in my block so that I can have the block resemble native
gnuradio code. I will use fftw and if it improves performance then I
will
use that instead of the gri_fft wrapper.
Thanks everybody.
On Wed, Aug 17, 2011 at 4:31 PM, Marcus M [email protected] wrote:
I actually wanted to test my gnuradio block that performs acquisition of
DSSS signals. As I am not sure how gprof works in gnuradio I thought i will
use the same classes that I used for my block and test the block using a
test code outside of gnuradio while retaining everything ‘gnuradio’ in it. I
didn’t want to change the code as I suspect that may result in performance
difference.
Just FYI, in GNU Radio, it’s probably easier to learn and use OProfile
than gprof (I actually think that’s true in general, but you
specifically don’t want to recompile GNU Radio just to work with
grpof).
You can use KCachegrind as a GUI interface to reports produced by
OProfile, which can give you some interesting visuals on the
performance.
Tom
Hi Marcus M (cool name, actually),
gr_complex is an STL complex, so you won’t need the complete GR
core to use it:
gnuradio-core/src/lib/runtime/gr_complex.h:typedef
std::complex gr_complex;
gri_fft requires only gr_complex (see above) and gr_sys_paths, which is
essentially replaceable by
string literals. (and boost filesystem&threads and fftw of course, but
those are not part of GR)
By the way: You’ll be benchmarking FFTW (float implementation)
complex2real fft, why would you want
to use it wrapped in gri_fft? Using FFTW is -after all- three lines of
code, using the benchmarking
functions one line more.
Hope this was helpful,
greetings
Marcus M.
Am 17.08.2011 13:03, schrieb Alexandru C.: