[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Memory oinking
From: |
Eric Blossom |
Subject: |
Re: [Discuss-gnuradio] Memory oinking |
Date: |
Thu, 29 Jan 2009 11:02:54 -0800 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
On Thu, Jan 29, 2009 at 10:33:06AM -0500, Marcus D. Leech wrote:
> I have a simple flow-graph,
>
> A USRP, single channel, and a large FFT block, followed by a "vector to
> stream", and a file-output block.
>
> The FFT is 8M points, which for complex float samples, give something
> like a 64M memory footprint.
Sounds right.
In the naive interface to FFTW we're using, I'm allocating
additional input and output buffers for another 128M. I think I can
get rid of that.
> But I'm finding that the virtual size of the resulting process is
> 4.5GB!, with an RSS of about 2.3G.
That's big!
> This seems larger than you'd expect, by a fairly large factor!
>
> For comparison, I have a C program that processes the samples created by
> the Gnu Radio "front end",
> which has:
>
> 120 8M buffers (unsigned char)
> 2 x 8M buffers (float)
>
> The virtual size of this process is only about 1G, with a similar RSS
> (it touches those buffers very
> regularly!).
>
> It seems to me that there only needs to be perhaps a couple of buffers
> per block inside Gnu Radio,
> which at worst gives you something like 8 complex buffers (about 64M
> per buffer for complex float)
> in my flow-graph. Why the massive hugeness in memory footprint?
Not sure. Can you post a link to the code (or the code if it's small)
and I'll take a look at it.
> Now, I'll agree that memory is *cheap* these days, but scaling my
> application is going to be limited
> by what Gnu Radio is capable of, rather than my back-end C program.
Eric