944143 - flushDenormalFloatToZero is a no-op in ZeroPole::process - affects perf with DynamicsCompressorNode

Status: RESOLVED FIXED

(Core :: Web Audio, defect, P1)

Description

[Karl Tomlinson (:karlt)]

From bug 939491 comment 11:

If HAVE_DENORMAL is defined, then flushDenormalFloatToZero() is a no-op on
x86(_64) because it is assumed that a DenormalDisabler exists while this
code is run.  No such object is instantiated in Gecko.

Flushing subnormal audio sample values to zero is sensible, but making the
hardware flush subnormals to zero for all arithmetic may cause unexpected
results, such as divide-by-zero due to permitting a - b = 0 when a != b.

Comment 1

[(no longer active)]

Aha, that answers my question in bug 939491 :-)

Comment 2

[Maire Reavy [:mreavy]]

Karl -- How much does this bug affect perf? (This bug's priority is currently a P2. I wonder if it should be higher.)

Comment 3

[Karl Tomlinson (:karlt)]

ZeroPole is used in DynamicsCompressorNode.
The symptoms would be considerably worse performance when processing silence, but only when the graph doesn't know that it is processing silence.  DynamicsCompressorNode skips processing when it knows the input is silence.

Subnormals are something we need to watch out for when looking at performance profiles.  They can slow arithmetic by a factor of 50 or so.

I didn't think this needed to be P1 because we should normally know when we are processing silence.  However I see now that a WaveShaperNode upstream would mean that DynamicsCompressorNode doesn't know when it is processing silence.  If we fix bug 949680, then this bug shouldn't be a problem, but this bug should be easy to fix, so I'm tentatively changing to P1.

See also bug 949683.

Comment 4

[Karl Tomlinson (:karlt)]

Attachment: gnuc/x86(_64) patch for detecting subnormals in the debugger

This sets up status and control registers to generate SIGFPE on underflow and on subnormal operands on each AudioNodeStream::ProduceOutput call.

The SIGFPE handler restarts the instruction with the underflow or denormal operand mask re-enabled, so only the first underflow and first subnormal use per engine/stream/block will trigger a call to the handler.  (Disassembly of the instruction would be required to substitute different values and continue with the handler enabled.)

Placing a break point in the handler finds such situations.  Sometimes these are one-off exceptions, and sometimes, as in ZeroPole, the subnormals lead to more subnormals.

http://software.intel.com/en-us/articles/x87-and-sse-floating-point-assists-in-ia-32-flush-to-zero-ftz-and-denormals-are-zero-daz

Comment 5

[Karl Tomlinson (:karlt)]

Attachment: avoid producing infinite stream of subnormals in ZeroPole tail

This reduces MSG CPU usage by almost 2% on Demo 3 of http://webaudiodemos.appspot.com/MIDIDrums/index.html

Performance with this patch is not detectably different (on Demo 3) from setting DAZ and FTZ in MXCSR for the MSG thread.

Comment 6

[Karl Tomlinson (:karlt)]

Attachment: avoid producing infinite stream of subnormals in ZeroPole tail v1.1

Adjust headers, and use fabsf for float parameters.

Note that ZeroPole uses single precision even where Biquad uses double precision.
Single precision is enough here because ZeroPole is used only in DynamicsCompressorNode where only high cutoff frequencies are used.  (Low cutoff frequencies could cause instabilities.)

Comment 7

[Karl Tomlinson (:karlt)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/353967ff6f4f

Comment 8

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/353967ff6f4f