- 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-users@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-users mailing list Faudiostream-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/faudiostream-users
