Float denormal issue in JavaScript processor node in Web Audio API

Allen Wirfs-Brock allen at wirfs-brock.com
Wed Jul 9 10:21:20 PDT 2014

On Jul 4, 2014, at 8:19 AM, Benjamin Bouvier wrote:

> Hi,
> I would like to emphasize this topic, as it actually matters a lot in
> signal processing in general. When one is applying operations like
> filters, feedback loops and so on, one isn't interested in very low
> values, as they can't be perceived by the eyes or the ears anyways.
> Ideally, we would define zones of code in which we run with the FTZ
> (flush to zero) processor flag applied, making it clear we're not
> following IEEE754 arithmetic anymore. A few ideas have been already
> thrown in the bug:
> [1] A function annotation "use flush_denormals_to_zero"
> - Math.flushDenormalToZero(v) (returns 0 if v is denormal, otherwise v)
> - flush-to-zero versions of JS SIMD intrinsics (or just make the
> intrinsics flush-to-zero by default)

Based upon various other conversations, it appears to me that a the "Math.flushDenormalToZero" function is the most feasible of the various alternatives. 
Perhaps called: Math.denormz  (thanks to dherman for the name)

Code generators like Emscripten could wrap math operators with it, much as it current does with Math.fround.  Manually you would code things like:
   Math.denormz(small / big)
if you want to ensure a zero result.

It's also been suggested we may want a function that is equivalent to Math.denormz(Math.fround(x)).  Perhaps:
  Math.fdzround  (name also due to dherman)

The other alternatives that expose the FTZ flag in various ways seem very undesirable from an overall language perspective. If a language like JS is going to have control of this sort of mode then it really needs to be lexically scoped in some manner. And it probably needs to be part of the state that is captured by closures.  Overall that seems like a very expensive feature for a limited use case.

> [2] Set FTZ in loops surrounding SIMD code.
> [3] Have a wrapper function withFTZ(f), where f is another function,
> such that we set FTZ, we call f() and then we unset FTZ at the end. This
> method sounds easy to optimize in the JITs and avoids the issue of
> interleaving code using FTZ with code that doesn't.
> Out of the wild, I am wondering whether having a FTZ flag on a Realm
> could have all operations executed within this realm use flushing
> denormals arithmetic. That is just a (maybe crazy) idea and I am not
> sure this fits in the Realms scope.

Realms aren't the equivalent of processes or even threads, they aren't a container of an execution context.  A flag like this would probably have to be associated with each function and would have to be saved/restored across each call/return/unwind.  This would be a significant change to the runtime behavior.  Hard to justify for a limited use case.

> Do you have any other better ideas or opinions about these?
> Could this be brought up to the next TC39 meeting?

I've added to the July meeting agenda.

> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1027624#c13
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1027624#c17
> [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1027624#c30

More information about the es-discuss mailing list