Eric Blossom wrote:
<soapbox-mode>
You know, I wish you guys would quit screwing around with the 0.9
code, and instead help us *all* move forward by investing some time
in porting it to 2.x. The framework is already set up, and the
first 4 blocks have been ported and tested. I'd really like some
people to step up and finish it off. It's in CVS under gr-atsc.
We've also got *much* faster filtering algorithms in 2.x. We might
even be able to get it running in real time on a dual processor
machine. Today's machines are a lot faster than when we first wrote it.
</soapbox-mode>
Roughly every 18 months, available CPU speed doubles. Which means that
using todays
machines, if you can just-barely-not-quite do real time now, in 18
months you'll be able to,
on a machine that costs you roughly what your current machine cost
you. Single-CPU
Moores law *is* slowing down some, but multi-core appears to be making
great
strides.
My astronomy apps are pigs. But I can do useful stuff with them. On my
single-processor
2.6Ghz Celeron D, I can manage 2Mhz of combined total-power and
spectral observations. On
Lamars Dual-CPU Xeon, he's able to do 8Mhz using the same code.
My pulsar application can run at roughly 1Mhz bandwidth on my single-CPU
2.6Ghz Celeron D, and
we haven't tested it on Lamars Dual Xeon system yet. When the
de-dispersion filters get longer,
that 1Mhz will be pushing it on a single-CPU system.
I'm having a hard time believing that processing ATSC video is a *less*
CPU-intensive application than
pulsar processing, but I could be completely wrong.
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
