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/ ------------------------------------------------------------------------------ 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
