64 bit vs 32 bit

GNU Radio
1

Hello Everyone,

I am new to GNUradio.  I have a CPU that is capable of running 64bit

GNU/Linux distributions but have not installed it yet on the machine
that I am using GNUradio yet. I heard that 32bit v. 64bit makes a
difference with the newest python interpreters. Is this the case? Is
there a significant performance boost when running GNUradio apps in 64
bit mode?

2

Manaen Schlabach wrote:

that I am using GNUradio yet. I heard that 32bit v. 64bit makes a
difference with the newest python interpreters. Is this the case? Is

Hi,

I am running 32 and 64 bit versions of ubuntu on my Dell M90. On the 64
bit version, the USRP is not seen with an error similar to “Unable to
find USRP#0”. I did not investigate further. I am confident I properly
setup gnuradio/USRP/udevrules/permissions because I just went through
the process on the 32 bit version.

Chris

3

On Sat, Aug 04, 2007 at 09:49:15AM -0400, Manaen Schlabach wrote:

Hello Everyone,

I am new to GNUradio. I have a CPU that is capable of running 64bit
GNU/Linux distributions but have not installed it yet on the machine
that I am using GNUradio yet. I heard that 32bit v. 64bit makes a
difference with the newest python interpreters. Is this the case? Is
there a significant performance boost when running GNUradio apps in 64
bit mode?

The performance is better under 64-bit.

Eric

4

Eric B. wrote:

The performance is better under 64-bit.

Eric

I was afraid of that. It looks like I will be reinstalling my distro :slight_smile:

Thanks,
Manaen

5

I just loaded 64 bit Ubuntu on my new supercomputer (Core 2 Quad
Extreme) but I have not tried the usrp yet to see if it is found. When
you plug in the usrp, have you looked at the enumeration with some tool
like usbview (available with apt-get or synaptic)?

Bob

Chris S. wrote:

find USRP#0". I did not investigate further. I am confident I properly
setup gnuradio/USRP/udevrules/permissions because I just went through
the process on the 32 bit version.

Chris

–
AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL,
TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair
“If you’re going to be crazy, you have to get paid for it or
else you’re going to be locked up.” Hunter S. Thompson

6

On Mon, Aug 06, 2007 at 10:38:58AM +0930, Daniel O’Connor wrote:

On Mon, 6 Aug 2007, Manaen Schlabach wrote:

I was afraid of that. It looks like I will be reinstalling my distro
:slight_smile:

It would probably be a fairly marginal difference though…
(Right? I haven’t done any tests…)

Twice as many registers available for the compiler in 64-bit mode.
This makes a big difference, since the X86 architecture is register
starved.

Eric

7

On Mon, 6 Aug 2007, Manaen Schlabach wrote:

I was afraid of that. It looks like I will be reinstalling my distro
:slight_smile:

It would probably be a fairly marginal difference though…
(Right? I haven’t done any tests…)

8

Daniel O’Connor wrote:

(ie I am wondering if anyone has done a comparison)

My Gnuradio block which does processing in 64 bit doubles runs nearly
twice as fast under 64 bit ubuntu over 32 bit ubuntu. Hardly a good
comparison though since your blocks probably don’t do the same thing.

Chris

9

Hello,

Please help me. I’m having a lot of trouble understanding the make
files to
build gnuradio and the makefiles I use to build my own gnuradio blocks.
Also, swig hates me and I hate it. So far I’ve had no trouble building
gnuradio and building my own blocks by delicately modifying an example
build
tree, but now I want to do something a little different.

I want the python code to make an instance of the usrp1.source_c object
and
pass it into C++ by calling this function:
void run_radio( usrp1_source_c_sptr usrp );

I added this function and it’s definition to one of my cc files and
added
the declaration to the swig i file for my blocks, and everything builds
properly.

In the python I create the usrp object with:
adc = usrp.source_c(0,250, fpga_filename=“std_4rx_0tx.rbf”)

then later call the new function with:
sm.run_radio( adc._u )

When python executes the last line it throws an exception:
“TypeError: in method ‘run_radio’, argument 1 of type
‘usrp1_source_sptr’”

My question is, what type should the parameter be in the run_radio
function?
How do I get swig to correctly marshal this smart pointer back to c++?

Thanks for the help,
Hans

10

On Mon, 6 Aug 2007, Eric B. wrote:

It would probably be a fairly marginal difference though…
(Right? I haven’t done any tests…)

Twice as many registers available for the compiler in 64-bit mode.
This makes a big difference, since the X86 architecture is register
starved.

Yes, I am aware there are architectural improvements but theory doesn’t
always hold :slight_smile:

(ie I am wondering if anyone has done a comparison)

11

On Mon, Aug 06, 2007 at 12:13:51PM -0700, Hans G. wrote:

void run_radio( usrp1_source_c_sptr usrp );

I added this function and it’s definition to one of my cc files and added
the declaration to the swig i file for my blocks, and everything builds
properly.

In the python I create the usrp object with:
adc = usrp.source_c(0,250, fpga_filename=“std_4rx_0tx.rbf”)

then later call the new function with:
sm.run_radio( adc._u )

When python executes the last line it throws an exception:
“TypeError: in method ‘run_radio’, argument 1 of type ‘usrp1_source_sptr’”

My question is, what type should the parameter be in the run_radio
function? How do I get swig to correctly marshal this smart pointer back to
c++?

I think it should be:

usrp1_source_c_sptr

I think your sm.i file will need to:

%import “usrp1.i” // N.B., not %include

to pick up the right types.

There’s a chance you’ll have to add the following three lines in
front of the %import, but I’m not sure off the top of my head.

%{
#include “usrp1_source_c.h”
%}

Thanks for the help,
Hans

You’re welcome!

Eric

12

On Tue, 7 Aug 2007, Chris S. wrote:

Daniel O’Connor wrote:

(ie I am wondering if anyone has done a comparison)

My Gnuradio block which does processing in 64 bit doubles runs nearly
twice as fast under 64 bit ubuntu over 32 bit ubuntu. Hardly a good
comparison though since your blocks probably don’t do the same thing.

Probably not, but interesting nontheless! :slight_smile:

13

c++?

I think it should be:

usrp1_source_c_sptr

yes, you’re right. I made a typo in the email.

#include “usrp1_source_c.h”
%}

Hi,

OK, I made those changes and then did a build. I got a compile error
stating “Error: Unable to find ‘usrp_spi_defs.h’”

This is one of those points where I have troubles with the make files.
How
do I change the make files so the compiler finds the h file in a
directory
under a different source tree? Isn’t top_srcdir different when I’m
building
my blocks as opposed to building gnuradio?

Also, how can I make my block library link with the library that
contains
the stuff in usrp1_source_c.cc? I tried adding “-lusrp1” and “-l_usrp1”
to
the _sm_la_LIBADD, but neither worked.

Thanks for your help,
Hans

14

On Tue, 7 Aug 2007, Hans G. wrote:

Please help me. I’m having a lot of trouble understanding the make
files to build gnuradio and the makefiles I use to build my own
gnuradio blocks. Also, swig hates me and I hate it. So far I’ve had
no trouble building gnuradio and building my own blocks by delicately
modifying an example build tree, but now I want to do something a
little different.

Please don’t just follow up to a random thread and change the subject to
something completely different…

If you don’t then it will look like you’re replying to the old thread
(assuming your mail reader actually groks threading) and that can be
most confusing…