bbouvier at mozilla.com
Fri Jul 4 08:19:32 PDT 2014
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:
 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)
 Set FTZ in loops surrounding SIMD code.
 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.
Do you have any other better ideas or opinions about these?
Could this be brought up to the next TC39 meeting?
On 06/24/2014 04:20 PM, Stéphane Letz wrote:
> We have ported our audio C++ code (audio nodes generated using the Faust audio DSP language : http://faust.grame.fr) as JS nodes in the Web Audio API using emscripten. We get very high CPU load on Intel processors, as soon at the computation produced denormal floats numbers.
> When the same code runs in a C++ context, we typically solve the problem by adding "flush denormal to zero" kind of macro before the audio computation, since audio code can perfectly live without following strict IEEE754 compatibility. This is a very common solution that is used everywhere when developing native audio code.
> The problem has been seen on all recent browsers we tested : Firefox, Chrome and WebKit on OSX. It can be tested on the following page with contains a physical model of a piano string, compiled in asm.js using emscripten, and run as a Web Audio API ScriptProcessorNode. If you hit the "gate" button a sound is played. After some seconds when the notes become idle again, the CPU load raises to 100% (seen in activity monitor on OSX).
> We started a bug report on Firefox which causes a lot of feedback: https://bugzilla.mozilla.org/show_bug.cgi?id=1027624
> Best Regards
> Stéphane Letz
> es-discuss mailing list
> es-discuss at mozilla.org
More information about the es-discuss