Re: [Discuss-gnuradio] Weired GNURADIO Performance

[Andrew Lutomirski]

On Sat, May 2, 2009 at 10:15 AM, Firas A. <address@hidden> wrote:
>
> Hi,
>
> Today was a day-mare  for me. I had to reformat/install gnuradio on my PC 3
> times in few hours.
>
> The story begins when I tried to upgrade my nice working Ubuntu 8.10 OS to
> the new 9.04 on my old 3.0GHz C2D system (2G RAM). I had an application
> which needs much CPU performance. The application is doing a streaming 1024
> point FFT with 25MSps on USRP2. The application was consuming about 50% from
> my CPU (both). That was with Ubuntu 8.10 32 bit + python 2.5 + original
> USRP2 firmware ( I think 9936) + gnuradio 10368.
>
> When 9.04 came, I wanted to upgrade my system and even I came with an idea
> to use the 64 bit version with my C2D system. So I reformatted/installed
> Ubuntu 9.04  64 bit + python 2.6 + installed latest USRP2 firmware (10766) +
> gnuradio 10945. Every thing was OK.
>
> The surprise was when I started my same application, but its now consuming
> about 90% from my CPU!!!. I shocked. I couldn't figure out what was the
> problem because I changed many variables at a time.
>
> To debug the problem, I reformatted/installed Ubuntu 9.04 32 bit + python
> 2.6 + same USRP2 firmware (10766) + gnuradio 10945. This time the CPU
> utilization was 75%. So may be this is a bad OS + GNURadio interaction.
>
> To be sure, I reformatted/installed back the Ubuntu 8.10 32 bit + python 2.5
> + USRP2 firmware (10766) + gnuradio 10945. When checked with the same
> application, my CPU utilization was back to 50% and I'm very happy now.
>
> I thought sharing it may be useful to gnuradio developers.
>
> Any suggestions/speculations ????

I can speculate: some versions of Ubuntu (i.e. all the ones I've
actually looked at) seem to build fftw *without* SSE/SSE2.  I'm using
a copy that I built myself.  (This is 64-bit.  I don't know whether
the 32-bit versions have the same problem.  I'm also running on Ubuntu
8.10, which does not explain what you're seeing.)

You could try rebuilding FFTW from source to see if it has any effect.

I've attached a little test program that demonstrates the difference nicely:

Build like this:
$ g++ -lfftw3 -lrt -O2 -o fftw_bench fftw_bench.cc

Test like this.  Adjust as appropriate for your system.  1024 is the FFT length.
$ ./fftw_bench 1024  # This uses my custom FFTW in /usr/local/lib
Done planning
Took 943574ns, which is 1.08524e+08 samples per second
1753.33 MFLOPS
11.5938 adds 3.5625 muls 1 fmas
27782Mbps
5426.18MFLOPS (canonical)
(dft-ct-dit/32
  (dftw-direct-32/124 "t2fv_32")
  (dft-direct-32-x32 "n2fv_32"))

$ LD_LIBRARY_PATH=/usr/lib ./fftw_bench 1024  # This uses Ubuntu's copy
Done planning
Took 1493072ns, which is 6.85834e+07 samples per second
2074.65 MFLOPS
21.125 adds 5.125 muls 4 fmas
17557.4Mbps
3429.17MFLOPS (canonical)
(dft-ct-dit/16
  (dftw-direct-16/30 "t1_16")
  (dft-direct-64-x16 "n1_64"))

Some day I'll get around to filing a bug report with Ubuntu/Debian (I
should figure out whos bug it is first).

--Andy

fftw_bench.cc
Description: Binary data