Re: [Faudiostream-users] Regalia-Mitra filter bank in FAUST

Orlarey Yann Thu, 09 May 2013 13:47:46 -0700

Hi,

I pushed some modifications (master branch only for the moment) that speeds up the propagation phase. Now it is negligible, For example for rmfbd_syn.dsp we now have :

rmfbd_syn.dsp
==============
parser (duration : 0.01706)
evaluation (duration : 52.0515)
propagation (duration : 0.564698)
compilation (duration : 0.050071)

real    0m52.706s
user    0m51.975s
sys    0m0.727s

instead of :

rmfbd_syn.dsp
==============
parser (duration : 0.017298)
evaluation (duration : 56.7303)
propagation (duration : 596.579)
compilation (duration : 0.0540679)


real    10m53.404s
user    10m52.247s
sys    0m1.091s

There is also a new option : -time, to obtain timing information for the various compilation phases.

Cheers

Yann

Le 09/05/13 21:31, Marc Joliet a écrit :

Am Thu, 09 May 2013 12:18:34 +0200
schrieb Orlarey Yann <[email protected]>:

Hi Marc,

Hi,

Thanks for your email and welcome to the mailing list. I still have to play with your programs, but I am impressed by your code considering you just started using Faust, congratulation !

Well, shucks :) .

I suppose reading many of the papers and the documentation, watching all of the
LAC videos and reading through the standard library helped ;) .

I did some compilation benchmark of your code using faust1 on a macbook air. The compilation is decomposed in 4 phases :
- parsing
- evaluation : translates the algorithmically described block-diagram into a big flat block-diagram in normal form
- propagation : propagates symbolic signals into the block-diagram in order to discover how each output signal is expressed
- compilation : translates output signal expressions into C++ code


Here is what I get :

mbstereophony.dsp
=================
parser (duration : 0.0188298)
evaluation (duration : 60.66)
propagation (duration : 20.5604)
compilation (duration : 0.170211)

real    1m21.447s
user    1m20.855s
sys    0m0.576s


rmfbd_sum.dsp
==============
parser (duration : 0.02108)
evaluation (duration : 26.707)
propagation (duration : 152.806)
compilation (duration : 0.0284498)

real    2m59.700s
user    2m59.090s
sys    0m0.467s


rmfbd_syn.dsp
==============
parser (duration : 0.017298)
evaluation (duration : 56.7303)
propagation (duration : 596.579)
compilation (duration : 0.0540679)

real    10m53.404s
user    10m52.247s
sys    0m1.091s


rmfbs_sum.dsp
==============
parser (duration : 0.020314)
evaluation (duration : 8.90142)
propagation (duration : 4.13869)
compilation (duration : 0.048768)

real    0m13.181s
user    0m12.987s
sys    0m0.134s


rmfbs_syn.dsp
==============
parser (duration : 0.019501)
evaluation (duration : 21.5213)
propagation (duration : 8.68882)
compilation (duration : 0.090451)

real    0m30.341s
user    0m30.071s
sys    0m0.264s

Clearly rmfbd_syn.dsp was very slow to compile : 11mn  essentially spent in the propagation phase !

Yes, rmfbd_syn was what I was writing about. Of course I forgot to mention that
I was using -vec, with which I got one hour compilation time. My experience is
that using -vec (and auto-vectorisable code in general) really does make a
difference in run-time performance, so I don't even bother with scalar code by
default.

Also, how do you get those numbers above?

But you can accelerate the compilation time by changing the way you declare the UI to

freq_slider(i) = hgroup("Filterbank edge frequencies", vslider("Freq. %j [unit:Hz]", fdef(i),fmin(i),fmax(i),1)) with {
        j=i+1;
        fmin(i) = take(i+1,freq_minima);
        fmax(i) = take(i+1,freq_maxima);
        fdef(i) = take(i+1,freq_defaults);
        };

freqs = par(i,N,freq_slider(i));

With this modification I was able to get better timings for the same resulting C++ code :

parser (duration : 0.017338)
evaluation (duration : 29.548)
propagation (duration : 133.139)
compilation (duration : 0.051075)

real    2m42.789s
user    2m42.201s
sys    0m0.535s


Let me know if that improves the situation on your side...

Yes! I thought the inputs might be the problem after the "-vec and multiple
control inputs" thread (and also because I get the feeling that "selector" in
general is quite expensive to compile), but didn't see how to simplify it. Of
course, now it looks totally obvious :) .

Anyway, after making the changes to rmfbd_{syn,sum}.dsp, the total compile time
(via "scons -j2 all CXX=clang++") on my system (with -vec) went down to about
15 minutes :) .

This also made it feasible to add frequency sliders to mbstereophony, even if
it still takes about 40 minutes to compile with -vec :) . Therefore, as with
rmfb*, I added four mbstereophony* variants. Of course, that shot the compile
time for all 8 programs up to about an hour, but I'm still happy about the
results :) .

Cheers

Yann

Thanks a lot

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may

_______________________________________________
Faudiostream-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may

_______________________________________________
Faudiostream-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] Regalia-Mitra filter bank in FAUST

Reply via email to