On Mon, 2015-05-18 at 12:01 -0400, discuss-gnuradio-requ...@gnu.org
wrote:
> Message: 4
> Date: Mon, 18 May 2015 09:52:26 +0200
> From: Marcus M?ller <marcus.muel...@ettus.com>
> To: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] Which blocks do you like?
[snip]
> >
> > std::vector<float> corr_mag(noutput_items);
> > int i = d_sps;
> > while(i < noutput_items) {
> > if((corr_mag[i] - corr_mag[i-d_sps]) > d_thresh) {
> > while(corr_mag[i] < corr_mag[i+1])
> > i++;
> >
> > is not possible that the variable i will go outside the
> > array corr_mag?I know that is necessary a strange pattern in order to
> > have the last item greater than the previous..
> >
> I agree, relying on the signal to limit execution of this loop feels a
> bit "dangerous", but I also agree that as long as your "known symbol"
> has a sane shape, this won't be a problem. The problem is that this is
> indeed a bit of a CPU-hungry bit of code, so every additional condition
> might slow things down; I think it should be possible to come up with a
> nearly-as-effective implementation that is more secure, but I can't
> think of one right now. Any hints? [1]
> At any rate, the outer `while` shouldn't run till `noutput_items`, but
> till `noutput_items - 1`, because of the inner `while(corr_mag[i] <
> corr_mag[i+1])`. Thanks for spotting that!If you don't mind, I'd like to
> ask you to fix that line
> (`while(i<noutput_items)`->`while(i<noutput_items-1)`)and submit a pull
> request on github [2] (if possible, base it off the "maint" branch).
Hi Marcus and Marco,
The corr_est block fixes this bug, and a few others, that the original
correlate_and_sync block has. The corr_est block should perform
reliably, whereas the correlate_and_sync block does not, due to bugs.
They are different blocks because the corr_est block has different input
arguments, to handle more general cases.
If you wish to spend time optimizing the performance of a block, I'd
recommend you optimize the corr_est block, not the correlate_and_sync
block. Optimally doing something unreliably is still doing something
unreliably. :)
Regards,
Andy
> Best regards,
> Marcus
>
> [1] Hard to properly optimize; intuitively, it's not clear whether a
> highly optimized "precompute the complete
> corr_mag[0:end-d_sps]-corr_mag[d_sps:end] and
> sign(corr_mag[:end-1]-corr_mag[1:end])" would be faster than selectively
> only computing the relevant parts (like this branching-intense algorithm
> does) on a CPU. Pretty sure that on CUDA, you'd just precompute the
> whole arrays.
> [2]
> https://gnuradio.org/redmine/projects/gnuradio/wiki/Development#How-can-I-use-github-to-submit-patchesfeatureschanges
> On 05/17/2015 10:58 PM, marco Ribero wrote:
[snip]
> > While I was reading the code,a question arise about this code(
> > method work in cc implementation):
> >
> > while(i < noutput_items) {
> > if((corr_mag[i] - corr_mag[i-d_sps]) > d_thresh) {
> > while(corr_mag[i] < corr_mag[i+1])
> > i++;
> >
> > is not possible that the variable i will go outside the
> > array corr_mag?I know that is necessary a strange pattern in order to
> > have the last item greater than the previous..
> >
> > Greetings,
> > marco ribero
> >
> >
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
