discuss-gnuradio
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]