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
