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.
Or is this more like the idea of combining FAUST with another language
like pure?
Victor
On 10 Dec 2010, at 12:28, Stéphane Letz wrote:
Well what could be interesting to share would be something similar
to the "FIR" (Faust Intermediate Language) that we are currently
designing and implementing.
Basically Faust currently does :
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.
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:
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.
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).
3) Work Stealing Scheduler : the loops DAG is compiled with an
"embedded" WSS algorithm (and each loop can possibly be auto-
vectorized).
2) and 3) steps are typically expressed as "FIR to FIR"
transformations.
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.
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 :-
Stéphane
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev