What is probably possible in the WebAssembly context would be to compile and use this fastapprox library in wasm.
The thing is that the documentation is quite inexistant..., and looking at the API I see for instance for cos : « fastcos », « fastercos » « fastcosfull » « fastercosfull » ===> how are we supposed to choose which one to use ? Stéphane > Le 23 sept. 2017 à 09:42, Stéphane Letz <l...@grame.fr> a écrit : > > - yes pow is slow, but we still have to understand why this filterBank.dsp is > so slower in the wasm context... > > - that for this « fastapprox » reference. I guess one way to switch between > the standard math functions to specific ones would be to have a kind of « > function mapping file » described somewhere that the compiler would use with > a special -approx parameter or something. > > Stéphane > >> Le 22 sept. 2017 à 18:49, Julius Smith <j...@ccrma.stanford.edu> a écrit : >> >> Ah, yes, pow is definitely way slow. For occurrences in the inner >> loop (audio rate), I've taken to using the foreign function fastpow2() >> from fastapprox-0.3.2.tar.gz by Paul Mineiro (this might also be the >> one Kjetil Matheussen uses, who alerted me to the idea). It >> sacrifices precision for speed, so if the Faust compiler is to use it, >> maybe there should be a new fastpow() primitive, and/or a compiler >> switch that says to use it wherever applicable at the audio sampling >> rate. This was critical for getting GeoShred running on the iPad 2 >> without dropouts! >> >> - Julius >> >> On Fri, Sep 22, 2017 at 12:21 AM, Stéphane Letz <l...@grame.fr> wrote: >>> Thanks Julius for the feedback. Several things: >>> >>> - it appears that this "5 times slower » case for filterBank.dsp is a bit >>> of a « pathological one » : since 1) Chrome which is usually the best is >>> significantly slower in this example, I don’t know why… 2) filterBank.dsp >>> uses a lot of pow (10, x) that the C++ backend path rewrites (and I guess >>> optimize as...) as exp10(x) which probably explains the « C++ is better >>> than LLVM IR which does not do this rewriting ». I will add this remark in >>> the post… And doing this pow (10, x) ==> exp10(x) rewrite rule is probably >>> easy to add in the Faust compiler >>> >>> - I’m currently only testing the Faust internal wasm backend. I should also >>> benchmark the Faust ==> C++ ==> Emscripten ==> wasm path, to see if the >>> Emscripten C++ ==> wasm path is better and by how much compared to our own >>> Faust internal wasm backend. >>> >>> - I think we should avoid to go for a "use native primitives » strategy... >>> >>> - so I’m trying to get feedback from a french Mozilla developer, who works >>> in the compiler part. I hope he will give me some insights... >>> >>> Stéphane >>> >>> >>>> Le 22 sept. 2017 à 00:36, Julius Smith <j...@ccrma.stanford.edu> a écrit : >>>> >>>> Hi Stéphane, >>>> >>>> Thanks for the interesting and informative report! It appears that >>>> the big differentiator in performance is small audio feedback loops, >>>> such as used in filterbank. If this is the case, then the simple >>>> one-pole filter, "pole(p) = + ~ *(p);" should show substantially the >>>> same performance differentials as filterbank. The question then >>>> becomes whether the compiler can make use of native primitives for >>>> optimizing such constructs. One approach might be to write alternate >>>> source employing foreign functions using things like Web Audio's >>>> BiquadFilterNode (for example). It would be ideal if such primitives >>>> could be substituted by the Faust compiler, given the appropriate >>>> option(s). >>>> >>>> - Julius >>>> >>>> On Thu, Sep 21, 2017 at 1:50 AM, Stéphane Letz <l...@grame.fr> wrote: >>>>> Hi All, >>>>> >>>>> Based on WebAssembly code generated from the wasm backend. >>>>> >>>>> Extensive testing in different situations, compiled in the post here: >>>>> http://faust.grame.fr/news/2017/09/15/backend-benchmarks.html >>>>> >>>>> Stéphane >>>>> ------------------------------------------------------------------------------ >>>>> Check out the vibrant tech community on one of the world's most >>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>>>> _______________________________________________ >>>>> Faudiostream-users mailing list >>>>> faudiostream-us...@lists.sourceforge.net >>>>> https://lists.sourceforge.net/lists/listinfo/faudiostream-users >>>> >>>> >>>> >>>> -- >>>> Julius O. Smith III <j...@ccrma.stanford.edu> >>>> Professor of Music and, by courtesy, Electrical Engineering >>>> CCRMA, Stanford University >>>> http://ccrma.stanford.edu/~jos/ >>> >>> >>> >> >> >> >> -- >> Julius O. Smith III <j...@ccrma.stanford.edu> >> Professor of Music and, by courtesy, Electrical Engineering >> CCRMA, Stanford University >> http://ccrma.stanford.edu/~jos/ > ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Faudiostream-devel mailing list Faudiostream-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/faudiostream-devel
