filter: firdes functions can return denormal or near denormal numbers

[jacobagilbert]

This can result in substantial performance impact.

Consider the following:

>>> filter.firdes.gaussian(1,16,3,21)
(3.2424925425704807e-40, 2.1742435751068437e-32, ... , 2.1742435751068437e-32, 3.2424925425704807e-40, 0.0)
>>> filter.firdes.gaussian(1,16,2,21)
(1.3652488831168542e-18, 4.107945469791589e-15, ... , 1.3652488831168542e-18, 1.863411258255796e-22)

The first results in a filter with two denormal filter coefficients, the impact of which is extreme. In the following flowgraph on my particular system:

Using normal taps results in a throughput of ~32 MS/s
Using the first set of taps with two denormal values results in a throughput of ~ 8.8 MS/s
Using a set of taps which are all denormal results in a throughput of ~2.2 MS/s

This is a contrived example of a real world issue I faced on two different hardware platforms due to a single denormal tap returned by firdes cutting throughput in half.

Even near-denormal taps can cause issues as they can produce denormal output which is also a performance problem.

GR cannot save users completely from themselves, but it should probably not return denormal values from tap generators. Other recommendations from chat.gnuradio are to use compiler flags to set the FTZ and DAZ flags.

[jacobagilbert]

Note: using the -ffast-math complier flag (as suggested by @noc0lour) does resolve this, however it seems like this does more than just enable the DAZ and FTZ flags.

[noc0lour]

For avoiding this issue in real time systems we could add a build option to set the correct flags (not fastmath). Maybe coercing taps from (almost) denormal to 0 in filter design function is a good idea.

[marcusmueller]

should consider using a better implementation of a Gaussian shape in firdes. For now, this persists. (it's really not hard to write a better Gaussian generator, we can calculate an acceptable cutoff by the area under the curve we're losing when setting small coefficients to zero)