<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>This is all very interesting. One question I had regarding the future development of FAUST is whether it will include some sort of scheduler so that various faust-coded objects can be instantiated at different times, connected together in series, etc.. Then an interpreter could be developed with JIT compilation etc. </div><div><br></div><div>Or is this more like the idea of combining FAUST with another language like pure?</div><div><br></div>Victor<br><div><div>On 10 Dec 2010, at 12:28, Stéphane Letz wrote:</div><blockquote type="cite"><div><blockquote type="cite"><font class="Apple-style-span" color="#000000"><br></font></blockquote><br>Well what could be interesting to share would be something similar to the "FIR" (Faust Intermediate Language) that we are currently designing and implementing. <br><br>Basically Faust currently does :<br><br>Faust dsp program ==> [BDA (Block Diagram Algebra) evaluation ] ==> Signals ==> FIR loops DAG (Direct Acyclic Graph) ==> C/C++, JAVA, LLVM, (possibly CUDA, OpenCL at some point) backends.<br><br>FIR is a imperative like language where a Faust program is represented as a data structure + list of functions (init, buildInterface, compute...). The "compute" function does the actual DSP computation and is currently executing the DSP loops DAG in different modes:<br><br>1) vector mode : the loops DAG is simply topologically sorted and compiled in the target language (C/C++, LLVM...). The we hope GCC or ICC auto-vectorization features can do the job to produce SIMD code.<br><br>2) OpenMP mode: OpenMP pragmas are inserted at the right place in the DAG to express parallelism (and each loop can possibly be auto-vectorized).<br><br>3) Work Stealing Scheduler : the loops DAG is compiled with an "embedded" WSS algorithm (and each loop can possibly be auto-vectorized).<br><br>2) and 3) steps are typically expressed as "FIR to FIR" transformations. <br><br>It could be possible to let other tools enter the chain before the "FIR loops DAG" step so that to take benefit of all the later steps : FIR to FIR parallelisation, and all available backends. We can even imagine to implement some kind of "inter plug-in" optimizations at the FIR level.<br><br>But of course the simplest way to produce this "FIR loops DAG" is... using Faust itself, and "inter plug-in" optimizations are way simpler to handle at the Faust level (basically at the "signal step") . So I don't know if the idea makes sense, but you never know :-><br><br>Stéphane <br><br><br><br>_______________________________________________<br>Linux-audio-dev mailing list<br><a href="mailto:Linux-audio-dev@lists.linuxaudio.org">Linux-audio-dev@lists.linuxaudio.org</a><br>http://lists.linuxaudio.org/listinfo/linux-audio-dev<br></div></blockquote></div><br></body></html>