Re: [Discuss-gnuradio] *much* faster filtering

[Eric Blossom]

On Tue, May 10, 2005 at 11:49:30PM -0400, Chen-Mou Cheng wrote:
> That's awesome! :)
> 
> BTW while I was reading the following comments in gr_fir_fff_simd.cc 
> 
>   // Round input data address down to 16 byte boundary
>   // NB: depending on the alignment of input[], memory
>   // before input[] will be accessed. The contents don't matter since
>   // they'll be multiplied by zero coefficients. I can't conceive of any
>   // situation where this could cause a segfault since memory protection
>   // in the x86 machines is done on much larger boundaries.
> 
> You probably won't get segfaults; on the other hand you may not get
> correct answers either-- if one or more memory locations preceding
> input[] happen to be infinity (you'll get a nan, not-a-number, if you
> multiply zero and infinity).  We suspect we have encountered such a
> situation because the nan stuff went away after we switched to
> gr_fir_fff_generic.cc

Interesting.  I had the same thought when I was reviewing the code a
day ago.  I was burned not too long ago with some NaNs while
interpreting an executable file as single-float...  (Don't try this at home.)

If you really think you ran into this problem, it would be great to be
able to reproduce it.  In our normal situation (buffers containing
streams of floats) I don't think there's a case where we should
reference something that wasn't a valid float.  I could be wrong...

Eric